Its trend line equation is f(x) = 6.1x + 3.3. Slightly lower latency, than the Korg B2 interface. Probably because the 2i2 gen2 supports the UAC2 standard and the B2 not.
]]>Exactly one buffersize?
(for example when Audio buffer size is set to 64 in Pianoteq - does the first sample appear after the time 64/samplerate?)
Maybe only Modartt can answer that question, in the forum I found just the following interesting discussion:
https://forum.modartt.com/viewtopic.php...41#p951941
But not 100% clear there, if only one "BLOCK" is computed before send to Pianoteq's output.
Furthermore, does Pianoteq MIDI-input buffering? Is a timeperiod of MIDI events buffered, before they are processed? If so - how long?
]]>How many samples are calculated by Pianoteq, before they are sent to the audiodriver?
I suppose 2 * 64 samples (= 128 samples), but is it true?
PS: Forgot to mention with setting Audio buffer size 64 samples in Pianoteq.
]]>I just meant all the USB-Audiointerface combinations we both examined. With Alsa we just found 6x or 9x the buffer size represented by the slope -- but not one with 3x.
So it seems at the moment that the README_LINUX.txt of Pianoteq is not applicable to USB-Audiointerfaces:
"With the Alsa driver, the latency is 3 times the buffer size (a buffer of 64 samples at 44100Hz gives a latency of 4.3 ms)."
But more important: Should 3n (with n=2 or 3) be the rule for Alsa+USB -- what is the deeper reason? The more I meditate on it, the more I'm confused
]]>You wrote "(with n=1,2 or 3)". But it seems we just have evidence for 3n (with n=2 or 3) with ALSA USB at the moment -- or have I overseen something?
I took the green bar about 2 as 3, remember I made those lines with just two points... but you are right.
]]>
Its trend line equation is f(x) = 6.1x + 3.3. Slightly lower latency, than the Korg B2 interface. Probably because the 2i2 gen2 supports the UAC2 standard and the B2 not.
]]>It seems that ALSA takes 3n the size of buffer (with n=1,2 or 3), depending on who knows (?)
Don't know, but I can offer a hypothesis: Besides the alsa usbaudio driver (3 periods) the DAC-hardware itself could have a buffer of 3 periods, which would add up to 6 in this example (or multiple in other hardware).
From HIFI-DACs it is known, they often have big buffers, because break-free audiostreaming is the intention and not a very fast latency after pushing the play-button.
In the non-additive latency thread you can find an exception. The USB Scarlett 2i2 gen2 had been driven in SYNC mode there, which means just 2 periods instead of 3. The function I found there had been f(x) = 4.0x + 7.3, in other words the slope had been 4. If my hypothesis is true, the explanation would be: 2 periods in the alsa usb-driver plus 2 periods in the hardware DAC results in 4.
More common is the ASYNC mode today with an extra period (2+1=3).
It is not the best idea in my opinion to mix USB-Audiointerfaces with onboard-Audiointerfaces (PCI bus and others), because they have their own architecture and other drivers. Non-USB interfaces and their drivers usually have a flatter slope and a smaller static offset, because no USB-bus has to be passed. -
You wrote "(with n=1,2 or 3)". But it seems we just have evidence for 3n (with n=2 or 3) with ALSA USB at the moment -- or have I overseen something?
]]>
Although alsa is using 3 samplebuffers (README_LINUX.txt of Pianoteq) the tested example of a real system has a lag with factor 6.
PS: The samplebuffer 96 is an exception. While using 48000 Hz externally the internal samplerate was 32000 Hz. But I included it, because the internal rate just affects the performance index, not the latency.
]]>In the last setup (Pi400, Korg B2) the sample buffersize had been 64 at 48kHz, that I now changed temporarily to 128. I expected, that the latency increases just around 4.2 ms:
64 -> 3 * 1.3 ms = 3.9 ms
128 -> 3 * 2.7 ms = 8.1 ms
delta = 8.1 ms - 3.9 ms = 4.2 ms
But I measured a delta of 9 ms, which is more than double (21 ms in the following display minus 12 ms from my previous post):
Could be the reason, why I usually prefer playing PIanoteq with smaller buffersizes like 64 - 96 at rates of 44.1 - 48 kHz.
]]>
Platform this time had been my Raspberry Pi 400 with ARM Cortex-A72, PiOS 64-bit beta and the internal USB-Audiointerface of a Korg B2 Digitalpiano.
(my previous test had been with an Intel N4200 based Laptop, Debian Stretch 64-bit and Focusrite 2i2 gen2.)
In both setups the same MIDI-to-USB Interface (Edirol UM-1SX) was used at the input.
To generate cyclic MIDI Note-On events I used a software-sequencer this time (Muse).
The internal Korg audiointerface has a fixed samplerate of 48 kHz and so it had a small advantage in this competition against the 44.1 kHz that I used in my Focusrite rig.
]]>Could it be related to focusrite drivers?
It is the standard usb-audio kernel module (which is also responsible for MIDI), don't know. Eventually it helped, that the system timer is 1000 Hz and not common 250 Hz or 100 Hz.
]]>Yes, each of the ten measurements in Audacity had a 'Length of Selection' of 12 ms (not 11 or 13 ms). The time resolution is limited to 1 ms in that window (00h00m00.012s).
Could it be related to focusrite drivers?
In this PW post, some years ago, I had found a relative standard devition between measurements ranging from 1.6 to 19%
edit: I forgot to paste the URL
http://forum.pianoworld.com/ubbthreads...._USB_.html
