End of audio being truncated when playing via SCO #260
Comments
|
One of reasons, why the audio is truncated, might be lack of "drain" functionality for SCO. See this: https://github.com/Arkq/bluez-alsa/blob/c39fd33f005cd46f8d324f12a0726df5801840f6/src/io.c#L2352 Try to increase this delay and see what will happen: https://github.com/Arkq/bluez-alsa/blob/c39fd33f005cd46f8d324f12a0726df5801840f6/src/ba-transport.c#L705 |
|
I increased it to usleep(1000000) and it worked! I don't know if that is the optimal value (too long or maybe still too short, I'll have to take a closer look with btmon), but it sounded like it played all of it. It's funny, because I'd played around with this line of code before when trying to solve that portaudio truncation issue. I didn't realize at the time it was for SCO. Thanks! |
|
This sleep is not for SCO only, it is for bluetooth communication in
general. The problem is, that there is no sync/flush mechanism (or I'm not
aware of such). The only thing we can do, it is to wait and pray that
everything will be played out. There is one potential solution to this
problem. Play silence for few seconds after PCM disconnection. However,
right now it will be hard to implement. Firstly I have to make a mixer
inside bluealsa so more than one stream could be played simultaneously.
Then it will be very easy to add extra silence, which will flush PCM
buffers :)
|
|
I'm closing it for now because it's not an easy fix.... Please use increased |
When I play audio via sco, the end of the audio is truncated. This happens regardless of profile (so not specifying profile, or specifying -p hsp-ag or -p hfp-ag all still experience truncation). If I play using a2dp there is no truncation.
This occurs with hardware with two Broadcom / Cypress chipsets: A Raspberry Pi 3 (CYW43438 chipset) and an embedded board (CYW43455 chipset, which is also used in the Pi 3 B+ and 4). I am using an hcitool cmd hack from here raspberrypi/linux#2229 (comment) in order to reroute the audio properly for SCO. On the CYW43455 system, libasound was compiled with --disable-thread-safety.
Example command line:
aplay -v -D bluealsa:DEV=E9:08:EF:2D:40:33,PROFILE=sco test_8k.wavWhen comparing the audio file with the output of
sudo btmon --sco, this is the last audio data from the file that appears to be sent. From what I can tell btmon outputs "<" for data sent to SCO, and ">" for responses (the TX and RX also back that up):These are the messages directly after that. There are 3 response messages, followed by a disconnect. It seems that the truncation is happening because it's disconnecting early.
I'd like to know why the disconnect occurred. Was it from bluealsa, aplay, or my Bluetooth chip? Did some kind of error occur? I'm not seeing any errors in the bluealsa or aplay output. I'm mostly not really sure which files or functions to even start to look at. Can anyone offer some guidance on where I should start to look in the bluealsa code? Thanks!
The text was updated successfully, but these errors were encountered: