![[OpenBSD]](../images/smalltitle.gif){kind=small}
[FAQ Index] [To Section 12 - Hardware and Platform-Specific Questions] [To Section 14 - Disk Setup]
All supported audio drivers are already included in the GENERIC kernel so there is no need for extra configuration or installation of drivers. To find out about options for your specific sound chip, you must find out which sound chip you have. Supported chips may be found on the hardware compatibility page for your platform. When you already have OpenBSD running, look for a sound driver in the output of the dmesg(8) command, and read its manual page to find more specific information like options and other details about the driver. An example of an audio chip in a dmesg output is:
auich0 at pci0 dev 31 function 5 "Intel 82801BA AC97" rev 0x04: irq 10, ICH2 AC97 ac97: codec id 0x41445360 (Analog Devices AD1885) ac97: codec features headphone, Analog Devices Phat Stereo audio0 at auich0
OpenBSD base provides two tools for monitoring and configuring audio devices. audioctl(1) is used for the audio processing parameters, such as encoding, sample rate and number of channels, while mixerctl(1) is used for the mixing parameters, such as channel source, gain level and mute.
The following command uses audioctl(1) to display the default processing parameters of an audio device.
Note that -f /dev/audio was used explicitly. Opening /dev/audio causes the audio device to reset to the default parameters, which is what we wanted to see.$ audioctl -f /dev/audio ...
audioctl(1) is also quite useful for exploring the capabilities of an audio device. For example, to see if the device supports some common sample rates, you could simply try setting the playback rate:
This device supports 48000 and 44100 Hz playback rates, but not 22050 or 8000. Note that if a sample rate is not supported, there is not always an error message, but the returned sample rate is not the one that was desired.$ audioctl play.rate=48000 play.rate: -> 48000 $ audioctl play.rate=44100 play.rate: -> 44100 $ audioctl play.rate=22050 audioctl: set failed: Invalid argument $ audioctl play.rate=8000 audioctl: set failed: Invalid argument $
This device supports 48000 Hz playback only.$ audioctl play.rate=48000 play.rate: -> 48000 $ audioctl play.rate=44100 play.rate: -> 48000 $ audioctl play.rate=22050 play.rate: -> 48000 $ audioctl play.rate=8000 play.rate: -> 48000 $
Audio hardware is usually capable of at least some minimal mixing. Running mixerctl(1) with no arguments will list the device's mixer controls and current settings.
Some devices have only a handful of controls, some have a hundred or more. Note that not every option of every audio chip necessarily reaches the outside world. So there may be, for example, more outputs listed than are physically available on a sound card or motherboard.$ mixerctl ...
There are a few controls that are common to many devices:
Some devices use what is known as EAPD, which stands for external amplifier power down. However, this is just another on/off switch. It is probably refered to as "power down" because it is often used for power saving, which means this type of control is more often found in laptops. Sometimes it is necessary to set controls with eapd or extamp in their name to on to get an output signal.
As a basic example of common mixerctl usage, to set the volume of the left and right channels to 200, you would issue
Notice how the value becomes 207. The reason for this is that this audio device has an AC'97 codec, which uses only 5 bits for volume control, leading to only 32 possible values. Other hardware could have different resolution.$ mixerctl outputs.master=200,200 outputs.master: 255,255 -> 207,207
To unmute the master channel, you would do
$ mixerctl outputs.master.mute=off outputs.master.mute: on -> off
To make the changes take affect on each reboot, edit /etc/mixerctl.conf, for example:
$ cat /etc/mixerctl.conf outputs.master=200,200 outputs.master.mute=off outputs.headphones=160,160 outputs.headphones.mute=off
OpenBSD comes with aucat(1), a program for recording and playing uncompressed audio. The following example will play a WAV file.
aucat(1) supports both headerless and WAV audio files with the -i option. aucat also plays Sun audio files where the audio data is encoded as 8 kHz monaural mulaw, which is the most common encoding for this type of audio file.$ aucat -i filename.wav
It is also possible to play uncompressed audio data by passing it directly to the audio device. To do this, you need to know its main parameters: encoding type, number of channels, sample rate, bits per sample. If you don't know this, you might find out with the file(1) utility:
$ file music.au music.au: Sun/NeXT audio data: 16-bit linear PCM, stereo, 44100 Hz
The only remaining things to know about these example files is that they use little-endian byte ordering and signed linear quantization. You could figure this out by reading the header with hexdump(1). If you are using a headerless (raw) file, there is no way to know the parameters beforehand. Set the following parameters accordingly using audioctl(1).$ file music.wav music.wav: Microsoft RIFF, WAVE audio data, 16 bit, stereo 44100 Hz
Next, pass the audio file to the sound device:play.encoding=slinear_le play.rate=44100 play.channels=2 play.precision=16
If you applied the correct settings, you should be hearing what you expected.$ cat music.au > /dev/sound
Note: Always use /dev/sound, not /dev/audio, if you want the settings you applied with audioctl to stay in place.
There are, of course, other utilities you can use to play these files. Such as XMMS which is available in packages and ports and can play numerous other audio formats.
Apart from the above, there are audio formats which use lossless data compression. Examples are the Free Lossless Audio Codec (FLAC) and TTA. The FLAC implementation has been ported to OpenBSD and may be found under audio/flac in packages and ports.
A good example is the free, open and unpatented Ogg Vorbis format. To play Ogg Vorbis files, you can use the ogg123 utility, which is bundled in the audio/vorbis-tools package. For example:
Of course, Ogg Vorbis plugins exist for many other audio software.$ ogg123 music.ogg Audio Device: Sun audio driver output Playing: music.ogg Ogg Vorbis stream: 2 channel, 44100 Hz Time: 00:02.95 [02:21.45] of 02:24.40 (133.1 kbps) Output Buffer 87.5%
Another example is the very popular MPEG-1 Audio Layer 3 (MP3) encoding, which has, however, its share of licensing and patent issues. Many tools can play MP3 files, just have a look through the audio section of the packages and ports system and pick one you like.
How about the proprietary Windows Media Audio (WMA) format? Files of this type can be played using x11/mplayer which uses the FFmpeg framework.
A good starting point to learn more about different audio file formats is this Wikipedia article: Audio file formats.
$ timidity file.mid
The easiest way to play your favorite MOD files on OpenBSD is probably to use the XMMS software, available through packages and ports. You should install the -mikmod subpackage for XMMS to let it use the MikMod sound library, which supports the MOD, S3M, IT and XM module formats.
You will also find a number of so-called "trackers" in the audio section of the packages and ports collection, e.g. tracker, soundtracker. With these trackers you can not only play but also generate your own modules. Note, however, that not every tracker format is supported by the tools in the ports tree. You are always welcome to submit a port of your favorite tracker software.
To play an audio CD using the analog output of your CD-ROM drive, you can
A nice command line utility called cdio(1), has been included in the base system. Called without parameters, it will enter interactive mode. If you want to play the CD right away, just enter
$ cdio play
This will play from the first CD-ROM drive, cd0, by default. Note that the user running cdio should have permissions to read the CD-ROM device (e.g. /dev/rcd0c). As this device is only readable by root or the operator group by default, for convenience you may want to add the user to the operator group by adjusting this group's line in /etc/group. Alternatively, you can modify the file permissions of the device as needed.
Note that you may need to unmute the CD input of the mixer. Just like the outputs, the actual name of this input may vary between systems, but you will be using a command like:
It is also possible that there is no analog audio connection between your CD drive and audio device. In this case you could use cdio's cdplay command to send the CD audio data to the sound card through the PCI bus.$ mixerctl inputs.cd.mute=off
$ cdio cdplay
If you prefer a beautiful GUI, there are plenty of X11-based CD players in the packages and ports collection. Just have a look in the audio section.
The above command will start the recording of a file in WAV format. Press [CTRL]-C to finish the recording. The file will contain signed 16-bit stereo samples, sampled at 48kHz. Other sample formats, sample rates and number of channels can be recorded. See the manual for more details.$ aucat -o file.wav
Use aucat to play the file back:
$ aucat -i file.wav
If recording seemed to work, but playback of the recording was silent or not what was expected, the mixer probably needs some configuration. Make sure that you select the right device to record from and that the source is unmuted. You can set the necessary parameters using mixerctl(1). For example:
These are settings for recording from a microphone. Pre-amplifying has been enabled, otherwise the recorded sound can be pretty silent on some systems. However, pre-amplifying can also be quite loud on other systems.inputs.mic.mute=off inputs.mic.preamp=on inputs.mic.source=mic0 record.source=mic record.volume=255,255 record.volume.mute=off record.mic=255 record.mic.mute=off
The sndiod(1) daemon is an intermediate layer between audio or MIDI programs and the hardware. It performs the necessary audio processing to allow any program to work on any supported hardware. It exposes at least one sub-device that any number of audio programs can connect to and use as if it were audio hardware. During playback, sndiod receives audio data concurrently from all programs, mixes it and sends the result to the hardware device. Similarly, during recording it duplicates audio data recorded from the device and sends it to all programs.
By default, it accepts connections from programs running on the same system only; it initializes only when programs are using its services, thus, consuming a negligible amount of system resources. Systems with no audio hardware can use sndiod to keep hot-pluggable devices usable by default at virtually no cost.
If applications you use are compatible with your hardware and you don't plan to run multiple applications concurrently, then you don't strictly need an audio server. Since OpenBSD 5.1, sndiod(1) is started by default at boot time. There is no more reason to disable sndiod(1) on a system with no audio hardware than there is to disable getty(8) on a headless system.
Note that sndiod can be bypassed by using rsnd/0 as audio device instead of the default one.
sndiod(1) imposes a minimum latency on all audio applications, and the default latency is 160ms. If you plan to use applications that require a lower latency, use the ``-b'' option to select the desired latency (expressed in number of frames). For instance, at 48000 samples/second, 50ms latency corresponds to:
48000 samples/second x 0.050 seconds = 2400 samplesthen add:
sndiod_flags="-b2400"to /etc/rc.conf.local.
sndiod_flags="-L-"to /etc/rc.conf.local. On the local system, configure your program to use:
snd@hostname/0where ``hostname'' is the address of the remote system. The AUDIODEVICE environment variable could be set to the above value to make the remote sound card the default audio device.
Note that any system able to connect to TCP port 11025 of the remote host, will be able to use the audio device. For privacy reasons only one user from one system may have connections to it at a given time. If multiple systems have to use the audio device simultaneously, the sndio(7) authorization cookie must be the same. For instance, copy your ~/.aucat_cookie to all accounts that may use the audio device.
To avoid glitches, TCP traffic on port 11025 could be prioritized with the packet filter. With the default configuration sndiod will consume around 200kB/s of network bandwidth.
If you do not hear anything when playing audio, it's possible there is a mixer control turned to low or simply muted. See section 13.1 - How do I configure my audio device for configuring the mixer. Please unmute all inputs and outputs before reporting a problem.
If sound is distorted, it could be that your sound card only supports a single or limited set of sample rates or encodings. See section 13.1 - How do I configure my audio device for examples of determining what parameters your audio device supports.
If your device only supports unusual encodings or only one or a few sample rates and applications you use do not perform the necessary format conversions, consider using aucat(1) as audio server. See section 13.5 - How do I setup an audio server?
If you are still experiencing trouble, here are some things to consider:
If you believe your device should be working, but for whatever reason isn't, then it's time for a little debugging. The following steps can determine if data is being processed by the DAC.
$ cat > /dev/audio < /dev/zero &
[1] 9926
$ audioctl play.{seek,samples,errors}
play.seek=48000
play.samples=3312000
play.errors=0
$ audioctl play.{seek,samples,errors}
play.seek=57600
play.samples=7065600
play.errors=0
$ audioctl play.{seek,samples,errors}
play.seek=48000
play.samples=9379200
play.errors=0
$ kill %1
$ fg %1
cat > /dev/audio < /dev/zero
Terminated
Note that even if you had speakers plugged in when running the above test, you should not have heard anything. The test sends zeros to the device, which is silence for all currently supported default encodings.
Since we know the device can process data, it's a good idea to check the mixer settings again. Make sure all outputs and all inputs are unmuted and are at a reasonable level.
If at this point you are still having problems, it's probably time to file a bug report. Besides the normal bug report information such as a full dmesg and description of the problem, please also include the default output of mixerctl -v and the output of the above test for DAC processing.
To play MIDI data, a synthesizer connected to a MIDI port of the machine is required. Similarly, to record a MIDI data a MIDI instrument is required (eg. a MIDI keyboard). Certain sound cards contain embedded MIDI synthesizers that are attached as MIDI ports. Advanced MIDI instruments may contain multiple subparts (synthesizers, keyboards, control surfaces, etc...), they appear as multiple MIDI ports on OpenBSD.
When you already have OpenBSD running, look for MIDI ports in the output of the dmesg(8) command. An example of MIDI ports in a dmesg output is:
It shows three MIDI ports, corresponding to:umidi0 at uhub2 port 2 configuration 1 interface 0 "Roland Roland XV-2020" rev 1.10/1.00 addr 2 midi0 at umidi0: <USB MIDI I/F> umidi1 at uhub1 port 2 configuration 1 interface 1 "Evolution Electronics Ltd. USB Keystation 61es" rev 1.00/1.25 addr 3 midi1 at umidi1: <USB MIDI I/F>
The output of the keyboard can be connected to the input of the synthesizer, as follows:$ aucat -Mq rmidi/1 -o - | hexdump -e '1/1 "%02x\n"' 90 3c 71 ...
Now you can hear on the synthesizer what you're playing on the MIDI keyboard. Refer to the aucat(1) manual page for further information.$ aucat -M -q rmidi/0 -q rmidi/1
The main utility to play standard MIDI files is midiplay(1). Playing a standard MIDI file, in this example through the synthesizer, is as easy as:
$ midiplay -f rmidi/0 file.mid
To record MIDI files, you can use the smfrec utility bundled in the audio/midish port, for instance:
will record what is played on the keyboard (rmidi/1) while sending it in real-time on the synthesizer (rmidi/0) so you can hear what you're playing. More complicated operations like editing, routing, mixing and transforming MIDI data, can be achieved using the rmidish utility bundled in the audio/midish port.$ smfrec -d rmidi/0 -i rmidi/1 file.mid
Say you have a number of WAV files ready to encode, for example your favorite album you just extracted from its CD. To encode all these files using an approximate bit rate of 192 kbps, you could issue a command like
When finished, this will give you a set of .ogg files in the current directory. More extensive examples, as well as encoding options, can be found in the oggenc manual page.$ oggenc *.wav -b 192
Below is a simple example of encoding a WAV file with a bit rate of 192 kbps:
For all options and details, please consult the manual page that comes with lame.$ lame -b 192 track01.wav track01.mp3
As most computers with DVD-ROM drives use software decoding, it is recommended to have at least a 350-MHz Pentium II or equivalent CPU to have good quality playback.
Some popular media players, supporting DVD playback, have been ported to OpenBSD. Examples are ogle, mplayer, xine, and kaffeine. Please read the installation instructions that come with these packages, because these tools may need further setup. With these utilities, it is possible to playback the DVD by directly accessing the raw device. Of course, it is also possible to mount a DVD first using mount_cd9660(8), and play the files on this or any other mounted filesystem.
Notes:
cd0 at scsibus0 targ 0 lun 0: <TOSHIBA, CD-ROM XM-5702B, 2826> SCSI0 5/cdrom removable cd1 at scsibus1 targ 4 lun 0: <PLEXTOR, CD-R PX-R412C, 1.04> SCSI2 5/cdrom removable
In what follows, we will mostly be accessing the CD/DVD writer through the raw character device, not the block device.# cd /dev # ./MAKEDEV cd2
Try to use it by mounting an existing CD/DVD in it. If desired, you could also check the transfer rate you are getting when copying files to your hard disk. The time(1) command will be your willing assistant.cd2 at scsibus2 targ 1 lun 0: <LITE-ON, DVDRW LDW-851S, GS0C> SCSI0 5/cdrom removable
If something goes wrong here and you are getting errors during this phase, it is wise to fix the problem and not to start writing a CD/DVD yet.
As an example usage, let's say I wanted to store the OpenBSD kernel sources in an ISO 9660 image:
$ mkhybrid -R -o sys.iso /usr/src/sys Using ALTQ_RMC.000;1 for /usr/src/sys/altq/altq_rmclass_debug.h (altq_rmclass.h) ... Using IEEE8021.00H;1 for /usr/src/sys/net80211/ieee80211_amrr.c (ieee80211.c) 10.89% done, estimate finish Sat Nov 3 08:01:23 2007 21.78% done, estimate finish Sat Nov 3 08:01:28 2007 ... 87.12% done, estimate finish Sat Nov 3 08:01:31 2007 98.01% done, estimate finish Sat Nov 3 08:01:32 2007 Total translation table size: 0 Total rockridge attributes bytes: 896209 Total directory bytes: 2586624 Path table size(bytes): 11886 Max brk space used 0 45919 extents written (89 Mb)
The -R option tells mkhybrid to create Rock Ridge extensions in the ISO 9660 image. The Rock Ridge Interchange Protocol was created to support POSIX filesystem semantics in ISO 9660 filesystems, such as longer file names, ownerships, permissions, file links, soft links, device nodes, deep file hierarchies (more than 8 levels of subdirectories), etc.
If you want the long file names on your CD-ROM to be readable on Windows or DOS systems, you should add the -J flag to include Joliet extensions in the ISO 9660 image as well.
After creating the filesystem, you can verify it by mounting the ISO 9660 image. If all is well, you are now ready to burn the CD-R(W). The easiest way to do this is to use the cdio(1) utility.
If you are using multi-write media such as CD-RW, you will need to blank the media before burning it.
You are now ready to burn the image created in the above example to a blank CD-R(W). You could use a command similar to:# cdio -f cd1c blank
With the options specified above, we're asking cdio to use the second CD-ROM device as the CD writer.# cdio -f cd1c tao sys.iso
To verify whether the CD-ROM has been written correctly, you can mount it and check whether everything is there. To mount the filesystem, you should use the block device for the CD-ROM drive, which in this case is still the CD writer:
# mount /dev/cd1c /mnt/cdrom
As an example, I'll be making a backup copy of one of my music CDs. This involves two steps:
This command will extract a series of WAV files from your second CD-ROM drive to your disk.# cdio -f cd1c cdrip
# cdio -f cd1c tao -a *.wav
Important notes:
A pretty different format is DVD-RAM, which was mainly developed as a data drive and has advanced packet writing functions, allowing it to be used like a kind of optical hard disk. DVD-RAM is not recommended for video usage as video gets written to the discs in a format not compatible with normal DVD players.
The important thing is you use media which suit your DVD writer. If you expect compatibility with other DVD players, watch your step and be sure to read this section of the DVD FAQ.
| DVD read/write speed | Transfer rate (MB/s) | Equivalent CD-R(W) read/write speed |
| 1x | 1.32 | 9x |
| 2x | 2.64 | 18x |
| 4x | 5.28 | 36x |
| 8x | 10.57 | 72x |
As can been seen from the table, the transfer rates are relatively high, and you should check whether your bus (SCSI, IDE/ATAPI, SATA, USB) is performant enough to handle this throughput. Especially the older USB 1.0 and 1.1 interfaces work at slower transfer rates, with maximal rates of 1.5 Mbit/s and 12 Mbit/s, respectively. That means USB 1.0 has a maximal throughput of 178.8 kByte/s and USB 1.1 has a maximal throughput of 1.43 MB/s. USB 2.0 is much faster: 480 Mbit/s or 57.2 MB/s. In general, the speed of SCSI, SATA, and IDE/ATAPI buses should be just fine.
In case you want to find out more info about the media in your DVD writer (for example if you lost the info label in the jewel case or are just disorganized like me), you can use the dvd+rw-mediainfo utility. There are two options to write the DVD:
I created a pre-mastered ISO 9660 image from the OpenBSD CVS modules (src, xenocara, ports and www) contained in the /cvs directory on my disk. I used the following command, which looks very similar to the one I used to create the CD-ROM image above.
If desired, check the ISO 9660 filesystem by mounting the image. To write this image (about 2 GB) to an empty DVD disc, one could use:$ mkhybrid -r -o cvs.iso /cvs
The -Z option tells growisofs to burn an initial session to the device, which in this case is my DVD writer, attached to cd2. The -dvd-compat option closes the disk, which means no more sessions can be appended to it. This should provide better compatibility with video DVD players and some older DVD-ROM units.# growisofs -dvd-compat -Z /dev/rcd2c=cvs.iso Executing 'builtin_dd if=cvs.iso of=/dev/rcd2c obs=32k seek=0' /dev/rcd2c: pre-formatting blank DVD+RW... /dev/rcd2c: "Current Write Speed" is 4.1x1385KBps. 23822336/1545832448 ( 1.5%) @3.9x, remaining 5:19 42172416/1545832448 ( 2.7%) @3.9x, remaining 5:20 60522496/1545832448 ( 3.9%) @3.9x, remaining 4:54 ... 1504706560/1545832448 (97.3%) @3.9x, remaining 0:07 1523318784/1545832448 (98.5%) @3.9x, remaining 0:04 1541898240/1545832448 (99.7%) @3.9x, remaining 0:00 /dev/rcd2c: flushing cache /dev/rcd2c: writing lead-out /dev/rcd2c: reloading tray
Notice how growisofs indicates the writing speed, in this case 3.9x DVD speed, which is what could be expected from the media and writer combination, as indicated by dvd+rw-mediainfo.
If you are short on disk space and cannot store an ISO 9660 image for a DVD, you can write your data directly to the DVD. Let's first do a dry run, which simulates the creation of the filesystem.
If this succeeds, just leave out the -dry-run option and start burning the DVD.# growisofs -dry-run -Z /dev/rcd2c -R /cvs
# growisofs -Z /dev/rcd2c -R /cvs
It is also possible to append data to an existing DVD, by using the -M option, which merges a new session to an existing one:
For more information about growisofs, refer to the manual page.# growisofs -M /dev/rcd2c -R /mydata
When you have finished writing the DVD, mount it and see whether everything you expected to be there, is indeed there.
which is much slower. It means you are somehow not getting enough throughput on whatever bus your DVD writer is using. In the above example, the USB DVD writer was attached to a machine on which the ehci(4) driver, used by USB 2.0 controllers, failed to initialize properly. As always, you are welcome to provide patches and test results. The DVD writer fell back to the slower USB 1.1 interface, which causes reduced throughput. Indeed, USB 1.1 is limited to 12 Mbit/s, which amounts to 1.43 MB/s or 1.08x in DVD speed terms. The DVD writer falls back to a lower pace than the maximum, to reduce the risk of buffer underruns.4784128/1545832448 ( 0.3%) @0.7x, remaining 26:50 7929856/1545832448 ( 0.5%) @0.7x, remaining 29:05 14123008/1545832448 ( 0.9%) @0.7x, remaining 27:06 ...
One sound conversion tool is audio/sox, available through packages and ports. sox supports AIFF, AU, MP3, Ogg Vorbis, RIFF WAV and raw formats, as well as some of the more exotic audio formats out there. Below is an example for converting the recording to RIFF WAV format.
Note that the specified parameters correspond to the recording parameters specified before the recording. This was just an example. More audio-related libraries and software can be used for audio conversion.$ sox -U -c 1 -r 8000 -b myvoice.raw myvoice.wav
Note: It is not recommended to convert between different lossy compression formats. For instance, the MP3 and Vorbis codecs throw away different parts of an original audio waveform. Therefore, when converting a MP3 file to Ogg Vorbis, the end result will probably sound worse than the original MP3.
Two popular utilities are multimedia/transcode and mencoder (part of x11/mplayer). They use or can use the libavcodec library as part of the graphics/ffmpeg port, which generates good quality output. You can, of course, also use ffmpeg directly. It should also be possible to use the XviD encoder in multimedia/xvidcore.
The documentation that comes with these packages, under the form of manual pages or HTML documents in /usr/local/share/doc, contains many examples, so it is HIGHLY recommended to read those documents.
This is not meant to be a complete, overly detailed answer to have every possible streaming format work on any hardware architecture. You may want to learn more about streaming media to start with. A slightly dated but still good starting point is this chapter about streaming media from the O'Reilly book titled Designing Web Audio.
The first thing to understand is that there are a number of different streaming protocols around. The streaming protocol defines how the streams will be sent over the network. They have been developed to allow efficient transmission of audio/video over the internet in real-time. Mostly, the streaming protocol is a (Layer 7) application protocol, which can use either UDP or TCP (Layer 4) transport protocols. The User Datagram Protocol (UDP) is very suited for this type of application since it doesn't do any retransmission of packets or other overhead. A number of specialized but proprietary protocols have been developed, e.g. Microsoft Media Services (MMS) and the Real Time Streaming Protocol (RTSP). As we will see, HTTP (which uses TCP) is sometimes used as well, even though it does not allow serving streams at a steady bitrate like UDP, RTSP and MMS.
Next, there is the streaming format, which is how the audio/video data has been organized and can be played. The most widely used streaming formats are MP3, Real Audio (RA, RM) and Windows Media (ASF), all proprietary technologies. Occasionally you will also encounter streams in the open Ogg Vorbis format.
As an example, I'll explain in a few steps how I get to listen to Radio 1, one of the Belgian national radio stations. Browser-embedded plugins are not available on OpenBSD, so the story is usually not an instant "click and play".
It looks like I can even choose between low, medium and high quality streams. Other websites may contain some JavaScript code to generate the URL. In that case, the best tip is: dig up the HTML source and scripts it refers to. There is a good chance you can reconstruct the URL from it.$ ftp http://internetradio.vrt.be/dab/hoeluisteren/pc/help/gebruiksvoorwaarden/stream_11.m3U $ cat stream_11.m3U http://mp3.streampower.be/radio1-mid.mp3 http://mp3.streampower.be/radio1-low.mp3 http://mp3.streampower.be/radio1-high.mp3
$ mplayer -loop 0 http://mp3.streampower.be/radio1-mid.mp3
alias radio1='mplayer -loop 0 http://mp3.streampower.be/radio1-mid.mp3'
Upon installation, instructions are displayed for using the Java plugin with the Firefox or Seamonkey web browser. Create the symlink as explained, and then you should see the Java plugin upon entering "about:plugins" in the URL bar.
For KDE's Konqueror web browser, either the java binary must be in your PATH, or its absolute path can be configured from the menu Settings -> Configure Konqueror -> Java & JavaScript. By default, the java binary is located in /usr/local/jre-version/bin/ or /usr/local/jdk-version/bin/, depending on whether you installed the JRE or the JDK.
Note: Java support has only been tested with the Firefox, Seamonkey, and Konqueror web browsers. If it works well for you using a different browser, please let us know.
If you are just looking to watch flash videos from common websites, there are a number of options in packages, including: get_flash_videos, minitube, youtube-dl, get_iplayer and yt. Also, the Gnash project has made a lot of progress lately, and may fill your needs.
[FAQ Index] [To Section 12 - Hardware and Platform-Specific Questions] [To Section 14 - Disk Setup]