I haven't done work in the Bluetooth space for years now, but a big problem with audio streaming in the Bluetooth 1/2 days was that devices wouldn't reliably ad

I haven't done work in the Bluetooth space for years now, but a big problem with audio streaming in the Bluetooth 1/2 days was that devices wouldn't reliably adjust their page and inquiry scan intervals (time the radio spends listening for connections and answering device discovery requests, rather than sending data). The effective remaining bandwidth fell far short of what the default Bluetooth codec, SBC, required. SBC was already pretty low end, more like MPEG Layer-1 audio. Even so, for point to point streaming if the devices cooperated well there was enough bandwidth for fairly good audio quality. It's just that it was a crapshoot what any pair of devices would get you. The other big issue is that there wasn't, at least at the time, any standardized method for synchronizing the audio sampling rates of the source and sink. This could have been achieved by slaving the audio PLL to the connection master's frequency hopping clock, which the slave has to follow to even maintain a connection, but there wasn't any requirement to do so. Plus it'd be a massive layer violation in the Bluetooth stack. We basically ran a software PLL on the sink side to try to match what the source was giving us, but packet retransmissions due to loss could gum up the timing. You could get a pitch-bending effect as a connection was starting up, or had just suffered a lot of loss. I imagine they've sorted most of that out by now.