So creating a BT sink for a digital audio system turned out to be very easy.
However it seems that creating a BT source is a lot more difficult. It took me a while until the penny dropped that of course the difference in a BT source compared to a sink, is that the source is usually the master. So it's the sources job to discover the sink and connect to it. Headphones/headsets and BT speakers typically don't have text based UIs and discovery functionality.
This is why you don't find many BT Transmitter type modules out there.
Of course they exist in IC/SoC/daughterboard form. The discovery and paring processes and the textual feedback is handled over the UART console, either by hand or from automation..
This gives me what I need, a way to connect a custom digital audio circuit to a pair of "known" headphones. In that it will be discovering periodically and if it see a pair of "my" headphones it will connect.
It leaves me to pick one and I'm going to start with a FEasyCom module as it's cheap.
However, the reason I'm posting is it got me thinking. There is more to this A2DP protocol surely. Advanced audio distribution. Hmmm. I thought about this when I walked out of reception range of my wireless headphones as I went downstairs and pondered ... can't I just create a repeater? Does BT and A2DP not support roaming of any kind?
So in short... can you use BT sources and sinks in a way to create a distribution network such that wireless headsets work across the whole house? Maybe I don't even need that if the master has a proper SMA antenna it might reach downstairs.
Anyone played around with the more advanced side of BT? Surely some of the home theatre guys using it for remote speakers and people running house wide audio. Have you explored the more advanced side of BT?
However it seems that creating a BT source is a lot more difficult. It took me a while until the penny dropped that of course the difference in a BT source compared to a sink, is that the source is usually the master. So it's the sources job to discover the sink and connect to it. Headphones/headsets and BT speakers typically don't have text based UIs and discovery functionality.
This is why you don't find many BT Transmitter type modules out there.
Of course they exist in IC/SoC/daughterboard form. The discovery and paring processes and the textual feedback is handled over the UART console, either by hand or from automation..
This gives me what I need, a way to connect a custom digital audio circuit to a pair of "known" headphones. In that it will be discovering periodically and if it see a pair of "my" headphones it will connect.
It leaves me to pick one and I'm going to start with a FEasyCom module as it's cheap.
However, the reason I'm posting is it got me thinking. There is more to this A2DP protocol surely. Advanced audio distribution. Hmmm. I thought about this when I walked out of reception range of my wireless headphones as I went downstairs and pondered ... can't I just create a repeater? Does BT and A2DP not support roaming of any kind?
So in short... can you use BT sources and sinks in a way to create a distribution network such that wireless headsets work across the whole house? Maybe I don't even need that if the master has a proper SMA antenna it might reach downstairs.
Anyone played around with the more advanced side of BT? Surely some of the home theatre guys using it for remote speakers and people running house wide audio. Have you explored the more advanced side of BT?
So you have two options with BT:
* BT audio- most BT is limited to 16bit and lower data transfer rates. There are some formats that allow 24bit for example but even the now HQ standard is hamstrung.
*BT data transfer with proprietary sender and receiver units. 2Mbit is an option with HQ..
32bit (24bit) at 192khz in stereo is over 12Mbit supported in USB1 hence having to go to USB2 with UAC2. So BT is too slow.
So 16bit CD rates work with BT but trying anything above is asking for issues and compromises.
Latency is also an issue as a BT is also used for AV so the AV player needs to be able to correct for lipsincing delay.
* BT audio- most BT is limited to 16bit and lower data transfer rates. There are some formats that allow 24bit for example but even the now HQ standard is hamstrung.
*BT data transfer with proprietary sender and receiver units. 2Mbit is an option with HQ..
32bit (24bit) at 192khz in stereo is over 12Mbit supported in USB1 hence having to go to USB2 with UAC2. So BT is too slow.
So 16bit CD rates work with BT but trying anything above is asking for issues and compromises.
Latency is also an issue as a BT is also used for AV so the AV player needs to be able to correct for lipsincing delay.
This would be my only concern in my project.
I know when I connect my Sennheiser BT250s to the TV or the PC, the video I'm watching "twitches" as the headphones are reporting their latency to the AV sync and it's adapting. I assume.
I don't see a way to implement that latency feedback through anything but a point to point BT-BT set up. Even then as soon as you offload the A2DP stream it loses all that meta info anyway.
What I'm aiming for initially is just a headphone hotspot I can send audio to with the intent of it ending up there if the pre-determined list of headphones is present.
The features of BT headphones I'm trying to avoid is, "Which PC will connect first..." and similar problems. Like the PC I'm using doesn't have BT, but the other one does. While the BT250s will connect to 2 masters at the same time, the other ones don't. The idea I had was to centrally route the headphones from any source.
This may not be practical.
Using a custom data stream sounds like an interesting option. Range/signal/bitrate allowed for, it could, potentially be used for low latency. However, knowing just how hit and miss the 2.4Ghz range is, there will be packet loss and without retransmission distortion... with retransmission, latency.