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

[Charles Levert]

Hi.

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

David Morano <morano at computer.org> writes:

> > The problem is intermittent dropouts in the playing of a wav file.
> > They seem to occur at the same points in the sound, i.e., if you
> > play the sound again you are likely to hear the same pattern of
> > dropouts.

> I also get sound dropouts on Solaris 2.6 on SPARC hardware.  I am using
> NAS 1.4.  The dropouts appear to be the worst when the client is on the
> same machine as the server but the dropouts can be observed with a
> remote client also to a lessor extent.  They seem to show up the most
> when playing straight 44100 sps stereo PCM files (at least that makes
> sense being as its about the most data the server will see compared to
> lower sample rates).

I don't have any problem with auedit or auplay at 8000 samples/s.  I
do have problems with an older mpg123 (0.59o) at 44100 samples/s.  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.  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:

	800 samples/SIGPOLL => 800/44100 = 0.01814058956916099773

	# actual data
	...
	0.018115
	0.018155
	0.018408
	0.055849
	0.002810
	0.018216
	0.018143
	...

So it may have more to do with the kernel audio driver support for
44100 samples/s than anything else.  The driver I am using is from a
Sun patch for SunOS 4.1.4 that backported Solaris 2.5 stuff.  (The
original CS4231 driver for SunOS 4.1.4 just didn't work, for those who
can remember.)

> Further, it appears that the problem is the worst for servers on
> Sun Ultra SPARC boxes as compared with an older SPARC-20.

> Here is the Ultra SPARC server information :

> > Version Number:         2.2
> > Vendor:                 NAS Release 1.4 - Sun unified dda 
> >                         (running on SUNW,CS4231)
> > Vendor Release:         1

> Here is a SPARC-20 server information :

> > Version Number:         2.2
> > Vendor:                 NAS Release 1.4 - Sun unified dda 
> >                         (running on SUNW,dbri)
> > Vendor Release:         1

> The Sparc-20 box is an old dual CPU 150 Hz Hyper SPARC while the Ultra
> SPARC (which causes a much worse dropout problem) is a dual CPU 200 MHz
> Ultra SPARC-1.

I use a uniprocessor SparcStation 20 with SunOS 4.1.4 (still!).

> Here is another funny thing to consider (maybe it is not related)
> but why does :

> $ audial 123456789

This works fine for me within a single digit sound.  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.)

> cause what seems to be dropouts and runs the sound of the digits
> together ?  This problem only occurs on the Ultra-SPARC box.  It might
> be unrelated to the general dropout problem but it is curious that NAS
> on Ultra SPARC seems to perform the worst in every way even though it
> has more CPU available than older Sparcs !


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.  You
can see in the source code for server/dda/sun/ausuni.c that I already
tried several options for implementation.  (Look for

	/* Local compilation options. */

in that file.  Caution: this is weird and very pragmatic programming
to fit the situation and the code is not very documented aside from
the preprocessor #define names.  Of these #defines, ADD_OUTPUTS is
correct and there is no use in playing with it.)

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.  It's not as elegant as SIGPOLL or some other type
of solution which involves what is essentially a callback from the
kernel to userspace to send data at the right time, but I mention it
in case it could work for you.


Charles