[nas] Re: debugging help: nas enabled mpg123 sounds slow and scratchy?

[Jon Trulson]

On Sun, 2 Mar 2003, Scott Presnell wrote:

> Date: Sun, 02 Mar 2003 17:16:08 -0800
> From: Scott Presnell <srp at tworoads.net>
> To: netbsd-help at netbsd.org, nas at radscan.com
> Cc: Frederick Bruckman <fredb at immanent.net>, Jon Trulson <jon at radscan.com>
> Subject: [nas] Re: debugging help: nas enabled mpg123 sounds slow and
>     scratchy?
>
> Hi Folks,
>
> After some further debugging I can tell you the following:
>
> 1) this is not a network problem
>

	Probably not.

> 2) there are some bugs and/or unexpected behaviours which you-all will
> have to help me further characterize.
>
> 1:
>
> I've now tried auplay with .wav files, and mpg123-nas, with .mp3 files
> made from those same wav files.
>
> I've been using two different PCI audio cards on two  PIII or
> thereabouts hosts with plenty of memory, etc. both under NetBSD 1.5.2
> (dmesg, etc, available should you need them).
>
> When NAS client and and server are on the same host I get very similar
> results
>
> using :0 (using unix domain nasd socket, but see bug below)
> using localhost:0 (which uses loopback, tcpdump'ed lo0 to check flow)
> and when using <samehost>:0
>
> I get scratchy, poppy output with all samples at 44100hz/16bit samples.
> With mpg123-nas I can troubleshoot this down to a  rate about 40000hz,
> sample width (8 or 16bits) makes no difference.  This is on a quiet
> machine.
>
> It gets somewhat but not much worse when client and daemon are separate
> machines (about 38000hz). Still a PCI audio card and a PIII
>
> ...and I couldn't make network audio acceptable in a situation where
> the audio card is ISA based (soundblaster), and client and server are on
> the same host. (I went down to 11kHz/8bit, and then punted).  This was
> a PPro & 64M, and NetBSD 1.5.2 but as far as I can tell no stress to the
> machine.
>

	I'm not sure what to do here... I need to be able to see this
problem before I can do anything about it...  It could be auvoxware
itself, or something in dia/ or os/ that affects the way connections
are formed and used... Then again...

> 2:
>
> Changing nasd.conf, restarting nasd, and using audioctl -a to check
> parameters I found:
>
> 	a) altering maxfrags corresponds to, and changes hiwat as 				expected.
> 	b) altering minfrags does not alter lowat (always == 1)

	This I will need to look into.

> 	c) altering fragsize does not alter blocksize (always == 2048)
>

	I can try to look at this too, but I don't think this is related
to your problem...

> Maually adjusting these via audioctl, to match up with nasd.conf, or
> just playing in general as Frederick suggested does not result in any
> positive change in the audio performace at 44100hz.
>
> Finally, I note a bug or problem with the unix domain sockets:
>
> In nasd.conf, it doesn't matter which method I chose to describe
> the audio device (/dev/audio0, or the convienence link /dev/audio),
> nasd always creates a unix domain socket at /tmp/.sockets/audio0.
> The bug: when using :0 or unix:0, I determined, using ktruss, that the
> clients (auplay, nas123-nas) are always looking for /tmp/.sockets/audio
> (no "0"). I checked that the clients are loading the correct libaudio.

	Yes.. The server is getting this right, but it seems libaudio
is not.  If you compile libaudio with '-DDEBUG', it should spit out
the iserver variable on client connect (ConnSvr.c).  This is what is
used to build the filename.  There was some whork done here for 1.6 -
perhaps a bug was introduced.  It is working properly under my linux
and UW (recently deceased) servers...

	Also, you can run nasd with something like '-v -d 99' and get more
debugging output from the server - if that helps...

>
> 	Thanks.
>
> 	- Scott
>
>
> Frederick Bruckman wrote:
> > On Fri, 28 Feb 2003, Jon Trulson wrote:
> >
> >>On Fri, 28 Feb 2003, Scott Presnell wrote:
> >>
> >>
> >>>and for Frederick: the output of audioctl -a is below.
> >>>
> >>>I played with blocksize and hi/lowat while a 44100 sample was playing
> >>>intrahost, but I could only make it worse :-(
> >
> >
> > Basically, you'll want to raise hiwat and lowat together, and assuming
> > that "nasd" is cognizant of the 2k blocks, and sending 2k blocks,
> > you'll want the difference between hiwat and lowat to be exactly one.
> > The idea is, that after the program wakes up from select() and writes
> > a whole 2k block, it actually gets a breather.
> >
> >
> >>	It seems almost like a network issue... If it works fine locally,
> >>but you are getting dropouts at higher bit rates when going remote, that
> >>does indicate that nasd just isn't getting data fast enough...
> >
> >
> > True, but I think the raw network speed should be more than adequate
> > for any kind of audio. If "nasd" is stuck in a tight loop writing to
> > the audio device, however, because the driver isn't tuned properly, it
> > might be dropping incoming packets on the floor.
> >
> >
> >>>name=Ensoniq AudioPCI
> >>>version=
> >>>config=eap
> >>>encodings=ulinear:8,mulaw:8*,alaw:8*,slinear:8*,slinear_le:16,ulinear_le:16*,slinear_be:16*,ulinear_be:16*
> >>>properties=full_duplex,mmap,independent
> >>>full_duplex=0
> >>>fullduplex=0
> >>>blocksize=2048
> >>>hiwat=3
> >>>lowat=1
> >
> >
> >
> > Frederick
> >
>
>

-- 
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>
You talk like a Ferengi.