11–20 of 145 posts
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)
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)
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)
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.
I don't mind compressing a phoneme to as much as I would mind it compressing it to a clearly audible different phoneme.
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)
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.
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)
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)
>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…
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).
One thing I'm slightly worried about "machine learning" in compression rather than conventional everything-is-sines mathematical approaches is the possibility of odd nonlinear errors. Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers? I don't mind compressing a phoneme to as much as I would mind it compressing it to a clearly audible different phoneme.
For those who don't remember: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_...