Fast Track Ultra latency and new streaming logic.

Fast Track Ultra latency and new streaming logic.

[Grant Diffey]

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.

Re: Fast Track Ultra latency and new streaming logic.

[Felix Homann]

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

Re: Fast Track Ultra latency and new streaming logic.

[Daniel Mack]

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

Re: Fast Track Ultra latency and new streaming logic.

[Felix Homann]

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

Re: Fast Track Ultra latency and new streaming logic.

[Felix Homann]

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

Re: Fast Track Ultra latency and new streaming logic.

[Clemens Ladisch]

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

Re: Fast Track Ultra latency and new streaming logic.

[Clemens Ladisch]

Felix Homann wrote:
> 2012/5/3 Clemens Ladisch <clemens@ladisch.de>:
>> 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.)
>
> I'm getting "URBs = 2 [ 5 6 ]"  for playback and  "URBs = 8 [ 8 8 8 8
> 8 8 8 8 ]" for capture with the "old" streaming logic. What does it
> mean?

The queue length is 5+6 = 11 packets; at high speed, that's
11 / 8 kHz = 1.4 ms.


Regards,
Clemens

Fast Track Ultra latency and new streaming logic.

[Aurélien Leblond]

> I can't seem to get below 512frames in flight (2 256sample frames or 4 128
> or 8 64's) without consistant overruns.

On my side, I can run 256 frames ; 3 periods, no xruns at all at 48kHz...
I haven't tried to push the driver more than that,

Aurélien

Re: Fast Track Ultra latency and new streaming logic.

[Takashi Iwai]

At Wed, 9 May 2012 15:05:47 +0200,
Felix Homann wrote:
> 
> Am 03.05.2012 16:03 schrieb "Felix Homann" <linuxaudio@showlabor.de>:
> >
> > Is this a
> > flaw in Alsa, Jack or the USB stack?
> 
> I'm starting to think that this is a Jack issue. At least I can set rather
> small period and buffer sizes in aplay without any xruns.

Or a full-duplex issue?  You can test the latency via
alsa-lib/test/latency program.

(Yes, the usage is quite undocumented.  Anyone contributing the howto
 would be great...)


Takashi

Re: Fast Track Ultra latency and new streaming logic.

[Felix Homann]

(For the list..)

>
> Is this a
> flaw in Alsa, Jack or the USB stack?

I'm starting to think that this is a Jack issue. At least I can set
rather small period and buffer sizes in aplay without any xruns.

Re: Fast Track Ultra latency and new streaming logic.

[Felix Homann]

(stupid me.. again for the list...)

Hi,

2012/5/9 Takashi Iwai <tiwai@suse.de>:
> Or a full-duplex issue?  You can test the latency via
> alsa-lib/test/latency program.

OK, I don't know if I'm using it the right way (see below ) but here
are some observations:

1. With the old streaming logic I can successfully go down to a
reported latency of 384 frames @96kHz without an xrun.

2. With the new streaming logic 'latency' will not start.

It fails with:
Unable to set hw params for capture: Device or resource busy
Unable to set sw parameters for playback stream: Device or resource busy

As a first guess this could be related to the fact that the PCM
streams of the FTU are never reported as "Running" with the new
streaming logic. (Daniel?)

3. 'latency' never returns cleanly.

On Ubuntu I'm getting
*** glibc detected ***
/home/fex/workspace/Audio/Latency/alsa-lib/test/.libs/lt-latency:
invalid fastbin entry (free): 0x00000000013c0570 ***

On Fedora (kernel with old streaming logic) I get:

*** glibc detected ***
/home/fex/workspace/Audio/Latency/alsa-lib/test/.libs/lt-latency:
munmap_chunk(): invalid pointer: 0x00000000018a5f90 ***
*** glibc detected ***
/home/fex/workspace/Audio/Latency/alsa-lib/test/.libs/lt-latency:
malloc(): memory corruption (fast): 0x00000000018a5a90 ***

On Fedora 'latency' hangs after this message.

>
> (Yes, the usage is quite undocumented.  Anyone contributing the howto
>  would be great...)

Yes, I don't even know how to use it or if I've used it correctly...

It doesn't seem to be neccessary to connect an output to an input. Is
this correct? At least results don't change without a connection...

Regards,

Felix