[nas] AuBadFlow errors under heavy load

Jon Trulson jon at radscan.com
Sat Dec 4 20:39:22 MST 2004


On Sat, 4 Dec 2004, Hynek Hanke wrote:

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

 	That's bad... This looks like the default error handler, which 
will just emit it's error and then exit.  Have you tried setting up your 
own error handler via AuSetErrorHandler().  This will arrange for your 
handler to get called instead of the default one...

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

 	No way for me to tell either - it's from the server... If you are 
familiar with X, NAS behaves the same way WRT error replies (async).

> I understand that libaudio is not thread safe and I'm forced
> to use it in a threaded environment. Specifically, I'm running

 	Why do you say this?  Thread safety was added to libaudio in v1.5 
(we're now at version 1.7).  Solved several issues with xmms anyway.  I 
have no other threaded audio apps I use, and since it's been in for a few 
years, I assumed it was working properly...  What version of nas are you 
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 theory, you should not need mutex's for libaudio, it has it's 
own to protect critical areas.  Now, you may need them for your own 
application of course depending on what you are doing...

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

 	Fatal I/O errors will cause an exit no matter what you do.  The 
above was not a fatal error however, so I can only assume it's exiting 
because you have not defined your own handler, which causes the 'default' 
handler to be used (which exits of course).

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

 	At least some of them I think you can deal with by seting up your 
own error handler.

 	Thready safety is already present (and has been since 2001).

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

-- 
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>
"I am Nomad." -Nomad




More information about the Nas mailing list