I'm curious how much, if any, this lossless codec improves on FLAC, which naturally we wouldn't want to standardize into the Bluetooth spec because it's well used, open source, and patent free.
Flac isn't used on bluetooth because of computational requirements. One of the biggest problems with bluetooth is extreme low power and low cost decoders that are required as baseline.
Flac is great, but you do need fairly decent computational power to encode it on the fly. Remember: you need both encode and decode components to be effectively real time AND low power + low cost.
If the material is stored on the phone as FLAC, just need to decode at the receiver.
No reason why audio streams couldn't be FLAC encoded at the source too. I expect that FLAC requires a bigger buffer to handle latency, but minor detail nowadays.
And buffer is the single biggest problem with modern wireless. How do you play a game where audio requires a significant buffer? How do you talk on the phone when audio requires significant buffering? These are notably the problems that Qualcomm started solving with their earlier AptX codecs, driving the SBC's typical latency of around 300-400ms down to 150-ish. Second gen AptX LL drives it down to 50-70ms, which is actually good enough for a lot of games that don't require real time sound for survival (i.e. hearing thing open behind you in a competitive shooter, where 70ms latency difference vs real time means you get to turn around to see the guy who kills you vs actually getting a chance to shoot back).
Flac on bluetooth would work for exactly one thing. Sending an existing audio file to a set of speakers/headphones as is. And even then, decoding power at end point would likely become a problem. It's great for long term storage and playback of existing media. It's utterly useless for real time communications in low power, low compute capability scenario that is bluetooth communications.
Reality is, Flac is utterly unfit for purpose because encoding it on the fly with low latency on devices with very limited computational power and low power usage is just not a thing. It's not what it was ever optimized for. As you correctly mention, it would need significant buffering, which definitionally makes it unsuitable for real time audio.
Reality is, Flac is utterly unfit for purpose because encoding it on the fly with low latency on devices with very limited computational power and low power usage is just not a thing. It's not what it was ever optimized for. As you correctly mention, it would need significant buffering, which definitionally makes it unsuitable for real time audio.
I wouldn't say "utterly unfit". 10ms latency for CD audio is 441 samples. You could choose a small blocksize and fixed predictors with FLAC and get very fast, low
Bluetooth as a system and codecs it uses in particular are aimed at tackling a specific fundamental problem. That being computational problem/power problem of digital properly handshaked bi-directional audio. It's exceedingly taxing on both compute and power to encode sound on the fly, send it over wireless, decode in target device and play it back all in real time, all while without needing major buffering for interruptions AND not requiring so much power and expensive decoders that as many devices as reas
Flac is designed to be encoded on a fairly powerful system once, and then decoded as many times on a much weaker system.
Again, you're partially right... I can confirm as the inventor that my intention was to push as much of the complexity of higher compression onto the encoder. But it was carefully designed to not preclude the applications you are describing. Dig into the format some more; the simpler modes are very low complexity/latency and give most of the bang for the buck on compression.
Right. So what are going to be the RAM and Tx/Rx requirements on those supposedly "low compression" modes?
Again. The codecs designed for "encode once, decode many" are categorically unsuitable for bluetooth. What bluetooth needs is "encode once, decode once, with minimal power, compute, memory, and Tx/Rx requirements".
This is simply NOT what "encode once, decode many" codecs are designed to do. In any way, shape or form. You can contort one in extreme ways, such as one you suggest to meet SOME of the blueto
Given its constituency, the only thing I expect to be "open" about [the
Open Software Foundation] is its mouth.
-- John Gilmore
vs FLAC? (Score:2)
I'm curious how much, if any, this lossless codec improves on FLAC, which naturally we wouldn't want to standardize into the Bluetooth spec because it's well used, open source, and patent free.
Re: (Score:2)
Flac isn't used on bluetooth because of computational requirements. One of the biggest problems with bluetooth is extreme low power and low cost decoders that are required as baseline.
Flac is great, but you do need fairly decent computational power to encode it on the fly. Remember: you need both encode and decode components to be effectively real time AND low power + low cost.
both encode and decode (Score:2)
If the material is stored on the phone as FLAC, just need to decode at the receiver.
No reason why audio streams couldn't be FLAC encoded at the source too. I expect that FLAC requires a bigger buffer to handle latency, but minor detail nowadays.
Re:both encode and decode (Score:2)
And buffer is the single biggest problem with modern wireless. How do you play a game where audio requires a significant buffer? How do you talk on the phone when audio requires significant buffering? These are notably the problems that Qualcomm started solving with their earlier AptX codecs, driving the SBC's typical latency of around 300-400ms down to 150-ish. Second gen AptX LL drives it down to 50-70ms, which is actually good enough for a lot of games that don't require real time sound for survival (i.e. hearing thing open behind you in a competitive shooter, where 70ms latency difference vs real time means you get to turn around to see the guy who kills you vs actually getting a chance to shoot back).
Flac on bluetooth would work for exactly one thing. Sending an existing audio file to a set of speakers/headphones as is. And even then, decoding power at end point would likely become a problem. It's great for long term storage and playback of existing media. It's utterly useless for real time communications in low power, low compute capability scenario that is bluetooth communications.
Reality is, Flac is utterly unfit for purpose because encoding it on the fly with low latency on devices with very limited computational power and low power usage is just not a thing. It's not what it was ever optimized for. As you correctly mention, it would need significant buffering, which definitionally makes it unsuitable for real time audio.
Re: (Score:2)
What would be the first in your estimation?
Re: (Score:2)
You have trouble finding huge bluetooth speakers, sound bars and so on? And you should do something about AC going out in your location if possible.
As for the rest, good troll.
Re: (Score:2)
I wouldn't say "utterly unfit". 10ms latency for CD audio is 441 samples. You could choose a small blocksize and fixed predictors with FLAC and get very fast, low
Re: (Score:2)
Bluetooth as a system and codecs it uses in particular are aimed at tackling a specific fundamental problem. That being computational problem/power problem of digital properly handshaked bi-directional audio. It's exceedingly taxing on both compute and power to encode sound on the fly, send it over wireless, decode in target device and play it back all in real time, all while without needing major buffering for interruptions AND not requiring so much power and expensive decoders that as many devices as reas
Re: (Score:2)
Typo: For Flac "as many times" should say "many times". I.e. encode once, playback many times.
Re: (Score:2)
Again, you're partially right... I can confirm as the inventor that my intention was to push as much of the complexity of higher compression onto the encoder. But it was carefully designed to not preclude the applications you are describing. Dig into the format some more; the simpler modes are very low complexity/latency and give most of the bang for the buck on compression.
Re: (Score:2)
Right. So what are going to be the RAM and Tx/Rx requirements on those supposedly "low compression" modes?
Again. The codecs designed for "encode once, decode many" are categorically unsuitable for bluetooth. What bluetooth needs is "encode once, decode once, with minimal power, compute, memory, and Tx/Rx requirements".
This is simply NOT what "encode once, decode many" codecs are designed to do. In any way, shape or form. You can contort one in extreme ways, such as one you suggest to meet SOME of the blueto