Configuring Audio Devices #

All supported audio drivers are already included in the GENERIC kernel, so there is no need for extra configuration or installation of drivers. Running mixerctl(1) with no arguments will list the device’s mixer controls and current settings.

$ mixerctl

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. There may be, for example, more outputs listed than are physically available on a sound card or motherboard.

There are a few controls that are common to many devices:

  • outputs.master controls the playback output level
  • record.source controls what inputs are mixed into the ADC (analog to digital converter), used when recording
  • record.volume controls the input level of the ADC

The controls of an audio device may be labeled differently. Usually the controls have a meaningful label, but sometimes one must simply try different settings to see what effect each control has.

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 referred 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

$ mixerctl outputs.master=200,200
outputs.master: 255,255 -> 207,207

Notice how the value becomes 207. The reason for this is that this audio device uses only 5 bits for volume control, leading to only 32 possible values. 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 the changes take effect on each reboot, edit /etc/mixerctl.conf. For example:

$ cat /etc/mixerctl.conf

To change the default audio output device, for example to use an external DAC rather than your motherboard’s onboard audio, just change sndiod(8)’s startup flags to use that device:

# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod

This would make the second audio device (rsnd/1) the default.

Playing Different Kinds of Audio #

OpenBSD comes with aucat(1), a program for recording and playing WAV, AIFF and AU files. The following example will play a WAV file.

$ aucat -i filename.wav

Other audio formats can be handled by third party applications.

Playing Audio CDs #

It is possible to play audio CDs by either having the CD drive play the disc and send analog audio to the sound card, or by reading the audio data and sending the digital samples to the sound card over the PCI bus.

To play an audio CD using the analog output of your CD-ROM drive, you can

  • Use the headphones output, usually at the front side of the drive.
  • Connect the audio output at the back side of the drive to your audio card.

Use the cdio(1) utility to play a CD:

$ 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, you may want to add the user to the operator group for convenience 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

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.

$ cdio cdplay

Many GUI CD players are in the audio section of packages and ports.

Recording Audio Samples #

aucat(1) comes with OpenBSD and can be used for recording.

$ aucat -o file.wav

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 at 48kHz. Other sample formats, sample rates and number of channels can be also be recorded. See the manual for details.

To play the file back, run:

$ 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.

Recording a Monitor Mix of All Audio Playback #

A monitoring stream records combined audio output from all playback devices, allowing you to duplicate or save anything going through the audio subsystem. This feature can be useful for screencasts or any kind of live audio mixing.

Create the monitor sub-device mon for sndiod(8) by using:

# rcctl set sndiod flags -s default -m play,mon -s mon
# rcctl restart sndiod

Configure your program to record audio from the snd/0.mon device:

$ aucat -f snd/0.mon -o file.wav

At this point, whatever your system plays is recorded in file.wav.

OpenBSD’s Audio Server (sndiod) #

What latency do I need? #

The latency is the time between when a program takes the decision to play a sample and when the user hears the sample. Since audio data is always buffered, this delay is proportional to the audio buffer size. The following values are recommended:

  • Real-time synthesizers: 5ms. This is the time it takes between hitting a key on your MIDI keyboard and actually hearing the note. Roughly, 5ms corresponds to the time it takes for the sound to propagate 1.75m.
  • Games: 50ms. This is the time between when you see an event and you hear the corresponding sound.
  • Movie players and alike: 500ms and more. Such applications “know” the sound to play in advance, and send audio data in such a way that it is played simultaneously with the corresponding picture.

The smaller audio buffers are (to achieve low latency), the larger the probability to overrun/underrun is. Buffer overruns/underruns result in stuttering of the sound. sndiod(8) 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 × 0.050 seconds = 2400 samples

Then do:

# rcctl set sndiod flags -b2400

Does low latency improve audio-video synchronization? #

No, synchronizing audio to video doesn’t require low latency. Synchronization problems are often caused by the software itself. Forcing the application to use smaller buffers (by starting sndiod(8) in low latency mode) may hide the actual problem in some cases, and give the feeling that the software works better, but obviously the right thing to do is to start searching for the corresponding bug.

How do I use a remote sound card? #

sndiod(8) can be configured to accept connections from the network, allowing other machines to use the sound card as well. On the remote system, the one with the sound card, run:

# rcctl set sndiod flags -L-

On the local system, configure your program to use:


where “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.

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.

Debugging Audio Problems #

If you do not hear anything when playing audio, it’s possible there is a mixer control turned to low or simply muted. See this section for configuring the mixer. Please unmute all inputs and outputs before reporting a problem.

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.{bytes,errors}
$ audioctl play.{bytes,errors}
$ audioctl play.{bytes,errors}
$ kill %1
$ fg %1
cat > /dev/audio < /dev/zero

Here we see that the processed data count play.bytes increases each time we check, so data is flowing. We also see that the device has not underrun any samples (play.errors). That’s good too.

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 you are still having problems at this point, 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.

Using MIDI Instruments #

The Musical Instrument Digital Interface (MIDI) protocol provides a standardized and efficient means to represent musical performance information as electronic data. MIDI data contains only instructions needed by a synthesizer to play the sounds, rather than the actual sounds.

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 (such as 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:

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>

It shows two MIDI ports, known by sndio(7) as:

  • rmidi/0 - synthesizer connected via USB
  • rmidi/1 - a MIDI master keyboard

They are backed by the /dev/rmidi0 and /dev/rmidi1 character devices. The latter devices are handy for testing the hardware, bypassing most software layers. To test your MIDI keyboard, you can use the hexdump(1) utility to display MIDI data you’re playing on it:

$ hexdump -e '1/1 "%02x\n"' < /dev/rmidi0

The output of the keyboard can be connected to the input of the synthesizer, as follows:

$ cat -u < /dev/rmidi0 > /dev/rmidi1

Now you can hear what you’re playing on the MIDI keyboard on the synthesizer.

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

The sndiod(8) server exposes MIDI thru ports, allowing programs to send each other MIDI data. For instance, if you have no hardware synthesizer connected, you could start a software one (like the audio/fluidsynth port) and then use it as MIDI output:

$ midiplay -f midithru/0 file.mid

To record MIDI files, you can use the smfrec utility bundled in the audio/midish port. For instance:

$ smfrec -d rmidi/0 -i rmidi/1 file.mid

This 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.

Playing DVDs #

OpenBSD supports DVD media through the ISO 9660 filesystem, which is also used on CD-ROMs, and also through the Universal Disk Format (UDF) filesystem which is found on some DVDs. However, almost all DVD-Video and DVD-ROM discs use the UDF bridge format, which is a combination of the DVD MicroUDF (subset of UDF 1.02) and ISO 9660 filesystems. It is used for backward compatibility reasons.

Some popular media players, supporting DVD playback, have been ported to OpenBSD. Please read the installation instructions that come with these packages, because these tools may need further setup. With these utilities, it is possible to play the DVDs by directly accessing the raw device. Of course, it is also possible to mount a DVD using mount_cd9660(8) and play the files directly.


  • Nearly all DVDs you buy are encrypted using the Content Scrambling System (CSS). To be able to play these encrypted DVDs, you can use the libdvd library, also available through packages and ports.
  • Be aware that a region code may be present on your DVD disk(s). This should not be much of a problem when playing DVDs on a computer.

Burning CDs and DVDs #

Introduction and Basic Setup #

You should first make sure your CD/DVD writer has been recognized and configured by the kernel. Most SCSI devices are supported. SATA, IDE/ATAPI and USB devices are supported through SCSI emulation. You can quickly find your device in the output of dmesg(8). Just look for lines beginning with “cd.” For example:

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

Error: mount_cd9660: /dev/cd2c on /mnt/cdrom: No such file or directory

By default, the OpenBSD installer creates only two cd device nodes, cd0 and cd1. To start using your cd2 device, you must create the necessary device nodes for it. The recommended way to do that is using the MAKEDEV(8) script.

# 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.

Checking CD/DVD Writer Operation #

It is recommended to check whether your CD/DVD writer is working correctly. In this example, we’ll be using this USB DVD writer:

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.

Writing CDs #

Creating Data CD-ROMs #

First, you will want to create an ISO 9660 filesystem to put on a CD-ROM. To do this you can use the mkhybrid(8) utility in the base system, or the mkisofs utility from the cdrtools package. In the examples below, we will use mkhybrid, although mkisofs usage is very similar.

For example, to store the OpenBSD kernel sources in an ISO9660 image, you might do:

$ 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 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

Creating Audio CDs #

To burn audio CDs, you can again use cdio(1) with the tao -a option.

As an example, we’ll be making a backup copy of a music CD. This involves two steps:

Fetch the audio tracks from the original CD.

# cdio -f cd1c cdrip

This command will extract a series of WAV files from your second CD-ROM drive to your disk.

Write the audio tracks to a blank CD.

# cdio -f cd1c tao -a *.wav

Writing DVDs #

There are a few important things about DVD you should know about before proceeding to write your own DVDs.

  • If you really want to know all about DVDs, you can read the very extensive DVD FAQ document to start with.
  • This section has seen only very limited testing, and we certainly have not tried every possible media and writer combination. Nevertheless, we have had, or have heard of, positive experiences with all of the DVD formats mentioned below.

Different DVD Formats #

There are a number of different DVD formats. Commonly used are the DVD-R, DVD-RW, DVD+R, and DVD+RW formats (R means writable once, RW means it can be rewritten a few thousand times). They are pretty much competing standards. 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 using media which suits 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 Writing Speed #

It may be useful to point out that DVD speed indications differ from CD-ROM speed indications. The following table gives an overview:

DVD read/write speedTransfer rate (MB/s)Equivalent CD-R(W) read/write speed

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. In general, the speed of SCSI, SATA, and IDE/ATAPI buses should be just fine.

Writing the DVD #

Basically, the process is very similar to writing CD-R(W)s. The software used, however, is different. At the moment, the best option is growisofs from the sysutils/dvd+rw-tools package. This utility writes an ISO 9660 image to the DVD medium. All recordable DVD formats are supported by the dvd+rw-tools.

In case you want to find out more info about the media in your DVD writer, you can use the dvd+rw-tools utility. There are two options to write the DVD:

  • Pre-master an ISO 9660 from your data, storing the image on your hard disk, then write this image to the DVD.
  • Write an ISO 9660 from your data immediately to 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.

$ mkhybrid -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-tools.

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.

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 man page.

When you have finished writing the DVD, mount it and check whether everything you expected to be there is indeed there.

Why am I not getting the writing speed I expected? #

Instead of the above writing output, you may see something like:

   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.

Browser Plugins (Java and Flash) #

Java plugin support can be obtained with the icedtea-web package. In your browser, check for the list of detected plugins and ensure icedtea-web is there. This is usually found via about:plugins in Mozilla browsers and chrome://components in Chromium/Iridium.

Note that due to the security issues with Java applets on the web, most browsers disable Java support by default. You will be prompted for your explicit consent to run applets via icedtea-web.

Adobe’s Flash plugin is distributed in binary form only, and they do not provide a native OpenBSD version. Considering their security record, we thank them for this neglect.

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, streamlink and youtube-dl.