[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
You can test whether or not your audio device is working properly by sending an audio file (usually with .au extension) to it. If you don't have an audio file, you can also send any text or binary file to the device:
$ cat filename > /dev/audio
If you hear something (if it's not an audio file it will not sound good and
may sound loud, too), it means that the chip is supported by OpenBSD and was
recognized and configured by the kernel at boot time.
Note: Not every variation or utilization of every chip has been tested or debugged.
If you did not hear anything upon entering the above command, there are a number of possible reasons:
Note that even if you did hear a sound, it does not necessarily mean that everything is going to be functioning as desired. If you encounter problems while playing sound, here is another list of things to check:
To tune the parameters for the audio device, such as playing sample rate, you can use audioctl(1). To tune the sound volume and other mixer settings, you can use mixerctl(1). Both utilities are provided as part of the base system.
For instance, to set the sound volume of the left and right channels to 200, you would, for example (see Note 2 below), issue
$ mixerctl outputs.master=200,200
outputs.master: 255,255 -> 207,207
Notice how the value becomes 207.
The reason for this is that my audio device has an AC'97 codec, which uses
only 5 bits for volume control, leading to only 32 possible values.
Obviously, other hardware could have different resolution.
To unmute the master channel, you would do
$ mixerctl outputs.master.mute=off
outputs.master.mute: on -> off
To make your changes permanent you need to 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
Note 1:
You may see more outputs than there are on your sound card or motherboard.
This is because audio chips are generally cheaper to install on boards than
the jacks used to connect the outputs, so not every option of every audio
chip necessarily reaches the outside world.
Note 2: The outputs of the audio device in your system may be labeled differently. For instance, you might not have an "outputs.master" as in the above example, you may need to adjust "outputs.output" or something else instead. This depends on the audio driver, and you can easily find the proper name by listing the controls with
$ mixerctl -a
In order to play such a file, you should 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
$ file music.wav
music.wav: Microsoft RIFF, WAVE audio data, 16 bit, 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).
play.encoding=slinear_le
play.rate=44100
play.channels=2
play.precision=16
Next, pass the audio file to the sound device:
$ cat music.au > /dev/sound
If you applied the correct settings, you should be hearing what you expected.
Note: Always use /dev/sound, not /dev/audio, if you want the settings you applied with audioctl to stay in place.
There are other utilities you can use, such as aucat(1), and audio/waveplay in packages and ports. Of course, popular software like XMMS is also able to play these files, among 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:
$ 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%
Of course, Ogg Vorbis plugins exist for many other audio software.
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.
There are audio utilities in the packages and ports collection that tackle this problem by performing rate resampling. For example, x11/mplayer has a "-srate" switch to specify a desired output sample rate. You would set that to the rate your sound device is using. KDE's artsd and some games support similar options. Read the documentation of your specific audio application to find out whether it supports rate resampling.
Two widely used technologies in music synthesizers are:
Most of the necessary information about MIDI on OpenBSD can be found in the midi(4) manual page.
The main utility to handle standard MIDI files is midiplay(1). To get a list of MIDI devices available on your system, try the following:
$ midiplay -l
0: SB MIDI UART
1: SB Yamaha OPL3
2: PC speaker
In this example, we see the UART output to which an external MIDI device
can be connected, the Yamaha OPL3 FM on-board synthesizer, and the plain
old speaker.
Note: Not all sound cards have an on-board MIDI synthesizer, so you may see only an UART ouput and the PC speaker listed.
Playing a standard MIDI file, in this example through the OPL3 synthesizer, is as easy as:
$ midiplay -d 1 file.mid
Notice that we specified MIDI device number 1 as a parameter because
device number 0 is used by default.
More information: Tutorial on MIDI and Music Synthesis
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.
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 read 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:
$ mixerctl inputs.cd.mute=off
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.
First, set the relevant recording parameters with audioctl(1), e.g.
record.encoding=mulaw
record.rate=8000
record.channels=1
record.precision=8
Here I'm using nonuniform quantizing with the mu-law algorithm, with one
channel, a sampling rate of 8000 Hz and using 8 bits per sample.
The mu-law and A-law algorithms are especially useful when digitizing speech
signals, because they achieve a greater coding efficiency.
This means that the quality of the sampled speech will be better for a given
number of bits per sample, or less bits will be required for a given quality.
If you decide to adopt the above values (only those!), you can use the /dev/audio device which uses them by default, so you do not need to set them explicitly in that case.
Next, 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:
inputs.mic.mute=on
inputs.mic.preamp=on
inputs.mic.source=mic0
record.source=mic
record.volume=255,255
record.volume.mute=off
record.mic=0
record.mic.mute=off
In this example, I'll be recording from a microphone.
Pre-amplifying has been enabled, otherwise the recorded sound can be pretty
silent.
To do the actual recording, just use cat(1) or dd(1):
$ dd if=/dev/audio of=myvoice.raw
Press [CTRL]-C to finish the recording.
The output is a raw sequence of bytes.
This sound can be played, as explained in
Playing different kinds of audio.
For a quick test, assuming the audio parameters are set correctly:
$ dd if=myvoice.raw of=/dev/audio
Again, if you set other encoding parameters, you should be using the /dev/sound device. Another example of encoding parameters:
record.encoding=slinear_le
record.rate=22050
record.channels=2
record.precision=8
This will result in PCM with signed linear (uniform) quantization, stored in
little-endian byte ordering, at a sampling rate of 22050 Hz, in stereo,
and using 8 bits to represent one sample
(2^8 = 256 quantization levels).
Note: You will probably want to convert this recording in raw (headerless) format to a more usable format for further processing. Read FAQ 13 - Conversion to find out more.
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
$ oggenc *.wav -b 192
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.
Below is a simple example of encoding a WAV file with a bit rate of 192 kbps:
$ lame -b 192 track01.wav track01.mp3
For all options and details, please consult the manual page that comes with
lame.
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
# cd /dev
# ./MAKEDEV cd2
In what follows, we will mostly be accessing the CD/DVD writer through the
raw character device, not the block device.
cd2 at scsibus2 targ 1 lun 0: <LITE-ON, DVDRW LDW-851S, GS0C> SCSI0 5/cdrom removable
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.
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.
# cdio -f cd1c blank
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 tao sys.iso
With the options specified above, we're asking cdio to use the second
CD-ROM device as the CD writer.
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:
# cdio -f cd1c cdrip
This command will extract a series of WAV files from your second CD-ROM drive
to your disk.
# 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, (E)IDE/ATAPI, 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 and (E)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, XF4, 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.
$ mkisofs -R -o cvs.iso /cvs
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:
# 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
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.
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.
# growisofs -dry-run -Z /dev/rcd2c -R /cvs
If this succeeds, just leave out the -dry-run option and start burning the
DVD.
# 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:
# growisofs -M /dev/rcd2c -R /mydata
For more information about growisofs, refer to the manual page.
When you have finished writing the DVD, mount it and see whether everything you expected to be there, is indeed there.
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
...
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.
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.
$ sox -U -c 1 -r 8000 -b myvoice.raw myvoice.wav
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.
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 retransmision 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".
$ 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
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.
$ mplayer http://mp3.streampower.be/radio1-mid.mp3
alias radio1='mplayer http://mp3.streampower.be/radio1-mid.mp3'
Upon installation, instructions are displayed for using the Java plugin with a Firefox or Mozilla web browser. Create the symlink as explained, and then you should see the Java plugin upon entering "about:plugins" in the URL bar.
Note: The Java plugin has only been tested with the Firefox and Mozilla browsers. If it works well for you using a different browser, please let us know.
Before continuing, it is a good idea to read about Linux emulation in the compat_linux(8) manual page, and also FAQ 9 - Running Linux binaries on OpenBSD.
If you have understood this and you didn't install the necessary files yet, just add the fedora package. Assuming you have the environment variable PKG_PATH set (see FAQ 15),
# pkg_add -i fedora_base
This will automatically set kern.emul.linux=1, but not permanently.
If you need permanent Linux emulation, you need to specify that in
/etc/sysctl.conf, as explained in
FAQ 9 - Running Linux binaries on OpenBSD.
Another thing you should know is that Linux shared libraries and modules cannot be used with OpenBSD executables, so you will need a Linux browser as well.
One candidate is the Opera web browser, available in the ports tree. OpenBSD does not distribute packages for it, since Opera's license is not clear about its redistribution. However, installation should not take long, since it is distributed in binary form by Opera Software. After that you can easily install the Flash plugin from the ports tree.
# cd /usr/ports/www/opera
# make install
# cd /usr/ports/www/opera-flashplugin
# make install
Note: It should be sufficient to perform the last step alone, and the ports system will install the dependencies automatically. For clarity, however, we split the process into a few steps here to explain.
If you have followed the above guidelines, the Flash plugin should now be listed when you type "about:plugins" in the URL bar.
[FAQ Index] [To Section 12 - Hardware and Platform-Specific Questions] [To Section 14 - Disk Setup]