2 Oct
2004
2 Oct
'04
8:43 p.m.
On Sat, 2004-10-02 at 18:03, John Hedditch wrote:
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
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?