Bluetooth audio generally uses one of two "profiles"; there's A2DP, and generally sounds fine. I've not noticed the compression. A2DP is one-way, audio output only.
There's also HSP, which is two-way (mic+headphones, essentially), and it sounds like a potato.¹
(I have no idea why this is, either. My brother once "solved" the quality issues of HSP by getting a second headset, putting both headsets on his head, putting one in HSP and using the mic from that one, and putting the other in A2DP. It worked fine, aside from it wasn't comfortable and it looked ridiculous. He was on Windows, but I have the same issues in Linux and OS X.)
Short answer is no. I'm not really sure why so many try to hate on bluetooth audio. But don't take my word for it, hear for yourself. You can first read up some on it[0] Then get the needed tools to encode audio into the exact same format that your headphones would see [1]
Hopefully, you have an uncompressed wav file to test with. Unfortunately, the sbcenc command wants the wav in the uncommon big-endian format. Not worries, just do: "ffmpeg -i test.wav test.au" and it will convert it for you. Now feed that .au file into sbcenc:
"sbcenc -B 16 -s 8 -j -b 51 test.au >test.sbc"
That is the default scheme for "bluetooth high quality". Personally I have not found a difference in the sound. Of course note that the audio encoding is adaptive, so if you put on your bluetooth headphones and walk 50 ft away, yea it might sound bad...
My real problem with BT is how unreliable it is. I'd like to find someone who never had an issue pairing some earphones or headphones and had it working flawlessly every time.
There are many variants of BT audio and they don't all work the way you would expect. It's still not rare to end up with lag if your combination of hardware, software and receivers don't have compatible technologies like aptX.
For me the unreliable and lengthy pairing process is the major pain. Takes out the earbuds, wait at least 10-20s to get them connected, then wait another 10s for the phone to realize it needs to output to the earbuds. More often than I'd like, I have to put back the buds in their case and take them out again to force a reconnection because the phone or one of the buds said it was connected but isn't getting any sound...
And I'm not talking about a cheap Chinese Android phone with a pair of crap $20 earbuds. I'm talking about iPhone 11 Pro with Sony 1000XM3.
It's not the equipment, had similar issues with an iPhone 8 and Bose headsets, and with various dongles and computers.
A friend recently thought his new Sony WH-1000XM4 headphones were not working and asked me to have a look. Took me 15 minutes to hook them to Windows properly. Turns out there are multiple devices that appear (but not at the same time) during the pairing process and if you connect to the BLE stack, you don't get the headphone functionality... (what functionality you get is a mystery) and of course, no mention of that in the documentation.
Wireless audio is important enough that we shouldn't have to settle for these subpar experiences. Although BT has made progress on the audio front by providing protocols with lighter overhead and latency, it's still not particularly suited for audio (no high quality transmission, mono/stereo only, no multicast, lengthy connection, ...)
>My real problem with BT is how unreliable it is. I'd like to find someone who never had an issue pairing some earphones or headphones and had it working flawlessly every time.
The first project I worked on was for elderly care[0], with a fitness tracker we would connect with over Bluetooth Low Energy (BLE). The first things I had done was to request the manufacturer's communication protocol for that device and then abstract that away in a nice library so we could control the tracker with Python functions `tracker.start_ecg()`, etc.
The second part was dealing with all the weird connectivity problems, troubleshoot, and add helpful exception messages for others. Here's an example:
message = """
We were unable to connect to the device {}{}{}...
Bluetooth devices are tricky and even when you do everything
right, you can still get this exception. Here are a few things
to consider:
- Simply retry to connect.
- Check `rfkill list`: it will tell you whether your device
is blocked or not. If it is indeed blocked, you can run:
`\x1b[33mrfkill unblock bluetooth\x1b[0m` to unblock it.
- Check `hciconfig`: it will tell you whether your device is
down or up. If it is down, you can raise your device:
`\x1b[33msudo hciconfig [hci0|hci1] up\x1b[0m`.
- You can also restart the bluetooth service:
`\x1b[33msudo service bluetooth restart\x1b[0m`.
- Calling Bluetooth.connect with the wrong hci_device param
can result in this exception, too. Check which device is
active and call the method with that one.
- Take a deep breath, you'll probably get this often.
"""
I don't understand your comment. Are you referring to the error message? If yes, that is targeted to the developers using the library that controls the device. i.e: us. The library helps us talk to a device by abstracting away low level details.
It’s gotten a lot better recently. But you do have to remember to unpair the last device before trying to use a new device because you can only connect one thing at a time.
In case that wasn't a rhetorical question, I use a Sennheiser 4.50BTNC every day and it works flawlessly, both on my phone and on my Linux computer (through a generic USB adapter).
1. Audio quality is not as good as my older same price headphones (3.30 I think), even with noise cancelling turned off. Apparently the 4.40 is better in this regard at the cost of losing the noise cancelling feature.
2. It can connect to two devices at once in a mostly intelligent manner, e.g. your phone and laptop where the laptop is playing music but the phone takes priority for calls or noisy alerts or alarms. But if one of these devices disconnects, its going to interrupt your audio every 2 minutes to say "Disconnected" until you reboot the headphones and connect just your new device(s). This has caused trouble with my Surface Go waking up from sleep, connecting automatically, then going back to sleep and disconnecting, disrupting my music listening.
If you want to skip the intermediate file and do it all in one go, you can pipe directly to stdout with ffmpeg if you give it sufficient information to make up for the loss of file name hints. I’ve never used sbcenc, but .au defaults to signed 16-bit big endian which you can specify and pipe (so as to skip the intermediate file) as follows:
ffmpeg -i input.foo -f s16be - | sbcenc ...
EDIT:
gstreamer supports encoding to SBC directly, from whatever input format you have (its sbcenc plugin takes signed 16-bit LE PCM, but it can losslessly convert between audio/video formats on-the-fly):
This. I've noticed Bluetooth quality issues, and they are always either
- The source is using low bitrates. SBC is a poor codec, but at the high bitrates (bitpool values) it should be used at it sounds perfectly fine.
- Just shitty hardware/DSP. If your Bluetooth speakers sound different over bluetooth than over line in, then the DSP/DAC processing going on in them is what is screwing up the audio, not the codec.
"High quality" Bluetooth audio codecs are largely a marketing scam to get patent royalties, because it seems that when a standard actually manages to mandate a royalty free codec (a rarity these days!) companies just can't help but try to jam patented nonsense down people's throats anyway. I'm sure some products even deliberately gimp SBC just to make proprietary alternatives sound better.
LC3 is the new audio standard for Bluetooth 5.2 and up, but when I read the Bluetooth SIG claims it provides better quality at comparable bitrates to a long list of codecs that ended with "and Opus," I had to laugh and close the tab.
For those that don't know, Opus is pretty much the current gold standard for freely available audio formats that are at least partially designed to operate at the very lowest end of the bitrate spectrum while delivering comprehensible audio; unless LC3 is also using SILK but just under a different name, I'd be extremely shocked to find it actually beats Opus.
On that topic, when I get fully set up after my move, I'll have more time to devote to my A2DP Opus mode.
I think it's actually not crazy to decode Opus on Bluetooth chipset DSPs, even all the way up to the maximum bitrates.
One nice thing about this as well is that adding surround sound modes shouldn't be that hard, I think it would be the first surround sound A2DP configuration.
That test is indeed laughable, I read their materials, and it looks like they crippled the Opus encoder, which was already on old release before they used it. Opus 1.3 at an ordinary complexity is doubtless better than LC3, and there are actual encoders and decoders that you can just download and port yourself.
There is a fork of the PulseAudio Bluetooth modules that supports LDAC, AAC, AptX, and AptX-HD. LDAC should be supportable upstream, I think it's coming.
On a side note, LDAC is so laughable. I have to imagine the engineers working on it had a lot of laughs. It has all the "high resolution audio" mumbo jumbo that Sony has marketed to audiophools for decades, and it is hilariously inefficient.
