Synchronization errors

[badbat75]

Hi @arkq , I'm testing openaptx with bluealsa on raspios.
I have some issues using with a Samsung A5 (2017) connected via bluetooth, forcing it to use aptx coded, but I don't think it is related on the device itself.
I get a plethora of errors on syslog getting the audio streams choppy and unusable.

Those are the errors:
Jan 24 11:33:10 moode bluealsa[20368]: [aptx @ 0x3bd000] Synchronization error
Jan 24 11:33:10 moode bluealsa[20368]: openaptx: ffmpeg apt-X: Send packet failed: Invalid data found when processing input
Jan 24 11:33:10 moode bluealsa[20368]: /usr/bin/bluealsa: E: Apt-X decoding error: Communication error on send

openaptx is built with those flags:
-DENABLE_DOC=ON -DENABLE_APTX422=ON -DENABLE_APTXHD100=ON -DWITH_FFMPEG=ON -DWITH_SNDFILE=ON

I had to add libavutil>=56.22.100 dependency in CMakeFiles to complete the build.
Thank you for the effort you are putting in your projects.

[arkq]

Yes, it is possible that you will have sync issue with ffmpeg decoder, because it lacks proper synchronization. Better alternative is libopenaptx maintained by Pali Rohar.

Now, I'm working on (optional) direct bluez-alsa integration with that library, so the usage of openaptx (this repo) will not be required, unless one wants to use proprietary Qualcomm encoder/decoder. Stay tuned, I hope I will finish this integration today :).

I had to add libavutil>=56.22.100 dependency in CMakeFiles to complete the build.

Hmm, I've never seen such issue... Thanks for reporting it.

[badbat75]

Thank you for your reply. Unfortunately to build bluealsa with libopenaptx is not straightforward with latest commits. There are some type definitions in openaptx that are not present in libopenaptx. (i.e.: APTXENC).

[arkq]

Thank you for your reply. Unfortunately to build bluealsa with libopenaptx is not straightforward with latest commits.

That's why I've said that I'm working on this integration :) I know it's not straightforward right now. When I will finish, I will ping you in this thread so maybe you could test whether it is working properly, will that be OK?

[badbat75]

It's fine. This is a important feature, together with added codecs in sink mode makes bluealsa a big product.
Thank you again and sorry for bothering you.

[arkq]

Please, check this brach: https://github.com/Arkq/bluez-alsa/tree/libopenaptx

In order to compile with libopenaptx add --with-libopenaptx during configuration.

I'd be glad if you could check firstly the new code but still with the openaptx library. There should be no enhancement, but I'd like to know if it works in the same manner - whether I did not break anything. Currently I'm not able to test that properly (otherwise, it would have to wait for few weeks until I will have access to aptX capable device). Then, remove from your system openaptx and install libopenaptx - header files have the same name, so it is not possible to have both installed at the same time :/

[badbat75]

Oh great. I had a brief test session.
I can compile without issues.
The audio stream work flawlessly the first time, but if I stop the stream (pause a video in youtube for example) and I restart again I have those errors with no audio played:
Jan 25 09:17:19 moode bluealsa[25654]: /usr/bin/bluealsa: I: Apt-X stream out of sync: Dropped bytes: 0
Jan 25 09:17:19 moode bluealsa[25654]: /usr/bin/bluealsa: I: Apt-X stream out of sync: Dropped bytes: 0
Jan 25 09:17:19 moode bluealsa[25654]: /usr/bin/bluealsa: I: Apt-X stream out of sync: Dropped bytes: 0
Everything goes back to normal if I disconnect the device from bluetooth and I reconnect it.
It doesn't happen using AAC codec.
Just for info bluealsa is compiled with --disable-payload-check (to solve stream issues with iOS devices), I don't know if this can have impact on this behaviour.
BTW, to me is a big achievement in less than half day :-)
Thank you.

[arkq]

Just for info bluealsa is compiled with --disable-payload-check (to solve stream issues with iOS devices), I don't know if this can have impact on this behaviour.

It should not have any impact. AptX stream does not use RTP anyway, so for aptX it changes nothing.

Could you please record hci dump with this case scenario? It can be from phone or from host with bluealsa (the letter is preferable).

[badbat75]

Hi, I created the dumps you requested.
All the logs were captured on host (sink) device.
connection and disconnection logs captured connection and disconnections of the mobile
stream01 represent the audio stream that works perfectly for 5 seconds.
stream02 represent the audio stream that stays mute for 2 secs and then starts playing something near the end
stream03 represent the audio stream that stays completely muted, with errors I wrote before.
hcidump.zip

[arkq]

Please capture dumps with "tcpdump -i bluetooth0". With your text logs there are no data, I need binary data for tests :) Note, that you have to start tcpdump BEFORE connecting headset.

[badbat75]

Oh sorry, I've never used hcidump before.
Ok this is new dump.
This was the process:
connection
-wait-
play youtube video (success)
pause video
-wait
resume youtube video (fail)
pause video
-wait
disconnection
hcidump.zip

[arkq]

OK, third time lucky :) Since you've never used tcpdump, there is the exact command which you shall use: tcpdump -i bluetooth0 -w /tmp/hcidump.log (the important part is -w, which will write dump in a binary format, so all data will be stored, not only "description", because in your txt file there is still missing atpX stream, which is the most important part). Sorry for not writing the full command before. The sequence of actions is correct.

[badbat75]

And finally :-D
hcidump.zip

This time it decided to work 2 times :-)
You can find the 3rd stream with no audio.
Same as before but with 3 streams.

[arkq]

Great, now it is OK. I will try to find the cause maybe today or tomorrow (in the worst case scenario during comming weekend :)) I will ping you here.

[arkq]

I've updated the https://github.com/Arkq/bluez-alsa/tree/libopenaptx branch and this (openaptx) repository. I've made some tests with the dump you've provided and it seems that now sink more or less works with openaptx (there should be less error messages) and with libopenaptx. Could you please test with these both libraries?

[badbat75]

Hi @arkq , sorry for my late feedback, but I didn't have much time to work on it. BTW I did a quick test with libopenaptx and results are encouraging. It seems it works flawlessy, I tried to play, pause, close the application different times in the same session, no issues at all. Give me some time to have a deep test session and of course to give a chance to openaptx libraries, I will give you some feedbacks soon.