News for hackers. Stuff that matters.

A comment on Benchmarking latency across common wireless links for microcontrollers. Parent comment

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...

[ Parent | on HN ]
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?
[ Parent | on HN ]
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.
[ Parent | on HN ]
Re:Benchmarking latency across common wireless links for mic... by polishdude20 on Monday February 12, 2024 @09:32PM (#39353616)
Ah right that makes sense
[ Parent | on HN ]