[vorbis] Is GCC 2.95.2 also unusable?

[volsung at asu.edu]

On Sun, 14 Oct 2001, Michael Smith wrote:

> >However, if you are, you would be the third Linux+Mac user to observe this
> >problem.  It occurs because libao opens the audio device in non-blocking mode
> >and then turns blocking on after the device is open.  (There are good reasons
> >for this, which I can explain if you care.)  However, one or more of the audio
> >drivers for Linux on PPC seem to be ignoring the second call in libao that
> >turns the blocking flag back on.  This is a bug in the audio driver and not
> >libao, however.
> >
> 
> Note that the OSS API is _very explicit_ in saying that what you're trying
> to do is incorrect behaviour and has undefined results. The drivers are NOT
> at fault here, libao is. 

Okay, I stand corrected.  I assume the documentation to which you are
referring is: http://www.opensound.com/pguide/oss.pdf

The relevant bit is on page 29:
"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."

O_NONBLOCK would be one of those flags that is not allowed then.

In looking through the docs, I also discovered that the behavior that drove me
to use such an ugly hack in the first place is _also_ not standard.

Some background:
 
ALSA (the up and coming Linux sound API) has an OSS compatibility layer so old
apps can still run.  Mandrake uses this ALSA + OSS compat combo in their
distribution, and I imagine other distros will follow once ALSA becomes less
bleeding-edge.  When you try to open a /dev/dsp device that is already in use
on such a system, it will actually force the open() call to block until the
device is available again.  When I initially discovered this, I was about to
report it as a bug until I read the ALSA FAQ, which claims that this blocking
behavior is "standard" and that modern OSS drivers also act this way.  This is
quite annoying for applications that want to figure out if the sound device is
already in use.  Rather than check the standard for myself, I stupidly
believed them, cursed the standard, and wrote a workaround.

So now I find the following in the OSS spec on page 26:

"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)."

So the "standard" behavior isn't actually standard after all.  Anyway, I'll
talk to the ALSA people and see what they have to say.  I may still need to
work around this, but at least I know what I can't do.  :)


---
Stan Seibert

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.