On 2023-03-13 00:49, Fons Adriaensen wrote: I don't use rpi4 and audio but the throughput is significantly better than rpi3, both on USB and Ethernet. Magpi has an article about it. https://magpi.raspberrypi.com/articles/raspberry-pi-4-specs-benchmarks "Ethernet throughput While Raspberry Pi 3 Model B+ added Gigabit Ethernet connectivity, throughput on Raspberry Pi 4 is free from the single shared USB 2.0 channel to the SoC" -- /bengan

It's been a while but it had something to do with USB and ethernet being shared on the same bus like Bengt already pointed out, see also https://wiki.linuxaudio.org/wiki/raspberrypi#usb_audio. On the Rpi4 those are separated now so I guess ethernet interfering with USB is not an issue anymore. Best, Jeremy

On Sun, Mar 12, 2023 at 02:47:59PM -0400, Joe Hartley wrote: Babyface Pro measured using alsa_delay, 48 kHz: P N delay (ms) ------------------ 256 2 11.369 192 2 8.702 128 2 6.035 96 3 6.702 48 3 3.702 P < 128 required 3 periods buffering. P < 48 was unstable. Ciao, -- FA

On Mon, 13 Mar 2023 00:24:22 +0100 Fons Adriaensen &lt;fons(a)linuxaudio.org&gt; wrote: Thanks, Fons!! -- ====================================================================== Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com Without deviation from the norm, "progress" is not possible. - FZappa

On Sun, 12 Mar 2023, David W. Jones wrote: At lower latencies that would be true, as listed above. Note that it is stated periods less than 128 require 3 periods. This is because USB audio does not send periods over it's wire but rather 1ms chunks that have to be assembled into period sized buffers inside the computer. Those 1ms chunks are not synced to the media clock but arbitrary size and timing. By the time the period size reaches 128, there are enough 1ms cycles involved that two period buffers work fine because they are an artificial construct anyway. I am sure I have glossed over many details ... Basically, USB was not designed with audio in mind. Also bear in mind that those who design most consumer audio, consider 30ms or less as "low latency". I think even 8 or 16 foot pipes sound much faster than that. Len -- Len Ovens www.ovenwerks.net

On Mon, Mar 13, 2023 at 10:20:01PM +0100, Giso Grimm wrote: I'd agree. When I use alsa_delay with 96/2 things are OK for around 10 seconds, then for another 10 s I get all sorts of weird values, and finally a stable value that is a few tens of samples higher than the original. This stable value is different each time the test is run. For 48/2, I get unstable values for the first 10 seconds, then a stable value that is again different each time. It almost looks as if something tries to adapt to the situation, but not in a deterministic way. It's also not clear why 96/2 should go wrong at all with such a light load. Imagine my sample rate is just a bit low when measured against the 1 ms clock used by the USB system. Then occasionally we get 47 samples instead of 48, and the start of period has to wait for another 1 ms. But that is only half a period, so it should not have any ill effects at all if the actual processing time is much shorter. Re. using Jack on OSX: that is probably Jack2, which unless you use -S runs in a mode that adds one period to the round-trip latency. This is done by sending the output of the previous cycle to the hardware at the start of each cycle, rather than the output of the current cycle when it is done. This provides some extra resilience against xruns, but not as much as -n 3. Ciao, -- FA

On Tue, 14 Mar 2023 12:04:43 +0100 David Kastrup &lt;dak(a)gnu.org&gt; wrote: I did some reading on USB audio quite a long time ago, and from that this is what I 'think' I understand: Since USB2 full speed, it will try to fit up to 8 'packets' if it can into it's 1mS time frame where as previously it was one-for-one. Presumably if you're sending a continuous stream of suitably sized packets and are close to that number, sometimes you'll get 8 but other times you'll only get 7 -- Will J Godfrey {apparently now an 'elderly'} https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On 3/15/23 18:18, Fons Adriaensen wrote: Very nice plots. Well almost, even though it's in the description I'd expect axes to have labels :) In case of P = 96, N = 3, do the 5 outliers cause x-runs, or is it really just a clock difference? Have you calculated the average clock speed for all settings? I'd be interested if in the case P=48 N=3 the babyface's clock is also a 50ppm slow. The clustering around 1ms multiples reminded me about that old post: https://linuxmusicians.com/viewtopic.php?f=47&t=10707 (Frame & Period settings ideal for USB interface). -- robin

On 15.03.23 18:18, Fons Adriaensen wrote: Thanks, nice plots! I can reproduce (more or less) the plots with Audient EVO16 and jack. When I use period sizes below 1ms, I get this: http://vegri.net/p32-n2.png Here the clusters are at 0.5 ms and 0.75 ms. When I zoom in I see a pattern of 0.75, 0.75, 0.5, 0.75, 0.75, 0.5, and so on. So again on the 1 ms grid (every 3 callbacks), but since the round-trip delay is smaller than for P = 48, I guess that input and output blocks are not time-aligned. Best, Giso

On 14.03.23 07:16, Worik wrote: https://github.com/gisogrimm/ov-client/blob/master/tools/gethwdelay.sh It is basically a wrapper around jack_delay (which, as far as I know, was written by Fons). The idea behind this table is to know what delay is added to the theoretical minimum delay for block-wise audio processing. This differs significantly between audio devices. It measures the round trip delay, i.e., the delay one would get from a microphone to the headphones if no delay is introduced by the signal processing (e.g., reverb, filters). The second column is the period size configured in jack ("P" in the email from Fons), and the next two columns are the delays, first in audio samples, and then converted to milliseconds (this is just the first number divided by 48). Depending on your system you will get tons of underruns when using the smallest period sizes. On a Raspberry Pi 4 the Scarlett Solo runs well with P=48 at 48 kHz sampling rate and a jack load of about 30-40% (jackd2). The same Raspberry Pi 4 runs stable at 192 kHz and P=48 with 18% jack load using a HiFiBerry GPIO sound card, which results in the shortest delay I could achieve with jack on a Raspberry Pi 4. I use the HiFiBerry only for DA, not for AD (although the offer ADCs as well, AFAIK). The sound quality is good, the cheapest ones have only asymmetric outputs which may result in a bit of humming noise. The XLR output version has very low noise, but I did not measure it (nor any other properties). Best, Giso