Hi Pali, On Fri, Apr 26, 2019 at 6:47 PM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > 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. Btw, if you are to send a v10 also include the following: @@ -1838,6 +1847,9 @@ static DBusMessage *endpoint_set_configuration(DBusConnection *conn, DBusMessage t->release = bluez5_transport_release_cb; pa_bluetooth_transport_put(t); + if (!d->change_a2dp_profile_in_progress) + pa_bluetooth_transport_set_state(t, PA_BLUETOOTH_TRANSPORT_STATE_PLAYING); + pa_log_debug("Transport %s available for profile %s", t->path, pa_bluetooth_profile_to_string(t->profile)); return NULL; Otherwise last used logic don't work as intended. Btw, have you tried these patches with a phone? It seems to work but we got some problems: 1. At least Android seems to prefer aptX-HD but that doesn't seems to produce any audio, in fact it crashed a few times so either have to find out why aptX-HD is not working or don't include it. 2. Codec switching with Android always seems to timeout. 3. There seem to be some regression with loopback module, there seems it always produces some glitch when resuming (during the playback it seems alright): I: [alsa-sink-ALC293 Analog] module-loopback.c: Dropping 17414 usec of audio from queue I: [alsa-sink-ALC293 Analog] module-loopback.c: Dropping 20317 usec of audio from queue I: [alsa-sink-ALC293 Analog] module-loopback.c: Adding 30657 usec of silence to queue I: [alsa-sink-ALC293 Analog] module-loopback.c: Dropping 105170 usec of audio from queue > > -- > Pali Rohár > pali.rohar@xxxxxxxxx -- Luiz Augusto von Dentz _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
