lkml.org 
[lkml]   [2004]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Jackit-devel] Re: [patch] voluntary-preempt-2.6.8-rc2-M5
    From
    Date
    On Mon, 2004-08-16 at 11:33, Jack O'Quin wrote:
    > Lee Revell <rlrevell@joe-job.com> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:4.099 / U:0.384 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site