Underruns without restarting bluez-alsa? #265
Comments
hrc-amilcar
changed the title
hrc-amilcar
changed the title
|
I'm continuing to try to debug this issue. I pulled the latest at ec4775d and things are behaving a little differently. The device seems to recover after some time of robotic bleeps and bloops, but it does seem to recover. EDIT: I take that back. It's not recovering. But now, there is a perpetual RFCOMM poll timeout after connecting a device, even before opening a PCM. Is this a benign debug log? |
|
Hi, I've just fixed two issues found in the logs you've provided, but I think that these were not essential ( Regarding original issue, unfortunately, I don't know what might cause such problem. I see that you are using SCO connection, so you might try to look at this (search for "MTU"): #258 |
|
Please try branch: https://github.com/Arkq/bluez-alsa/tree/hsp-fix and tell whether it will help. The crucial part is the top commit: b1ab34e |
|
Thank you for that. I pulled b1ab34e . The RFCOMM poll timeout logs are no longer happening, but I continue to get the same phenomenon. As soon as I connect a second Bluetooth device while there's a currently open stream, the open stream goes into perpetual underrun. It's as if something is corrupting the active stream, or the CPU usage for adding the new device causes something to get out of sync. EDIT: I'll look into #258 as well. Perhaps there are more clues from these logs: |
|
It seems I'm able to get into a state where a particular headset (Zebra HS3100) gets SCO underruns all the time. I see a new error in the logs, but from bluetoothd this time. Any clues as to what 'sdp_extract_arr' error could mean in the context of BlueAlsa? This is upon connection, before opening playback/capture streams: |
|
In attempting to debug this issue, I've added some logs to the PCM plugin to see why it's getting into a perpetual underrun condition. The first letter of the log is either 'R' or 'W' for read or write. I noticed that the shadow copy of Do you have any clues as to why |
|
An update to whom it may concern. It seems that something in the HCI controller is affecting audio performance when there is simultaneous communication between multiple devices, even when simply connecting a second device while streaming to/from the first. I found this bug post that talks about a similar issue, which may point to a bug in bluez or elsewhere in the bluetooth stack but not related to BlueAlsa. The bug was reported in 2009 but some people are still having issues even 10 years later. The suggested mitigation is this: Audio still stutters sometimes, but there are rarely any underruns now. I'm still trying to understand why changing those modes helps. |
|
I'm closing this issue, since it seems, that it's not related to bluez-alsa. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello. I'm using bluealsa (master 740886b) to implement a VoIP app for Bluetooth Headsets. I listen for PCMAdded/PCMRemoved signals and display a list of available SCO devices to the user. The user selects a device and opens a call.
Note unrelated to the title of the post: It would be convenient if the PCM properties reported the ALSA Mixer names (SCO, A2DP, Battery) so that I wouldn't have to recreate the naming/numbering scheme programmatically (e.g. Savi 7xx #2 - SCO).
I am testing various brands/models of headsets. Things work fine the first time for any particular headset. But if I switch between headsets without restarting bluealsa, I get underruns for certain models. I'm handling -EPIPE and using snd_pcm_prepare then retrying the snd_pcm_readi/writei as a typical ALSA app would do.
It could very well be something in my ALSA handling code, but the fact that using a particular headset first causes another to fail without restarting, could point to something in bluealsa not releasing or resetting something properly?
Any hints are appreciated...
Here are some logs from bluealsa in DEBUG mode:
The text was updated successfully, but these errors were encountered: