No sound when playing via SCO #258
Comments
|
It is possible that SCO traffic is not being accepted on the HCI link between the host and controller. I know this has been an issue with the raspberry pi, so I guess similar issues might affect other boards too. For example, with the broadcom chip used on the rpi, SCO traffic is by default routed through the "PCM" pins, not the UART pins used by HCI. So the host may be sending SCO data through the HCI (so |
|
Thank you so much for mentioning btmon --sco. Here's the output from that. Before connecting: Connection: Playback: |
|
That trace appears to show that bluealsa is correctly sending SCO data to the HCI. Can't tell if that data is "music" or just a "pop", but if there are lots of SCO data packets, and the content is not all zeros, then I think it's reasonable to assume bluealsa is doing its job correctly here. There may be many reasons why the headset does not render the sound, but that's possibly out of scope here, and certainly beyond my knowledge. You should check that the controller is actually transmitting the data it is receiving on the HCI [SCO and A2DP are handled very differently by the controller hardware] - tcpdump is your friend there - and beyond that you might seek advice for your specific board/controller/headset. |
|
I trimmed the audio. There are some zeros at the beginning, but most looks like audio. Thanks for your help. I'll look into a controller problem. |
|
After some digging, I found out we are using the CYW43455 (also called BCM43455) chip, which is the same as is being used in the Pi 3 Model B+ and Pi 4 (confusingly, the original Pi 3 model used a CYW43438). Found the fix you were referring to, which is for the CYW43438 (or BCM43438). Tried their fix even though it was the wrong chipset, and it actually worked to enable audio on the CYW43455 in both hsp-ag and hfp-ag modes, although I am getting popping and audio truncation (might be a separate issue at this point). Thanks a lot! Someone in this thread has also already asked Cygnus for CYW43455 help with the Pi 4, as I guess the workaround isn't helping there: raspberrypi/linux#2229 (comment) This ticket is probably resolved, but I'd like to try out the fix on a Pi 3 (original), and a Pi 4, and see how things work there with bluealsa under Raspbian (vs this embedded chipset and OpenWRT installation) and see if there is truncation. |
|
You should also try the mtu fix for bluealsa, to see if that helps with the sound quality. See #225, specifically my comment here: #225 (comment). I have spent a lot of time and effort researching this MTU issue with linux bluetooth, but have made little progress in finding a generic solution. However, specifically with bluealsa with the BCM43455, hardcoding the MTU to 64 works for me (but breaks if i then use a USB bt adapter). |
|
Was able to recreate the truncated audio on Pi 3 (original, not the B+) with the hcitool cmd fix and bluez-alsa. So, I decided to try the hcitool fix with pulseaudio on the Pi 3. Well, with pulse, the first part of the sound was missing, and the audio quality was atrocious. If bluealsa used any of that code there has obviously been a lot of repair work done. I'll go ahead and create a new bug for the truncation issue. |
|
Fix for the no sound via SCO issue on the CYW43438 and CYW43455 can be found here (thanks to borine for the tip!): raspberrypi/linux#2229 (comment) Sample run (the output was identical for both chips): Closing. |
|
The hcitool call from #258 (comment) is no longer needed since commit 335f48c. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I play via SCO and hsp-ag on my headset I hear a pop, but no actual audio playback. Best I can tell, I'm not getting an error either. The sound file is 16-bit, 8000 Hz.
How I'm playing:
aplay -v -D bluealsa:DEV=E9:08:EF:2D:40:33,PROFILE=sco test_8k.wav, and output:How I'm running bluealsa:
sudo /usr/bin/bluealsa -p hsp-ag, and initial output:Output when BT headset is connected:
Output during playback:
The only configure arg that I used is --enable-debug, as I read in other tickets that mSBC might not be working properly for audio output yet. Also, I think I read that mSBC only applies to HFP?
This is on aarch64. It's an embedded platform, but not a Raspberry Pi. Pulseaudio is not installed. I hear the playback fine if I don't restrict to hsp-ag profile and if I play to A2DP, so that works. If I don't restrict to hsp-ag profile and play to SCO, I again hear nothing.
Due to the lack of errors, I'm assuming more information is needed in order to troubleshoot this. Do you have any recommendations on which source files I should be looking to add debugging code to?
The text was updated successfully, but these errors were encountered: