On Sat, 2004-10-02 at 18:03, John Hedditch wrote: > > On Sat, 2004-10-02 at 17:31, Florian Schmidt wrote: > > > Also maybe the alsa drivers themselfes might be problematic/buggy. If > > > the above minimal alsa app still produces xruns, then either alsa lib or > > > the drivers themselfes are to blame [probably]. > > > > > > Of course such a test is not a proof but might give important clues. > > How about the following? > arecord -t raw -r96000 -fU24_LE -c2 --period-size=64 --buffer-size=128 fish > > This work just fine (no xruns). > > If we tried to drop down to 32 frames per period it (unsurprisingly) > breaks, however, and we get > the following: > arecord -t raw -r96000 -fU24_LE -c2 --period-size=32 --buffer-size=64 fish > Recording raw data 'fish' : Unsigned 24 bit Little Endian, Rate 96000 Hz, Stereo > overrun!!! (at least 0.087 ms long) > overrun!!! (at least 0.053 ms long) > overrun!!! (at least 0.152 ms long) > overrun!!! (at least 0.055 ms long) > overrun!!! (at least 0.055 ms long) > overrun!!! (at least 0.054 ms long) > overrun!!! (at least 0.064 ms long) > overrun!!! (at least 0.070 ms long) > overrun!!! (at least 0.166 ms long) > overrun!!! (at least 0.175 ms long) > overrun!!! (at least 0.165 ms long) > overrun!!! (at least 0.175 ms long) > > Anyway, this tends to support the jack client / jackd hypothesis, yes? > Right, this is exactly the expected behavior with the VP kernel. 64 frames at 96kHz (or 32 at 48kHz) is about the lower limit of PC hardware, I would expect 32 @ 96 to break. Try to isolate the jack clients that don't work... Lee
