Re: [Jackit-devel] Re: [patch] voluntary-preempt-2.6.8-rc2-M5

[Lee Revell]

On Mon, 2004-08-16 at 11:33, Jack O'Quin wrote:
> Lee Revell <rlrevell@xxxxxxxxxxx> writes:
> 
> > On Mon, 2004-08-16 at 06:52, Lee Revell wrote:
> > > On Mon, 2004-08-16 at 06:48, Ingo Molnar wrote:
> > >  if the former then does jackd set itself up (does an mlockall, etc.) 
> > > > before it opens the audio device? If the audio device has an event for
> > > > jackd the moment the device is opened, and jackd opens the audio device
> > > > early during startup, then jackd might not be able to process this event
> > > > until it has started up (which can take milliseconds).
> > > 
> > > This is probably what is happening, the kernel-side issue seems fixed,
> > 
> > It looks like this is what happens - jackd calls snd_pcm_start, then
> > does several other thinks like malloc'ing memory for the array of fd's
> > to poll() before entering the polling loop, by which time there has been
> > data ready for a while.  This may or may not be worth fixing, I am
> > adding jackit-devel to the cc: list.
> 
> Yep.  This looks like a bug to me.  While jackd, itself, seems to
> allocate everything before calling driver->start(), the ALSA driver
> internally calls malloc() *after* calling snd_pcm_start().  I doubt
> anyone has ever made a concerted effort to clean up this path for
> realtime safety.
> 
> I think it should be fixed (I need to study the code in more detail).
> There's probably nothing to prevent us moving the free() and malloc()
> calls up nearer the top of alsa_driver_start().  That will probably
> require an extra error test and free in case snd_pcm_start() fails.

I made this change and it seems to work fine, snd_pcm_start is now the
very last thing that happens in alsa_driver_start, and we free() if
snd_pcm_start fails.

I still get the xruns at startup, but they were ~100ms before, now they
are more like 20ms.  Unfortunately the OO-ness of the code makes it hard
for me to figure out where alsa_driver_start gets called from, so I'm
not sure what else happens before we enter the polling loop.

Lee  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/