Audio over Bluetooth: most detailed information about profiles, codecs, and devices...

[Degru]

That means that the moment you start to stream app 1Mbps,

We are literally already streaming 990kbps LDAC without any of the disastrous power usage implications you are referring to. It's not that much of a stretch to stream 1411kbps instead for true lossless 16/44. I mean, it's 2019 and we're throwing gigabits over WiFi and cellular, surely Bluetooth can be scaled up just a little more.

The main concern regarding power is the codec used. This is why, say, FLAC can't be used and all of the Bluetooth codecs besides AAC are not psychoacoustic. But uncompressed audio doesn't exactly need much decoding so that isn't an issue. It's just a question of how consistently and at what range the Bluetooth implementation will be able to hit 1.4mbps+overhead, since there won't be any dynamic bitrate adjustment possible.

 

[Soniclife]

Has it been confirm independently that 999kbps LDAC is lossless for 44/16? The Sony marketing material suggests it is, but they way they say it makes them sound like lying weasels to my cynical mind.

 

[Degru]

Has it been confirm independently that 999kbps LDAC is lossless for 44/16? The Sony marketing material suggests it is, but they way they say it makes them sound like lying weasels to my cynical mind.

It's not completely lossless, but it's close enough IMO. Even 660kbps is still better than what my built in ADC can measure outside of a bit of IMD in the very high treble. All that hi res stuff is bullshit though, humans obviously can't hear that high.

 

[BillG]

We are literally already streaming 990kbps LDAC

Under optimal conditions, and given the all the situations that a smart device would be used in, they won't always be.

Here's an interesting article, with some response from a Sony employee, about LDAC:

https://www.avhub.com.au/news/sound-image/what-is-sony-ldac-and-how-does-it-do-it-408285

 

[Degru]

Under optimal conditions, and given the all the situations that a smart device would be used in, they won't always be.

Here's an interesting article, with some response from a Sony employee, about LDAC:

https://www.avhub.com.au/news/sound-image/what-is-sony-ldac-and-how-does-it-do-it-408285

I always use LDAC forced to quality mode and don't have any more dropouts than plain SBC. Like I said, it's not unreasonable to scale Bluetooth up enough to be able to do 1.4mbps consistently; it's 2019 guys come on.

 

[Frank Dernie]

I only use bluetooth on the bus or, very infrequently, walking my dog.
I have used wireless ear buds but recently got B&W LX whilst they were in a sale. They have noise reduction too.
I think almost everything about them, from the 'phone's response to background noise make a bigger difference than any loss of quality due to bluetooth codecs. I find the SQ more than adequate and the lack of wires splendid in the extreme
At home I listen almost exclusively to speakers through a very conventional wired system.

 

[Krunok]

We are literally already streaming 990kbps LDAC without any of the disastrous power usage implications you are referring to. It's not that much of a stretch to stream 1411kbps instead for true lossless 16/44. I mean, it's 2019 and we're throwing gigabits over WiFi and cellular, surely Bluetooth can be scaled up just a little more.

The main concern regarding power is the codec used. This is why, say, FLAC can't be used and all of the Bluetooth codecs besides AAC are not psychoacoustic. But uncompressed audio doesn't exactly need much decoding so that isn't an issue. It's just a question of how consistently and at what range the Bluetooth implementation will be able to hit 1.4mbps+overhead, since there won't be any dynamic bitrate adjustment possible.

Basically I think you are right - it seems not that this problem cannot be solved but that the industry is not very interested in solving it. Maybe they know something we don't - perhaps there is simply not enough interest in the market for losless portable products and for the non-portable products WiFi will do better job anyway.

 

[sajunky]

I'm not sure if you understand that, no matter how smart power management you implement, power consumption of the BT, and every other wirelss technology, is proportional to the ammount of data been sent plus some overhead to keep the connection alive. That means that the moment you start to stream app 1Mbps, which you need for compressed losless audio like FLAC, BT will start to consume much more energy than what it is consuming now and most devices simply wouldn't be able to handle that.

Streaming device consume more power, this is fine for the smartphone with a large battery. Receiving device like headphones consume less power. I don't understand why there is still no mandatory loseless transmission specification in Bluetooth. I'd like to take your attention to the alternative MAC/PHY introduced already in BT v.3. Bluetooth radio is only used for discovery, initial connection and profile discovery. Incidentally(?), most of current (if not all) Bluetooth cards in laptops are now combo with WiFi.

I suspect the WiFi PHY is used all the time when I do play music from Huawei Y6 2018 phone (Qualcomm chipset) with Sennheiser HD 4.40 BTNC headphones. I can walk away 25 meters (two walls) before music start breaking, exactly the same range as a WiFi hotspot from the phone. Buttons changing a track do not work anymore, but music do not break. This make me think that Sennheiser has built-in WiFi receivers (which is not shown in specs). When I stream from a laptop (Intel AC 3165 combo card- also Qualcomm chipset), music breaks at 10m (the same room), typical for BT transmitters, so it is a matter of driver implementation as well.

 

[Krunok]

I don't understand why there is still no mandatory loseless transmission specification in Bluetooth.

My guess is that young generation, who make most of the customers, doesn't care about loseless.

 

[somebodyelse]

I've got the 'HD audio: SBC' option in LineageOS 16, but nothing that can make use of it. It's interesting to know about in case I do get a bluetooth headset though, or if I connect to anyone else's device.

On another front I'm surprised none of the manufacturers have demanded Opus support in bluetooth audio. For a given bit rate it's at least as good as AAC, and the latency's lower even than any AAC or AptX variant so good for high quality voice. A computing resource limitation, or that those with the power to change it would rather a codec they can charge for?

 

[BillG]

I'm surprised none of the manufacturers have demanded Opus support in bluetooth audi

That's because it utilizes psycho-acoustics for its encoding scheme. With the exception of AAC, which Apple uses for Bluetooth, none of the other codecs rely upon psycho-acoustics for their theirs and utilize pure data compression instead.

 

[somebodyelse]

That's because it utilizes psycho-acoustics for its encoding scheme. With the exception of AAC, which Apple uses for Bluetooth, none of the other codecs rely upon psycho-acoustics for their theirs and utilize pure data compression instead.

I'm missing something about the relative merits of codecs. Why's it OK for Apple to use pyscho-acoustics in their preferred codec, but not for others? And what do you mean by 'pure data compression'? To me it implies lossless, which none of the currently used codecs are.

 

[Soniclife]

I'm missing something about the relative merits of codecs. Why's it OK for Apple to use pyscho-acoustics in their preferred codec, but not for others? And what do you mean by 'pure data compression'? To me it implies lossless, which none of the currently used codecs are.

Android supports aac as well, my phone does it fine.

 

[somebodyelse]

Android supports aac as well, my phone does it fine.

In the context of the question it doesn't really matter which manufacturer or device it is. I don't understand why use of psycho-acoustics in the encoding is a problem for Opus but not for AAC when it comes to Bluetooth. On closer reading of the original article I see "SBC is a simple and computationally fast codec with a primitive psychoacoustic model (with simple auditory masking) using adaptive pulse code modulation (APCM)." so that's using it too.

 

[Soniclife]

In the context of the question it doesn't really matter which manufacturer or device it is. I don't understand why use of psycho-acoustics in the encoding is a problem for Opus but not for AAC when it comes to Bluetooth. On closer reading of the original article I see "SBC is a simple and computationally fast codec with a primitive psychoacoustic model (with simple auditory masking) using adaptive pulse code modulation (APCM)." so that's using it too.

My guess is it's about decoding CPU use, hardware support for that decoding, and a large amount of big companies lobbying for what they want in the spec. It's probably beyond pure logic.

 

[ZeDestructor]

Right, oreo and later has it, but what about headphones, receivers, etc.?, what they get is a larger user base, at the beginning only sony smartphones were enabled.

LDAC is Apache 2.0 licensed, which is free, open-source, and free of patent bullshit, so it'll be rolling out into devices as the BT receiver chips add LDAC support in, and those chips in turn filter down to devices.

 

[sajunky]

LDAC is Apache 2.0 licensed, which is free, open-source, and free of patent bullshit, so it'll be rolling out into devices as the BT receiver chips add LDAC support in, and those chips in turn filter down to devices.

It still require certification from Sony and a cost is hidden. Not sure whether sink devices are covered under a license. The library contains headers for coding and encoding, but Android phones do not support LDAC sink mode, so they can't work for receiving. Similar is with the entire Windows Bluetooth stack, not only LDAC codec.

 

[ZeDestructor]

It still require certification from Sony and a cost is hidden. Not sure whether sink devices are covered under a license. The library contains headers for coding and encoding, but Android phones do not support LDAC sink mode, so they can't work for receiving. Similar is with the entire Windows Bluetooth stack, not only LDAC codec.

As I understand it, it's similar to how Android does it: you need Sony certification/licensing to use the LDAC™ logo and trademark on your device, but you are entirely free to implement the ldac codec and ship it quietly otherwise. If you couldn't, that would be in very flagrant violation of the Apache 2.0 license I believe (IANAL, etc).

PulseAudio + bluez (bluez is the underlying BT stack of Android I believe) already have LDAC support built in for both sink and source modes (they also have aptX+variants, and AAC, but you have to go get your licences from Qualcomm and MPEG-LA respectively if you want to use those without being sued).

As for the Windows, and Android BT stacks, those are much more limited. In fact, MS recently straight up removed the HFP/A2DP sink profiles completely from Windows desktop, which sucks if you want to do something fun with phone and audio routing.

 

[Degru]

As I understand it, it's similar to how Android does it: you need Sony certification/licensing to use the LDAC™ logo and trademark on your device, but you are entirely free to implement the ldac codec and ship it quietly otherwise. If you couldn't, that would be in very flagrant violation of the Apache 2.0 license I believe (IANAL, etc).

PulseAudio + bluez (bluez is the underlying BT stack of Android I believe) already have LDAC support built in for both sink and source modes (they also have aptX+variants, and AAC, but you have to go get your licences from Qualcomm and MPEG-LA respectively if you want to use those without being sued).

As for the Windows, and Android BT stacks, those are much more limited. In fact, MS recently straight up removed the HFP/A2DP sink profiles completely from Windows desktop, which sucks if you want to do something fun with phone and audio routing.

This makes it even more perplexing why Motorola explicitly removed LDAC from the Moto G6 and G7 when they updated to Pie...

 

[edechamps]

On another front I'm surprised none of the manufacturers have demanded Opus support in bluetooth audio. For a given bit rate it's at least as good as AAC, and the latency's lower even than any AAC or AptX variant so good for high quality voice.

You forgot to mention that Opus degrades gracefully in the face of packet loss and can change bitrate dynamically without any glitching. One could not dream of a better codec for wireless transmission. I would kill for the Bluetooth industry to support Opus, but it doesn't look like anyone cares. (Or maybe it's just too computationally intensive, I don't know.)