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.

[badbat75]

Using libopenaptx everything is perfect now. No packet loss, no errors in systlog. Wonderful.
Compiled with --enable-aptx --enable-aptx-hd (without --with-libopenaptx).
configure find openaptx libraries:
checking for openaptx >= 1.2.0... yes
checking for openaptxhd >= 1.2.0... yes
But it seems the binaries are not compiled with -lopenaptx, and in fact there's no support for aptx as sink in bluealsa binary, also the mobile connects using AAC:
Available BT profiles:
- a2dp-source Advanced Audio Source (LDAC, aptX-HD, aptX, AAC, SBC)
- a2dp-sink Advanced Audio Sink (AAC, MP3, SBC)
I'm guessing if I did a mistake in the build process

[arkq]

But it seems the binaries are not compiled with -lopenaptx, and in fact there's no support for aptx as sink in bluealsa binary,

Are you using latest master of openaptx? And what is the output of pkg-config --variable=aptxdecoder openaptx? Is should be true.

And the installed file openaptx.ps (on my host it is in /usr/lib/pkgconfig) should look like this:

prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${prefix}/lib64

aptxdecoder=true
aptxencoder=true

Name: libaptx
Description: Reverse-engineered apt-X header file and library
Version: 1.3.2
Libs: -L${libdir} -laptx
Cflags: -I${includedir}

[badbat75]

Oh my... no I'm using the v1.3.1 commit. I rebuild with the latest and I'll give you an update soon.

[badbat75]

No it is not working, same errors and choppy stream
I suppose you need another dump....

Jan 27 13:09:22 moode bluealsa[329]: [aptx @ 0xb000d550] Synchronization error
Jan 27 13:09:22 moode bluealsa[329]: openaptx: ffmpeg apt-X: Send packet failed: Invalid data found when processing input
Jan 27 13:09:22 moode bluealsa[329]: /usr/bin/bluealsa: E: Apt-X decoding error: Communication error on send

[arkq]

OK, thanks for the feedback :) I guess changes are ready to be merged with master.

I suppose you need another dump....

No, I think it's not required. The openaptx repo is mainly for compatibility layer with proprietary Qualcomm libs - and as a bonus there is a backend with ffmpeg, but only as an example. However, if you could provide a dump with an actual choppy stream maybe it would be possible to fix it :D I guess that starting and stopping stream with openaptx works now?

[badbat75]

Cool!!! Yes pause, resume and stop is working.
hcidump.zip
I leave up to you to close this issue. BTW if you want to keep it open and you need support from me, I'm available.
Thank you, for your quick response.

[arkq]

I will keep it open for now, and I will try to actually fix this issue, but if it will not be possible (or it will go beyond FFmpeg API usage) I will close it with an appropriate comment. Thank for your support!

[arkq]

Strange that you've got choppy stream.... I was able to decode this stream with ffmpeg-based decoder without any sync errors (the stream was: song 1, pause, song 2, pause, more song 2) . Of course, I'm doing it in the offline mode but using bluealsa code for decoding aptx stream. Which version of ffmpeg (libavcodec) you are using?

On my host I've got this:

$ pkg-config --modversion libavcodec
58.91.100

[badbat75]

It is exactly the same version you mentioned: 58.91.100 . The only thing I can say is that the chopping sound is completely de-synchronized. Let say, the small chunk of audible sounds seems to be in late more than 1 sec with a bluealsa buffer of 20ms. Also the cpu load is higher than using libopenaptx but not so high that make me think that there are load issues (we are at 50-55% over the 20-25% of the libopenaptx codec).