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

[Jon Trulson <jon@xxxxxxxxxxx>]

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@xxxxxxxxxxx 
#include <std/disclaimer.h>
"No Kill I" -Horta
--- server/dda/voxware/auvoxware.c.orig    2007-03-18 06:05:55.000000000 +0100
+++ server/dda/voxware/auvoxware.c 2007-07-23 22:22:03.000000000 +0200
@@ -1084,7 +1084,7 @@ intervalProc(int sig)
         sigset_t set;
         sigemptyset(&set);
         sigaddset(&set, SIGALRM);
-        sigprocmask(SIG_UNBLOCK, &set, NULL);
+        sigprocmask(SIG_BLOCK, &set, NULL);
     }
 #endif
     if (processFlowEnabled) {
@@ -1095,7 +1095,7 @@ intervalProc(int sig)
             sigset_t set;
             sigemptyset(&set);
             sigaddset(&set, SIGALRM);
-            sigprocmask(SIG_BLOCK, &set, NULL);
+            sigprocmask(SIG_UNBLOCK, &set, NULL);
         }
 #endif
         signal(SIGALRM, intervalProc);