Audio stuttering very frequently when navigating with Pixel 3XL

[iainheng]

I recently switched to Google Pixel 3XL and noticed that my audio stuttering so bad when navigating with Google Map or Waze. Audio stuttering almost every turns on the map.

The audio stuttering was much less frequent on my previous phone OG Pixel. Does any Pixel 3 owner experience the same?

Any optimizations we can make on the phone or headunit? I have tried disabled the adaptive battery optimizations on Android Pie without success. I have AA version 1.10+ installed from AIO.

[retaker]

Same with Oneplus 5, trying newer version now...

[blackdetail]

If you have Mazda Nav Card in the SD slot, remove the SD card and see if it is better.

[iainheng]

I have the Nav card removed all the time.

[zahitkara]

I think that's because AIO AA runs at 60fps while the official AA and other cars i drove with AA runs at 30fps. Even though Trez says it's programmed to run at 30fps mine definitely works at 60fps as it's extremely smoother. AA can't handle 60fps i think and the audio shutters because of that. That's my opinion.

[Trevelopment]

How do you know its running at 60fps? Also, how do we set it to run at 30fps?

[zahitkara]

How do you know its running at 60fps? Also, how do we set it to run at 30fps?

I don't think there is a setting to set it but i can record a video with a phone capable of recording 60 fps to show it to you.

[gh123man]

I have spent a pretty significant amount of time trying to fix the audio stuttering issue. The issue roots from audio packets not getting buffered fast enough. When a large stream of video packets comes in, the audio stream buffer empties before the next audio packet is actually received.

I benchmarked several parts of the code to rule out video processing and TLS decryption as the possible bottlenecks which leaves me to believe its likely bottlenecking somewhere in the USB data transfer (though I have not have been able to definitively prove this).

Anyway - two things I found that improve the audio stutter significantly are

1. Set the target framerate to 60fps. In my experience this improves responsiveness and causes more frequent smaller video packets to come through (and as a result more audio packets get mixed in with the bunch and end up getting buffered). I don't believe mzd connect actually displays more than 30fps as frames are dropped as needed (I did not notice a visual difference in framerate). If I remember correctly the hardware decoding is done by a closed source extension of gstreamer that already exists on the headunit (someone correct me if I am wrong).

The target framerate can be changed here: https://github.com/gartnera/headunit/blob/master/hu/hu_aap.cpp#L468

2. The other change that makes an apparent difference is changing the process priority. @Trevelopment has made this change in his latest (2.8.2) AIO repo. The change his here: https://github.com/Trevelopment/MZD-AIO/blob/master/app/files/tweaks/config/androidauto/data_persist/dev/bin/headunit-wrapper#L23 nice and ionice

I have been running with the two above modifications for about a month and it has made a significant improvement with the audio stutter issue to the point that it only tends to happen when trips recalculating or large animations are playing.

If someone is more knowledgeable in any of these areas Id love to discuss it further to get to the root of the issue - and if the 60fps change is acceptable I can make a PR to this repo.

One other thing I tried was increasing the asla buffer size, but for some reason this works locally (on linux) but not on the headunit itself. Its possible there are closed source changes preventing this from working.

[Trevelopment]

Tweaking the TCP stack buffers I don't know if this helps but I found part of this code in the new MZD v70 FW and I tried using it in headunit-wrapper

echo 41943040 > /proc/sys/net/core/rmem_max
echo 41943040 > /proc/sys/net/core/wmem_max
echo 17825792 > /proc/sys/net/core/rmem_default
echo 17825792 > /proc/sys/net/core/wmem_default
echo 4096 17825792 41943040 > /proc/sys/net/ipv4/tcp_rmem
echo 4096 17825792 41943040 > /proc/sys/net/ipv4/tcp_wmem

I am not a Linux expert but I think this might help a bit. I got the actual numbers from /usr/bin/autostart in v70 but only the "rmem" values were in it I added the "wmem". Also, I tried adding this too but in testing it seemed to make things worse echo 4096 17825792 41943040 > /proc/sys/net/ipv4/tcp_mem

[gh123man]

I suspect this could help with AA over WiFi - but the USB mode does not use TCP or the linux network stack to transfer data. Full disclosure - I have never even tried AA over WiFi so I am unsure what the audio situation is there.

Do you know where I can obtain a dump of v70?

Also I understand that the official AA/CarPlay retrofit requires a new USB board. Perhaps they are using a higher bandwidth USB port to get around these issues?

[Trevelopment]

You can get a copy of the FW here https://my.hidrive.com/share/hsodpqja.l#$/Mazda_Firmware The USB hub upgrade definitely supports higher bandwidth data transfer so it may be tough to fix all the issues without it. But while this headunit app does not work with v70 over USB it does work over wifi (with the no sound issue) so I am thinking maybe if we use another sink in the gstreamer pipeline maybe that will work then we can find out if the new hub will benefit this version as well.