[nas] audiolib: unexpected async reply...

[Erik Inge Bolsø]

On Mon, 29 Jan 2001, Jon Trulson wrote:
>On Sun, 28 Jan 2001, Erik Inge Bolsø wrote:
>> Greetings.
>> 
>> After the addition of mixer emulation to libaudiooss, I've started getting
>> in trouble with xmms. I suspect I'm stressing something too hard, due to
>> xmms' constant open->read->close mixer cycle several times a second.
>> 
>> symptom:
>> "audiolib: unexpected async reply (sequence 0x110)!"
>
>	Ahh... Threading...  The issue here is that libaudio and (probably
>libaudiooss) are not thread safe.  Bummer.  libaudio has calls to
>Lock/Unlock itself during protocol requests/replies, but I notice that
>they are currently defined as no-ops.  The issue you are probably seeing
>is that libaudio received a reply for a protocol request it doesn't think
>it made (another thread probably did that).  You can also get 'lost
>sequence' errors in these cases too.

Aha, I see... One or two xmms threads are playing audio, while a third
thread is doing mixer ops... that would cause trouble, indeed, if libaudio
is not thread safe.

And since I've not given any thought to making libaudiooss thread-safe, it
probably isn't. Any guides around on how to do that? Argh... I probably
need to start fiddling with critical sections and such things... but, on
the other hand, if I can make libaudiooss thread-safe, that would in
theory prevent libaudio from having to deal with it? (at least if I do
thread-safety by the "refuse to send a request if another thread is
awaiting a reply" route)

Is this feasible? Do libaudio usually have many outstanding requests,
awaiting replies? Or only one or two?

--
Erik I. Bolsø | email: <knan at mo.himolde.no>
The UNIX philosophy basically involves giving you enough rope to
hang yourself.  And then a couple of feet more, just to be sure.