I apologize in advance for bringing up what is probably an old issue, but I
think I am missing something.
Some time ago I discovered to my surprise that when the OSS compatibility
modules are loaded, applications that attempt to open /dev/dsp when it is
already in use will find themselves blocked. The call to open() will not
return until the device is available.
I though this was strange behavior and was about to report it as a bug when I
read the FAQ and saw this listed as the second question. The reasons given
for not complaining about this behavior are (quoting here):
- it's the right (standard) way
- the application that want a different behaviour can open the device in
O_NONBLOCK mode
- all modern OSS drivers in mainstream kernel (cmpci, es1370, es1371,
esssolo1, maestro, sonicvibes, vwsnd) works in the same ways and the
others have to be intended buggy
- we want you ask to broken applications author to fix them ;-)
So I changed my application to open the device using the O_NONBLOCK mode.
But then I discovered that this made _every_ call non-blocking, including the
write() calls. Suddenly my application would write data to the audio buffers
too quickly and cause the sound to play very fast since the ring buffers were
being overflowed constantly. This behavior was not desirable, so the
compromise I settled upon was to open() with O_NONBLOCK and then to clear the
flag using fcntl() after I was sure the device was open.
Later I was told that this way of doing things is not in accordance with the
OSS API standard (and a few Mac OSS drivers refuse to clear the O_NONBLOCK
flag after it is set), so I set out to find out for myself, and this is what I
found:
The API reference that I think is "the standard" is
http://www.opensound.com/pguide/oss.pdf
published by 4Front Technologies.
The two relevant quotes can be found on pages 26 and 29, respectively:
"Audio devices are always opened exclusively. If another program tries to
open the device when it is already open, the driver returns immediately with
an error (EBUSY)."
"The value of open_mode should be O_WRONLY, O_RDONLY, or O_RDWR. Other flags
are undefined and must not be used with audio devices."
So it would appear that either:
a) Half of the FAQ answer is wrong: ALSA violates the OSS API spec and the
suggested workaround also violates the spec.
b) I'm looking at the wrong standard.
I would appreciate any comments you could make on this situation. I want to
make sure my application doesn't mysteriously stall when the audio device is
already in use, but I also don't want it to behave erratically on some
systems.
---
Stan Seibert
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
