[nas] audiolib: unexpected async reply...

[Jon Trulson]

On Mon, 29 Jan 2001, Erik Inge Bolsø wrote:

> Date: Mon, 29 Jan 2001 18:13:18 +0100 (CET)
> From: Erik Inge Bolsø <knan at mo.himolde.no>
> To: Jon Trulson <jon at radscan.com>
> Cc: nas at radscan.com
> Subject: Re: [nas] audiolib: unexpected async reply...
> 
> 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
[...]
> 
> 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.
> 

	Yep...

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

	I'm not sure this would work completely... In addition to properly
syncronizing protocol requests, libaudio will also need to maintain a per
'context' state so that it won't stomp on itself (if 2 WriteElement calls
are called from a seperate thread for example) since even though multiple
threads could be using libaudio, only one libaudio 'context' is actually
loaded.  I don't know if this is correct - my threading experience is
limited...  Perhaps it's now a good time to learn more about it ;-)

	What you might try is to add a littel debugging to libaudiooss
(that spits out the PID or some other unique, per-thread identifier) and
see how many instances are being loaded... 1 for all threads or one per
thread.  I'm guessing its 1 for all threads or you shouldn't be having the
problem you're seeing...


-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
Free Mars!