/dev/dsp busy

/dev/dsp busy

[Phil]

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

Re: /dev/dsp busy

[Dave Platt]

Phil wrote:
> 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?

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.

Re: /dev/dsp busy

[Phil]

On Monday 01 June 2009 13:29:16 Dave Platt wrote:
<cut>
>
> 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.
>

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

Re: /dev/dsp busy

[Dave Platt]

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

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.

Re: /dev/dsp busy

[Phil]

On Monday 01 June 2009 15:38:15 Dave Platt wrote:
<cut>
> 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
>

Thank you for your detailed reply Dave.

I'll experiment further and see what results.

-- 
Regards,
Phil