Alan Stern wrote: > On Sat, 13 Jul 2013, Clemens Ladisch wrote: >> James Stone wrote: >>> On Mon, Jul 8, 2013 at 2:12 PM, James Stone <jamesmst...@gmail.com> wrote: >>>>> configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods >>>>> JackAudioDriver::ProcessAsync: read error, stopping... >>>> >>>> Some further info - on 3.5.0-28, I can start jackd in playback only >>>> with 8 frames/period, and capture only at 16 frames/period. >>> >>> Any thoughts on further investigating this bug with the 3.8.0 kernel >>> with the Focusrite Scarlett 2i4? >> >> Jack assumes that the interrupts for the playback and capture streams >> happen at more or less the same time. It might be possible that on the >> newer kernels, there is a difference between the arrival times of the >> first completion callback of each stream. > > The interrupts shouldn't differ by more than the duration of one URB, > which would be 1 ms. There is an initial delay when a stream is first > started, which generally lasts 5-10 ms. But I think that hasn't > changed since the 3.5 kernel. Would it make any difference?
The initial delay does not really matter as long as it's the same for both streams. (A difference of 1 ms would be significant if the period size is that short.) > Bear in mind that the input and output streams are started at totally > different times. Jack takes great care to start them together. > And anyway, James's latest problem occurs even with playback only. On my machine, 3 x 8 frames works, although Jack often complains that two periods are already completed when it expected only one. Anything less (2 x 8 frames) does not work; and 8 frames is where even my PCI card begines to make problems. In any case, "poll timeout" would not indicate completion delays but that no data was transferred _at all_. In theory, this should not be possible. I'm stumped at the moment. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
