Hacker News Reader

Comment by robert_foss | Hacker News Reader

Encoding takes >40ms? Opus takes 5-26.5ms. Apparently 150ms[1] is the generally accepted upper bound for call latency.

I think the article could do with some bandwidth/quality/latency/power comparisons to other codecs.

[1] https://en.wikipedia.org/wiki/Latency_(audio)

Ya I was just coming here to say the same thing. 40ms _just in the codec_ feels like a lot. Because that's not even including time to pull in audio from the hardware (could be 20ms or more in Android devices), time to upload, and time to have it across the Internet, and then time to decode + play on the receiver. That adds up pretty quickly. I'm guessing 40ms was chosen because it is some sweet spot of having enough data to get a worthwhile compression on, but it's one of these things where technology, however impressive it might be, is slowly giving us a worse experience over time in the pursuit of digitization.

From my understanding the 40ms is just the feature extraction part. The encoding also does quantization, which surely adds to this number.

>These speech attributes, also called features, are extracted in chunks of 40ms, then compressed and sent over the network.

So while Encoding doesn't take 40ms, the latency + encoding will indeed be 40ms+.

150ms is the End to End Latency, which is basically everything from Encoding + Network + Decoding. We cant beat the speed of light on our fibre network. We can certainly do something with Encoding and Decoding. And Lyra doesn't seems to help with that case here. Something I pointed out last time Lyra was on HN.

I think Opus default to 20ms with option of 10ms slot ( excluding Encoding speed ) at the expense of quality. What we really need is higher bitrate, lower latency and higher quality codec. Which is sort of the exact opposite of what Lyra is offering.

> We cant beat the speed of light on our fibre network.

Speed of light in what? We can absolutely be faster than fibre optics, which are quite slow relatively speaking (2/3rds that of light in a vacuum).

We wont be replacing Glass Fibre with Vacuum Fibre anytime soon. And I have been following this tech for long, but I do wish I am very wrong.

Starlink ?

Satellite links are orders of magnitude slower than fiber.

> Satellite links are orders of magnitude slower than fiber.

Minimum end-to-end latency for communications from opposite points of the earth is much lower for Starlink style LEO satellites than for fiber.

Which is only in the case of "opposite points of the earth", otherwise you are just adding ~700KM of distance between two point. The point is even if we have perfect Speed of light Data Transfer over a direct line, we are fundamentally limited by it and nothing can be done. But Encoding, Decoding, Time Slots and quality are everything that we have control of and should be look into more seriously.

Aren't they still heavily expected to feature in connecting that "next billion" ?

Yes, because they are convenient for other reasons (don't require infrastructure over land) which makes them suitable for connecting rural areas where it doesn't make sense to run fiber. But fiber will always be the fastest you can get, and if you get fiber in a vacuum, you could theoretically achieve near-speed of light communication. Satellites won't get you anywhere close to that, even if you use lasers, because there is always atmospheric disturbances that introduce latency.

Internet latency is much higher than it could be, even using fiber: https://arxiv.org/abs/1811.10737

And adding an HFT-style microwave backbone could reduce Internet latency even more: https://arxiv.org/abs/1809.10897

There is no such thing as 5ms VOIP audio latency at 6 Kbps, the IPv4+UDP headers would amount to 44.8 Kbps at minimum, so it's irrelevant if one encoder is tuned to be able to encode 5 ms chunks instead of 40 ms chunks. 40 ms intervals requires a minimum of 5.6 Kbps + the codec rate.

I.e. at 10 Kbps it's impossible to have a lower VOIP latency than 32 ms. Likely the 40 ms number they tuned for in the real world.

The favorite way to cheat compression contests. Buffer more data, get more compression.

I don't think it is discussing encoding time in the article, it says "features are extracted in chunks of 40ms". My reading is that its breaking down the speech into 40ms chunks, compressing it, and sending that.

But since the buffer size has to be 40ms then so the minimum latency is 40ms

Sure latency ends up being 40 ms but that's a function of needing to wait to send the encoded data + network headers at 6 Kbps not a function of the encoder being slow holding everything up.

Yeah, AMR (for GSM) is 10ms as well.

Reply on news.ycombinator.com