/dev/dsp busy

Thank you for reading this.

I've recently upgraded to Mandriva 2009.1 and now none of my Amateur Radio applications will run because /dev/dsp is busy. Yet, "fuser -v dev/dsp" shows that nothing is using the resource.

I've disabled Pulse Audio in case that was a problem and I don't have any sound applications sitting on the task bar. I had this problem four years ago and that was due to a music player sitting on the task bar.

The driver in use is: "intel HDA (snd_hda_intel [ALSA])"

Can anyone offer any suggestions?

Regards,
Phil

It's possible that something is using the ALSA sound resource path (which is the baseline audio implementation in modern Linux kernels - the old OSS sound drivers are deprecated, and /dev/dsp is usually implemented as an ALSA compatibility driver).

Try "lsof | grep dev/snd" to see what (if anything) is using the ALSA sound pseudodevices.

Another possibility is that the problem isn't /dev/dsp itself... rather, it may be that some resource needed by the kernel to support the sound device is busy (e.g. IRQ or DMA conflict). I wouldn't think that would be the case with the Intel HDA, but it's possible that your motherboard BIOS has mapped it onto the same IRQ which is being used by another device whose driver doesn't know how to share.

On Monday 01 June 2009 13:29:16 Dave Platt wrote:
<cut>

Thanks for your prompt reply Dave.

The problem was Pulse Audio, as I suspected. It wasn't enough to just disable pulse audio in the sound settings, I had to kill the resulting PID.

Now another problem has surfaced; there is a ticking sound in the background of the transmitted sound. Again, this is a problem that I had previously encountered and the cure was to buy a different sound card. However, this option is not viable in the case of a laptop.

I don't know what effect this ticking sound will have on my transmitted signal (I've recently returned to Amateur Radio after a lengthy break and need to construct a suitable lead) but I'm sure that I can do without it.

Again, can anyone offer any suggestions?

Regards,
Phil

I've observed something like this when:

- The sound card has an ALSA driver, and

- The sound card supports only a limited set of audio sample rates, and

- The application is asking for a sample rate which is not directly supported by the sound card hardware, and

- The application is using the legacy /dev/dsp audio API, via the ALSA OSS-compatibility driver

The problem here seems to be a flaw in the ALSA /dev/dsp driver in the kernel. This driver attempts to do sample rate (and format) conversion, when the app asks for a sample rate that the hardware doesn't support, but there's a bug in the conversion algorithm. I've seen this problem on input (the input data has zero-valued samples inserted) and I've noticed it on output as well. I think it occurs when the ALSA I/O ring buffer wraps around.

The only solution I've found (short of using a different sound interface) is to have the application use the ALSA I/O API directly, rather than going through the /dev/dsp OSS emulation driver. When using ALSA, the direct hardware driver ("hw:") won't do any sample rate or format conversions at all - if the app asks for a format or rate not supported, an error is returned. If the app really does need a rate not supported by the hardware, you can use the "plughw:" driver, which does software sample-rate/format conversion in a library plug-in - this conversion seems to work much better than the one in the OSS emulation driver.

As far as laptop sound cards go - I gave up on trying to get the one in my Chembook laptop to work right (the mic input is fouled up somehow), and bought a SignaLink USB. This works very well for ham applications (it has its own VOX- based PTT) when used with the ALSA "plughw:" driver.

On Monday 01 June 2009 15:38:15 Dave Platt wrote:
<cut>

Regards,
Phil