bluez-alsa
bluez-alsa copied to clipboard
arkq
Periodic scanning while playing - possible?
Bluealsa is working great for me, streaming internet radio from a Raspberry Pi to Bluetooth speakers.
I've integrated it into an open source privacy-focussed smart home system. One of the new features of that system is that it can detect Apple Airtags that haven't seen their owner in a while, as a form or protection against stalking.
Currently it scans for bluetooth devices one second every minute - the lowest duration I am able to do a scan for. But even scanning for just one second causes stutter in the audio playback.
My goal is to have some buffering happen that can help gloss over the scanning. I've tried playing with the delay value in asound.rc
#defaults.bluealsa.delay 100000000
defaults.bluealsa.delay 100000
But it had little effect, and I realise I really don't know what is wise here. I'm not even sure it's possible; wouldn't the buffering need to happen on the speaker? Can Bluealsa request speakers to buffer for at least a second?
Do you know if this is possible, and if so, do you have any recommendations on how to go about it?
I'm afraid that it is not possible to overcome this stutter caused by scanning. If I remember correctly, this kind of issue is quite common on RPi (with on board BT chip). One of the solutions is an external BT dongle. The other solution would be buffering on the receiver side (A2DP sink), which is in your case BT speaker (buffering on RPi will not resolve this issue, I think), but A2DP spec does not define such a feature.
defaults.bluealsa.delay 100000 But it had little effect, and I realise I really don't know what is wise here.
In your setup it will have not effect at all, I think. This delay is used by players to synchronize A/V. By setting this parameter to higher values, you are telling player (if it checks for audio delay) that the audio will be hearable after X number of frames (delay cased by buffering in speaker, audio encoding, decoding, etc.) But it does not increase any buffer. It is only for manual tuning.
I would suggest to read some RPi forums, maybe someone has a solution for this issue, I don't know, maybe you should tune UART baudrate with hciattach....
Thanks, that clears it up.
buffering on RPi will not resolve this issue, I think
I'd like to test that to be absolutely sure. Any tips on how to increase this buffer?
defaults.bluealsa.delay
Shall I set that value to 0, or just leave it undefined?
Shall I set that value to 0, or just leave it undefined?
defaults.bluealsa.delay is actually defined in /etc/alsa/conf.d/20-bluealsa.conf, so no need for you to define it yourself unless you need to change the value.
I've never tried this myself, but I came across an article suggesting that it is possible to reduce the BT traffic caused by scanning by using "passive" scanning. This post: https://github.com/IanHarvey/bluepy/issues/198 discusses it. I don't know if that is directly helpful to you, I guess it depends on which tools/libraries you are using for the scan.
Has there been any further progress with this? It would be useful for others to know if you have found a way to perform scans while bluealsa is playing, and if so, any special steps you needed to take to achieve it.