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

[Jack O'Quin]

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.
-- 
  joq
-
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/