Database Info

[Bug] Certain files make the audio cut out on Shield Tablet Lollipop

After I updated my Shield Tablet to Stock Lollipop (happens on both 5.0.1 and 5.1),
I noticed that with certain files that use the SW decoder, the audio in MXPlayer crackles a lot, and eventually the audio on the whole tablet cuts out for around 10 seconds (at least judging by the Logcat). This only occurs with MXPlayer. VLC has no audio issues, but I'd rather using MXPlayer for better seeking support. Also, when the audio cuts out, the video keeps playing, but when the audio starts working again, the video pauses until it aligns with the audio.
This appears to be a relevant line of the logcat:
Code:
W/AudioFlinger(17468): write blocked for 10016 msecs, 1 delayed writes, thread 0xaedd7000
One thing that the problematic video files have in common are 48000Hz audio channels, which I believe is the native sample rate of my device. Is there some resampling that isn't getting applied to 48KHz audio that might fix the issue? Is the AudioTrack not getting flushed properly?
The full log is attached. And these lines I believe are not relevant, because they happen nearly all the time when I have headphones plugged in:
Code:
W/NvAudioPolicyManager(17468): getDeviceForStrategy() unknown strategy:

xperia64 said:
After I updated my Shield Tablet to Stock Lollipop (happens on both 5.0.1 and 5.1),
I noticed that with certain files that use the SW decoder, the audio in MXPlayer crackles a lot, and eventually the audio on the whole tablet cuts out for around 10 seconds (at least judging by the Logcat). This only occurs with MXPlayer. VLC has no audio issues, but I'd rather using MXPlayer for better seeking support. Also, when the audio cuts out, the video keeps playing, but when the audio starts working again, the video pauses until it aligns with the audio.
This appears to be a relevant line of the logcat:
Code:
W/AudioFlinger(17468): write blocked for 10016 msecs, 1 delayed writes, thread 0xaedd7000
One thing that the problematic video files have in common are 48000Hz audio channels, which I believe is the native sample rate of my device. Is there some resampling that isn't getting applied to 48KHz audio that might fix the issue? Is the AudioTrack not getting flushed properly?
The full log is attached. And these lines I believe are not relevant, because they happen nearly all the time when I have headphones plugged in:
Code:
W/NvAudioPolicyManager(17468): getDeviceForStrategy() unknown strategy:
Click to expand...
Click to collapse
@xperia64Did I don't think this is a resampling issue. Have you tried HW+ decoder? SW decoder on high resolution video might cause this issue. And I will be test more if you send a sample video clip.

bleu8888 said:
@xperia64Did I don't think this is a resampling issue. Have you tried HW+ decoder? SW decoder on high resolution video might cause this issue. And I will be test more if you send a sample video clip.
Click to expand...
Click to collapse
The issue occurs on nearly all if not all videos with 48KHz audio tracks, from 320x240 all the way up to full HD. It is impossible to play some of these videos with HW+ due to them being WMV or Microsoft MP4's. I've encountered the issue even in Big Buck Bunny. I've tried the 1280x720 and 854x480 MP4's and the 854x480 MSMP4, which exhibit the issue https://peach.blender.org/download/
The lower resolution ones especially should not be that intensive.
If I play the regular BBB MP4's with the HW/+ decoder and SW audio (because AC3), I didn't notice any crackling. If I play them with the SW decoder, they eventually start crackling and audio on the whole tablet cuts out. If I play the MSMP4 version with the SW decoder and software or hardware audio, it will crackle.
I've been using MXPlayer for quite a while, and I remember that when playing larger files on an older device like the Motorola Droid 1, the audio track would sometimes get ahead of the video, and the audio would pause for a while, but this is different because there is no apparent lag and audio on the whole tablet dies.

It would appear that Nvidia's stock kernel is part of the problem here. I flashed a different kernel and I cannot reproduce the crackling/cutout. Although it's somewhat strange that only MXPlayer had this issue.

Well at least you have audio. I updated to 5.1 and did it through the ota with twrp and I have NO audio. Makes no sense. I went back to 5.0.1 and I have audio again. I tried a bunch of different things and still no way for me to get any audio on 5.1. I am thinking of trying a kernel and see if that helps. Or maybe go back, again, and wait for a fix!

JohnK71 said:
Well at least you have audio. I updated to 5.1 and did it through the ota with twrp and I have NO audio. Makes no sense. I went back to 5.0.1 and I have audio again. I tried a bunch of different things and still no way for me to get any audio on 5.1. I am thinking of trying a kernel and see if that helps. Or maybe go back, again, and wait for a fix!
Click to expand...
Click to collapse
@JohnK71 @xperia64
Would you try latest test version from following link?
https://sites.google.com/site/mxvpen/translation/test-build
Feedback will be appreciated.

bleu8888 said:
@JohnK71 @xperia64
Would you try latest test version from following link?
https://sites.google.com/site/mxvpen/translation/test-build
Feedback will be appreciated.
Click to expand...
Click to collapse
Sorry, but I am saying "NO" audio even playing music or checking and changing sounds. No sound at all and also no mic. It all works good back on 5.0.1 so not sure what's the deal with 5.1 for me. I guess I will hope for better results with next version of lollipop. Thanks anyway for the suggestion.

The test build did nothing different. However, version KS-034 of this kernel appears to have fixed my remaining audio issues. On KS-033, the audio was fine for 48KHz audio files, but would still cut out with 24KHz audio files and somewhat break any future AudioTracks in any app until reboot. Version 034 said it increased the HD audio buffer so I guess that did something.
http://forum.xda-developers.com/shi.../tweaked-kernel-nvidia-shield-tablet-t3069776

xperia64 said:
The test build did nothing different. However, version KS-034 of this kernel appears to have fixed my remaining audio issues. On KS-033, the audio was fine for 48KHz audio files, but would still cut out with 24KHz audio files and somewhat break any future AudioTracks in any app until reboot. Version 034 said it increased the HD audio buffer so I guess that did something.
http://forum.xda-developers.com/shi.../tweaked-kernel-nvidia-shield-tablet-t3069776
Click to expand...
Click to collapse
Shield Tablet OTA 3.0 looks like suspended due to audio issue.
See this link: https://forums.geforce.com/default/...3-0-update-feedback-thread-released-5-22-15-/

That is because of a different audio issue where the speakers would literally explode. I had the crackling on 5.0.1/2.2.1. as well.
And I actually went back to KS-033 because KS-034 made audio too latent and it reintroduced crackling on all files, granted it was diminished.

After updating to the latest BitO Kernel (KSX-043) and MXPlayer test version, crackling behavior has changed again, but I have a theory on the crackling this time.
I noticed that after a reboot, the crackling would stop for a while before it returned. The CPU in this device tries as hard as it can to keep its clockspeed at the minimum 51MHz while in sleep mode, regardless of wakelocks/background apps. I had been using Droidsound-e and my own AudioTrack-based music player in sleep mode and I noticed that those apps would skip/crackle a bit as they tried to process the music files but couldn't. That appears to somehow throw off audio output until reboot. The issues are still most noticeable in MXPlayer, but also appeared in other apps as well. I increased the minimum clockspeed to 204MHz and it seemed to help.
I don't know if this is the cause, or if it works on the stock kernel, but on my current setup it seems to work fine.

Bluetooth audio skips

I'm on 8.1 dp2 in hopes of a fix but it doesn't seem to have helped. My Bluetooth audio skips once every song or two and it's super frustrating while in my car. I've tried disabling WiFi and Bluetooth scanning and adjusting the codec options but nothing seems to work? Anyone else with this issue or a solution? I just received wireless earbuds so I'll test those to make sure it's not my stereo but my s8 had worked fine...
Ok say my new ear buds are Bluetooth 5 and I haven't noticed a single skip yet. My stereo is only 3 so maybe that has something to do with it? As far as I can find however there are no current bt5 stereos so I'm not sure what the issue or solution would be...

Enable the developer options. You can choose between sound quality and connective stability. You can also lower the sampling rate to 44100kHz. In a word, reduce the data transferring rate. I think these might help.

I did all of that and have tried all the options

slyr114 said:
I did all of that and have tried all the options
Click to expand...
Click to collapse
I have had this problem cropping up on various Toyota forums with the root cause being the automotive entertainment systems. It appears that most newer systems are still based on 2008/9 technologies which only have a limited ability to buffer the B/T audio. I'm not suggesting that this is your car but I thought it is worth mentioning.

Ive got a Sony stereo I put in myself haha it's relatively new

HTC U11 Bluetooth Audio Quality Issue on Android 8.0

Hi, last week I installed the OTA Android 8.0 update on my HTC U11.
Since this update the audio quality when streaming to my car's audio system or to my pioneer hi-fi system at home is a lot worse than on Android Nougat. Especially on tracks with a lot of high tunes. There's always a slight 'clink' noise. I don't know how to explain this in English..
Have you noticed this issue as well? Is there something I can do about it? Thanks

question are you using any sound mods?

6th_Hokage said:
question are you using any sound mods?
Click to expand...
Click to collapse
No, I don't use any sound mods.

joscht said:
No, I don't use any sound mods.
Click to expand...
Click to collapse
Same for me. Since this update, the quality of phone call when connected to Bluetooth to my car is really bad. No problem with music stream connected to the same car.
I tried managing the new bluetooth options in developper mode menu but it doesn't solve the problem.
The codec used is all the time SBC even is I change it to AAC or aptX or AptxHD.

Fredz said:
Same for me. Since this update, the quality of phone call when connected to Bluetooth to my car is really bad. No problem with music stream connected to the same car.
I tried managing the new bluetooth options in developper mode menu but it doesn't solve the problem.
The codec used is all the time SBC even is I change it to AAC or aptX or AptxHD.
Click to expand...
Click to collapse
I have the same issue, it seems it was fixed in 42 version for US market(at least for LDAC)

I have 2 issues with Bluetooth connections with the car. The first is that it picks up interference from the noise of the wheels and engine while driving, and the sound quality suffers and it sounds unclear, unless I mute the vehicle.
The second is that it has a lot of trouble connecting to the car at times. Or, more often, it would not connect the media through the car. Don't know what's up with that.

I know how you feel
I've got exact same problem like yours. Although I'm using HTC u11 plus. My new pair of Bluetooth headphones have the same not OK audio quality. You're right especially the high tunes. I'm desperate, trying to reset everything, but doesn't help. If you find the solution, please let me know. Thank you.
joscht said:
Hi, last week I installed the OTA Android 8.0 update on my HTC U11.
Since this update the audio quality when streaming to my car's audio system or to my pioneer hi-fi system at home is a lot worse than on Android Nougat. Especially on tracks with a lot of high tunes. There's always a slight 'clink' noise. I don't know how to explain this in English..
Have you noticed this issue as well? Is there something I can do about it? Thanks
Click to expand...
Click to collapse

Same issue here. I have the U11 as well and just updated to Oreo and I have the same issue as well. Music over BT was ok on Nougat but after the update, music sounds as if there is digital clipping. And it's there with both my headset and car audio system.

Got the same issue, hope they fix it soon. The only solution seems to do a RUU right now.
Btw. I am on a custom rom (LeeDroid), gonna go full stock and try again.

I would suggest looking in developer options and trying some of the different options for bluetooth in there!
Settings > about > software information > more > then tap the build number till it says you are a developer.
Then
Go to developer options and check under networking, there are some settings to toggle in there.
You may find something you are looking for! I personally haven't tried bt since the update so I don't know if it is a common issue. Good luck!

Thank you!
Thank you very much.
Playing around with the bluetooth options in the developer's menu solved this issue.
The audio quality through bluetooth is now pretty much the same as it was with the previous android os

joscht said:
Thank you very much.
Playing around with the bluetooth options in the developer's menu solved this issue.
The audio quality through bluetooth is now pretty much the same as it was with the previous android os
Click to expand...
Click to collapse
Share what settings you stuck with so it may help the other people with the same problem

Hey there!
Same problem for me since updating my U11 to Oreo - very poor bluetooth audio quality...
I tried using different bluetooth settings under the developer options but the thing is: no matter what I choose, it keeps switching back to the default values not affecting anything at all.

If it switch back to default SBC it means your headset/BT device doesn't support other codec.

Alpert3 said:
If it switch back to default SBC it means your headset/BT device doesn't support other codec.
Click to expand...
Click to collapse
That's not necessarily true. On 7.1 both Bluetooth devices which I use can support either AAC, SBC and aptX. My understanding is this issue occured because of the removal of AVRCP 1.3. I think Google added 1.3 back to Android 8.q because of this.

yournamehere484 said:
That's not necessarily true. On 7.1 both Bluetooth devices which I use can support either AAC, SBC and aptX. My understanding is this issue occured because of the removal of AVRCP 1.3. I think Google added 1.3 back to Android 8.q because of this.
Click to expand...
Click to collapse
Yours is not necessarily true either. I'm on 8.0 and I can still use aptX if I want but only if my BT device supports aptX.

Alpert3 said:
Yours is not necessarily true either. I'm on 8.0 and I can still use aptX if I want but only if my BT device supports aptX.
Click to expand...
Click to collapse
I'm not arguing that aptX and other codecs aren't working on 8.0. What I'm saying is that with certain devices, we are no longer seem to be able to use certain codecs that we could use prior. It's obviously device dependent, but to say their isn't a problem and blame it on the Bluetooth device is incorrect. Infact the same problem has occurred on non HTC devices when they've upgraded to 8.0 such as the OnePlus.

yournamehere484 said:
I'm not arguing that aptX and other codecs aren't working on 8.0. What I'm saying is that with certain devices, we are no longer seem to be able to use certain codecs that we could use prior. It's obviously device dependent, but to say their isn't a problem and blame it on the Bluetooth device is incorrect. Infact the same problem has occurred on non HTC devices when they've upgraded to 8.0 such as the OnePlus.
Click to expand...
Click to collapse
Fair enough, I didn't understand.

Does anyone know how to make the bluetooth options under developer options stick? I'm on stock unlocked Oreo, and they go back to defaults as soon as I change them. I've tried changing them whilst connected in the car, but no change. The only thing that could make a difference is that I'm running Pitch Black Substratum theme. Anyone else got them to stick?

In my Audi a3 2015 before oreo i can able to skip the track with entertainment commad and in the display i saw name of the track. After update i have lost all funtionality and the car see my device only like esternal suorce . Can i do something?

No support for higher bitrate on LDAC?

Been using the Pixel 3 as my daily driver for a while now, but just recently came an interesting piece. Apparently, the Pixel 3 doesn't support LDAC at Optimum Audio Quality (more details here - https://themrphone.com/article/google-pixel-3-xl-doesnt-support-ldac-at-optimum-audio-quality/)
I was planning on buying a high-end set of Bluetooth headphones, in fact, was considering the same ones used in the link above. Can anyone else confirm this?

varounmirchi said:
Been using the Pixel 3 as my daily driver for a while now, but just recently came an interesting piece. Apparently, the Pixel 3 doesn't support LDAC at Optimum Audio Quality (more details here - https://themrphone.com/article/google-pixel-3-xl-doesnt-support-ldac-at-optimum-audio-quality/)
I was planning on buying a high-end set of Bluetooth headphones, in fact, was considering the same ones used in the link above. Can anyone else confirm this?
Click to expand...
Click to collapse
Working fine for me with both LDAC (detected and used automatically) and "Optimised For Audio Quality" (switched from default "Best Effort" in Developer Settings)
Pixel 3 (non XL) with Sony MDR-1000X (gen 1 of the headphones in your linked article) and Google Play Music.
Granted GPM isn't a Hi-Res source, but it's playing fine! There was a momentary drop in audio for a split second on changing bit rate but it resumes with no issue!

I had this same issue with my Audeze Mobius--the Pixel 2 allowed me to set the rate to 990, but the Pixel 3 would do as described in the link. Seems like a software bug, I doubt it actually isn't capable of using the full rate

I can't say, I'm much of an audiophile or anything but I do like to play with settings for what sounds best with what I have. On my Galaxy s8 running oreo and my previous s5 running aospx/oreo I could change the developer Bluetooth settings on the fly and notice the difference instantly (avrcp/bt_codec/sample_rate/bit_rate/ldac_codec).
If I do it on the pixel 3, the Bluetooth just falls out, connection wise it stops but still shows it's connected, app wise I can't close and reload the app. I have to turn the Bluetooth off or reset it completely sometimes.
It's kind of a bummer, being a brand new phone and all, I noticed the absolute volume disable didn't seem like a difference either.
I hope they resolve it.

Update: disabling bluetooth a2dp hardware offload let me freely change all those settings while in use with out locking anything up. What that necessarily does or the effect of changing the settings and how well they actually change??? I can't answer with any rational or testworthy explanation as my audio products are oem Bluetooth radios in vehicles.

Developer options Bluetooth settings don't stick

I've been experimenting with the Bluetooth options in developer options, but every time I change them, they change back to the default settings.
Has anyone any help on how to make them stick?
Sent from my [device_name] using XDA-Developers Legacy app

I've experienced this as well. I believe by design, you must first have an audio device paired and connected before changing these settings, and even then, when doing so, the BT device must be capable of such settings. As an example, when my BT headphones are connected, I can set the DEV option to a lower than 24 bits "per sample" but not higher. All the settings here depend on the hardware in use and whether it is capable of the setting. ->Then when disconnected, the dev options return to their default settings. -But they should return when re-connected.
-hope this helps to at least get the discussion ball rolling.

oryanh said:
I've experienced this as well. I believe by design, you must first have an audio device paired and connected before changing these settings, and even then, when doing so, the BT device must be capable of such settings. As an example, when my BT headphones are connected, I can set the DEV option to a lower than 24 bits "per sample" but not higher. All the settings here depend on the hardware in use and whether it is capable of the setting. ->Then when disconnected, the dev options return to their default settings. -But they should return when re-connected.
-hope this helps to at least get the discussion ball rolling.
Click to expand...
Click to collapse
^ The above is definitely not true. At least not for everyone. I have a galaxy note 9 and I've tried connecting headphones as well as a pair of edifier speakers. Nothing except AVRCP version sticks, and that sticks whether I have a bluetooth device connected or not. Everything else does not stick, even though both devices are of course capable of aptX and 48khz and 24b/s. In fact the speakers are intended for 48khz 24b/s, it causes audio stuttering if I have anything else. No matter what I do, everything just defaults to SBC, 44.1khz, 16b/s. It's clearly broken and has been for like 3 versions of android OS lol. Every android phone I've ever had has had this problem too. So clearly it has nothing to do with the hardware you're connected to, since all the devices I've connected are intended for aptX, 48khz, 24b/s. And I don't think it has anything to do with the phone's hardware either, since I used to use an essential phone which is advertised as being intended for aptX HD use with the "TIDAL" app. They gave me a 3 month free trial to this service and said it output high fidelity audio via aptX HD. But no, the essential phone's bluetooth developer options behaved in exactly the same way. I've tried a lot of other things as well, so I'm pretty sure this UI element is either just fundamentally broken, or is intentionally locked from the user, presumably for some patronizing reason