[nas] Patch for libaudiooss

[Tobias Diedrich]

Erik Inge Bolsø wrote:

> >1) The GET[OI]SPACE implementation of libaudiooss does not work
> 
> It works well enough for most programs... If the program writes between
> calls, less space is available ... if it doesn't, more space is available.
> But, of course, more exact emulation is a good thing, mostly.

The thing is that mplayer writes more than a fragment in one write,
but libaudiooss would only decrease the number of available fragments
by one per write regardless how big the write is.

> >2) Before calling write() mplayer checks if the write would block and does
> >   not call it in that case. Because libaudiooss implements the
> >   NAS Eventloop in the blocking write() codepath, it is never called.
> 
> Hmm... I'm not sure if I see this problem occuring - I certainly got sound
> when I tested mplayer with my only-a-little-patched-from-0.9.13 version -
> granted, it was totally unsynced and unusable, but anyway.

I assume that to be because GETOSPACE would return a >0 value even
though the buffer is already full.

> >The solution is to use a separate thread for the Eventloop, which is what
> >this patch does.
> >I also emulate a fragmented buffer, because mplayer uses GETOSPACE to
> >determine how much data to write to the buffer.
> >
> >Tested and working with mplayer, mpg123 and mp3blaster.
> >
> >Please try this patch, I would be especially interested to hear wether you
> >still need the WINE_HACK with this.
> 
> Well, it fixes mplayer all right, but it breaks Wine and XMMS horribly, at
> least. And, I suspect, most other multithreaded and/or fork()ing
> programs.

Hmm, I'm looking at the xmms Problem right now.
I added an additional mutex to protect the libaudio library calls,
so it's not segfaulting anymore, but there seems to be some other
Problem. I get errors like this one:
|audiolib: unexpected async reply (sequence 0xd)!
But I don't understand what the problem might be...

> If you could solve the problem without using a separate thread, and
> without breaking compatibility with quite a bit of other programs like
> this does, I'd be happy to take the patch :)

I don't see why using a separate thread should break multithreaded / forking
programs, but I have not done much programming with threads in linux yet...
So If you could explain this to me that would be good :-)

-- 
Tobias							     PGP-Key: 0x9AC7E0BC
echo ${SIGNATURE}