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

[Scott Presnell]

Hi Folks,

After some further debugging I can tell you the following:

1) this is not a network problem

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.

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)
	c) altering fragsize does not alter blocksize (always == 2048)

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.

	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
>