Open nickajacks1 opened 8 months ago
Right now this library is LE only. If you have a proposal for a cross platform API that supports things like audio then I'd be happy to review it. (Note that because it's a big new API, I'd like to see at least two different implementations. For example, Linux and macOS).
Unfortunately I only have the resources to work with Linux, so if allowing BR/EDR connections would fundamentally break things, I probably won't be able to make an acceptable contribution in the near future. But just in case that changes, I'll ask this...Do you have a high level idea of what I'd need to touch to simply support BR/EDR, without adding APIs for audio etc?
Unfortunately I only have the resources to work with Linux, so if allowing BR/EDR connections would fundamentally break things, I probably won't be able to make an acceptable contribution in the near future.
It's not about breaking things, but rather about making sure the API is designed well enough so that it works on different platforms (not just Linux). Especially since, as far as I know, BR/EDR Bluetooth is often more tightly integrated in the OS than BLE.
But just in case that changes, I'll ask this...Do you have a high level idea of what I'd need to touch to simply support BR/EDR, without adding APIs for audio etc?
What do you mean? BR/EDR, if I understand correctly, only has some very limited uses such as A2DP, headset mode (for calls), and exchanging serial data. It would help if you could describe your particular use case.
What do you mean? It would help if you could describe your particular use case.
Sure, I can get into specifics. I need to be able to discover Bluetooth devices, specifically audio devices, and initiate pairing+connecting. Since audio over BLE is fairly new and not all devices support it, I need to also be able to discover BR/EDR-limited devices such as Apple Airpods. I also want to be able to filter out devices that are not audio-capable. For BR/EDR, this is done using Class of Device, which could rather easily be added to the AdvertisementPayload interface. For LE I assume I can use service UUIDs. For Linux, the story mostly ends there as BlueZ will automatically interact with pulseaudio and pipewire to set up the audio sink.
As far as implementation of BR/EDR scanning, I was thinking that the public API would need only change by adding scan filter parameters to the Scan function.
I apologize if I ask any questions or make statements that seem odd as I'm a Bluetooth novice and have never really worked with BLE before.
Yeah, this sort of thing really needs an implementation on at least two systems to ensure we have a cross platform API. I'd rather not implement something now and then have to break compatibility again once we add support for other OSes.
You are of course free to fork the package and use it for your purposes. Some day we might add cross-platform support for BR/EDR and having a Linux implementation ready might be useful.
I recently obtained a USB adapter for Windows. Maybe someday I'll open a PR for this 😀
Will this package function well with BR/EDR connections, or does it make assumptions that everything is LE? This is a nice library, and I'd like to utilize it for cases such as pairing with audio devices that don't support LE (airpods, etc).
If it won't break the entire world, I could make a PR to add scan options to specify the transport, which is currently hardcoded to
"le"
.