On Friday 26 April 2019 16:44:03 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Fri, Apr 26, 2019 at 1:55 PM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > > > On Friday 26 April 2019 13:09:00 Luiz Augusto von Dentz wrote: > > > Hi Pali, > > > > > > On Fri, Apr 26, 2019 at 11:34 AM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > > > > > > > On Friday 26 April 2019 11:20:26 Luiz Augusto von Dentz wrote: > > > > > I have an assert when I use a different headset which does support apt-X HD: > > > > > > > > > > https://gist.github.com/Vudentz/0d6b6f2ad08524db69a3e223e26bc80d > > > > > > > > I have not tested aptX HD, nor aptX Low Latency. I tested only (classic) > > > > aptX. I looked at code and there is incorrect calculation of buffer > > > > block size for aptX HD. Try following: > > > > > > > > static void get_buffer_size_hd(void *codec_info, size_t link_mtu, size_t *decoded_buffer_size, size_t *encoded_buffer_size) { > > > > /* aptX HD compression ratio is 4:1 and we need to process one aptX HD sample (6 bytes) at once */ > > > > *encoded_buffer_size = (link_mtu/6) * 6; > > > > *decoded_buffer_size = *encoded_buffer_size * 4; > > > > } > > > > > > Will try, btw if I disable aptX HD it attempts to pick up UHQ2 but it > > > asserts as well: > > > > > > https://gist.github.com/Vudentz/0e91f3ba260211cab38822bcf04edd1f > > > > > > It seems that fill_preferred_configuration and can_accept_capabilities > > > are not agreeing with one another > > > > When fill_preferred_configuration or can_accept_capabilities fails it > > prints debug message about it. But I do not see any of them in your > > output. So I think problem can be somewhere else. > > > > I have not got this assert for uhq2, so this looks like some race > > condition. > > > > > so we got a transport but no profile. > > > > In your log is: > > bluez activated sbc_uhq2, then module-bluez5-device started to be > > loading, card.c chose a2dp_sink_aptx as initial profile and due to bug > > in module-bluetooth-policy.c aptx was not changed to sbc_uhq2. Next > > sbc_uhq2 was released and prepared for switching to initial profile > > aptx. And then assertion failed. > > > > My guess is: because card.c was not fully initialized yet (it called > > hook for choosing initial profile), which called code for switching > > profile, then u->card->profiles was not fully initialized and crashed. > > Profile switching should be probably allowed only after full card > > initialization to prevent such race conditions... > > Managed to find the problem, it was in choose_remote_endpoint_table: > > > for (i = 0; i < PA_ELEMENTSOF(freq_table); i++) { > if (freq_table[i].rate == default_sample_spec->rate) { > - frequency = freq_table[i].rate; > + frequency = freq_table[i].cap; > break; > } Nice catch, thank you! > I have not idea how this worked with the bose, maybe that has more > frequencies enabled since I end up with 0x44 which did not match any > frequencies supported in case of sony. It worked also for me, so seems that more enabled frequencies was the reason. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
