a2dp profile not available #178
Comments
|
@sviande Would you mind to recreate the logs (bluetoothd, not btmon) with the daemon running in debug mode: |
|
@MarijnS95 please view attached logs, no audio playing in both cases. |
|
It appears the peer changes the configuration with EDIT: Increasing the timeout might work, but I'm not sure how stable it is. In this case I'm assuming the audio application should try more configurations before ultimately bailing; is this happening on PulseAudio or PipeWire? |
|
It's happening on PipeWire. |
|
@sviande It looks like the headset is not compliant: That configuration is mandatory for SBC, except perhaps if there are multiple SBC endpoints and in case of 0x03 it doesn't support such setting, you can use avinfo to capture what are the supported settings for it, it could be that we have to retry or something since the SBC endpoints seems to be given in different order it might be that 0x01 is the SBC indented to cover the mandatory parameters. That said we do send the exact capabilities of the endpoint on the SelectCapabilities so I wonder if PipeWire is ignoring that and parsing the capabilities on the endpoint objects thinking that it must be for another endpoint. |
|
Unfortunately the device replies with quite a few SEIDs which have all been cached, no @Vudentz It is indeed quite possible that ACP SEID 1 and 3 support the same SBC configuration, but the device only "allows" to use one of the two SEPs for it. It'd be great to see a recursive dbus introspection of It's worth trying PulseAudio from Either way it's strange that the device rejects every |
|
avinfo shouldn't care about the cache though, the problem is not the cache itself since we do validate then at reconnection but the fact there are multiple endpoints for the same codec with different capabilities might be confusing as the daemon is not able to select what is best to use, it just pick the first in the list. Anyway if the device really wants to take over and wouldn't accept any configuration from our side that would indeed be problematic since we would never be able to disconnect waiting the remote side to take over which can potentially just sit idle consuming battery. Btw, what model is this? |
|
The headset is a Bose QC35. EDIT: |
|
And here the result of avinfo: |
|
@sviande That However the output from |
|
thanks for the info: |
|
@sviande Looks like BlueZ is going bonkers, not PW. We clearly have node /org/bluez/hci0/dev_04_52_C7_33_E8_F7/sep3 {
...
interface org.bluez.MediaEndpoint1 {
...
properties:
readonly s UUID = '0000110b-0000-1000-8000-00805f9b34fb';
readonly y Codec = 0x00;
readonly ay Capabilities = [0xff, 0xff, 0x02, 0x35];
readonly o Device = '/org/bluez/hci0/dev_04_52_C7_33_E8_F7';
readonly b DelayReporting = false;
};
|
|
It's quite surprising too that both the codec and capabilities buffer are identical for each of the 7 SEPs. Maybe the DBus iterator is repeating old data? |
|
That is weird, maybe the cache is corrupted, try removing the cache file: /var/lib/blueooth// I think we might need to clear the cache if there and error like that since it could perhaps be that the codecs are rearranged after a firmware update which could affect the cache. |
|
Removing the cache /var/lib/bluetooth/ seems to work. Here you can find and Thanks @MarijnS95 and @Vudentz for your help and support 👏 |
|
@sviande Thanks for confirming! The original patch was merely an impartial solution to another problem that helped as a band-aid here, glad it is resolved properly. Did you hold on to the broken cache file so that we can have a look inside? It's probably obvious what we'll find, but interesting for future patch testing nevertheless. |
|
Sorry i remove the cache and think to move it when it was removed :/ |
github-actions bot
pushed a commit
to BluezTestBot/bluez
that referenced
this issue
Aug 3, 2021
If SetConfiguration fails with Unsupported Configuration it might indicate that either the capabilities stored are incorrect or the seid may have changed, so this attempt to invalidate the remote seps loaded from cache when that happens so the next time there is an attempt to discover this will force Get(All)Capabilities to be called and cause the cache to be updated. Fixes bluez#178
github-actions bot
pushed a commit
to tedd-an/bluez
that referenced
this issue
Aug 3, 2021
If SetConfiguration fails with Unsupported Configuration it might indicate that either the capabilities stored are incorrect or the seid may have changed, so this attempt to invalidate the remote seps loaded from cache when that happens so the next time there is an attempt to discover this will force Get(All)Capabilities to be called and cause the cache to be updated. Fixes bluez#178
hadess
pushed a commit
to hadess/bluez
that referenced
this issue
Aug 26, 2022
If SetConfiguration fails with Unsupported Configuration it might indicate that either the capabilities stored are incorrect or the seid may have changed, so this attempt to invalidate the remote seps loaded from cache when that happens so the next time there is an attempt to discover this will force Get(All)Capabilities to be called and cause the cache to be updated. Fixes bluez/bluez#178
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I have a problem with my bluetooth setup, i can't select the a2dp profile for my headset.
I tried the patch from https://patches.linaro.org/patch/285268/ and it works.
You can find the logs of both case with and without patch:
Logs with bluez build from master from arch package
Logs from master without patch
Logs from master with the patch
And the attached btmon
btmonWihtoutPatch.txt
btmonWithPatch.txt
The text was updated successfully, but these errors were encountered: