[nas] nasd outputs only part of a sample, client stalls -- exceptunder strace

[Jon Trulson]

On Mon, 23 Jul 2007, mmurray wrote:

> I've been trying to debug an identical situation, and have realized that
> the error only occurs with certain kernels. Specifically, running a
> debian machine, 2.6.18-4-686 has no problems, whereas 2.6.21-2-686
> hangs. I suspect this patch is the culprit:
>
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/broken-out/hrtimers-prevent-possible-itimer-dos.patch
>

   Interesting.

> But, I have yet to be able to prove it. It was merged into the mainline
> kernel with 2.6.21.
>
> To the best of my reasoning, the SIGALRM is being lost in a race
> somewhere. Is there a reason why its better to unblock and ignore the
> alarm signal while in AuProcessData instead of stopping and restarting
> the timer? This is all in auvoxware.c:intervalProc().

   No, there is no good reason the signal should be unblocked there.
   I've applied a patch sent by another user that corrects this, though
   I do not know if it will affect your problem.  I have attached the
   patch, though if you have svn, you can grab it in trunk.

>
> I'm having trouble following how the nasd event loop works. Are there
> any decent notes on the structure of nasd? Does nasd try to anticipate
> the exhaustion of the soundcard buffer with timers instead of relying on
> completion notification from the sound card drivers?

   Yes.  It sets up a timer that determines when it expects the samples
   written to the hw to run out, and ques up some more.  I believe the
   ausun version of nasd does use notification from the audio driver
   rather than a timer.

   I think notification from the driver would be preferable (as long as
   there is a way to set the low-water mark so that the samples aren't
   all consumed before nasd is made aware of it).

   I have not investigated this for the oss driver.

>
> Are the minfrag, maxfrag, and fragsize settings in the default nasd.conf
> (with the amusingly ancient comment "for doom!") still most appropriate?
>

   Hehe, usually.  Lower latency, even in normal (non-doom) use is
   usually preferable,  Have you tried increating them?

> I've seen patches submitted on the list that use sigaction(2) under
> linux instead of signal(2), any reason why it shouldn't be used?

   The sigaction call is used on sco systems at present.  No real
   reason why they are also not used on Linux, other than 'it works so
   why mess with it' :)

   Try the attached patch and let us know if it helps anything.

   PS: I still play doom with a couple of friends (legacy port) :)


-- 
Jon Trulson
mailto:jon at radscan.com 
#include <std/disclaimer.h>
"No Kill I" -Horta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nas-1.9.patch
Type: text/x-diff
Size: 739 bytes
Desc: 
URL: <http://radscan.com/pipermail/nas/attachments/20070724/9f8201d7/attachment.patch>