[pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs

[Luiz Augusto von Dentz]

Hi Pali,

On Fri, Apr 26, 2019 at 1:55 PM Pali Rohár <pali.rohar at gmail.com> 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 at gmail.com> 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;
         }

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.

-- 
Luiz Augusto von Dentz