Hitchhiker's Guide to Openbsd

Does low latency improve audio-video synchronization?
Synchronizing audio to video doesn't require low latency. Synchronization problems are often caused by 
the software itself (poor implementation, bugs, ...). Forcing the application to use smaller buffers (by 
starting aucat(1) 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. 
13.6 - What can I do if I have 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 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. 
http://www.openbsd.org/faq/faq13.html (10 of 25)9/4/2011 10:02:21 AM

---

13 - Multimedia
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: 
●
Some old ISA cards have particular quirks: 
❍
Some need to be configured with a different I/O address and IRQ value to avoid conflicts 
with other hardware. You can easily try different combinations using the 
User Kernel 
Configuration (UKC)
. 
❍
It is possible that a less than optimal driver attaches to the sound device, and that you can 
get better results using another driver. This is not the easiest thing to spot, but take a closer 
look at your 
dmesg(8)
output, and find the lines where audio drivers attach. If you see 
more than one sound driver attaching (or trying to), test them one at a time by disabling 
some and leaving one enabled using the 
User Kernel Configuration (UKC)
. 
●
Find information about your sound device. Use the documentation, or use an internet search 
engine to find its specifications. For 
ac97(4)
 and 
azalia(4)
 devices, look for documentation for 
both the controller and the codec. They may actually help you find the source of the 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.{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
Here we see that the processed data count 
play.samples
increases each time we check, so data is 
http://www.openbsd.org/faq/faq13.html (11 of 25)9/4/2011 10:02:21 AM

---

13 - Multimedia
flowing. We also see that the device is keeping enough data buffered 
play.seek
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 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.