On Tue, 23 Oct 2018, Jonathan Liu wrote:
Linux 4.17.14, Class Compliant Mode (snd-usb-audio, ALSA backend): 16/2 32 + 80 ~ 2.333 ms
What are these numbers? Are these lines supposed to in the format expressed by the first formula above? If they are, how come "block_size/periods" shows up as a pair of numbers "16/2" but "block_size*periods" shows up as a single number "32"?
To interpret "16/2 32 + 80 ~ 2.333 ms" Block size: 16 samples
Is this what ALSA would call the number of frames per period? I presume your sample is the same as an ALSA frame. (As I recall, in ALSA each frame in a stereo stream contains two samples. You _are_ using stereo, right? And each sample would be 3 bytes for 24-bit audio. Also, in ALSA the period size and block size are the sizes in bytes, not in frames.)
Periods: 2 (one period for playback + one period for recording when determining round trip latency)
In other words, one period per block in each direction?
The minimum round trip latency is: 16 * 2 = 32 samples However, I measured 112 samples round trip latency which is an additional delay of 80 samples (32 + 80 = 112). 112 samples at 48000 Hz is 112 / 48000 * 1000 is approximately 2.333 ms measured round trip latency.
16/3 48 + 109 ~ 3.271 ms
Presumably this indicates three periods, then. Is that two in the outward direction and one in the inward direction, or vice versa?
32/2 64 + 129 ~ 4.021 ms 32/3 96 + 166 ~ 5.458 ms 64/2 128 + 205 ~ 6.938 ms 64/3 192 + 242 ~ 9.042 ms 128/2 256 + 352 ~ 12.667 ms 128/3 384 + 496 ~ 18.334 ms 256/2 512 + 650 ~ 24.208 ms 256/3 768 + 650 ~ 29.542 ms 512/2 1024 + 634 ~ 34.542 ms 512/3 1536 + 634 ~ 45.208 ms 1024/2 2048 + 650 ~ 56.208 ms 1024/3 3072 + 650 ~ 77.542 ms 2048/2 4096 + 633 ~ 98.521 ms 2048/3 6144 + 633 ~ 141.188 ms
As compared to the other systems, it appears that in Linux the additional delay increases with the period size. This could be a result of the initial zero-filled URBs, since the size or number of those URBs may depend on the other settings.
macOS High Sierra, Class Compliant Mode (Apple Driver): 16/2 32 + 205 ~ 4.938 ms 32/2 64 + 205 ~ 5.604 ms 64/2 128 + 205 ~ 6.938 ms 128/2 256 + 205 ~ 9.604 ms 256/2 512 + 205 ~ 14.938 ms 512/2 1024 + 205 ~ 25.604 ms 1024/2 2048 + 205 ~ 46.938 ms 2048/2 4096 + 205 ~ 89.604 ms
What are the USB parameters for these tests? How many bytes/frame? What is the endpoint's maxpacket size? What is the speed of the USB bus?
How would I determine the USB parameters and bytes/frame?
USB port is Intel USB 3.0 port. Device is USB 2.0 high speed (480 Mbps).
Here is the lsusb output:
Both too much information and too little. Instead, let's see the device's entry in /sys/kernel/debug/usb/devices, copied at a time while the test is running. That will omit a lot of irrelevant information and will indicate which of all the possible device settings is the one actually in use.
If you want to get a better idea for exactly what is happening at the USB level, you can collect a usbmon trace while running a test. Also, it wouldn't hurt to see the values of max_packs_per_urb, urb_packs, max_packs_per_period, urbs_per_period, ep->max_urb_frames, and ep->nurbs from data_ep_set_params() in the audio driver.
Alan Stern