Re: Fast Track Ultra latency and new streaming logic.

[Daniel Mack <zonque@gmail.com>]

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