On 01.05.2012 02:18, Grant Diffey wrote:
In continuing my personal habit of looking gift horses in the mouth...
Testing is much appreciated :)
I can't seem to get below 512frames in flight (2 256sample frames or 4 128 or 8 64's) without consistant overruns.
I have a feeling that the pcm <-> urb layer is buffering until a urb is max urbsize from a quick look at the code does this seem like the right track?
No, it doesn't. The implicit feedback streaming model waits for capture urbs to arrive and then sends back an urb with the same amount of data for playback. Hence, the number of bytes per playback urb is defined by the device and the stream it sends to the host.
This leads to rather high latencies (22ms+) or is this conclusion bogus?
The urb length can't possibly lead to such latencies. With a sample frequency of 44100 Hz and a stereo stream @16bit, we're dealing with a data rate of 176400 bytes/s. Even with max urbsizes of 512 bytes, an urb can only hold ~2,9ms of audio data. With more streams, higher sample rates or deeper samples, this number is declining. So this can't be the reason.
Also, I doubt that the rewrite of the streaming code is to blame for what you're seeing, as it just changed the logical view on internal structures. The streaming behaviour itself should remain the same.
What you could do, though, is disabling the FTU quirk in sound/usb/pcm.c:set_format(). That should in theory restore the old streaming logic. Does that change anything?
Daniel