[alsa-devel] Fast Track Ultra latency and new streaming logic.
Daniel,
In continuing my personal habit of looking gift horses in the mouth...
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?
This leads to rather high latencies (22ms+) or is this conclusion bogus?
Grant.
Hi,
Am 01.05.2012 02:18 schrieb "Grant Diffey" gdiffey@gmail.com:
I can't seem to get below 512frames in flight (2 256sample frames or 4
128 or 8 64's) without consistant overruns.
Yes, I noticed this, too. I carelessly attributed this to the kernel used for my testing being non-realtime, non-lowlatency. Somehow I forgot to further investigate...
What could you achieve with the old streaming logic? I think I could go down to 2x128 frames.
(I'm typing this on my phone and can't tell reliably. I will post an update as soon as I'm back at my machines/FTU.)
Regards, Felix
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
Hi,
2012/5/1 Grant Diffey gdiffey@gmail.com:
I can't seem to get below 512frames in flight (2 256sample frames or 4 128 or 8 64's) without consistant overruns.
at least at 44.1 and 48 kHz I can get it to run without consistent xruns with 3 periods/buffer and 128 frames/period. For 88.2 and 96 kHz I need to go to 4 periods/buffer. Less than 128 frames/period lead to consistent xruns no matter how many periods/buffer I use.
I've been using a kernel freshly cloned from Tiwai's git with the latest rt patch on a rather slow laptop. I've switched to Fedora on that machine a couple of days ago so I don't know yet if my system settings are properly adjusted for Jack, yet.
This leads to rather high latencies (22ms+) or is this conclusion bogus?
Yes, I guess that this conclusion is bogus.
First, even at 44.1 kHz I think that you rather get 11.6 ms latency (512/44.1). At 96 kHz this reduces to 5.3 ms.
I've even done some measurements using jack_iodelay. At 96 kHz I get a total round trip latency of 17.5 ms. According to the jack_iodelay manpage this corresponds (if I get it right) to an hardware input/output latency of the device of ~584 frames (6.1 ms).
This would lead to the (maybe bogus) conclusion that we have a total output latency of 11.4 ms.
By the way, if you're using jack2 you would probably want to start it in synchronous mode (with the -S option ). Otherwise you get an implicit extra period/buffer. (I guess you already know that.)
@Daniel: I could not find any difference between my latest "old-streaming-logic" kernel and my latest "new-streaming-logic" kernel.
Regards,
Felix
Some more observations:
I've measured the latency on the same machine running Windows 7 using Centrance's latency test utility (http://centrance.com/downloads/ltu/) and got much better results than under Linux. That's a bit disappointing...
I don't know if these latencies come xrun-free since I don't know how to detect xruns on Windows. On the other hand, telling Jack not to complain about xruns from Alsa (softmode) I can get down to 64 frames/period and 2 periods/buffer without any noticable glitches or crackles (playing a sine test tone). Maybe the Windows driver just doesn't complain either?
Nevertheless, I'm a bit surprised that just starting Jack without any clients will result in a flood of xruns at small buffer sizes. Is there anything we can do about it? Is this to be expected? Is this a flaw in Alsa, Jack or the USB stack? Is there a way to debug these xruns?
Any suggestions?
Regards, Felix
Felix Homann wrote:
I've even done some measurements using jack_iodelay. At 96 kHz I get a total round trip latency of 17.5 ms. According to the jack_iodelay manpage this corresponds (if I get it right) to an hardware input/output latency of the device of ~584 frames (6.1 ms).
USB playback also adds further latency by queueing the packets; the number of packets can be seen under "URBs" in /proc/asound/card?/stream0. (There are 1000/8000 packets per second at full/high speed.)
Regards, Clemens
participants (4)
-
Clemens Ladisch -
Daniel Mack -
Felix Homann -
Grant Diffey