[nas] AuBadFlow errors under heavy load

[Hynek Hanke]

Hello everyone,

I'm using NAS for audio output of one accessibility related project.
I've noticed that under heavy load, I'll inevitably get an AuBadFlow
error sooner or later. By heavy load I mean that the play/stop cycle
has to be completed in around 40ms. (There are lot of messages, but
each one is quickly interrupted by a newer one). Although it might
not seem so, this happens quite often.

The error I get on stderr is:
	Audio Error:  BadFlow
	Request Major code 21 ()
	Error Serial #13163
	Current Serial #13183

And the library terminates the whole process.

I don't know if this message comes from AuHandleEvents
or AuStopFlow or both and I don't know how to find it out.

I understand that libaudio is not thread safe and I'm forced
to use it in a threaded environment. Specifically, I'm running
AuSoundPlayFromData in one, AuEventHandler in another, and
occasional AuStopFlow in yet another. This appears from the
need to be able to stop the playing immediatelly whenever
needed and to be able to exactly tell when the playing terminated.
(I supposed AuEventHandler to be blocking, which I still hope
is true on most systems -- not mine -- as posted in another
mail here in the conference). I can make myself everything
thread safe by using outside mutexes, but I'm not able to solve
AuEventHandler, since I can't put a mutex on it if it's blocking.

I wouldn't mind occasional errors from stop or play or
event handlers, if that wouldn't cause the whole process
to crash. If the audio library is able to detect this
error condition, I don't understand why does it exit
instead of returning an error code to the caller. 

Is there a hope for this to be fixed? Or are there any
plans to make libaudio thread safe? Is there something
I can do to avoid these problems?

This is a serious issue for me, because our project crashes
like ten times a day in real use with NAS, so we can't use the new
NAS output and have to continue using OSS or look for a different
audio/media server.

Thanks very much,
Hynek