[nas] [maddog at mir.com: Bug#168814: nasd always opens audio device at max sample rate]

[Jon Trulson]

On Wed, 4 Dec 2002, Steve McIntyre wrote:

> Date: Wed, 4 Dec 2002 20:42:54 +0000
> From: Steve McIntyre <steve at einval.com>
> To: nas at radscan.com
> Subject: [nas] [maddog at mir.com: Bug#168814: nasd always opens audio
>     device at max sample rate]
>
> An odd-sounding bug report from a Debian user:
>

	Not really - I've heard these from people too - but it seems SB
Live specific and I don't have one of those...


> Reply-To: Matto Marjanovic <maddog at mir.com>, 168814 at bugs.debian.org
[...]
>
> Hiya,
>
> I've had this problem for quite a while (over a year?), but, lazy me, I'm
>  just investigating/reporting it now:
>
>      nasd seems to always open the audio output device at the
>      maximum sample rate specified in /etc/nasd/nasd.conf.
>

	Yes... Isn't this the correct behavior?

>
> If I try to play a sound file with a *higher* sample rate than this
>  specification, it sounds alright (i.e. it is being automatically
>  downsampled somewhere).  However, if I try to play a sound file with
>  a *lower* sample rate, it is played too fast (i.e. no upsampling has
>  been done).
>

	Ok.  I've heard this too - but the only way I know this could
happen (unless there is a bug somewhere) is if nasd sets the hw sample
rate, and there is no error or anything - it just doesn't 'stick'.

> By setting the maximum sample rate in nasd.conf to equal the minimum rate,
>  sound files playback ok, being automatically up- or down-sampled as
>  appropriate.  (This is a convenient workaround, but the quality does
>  suffer due to resampling.)
>

	Ok...

> Also, it appears that there is no constraint that "max sample rate" must
>  be higher than the "min sample rate" in nasd.conf.  If I make the max
>  lower than the min, then sound files seem to get upsampled to the high
>  'min' rate (if necessary) but them played at the low 'max' rate (very
>  spooky).
>

	Hmmm. I will look into this... obviously max should be >= min...

> And, last tidbit, the "forcerate" option, whatever it is supposed to do,
>  has no effect on any of this.
>

	I think I may remove this option I can't remeber offhand who
supplied that patch, but it seems...  not quite right.

> (In my experiments, 'playing' means auplay or output generated by xfaces,
>  which is my main NAS client.  auinfo reports the correct sample rates for
>  the sound buckets created by xfaces.)
>
>
> I don't remember having such a problem until I switched to my current sound
>  card (SBLive soundcard, using stock kernel modules:  emu10k1, ac97_codec,
>  sound, soundcore).
> Indeed, I do not have this problem on another machine with an OPL3-SA2
>  sound chip (opl3sa2, ad1848, mpu401; linux 2.4.18; and nas_1.5-1, however
>  the problem machine suffered back in the 1.5 days as well).


	As far as I've been able to tell, the common denominator in the
bug reports mailed to me privately all involve the SB Live.  I always just
figured the drivers were buggy, and since I don't have one...

[...]
> Here is the "-d 1" output of nasd, from startup through a request from
>   auplay to play a file with 11025 Hz:
>
> AuInitPhysicalDevices();
> Init: will close device when finished with stream.
> Init: Leaving the mixer device options alone at startup.
> openDevice OUT /dev/dsp mode 2
> openDevice(1) IN /dev/dsp1 mode 0
> setupSoundcard(...);
> ++ Setting up Output device
> +++ requesting wordsize of 16, got 16
> +++ requesting 2 channel(s), got 2 channel(s)
> +++ Requesting minimum sample rate of 5000, got 8000
> +++ Requesting maximum sample rate of 44100, got 44100
> setupSoundcard(...);
> ++ Setting up Input device
> +++ requesting wordsize of 8, got 8
> +++ requesting 2 channel(s), got 2 channel(s)
> +++ Requesting minimum sample rate of 4000, got 8000
> +++ Requesting maximum sample rate of 44100, got 44100
> setTimer(rate = 0);
> createServerComponents(...);
> closeDevice: out
> closeDevice OUT /dev/dsp mode 2
> closeDevice: in
> closeDevice IN /dev/dsp en 2
> closeDevice: mixer

	What was this?  After the first startup?

>   [--------------------------- playing starts here (mm) ---------------------]
> setSampleRate(rate = 11025);

	Hmm.  Was this the correct samplerate of the file you were
playing?

> setTimer(rate = 11025);
> enableProcessFlow();
> openDevice
> openDevice OUT /dev/dsp mode 2
> setupSoundcard(...);
> ++ Setting up Output device
> +++ requesting wordsize of 16, got 16
> +++ requesting 2 channel(s), got 2 channel(s)
> +++ Requesting minimum sample rate of 8000, got 8000
> +++ Requesting maximum sample rate of 44100, got 44100
> openDevice IN /dev/dsp mode 2
> setupSoundcard(...);
> ++ Setting up Input device
> +++ requesting wordsize of 16, got 16
> +++ requesting 2 channel(s), got 2 channel(s)
> +++ Requesting minimum sample rate of 8000, got 8000
> +++ Requesting maximum sample rate of 44100, got 44100
> setSampleRate(rate = 44100);
> setTimer(rate = 44100);


	This is interesting... It set 11025 rate, then initted the
soundcard, which set samplerate to 44.1Khz?  Smells like the releasedevice
code may have some personal issues.  I'm suspecting that the
setSampleRate(rate = 11025) call should not be occurring before the
device has been opened. ;-)

	Try this, can you have him strace nasd as well and send it to me?
Looks like the ioctls() in setSampleRate aren't being checked (shame) for
error conditions.  I might be able to supply a patched auvoxware.c that
ensures that the device is actually available before blindly configuring
the device as well, if he wants to try it...

[...]

-- 
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>
Bad Color Temperature, Too much Peach.