a2dp_aptx.c: Error submitting the packet to the decoder

[xstsx]

Hi, I have issue with aptx_HD sync

[aptx_hd @ 0x555cfda92f40] Synchronization error
D: [bluetooth] a2dp_aptx.c: Error submitting the packet to the decoder

That's what I see in pulseaudio -vvv, a lot of messages like this (500+ lines).
When it's happening there is no sound at all from the phone.
It's became very randomly, you can listen to music 5-30 minutes and then no sound after changing songs or closing currently playing player at the phone. It will stop output errors only if you pause or closing current playing song or player. After it stops output errors music playing perfectly.

My setup:
linux: Archlinux
laptop: linux-lts (4.19.31-1), ffmpeg (1:4.1.2-1), pulseaudio (12.2-2 , 2channels - 24bit - 48000Hz),
raspberry pi: almost the same setup.
phone: Xiaomi Redmi 5 Plus, RR 7.0.1 + installed aptX libs
Tried with only one phone , haven't any other device supporting aptX.

Have tried with hardware solution CSRA64215, it's working without any issue.
Just curious if there is something wrong with my setup that's preventing sync for aptX.

P.S. Thanks a lot for this modules.

Thank you, StS.

[EHfive]

I have pushed bff80fd

That might fix this issue

[xstsx]

First of all thanks for fast response, and fix. Trying it out.
No more errors with playing music/video for now.
Still problems with music/video , every videos from this playlist is starting with errors, after 3-5 repeats of pause/play it's starting to play. If it had to pause at some point and rebuff - again errors.

The only way to "fix": pause, wait for all error messages printed out, play music. If there is more errors - repeat.

But..

[aptx_hd @ 0x5567b5358680] Synchronization error
D: [bluetooth] a2dp_aptx.c: Error submitting the packet to the decoder

Appears at UI "clicks", at DTMF tones when trying to dial number, at Volume up/down sounds, Power on/ off screen. Lets say all UI sounds is producing this error.

A little overpass for me now it's to mute UI sounds :)
Looks like it's mine personal issue because of 3rd-party aptx libs, isn't ?

[EHfive]

Looks like it's mine personal issue because of 3rd-party aptx libs, isn't ?

It might be.

Actually the same error "Synchronization error" printed when I use https://github.com/Magisk-Modules-Repo/aptx on my Oneplus 2, LineageOS 16; But without any issue on my Oneplus 6t which has official aptX/aptX HD support.

Look into ffmpeg aptX source, "Synchronization error" stands for a bad aptx frames data.

The 3rd-party libs might don't have ability to handle UI tones that break aptx frames data.

[xstsx]

Indeed, tried another lib. And it's working like yours.
Some random Sync errors ,at least it doesn't "stuck" on it.
I got everything work, UI sounds, video and audio on Raspberry PI.

Thank you very much ;)

[gpeter12]

Hi!
I have the exact same issue. I'm also trying to use a Raspberry Pi for bluetooth sink with aptX-HD. I'm getting a lot of Synchronization error.

[aptx_hd @ 0x1444c70] Synchronization error
[aptx_hd @ 0x1444c70] Synchronization error
[aptx_hd @ 0x1444c70] Synchronization error
[aptx_hd @ 0x1444c70] Synchronization error
[aptx_hd @ 0x1444c70] Synchronization error
[aptx_hd @ 0x1444c70] Synchronization error
I: [alsa-sink-bcm2835 ALSA] module-loopback.c: Could not peek into queue
I: [alsa-sink-bcm2835 ALSA] module-loopback.c: Could not peek into queue
[aptx_hd @ 0x1444c70] Synchronization error
I: [alsa-sink-bcm2835 ALSA] module-loopback.c: Could not peek into queue
[aptx_hd @ 0x1444c70] Synchronization error
[aptx_hd @ 0x1444c70] Synchronization error
I: [alsa-sink-bcm2835 ALSA] module-loopback.c: Could not peek into queue
[aptx_hd @ 0x1444c70] Synchronization error
I: [alsa-sink-bcm2835 ALSA] module-loopback.c: Could not peek into queue

The most interesting thing is that on my laptop (also as a sink) with the same code and with (almost) the same libavcodec version it works just perfectly fine. With ZERO error messages in the log.

I suspect that the error message comes from the 1039. line of libavcodec's aptx.c. But I assume the problem isn't in libavcodec.

I would really really appreciate the help because I spent almost 3 days on this issue already. It would be a waste...

My setup:

• Asus Zenfone 5Z (it has official support for AptX-HD and AAC)
  • Android 9
  • Bluetooth 5.0
• Raspberry Pi 3 B (with official PSU)
  • Bluetooth 4.1
• Laptop: Asus N550JK (Intel Core I7 4700HQ version)
  • Ubuntu 19.04
  • Bluetooth 4.0
• libavcodec-dev:armhf (7:4.1.4-1+rpt1~deb10u1)
• pulseaudio-modules-bt version is the currently most recent 3ecf1d7
• pulseaudio version is pulseaudio 12.2-dirty (git: ee910cf6d) (because with the current master I couldn't get it work at all)

[xstsx]

I think I found the solution: https://hackaday.io/project/165208-an-old-rotary-phone-as-bluetooth-set/log/162491-setting-up-the-bluetooth

changing imtu making it more stable. no more Sync errors when changing tracks.

[EHfive]

75af499 enable autodetect_mtu by default, hope it helps

[xstsx]

75af499 enable autodetect_mtu by default, hope it helps

Thank you for quick response :)

I would say it's working, but only for playing music when you stays only at APTX-HD profile(+notifications sound)

But if you receive call ,profile changing to HSP/HFP. After a call it's trying to switch back to APTX-HD and then it's falling to alot of Sync errors.

Overall playing music over APTX-HD became more stable, no more skips/silence/hanging up. Overall playback latency stable at 195-200ms (before it was very random 180-500ms)

I will continue trying figure out this behavior and what making it. Maybe it's my personal issue :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[EHfive]

Maybe it can be fixed by switching to libopenaptx.

[EHfive]

This project has been deprecated. #154

There will be no bug fixing commits anymore.