News for hackers. Stuff that matters.
Re:Benchmarking latency across common wireless links for mic... by utopcell on Saturday February 10, 2024 @01:01PM (#39328539)
Great article!

Here's a perspective from a guitarist's viewpoint. Most wireless guitar systems boast latencies below 3ms, with the better ones being closer to 1ms.

Latency is important here because even small delays can be felt by the player. Since sound travels at ~1 ft per 1ms, a delay on the order of BLE is equivalent to playing with the amplifier ~25ft away from you, which is pretty bad.

It is surprising that the best system is actually nrf24, given how old it is (or maybe because of that ?). It also seems to have enough bandwidth to transfer a 24-bit/48kHz signal.

Re:Benchmarking latency across common wireless links for mic... by polishdude20 on Sunday February 11, 2024 @12:51AM (#39332929)
With guitar, how would the latency stack up when you add a/d conversion?
Re:Benchmarking latency across common wireless links for mic... by zh3 on Sunday February 11, 2024 @03:55AM (#39333570)
A/D conversion itself wouldn't add much at the sample level (say 48KHz sample, it's about 50us per sample). However, packetisation will - a 256 byte packet of 128 samples is 128*50us = 6.4ms right there at the transmitter, and the receiver won't notify until the full packet is received. So a naive digital approach would be 12.8ms (2x6.4ms) even before anything else.

A pure analogue approach (modulated RF) on the other hand shouldn't have any human-detectable delay - it's effectively distance/speed of light with a bit of a phase shift (addtional delay) introduced by the electronics - should be only a handful of microseconds in total.

Re:Benchmarking latency across common wireless links for mic... by utopcell on Sunday February 11, 2024 @03:25PM (#39338318)
128-sample buffers are already too large. To compare, the nRF24 has a max buffer of 32 bytes. However, even in your 128 samples, 16bit/48kHz example, latency is a bit better. It will take 1000/48000 * 128 ms to collect the 128 samples, or ~2.66ms. This amounts to 16*128 bits or 2k bits of information that the transmitter will have to send over. At the nRF24 2mbps rate, another ~1ms will be needed to send the buffer over. I'm not sure why you'd think that this time needs to be doubled at the receiver. Even if the nRF24 receiver started moving the buffer after it was fully received, it does so over a 10MHz serial connection, so that would be at most another 0.2ms, for a total of <4ms. For 16-sample buffers and 24bit/48kHz, the end-to-end latency is ~0.6ms.
Re:Benchmarking latency across common wireless links for mic... by polishdude20 on Sunday February 11, 2024 @06:55PM (#39340047)
Wait so you can get the latency down to 0.6 ms end to end?
Re:Benchmarking latency across common wireless links for mic... by utopcell on Sunday February 11, 2024 @09:36PM (#39340799)
That's what a 16-sample buffer would get you. In reality, there are many devices on the market that can get close to 2.5ms. For example, Line 6 claims 2.8 ms end-to-end, BOSS claims 2.3 ms [2], the NUX B8 is at 2.5ms [3].

[1] https://line6.com/support/page/kb/relay-d-v-digital-wireless...

[2] https://www.boss.info/global/support/by_product/wl-20_wl-20l...

[3] https://www.proaudiostar.com/nux-b-8-professional-2-4ghz-gui...

Re:Benchmarking latency across common wireless links for mic... by polishdude20 on Monday February 12, 2024 @12:03AM (#39341554)
What's the drawback of a 16 sample buffer over 128 samples?
Re:Benchmarking latency across common wireless links for mic... by utopcell on Monday February 12, 2024 @01:08AM (#39341967)
Longer buffers allow for jitter in processing further upstream. If you get a buffer every 0.6ms, you need to be able to process it always within 0.6ms.
Re:Benchmarking latency across common wireless links for mic... by polishdude20 on Monday February 12, 2024 @09:32PM (#39353616)
Ah right that makes sense
Re:Benchmarking latency across common wireless links for mic... by zh3 on Monday February 12, 2024 @09:02AM (#39344837)
Agreed, and that's why the "naive" is in my comment :) An even faster is to drop the packerisation and run the transmitter continuously with an appropriate code (self-clocking); the digital radio delay then drops to microseconds. That might in turn make the 48KHz 16-bit ADC seem the limit (21us per sample), one can always use a faster ADC (after appropriate front-end filtering). Out in the real world though error correction is needed, so generally need to use a codec with forward error correction.
Re:Benchmarking latency across common wireless links for mic... by polishdude20 on Sunday February 11, 2024 @06:55PM (#39340050)
Analogue would be nice in that regard but wouldn't it be pretty bad with interference, signal quality over distances etc?
Re:Benchmarking latency across common wireless links for mic... by zh3 on Monday February 12, 2024 @08:53AM (#39344724)
It worked that like for many, many years (radio mics) before digital came along. Think of FM radio - if you have a good signal, it's pretty resilient to interference and in a controlled short range environment it is extremely reliable.