[nas] re: Sound dropouts using ALSA and NAS on Linux

[David Morano]

Charles wrote :

> I wrote the unified Sun Sparc NAS dda (reusing, rearranging,
> debugging, and adding to pre-existing code).

Thanks for responding.

> I don't have any problem with auedit or auplay at 8000 samples/s.  

I have no problems at low sample per second stuff either (even on Ultra).

> I do have problems with an older mpg123 (0.59o) at 44100 samples/s.  

I have only used :

$ auplay soundfile.au

so far with the sound being 44100 sps .

> I have a feeling that this may have more to do with to the
> interaction between the NAS dda and the kernel audio driver than with
> the interaction between and NAS client and the NAS server.

Yes, that was my feeling at first also (maybe that is still the best
explanation).

Why does :

$ audioplay soundfile.au

work so flawlessly ?  Being a total ignorant of these things, I thought
that the NAS server kind-of (in its own way) just did something like :

$ audioplay < sound_stream 

under the hood.

> Indeed, programs such as mpg123 typically program NAS with a huge
> playout buffering delay.  Moreover, using debugging output from the
> server, I can see that once in a while, the kernel sends a SIGPOLL
> late:

Ya, a late SIGPOLL is a killer if that is all that is used to
wait for the ability to write more data to the device.
Has there ever been a server implementation where a separate thread
just sits with blocking write(2)'s on the audio device ?
Maybe something like that would be a way to get around depending on
SIGPOLL arriving before the current data is all flushed out
of the device.

> This works fine for me within a single digit sound.  

Yes, it works fine for me also with a single digit or even with
something like :

$ auplay -spacing 200 12345

The default of '-spacing 100' causes dropouts.

> Because of the
> way audial is coded, disableProcessFlow is called by NAS at the end of
> every digit sound and this flushes the kernel audio driver backlog
> which always seems to produce a click in the output.  (Optionally,
> this also closes the audio device.)

This does seem like 'auplay' should be written to keep the
the flow open but with just silence between the digits.  OK, the
problems with 'auplay' may just be a quirk with it specifically.

> Basically, if the problem is indeed related to the kernel audio
> driver, there is not much else we can do, since it is proprietary
> source, than try to play with it from our side of its interface.  

Not that it is really of much help but Sun will be releasing source
code for Solaris 8 one of these days (if not already).

> There was also an older implementation of the NAS dda for Sun (well,
> patches on the mailing list, actually) which used SIGALRM instead of
> SIGPOLL.  It produced much worse problems for me (including locking
> the whole station, not just one of its subsystems), but it may have
> worked for others.  

I do not know what that older code might have done with SIGALRM
but it does sound like a more problematic implementation than using
SIGPOLL (what Sun seems to suggest).

It may be that using threads or specifically a separate thread just
sitting with a blocked 'write(2)' on the audio device (using no SIGPOLL
either), might be the way to go for the future.  Has anyone else
thought about or started work on something like this ?

Of course, my dream would be for Sun to adopt NAS as their standard
and just code up the NAS server themselves !  Then they can figure 
out how to keep the output sound clean (even if it means hacking up
their own drivers to perform better) !

Thanks,
Dave Morano
morano at computer.org