Playback sputters randomly for fractions of a second about vanilla HOT 21 CLOSED

I also experienced this "sputtering" twice today at seemingly random moments. Really scary. Strangely, today was the first time this happened to me, although I am using this app since months.

(Using Vanilla from Play Store on cyanogenmod 10.1 final)

from vanilla.

Negative priorities (like THREAD_PRIORITY_AUDIO = -10) can only be set by system applications, at least this was the case in Android 4.0 - I'll have to check if this restriction is still present in 4.2.

AFAIK, the buffer size of the MediaPlayer class can not be changed.

Does the 'sputtering' also happen with other 3th-party mediaplayers? (= Any NOT pre-installed mediaplayer. The Android Mediaplayer CAN set PRIORITY_AUDIO as it's installed in /system)

I also get some drop-outs on my HTC One X, but in this case it's a kernel problem related to the wifi driver:
It always happens while i enter or leave my flat: Logging in (and out) to my wifi network causes the wifi driver to stall the kernel for a small fraction :-/

from vanilla.

I was able to compile it with 'THREAD_PRIORITY_AUDIO' and get it running on Android 4.1.2. I haven't yet had an extended listen; i'll have an update on that later today, after my walk back home.

I haven't seen this issue with the stock player. The only other player I used extensively was PowerAmp during its 15 day trial, and hadn't seen it there too. I think i had seen it a few times with either DeadBeeF or doubleTwist (sorry, can't recall exactly which one), but my usage with those 2 was not that extensive.

FWIW, I typically use MP3s encoded @ VBR V0 with LAME, ReplayGain'ed for tracks (not album).

And since I haven't said it yet, "Thanks a ton!!!!" Your work on this is really appreciated. Bringing in support for Gapless and ReplayGain are exactly what the discerning listener needs :-)

from vanilla.

Hmm.. i just checket it myself and setting THREAD_PRIORITY_AUDIO does work in the latest android release, but i start to doubt that it has any effect on the mediaplayer:

All decoding is done in the 'mediaserver' process and this process (or the started decoding thread) does not inherit the priority of the thread that called 'new MediaPlayer()'.

I also verified that sending 'kill -STOP' to any of Vanilla Musics threads does not stop the audio playback.

Does the stuttering usually pop up at the beginning or end of a song or is it random?

from vanilla.

I spent my usual playtime (~45min) with Vanilla yesterday, modified with 'THREAD_PRIORITY_AUDIO', and it went well. I didn't see any issues, so it seems to work with 4.1.2. I'll update this thread later with further observations.

The behaviour is random; I have mostly noticed it in the middle of songs.

from vanilla.

It would appear the first instance of trouble-free playing was a fluke. On the next 2 subsequent days, I've noticed the same issue again. So 'THREAD_PRIORITY_AUDIO' is not the solution, although after this I have mostly seen the issue for microseconds (Only 1 instance where it went upto a sec).

from vanilla.

I just noticed that these random sputters have not occured on my device for nearly two months. I now use different headphones, a newer version of cyanogenmod and I have made multiple deep system changes to my device, so I can´t say what lead to the sputtering issues disappearing. But I would conclude that the issue is rare and device- or OS-specific (I can´t really imagine the headphones being the cause).

@gr1ff1n, has this issue persisted on your device, or does anyone else have them? If not, we could maybe close this issue.

from vanilla.

I've also noticed it.
Sony Xperia j Android 4.1.2

from vanilla.

I also noticed it sometimes (very rare) on my Xperia Z running 4.3 - it seems that files on the external sdcard are more likely to be affected. I therefore still think it's a readahead issue and i uploaded an experimental version at: http://neo01.eqmx.net/android/vanilla-ra.apk

This version includes a readahead option: It's disabled by default, you can enable it via Settings -> Audio -> Blabla (didn't care to translate it yet ;-) )

If this option is enabled, Vanilla will try to pre-read the currently playing file with about 256kB/s (that's good enough even for FLAC) and should therefore fill up the buffer-cache of the kernel.

from vanilla.

adrian, you might be onto something here regarding external cards. All of my music is on external storage.

FWIW, I'm using a MicroSDHC card of Samsung 32 GB, Class 6.

I'll try out the read-ahead version and report back in a few days whether the issue is resolved.

from vanilla.

You don't have to install the version i posted earlier: The feature is already included in the latest version available from the play store (but the feature is disabled by default: so make sure to enable it in the settings :-))

from vanilla.

I hadn't checked the latest version. So, i'll update to the latest and see if read-ahead solves the issue.

from vanilla.

I forgot to report back on this.

The read-ahead has solved the issue on my phone. I'm a happy user now :-)

from vanilla.

Starting with v0.9.24, I now encounter this stuttering bug VERY frequently (= every 3 to 6 SECONDS, not just twice per 45 min as the lucky OP :( )

It seems to happen without distinction with FLAC, Ogg Vorbis and MP3, and starts randomly after no particular event (I remember though that it once started stuttering after leaving airplane mode).

SD read-ahead is activated (The Nexus S only has an internal SD card though), and I have about 50MB RAM available at the time it happens. VLC has no problem playing music.

What SOMETIMES works to get rid of the problem :

• Rebooting the phone... but works only temporarily.

What does NOT work :

• Killing the app and restarting it
• Deinstalling and reinstalling the app
• Wiping cache/Dalvik cache (with Clockworkmod Recovery). Rebooting the phone afterwards does sometimes get rid of the stuttering, as stated above.

My setup :
Vanilla Player 0.9.24 from F-Droid
Samsung Nexus S i9023
CyanogenMod 10.2 stable (Android 4.3.1)

from vanilla.

Interesting. I use a Nexus S i9023, too, and I also used it with CM10.2 stable for some time, but I didn't experience sputters during this setup, as far as I can remember. (I didn't use the current Vanilla version, though, because it was not out at this time.)

This is strange, because I thought this was a device specific rom or kernel issue. Maybe it is important to note that I have always used Voodo sound (where I have set the amplifier to a slightly-below-standard level) and the standard Cyanogenmod kernel. Moreover, I always remove the DSP Manager app from my CM installations. I would try disabling it and see if something about those Vanilla problems changes.

Currently I am using Cyanogenmod 11 M6 (Android 4.4.2 based), which does not produce any sound problems with Vanilla either.
(As a sidenote, I would really recommend trying a 4.4-based rom for the Nexus S, because it needs by far less ram, and as a result, you have about 50 MiB more ram available for user processes. I would recommend CM 11 M5, as M6 has introduced an annoying SystemUI bug).

from vanilla.

Well, over the last months, I've had the following :

I used to have CM 10.2 and Vanilla 0.9.23 : no stuttering problem (I can't remember if 0.9.24 was out at that time). Used either the standard CM kernel, or the latest Matr1x one.

I then switched to CM 11 M5 : I only gave a quick try, as the "impossible-to-rotate welcome screen" and the "cannot enter new line in text messages" bugs were a deal-breaker for me. I can't remember if I used Vanilla (and what version it was), but I'm positive I would have remembered if I encountered stuttering.

I went back to CM 10.2 and Vanilla 0.9.24 : stuttering appears ! :-(

So I'm gonna try the following scenarios :

• Try disabling DSP Manager
• Keep CM 10.2 and downgrade to Vanilla 0.9.23
• If you can confirm that the two CM 11 M5 bugs I mentionned above have been corrected in CM 11 M6, I'd gladly update and give it a try. :-)

BTW, how did you use Voodoo sound ? I thought you needed a kernel that supports it.

from vanilla.

Sorry for going a bit off-topic now. What do you mean by "welcome screen" (and why do you want to rotate it)?

For text messages I use Textsecure, which works fine. As far as I know, CM's standard messaging app is based on it. Just try the original Textsecure from the Play Store, it does not have issues with new lines.

The official standard CM kernel does have Voodoo support. You can simply access it through the Voodoo app from the Play Store.

from vanilla.

Hi, and thanks for you reply.

I gave CM11 M6 a try, and at first, did not encounter the stuttering problem. However, it soon started again, though in a different way : instead of having bits of silence every few seconds, I had bits of white noise/screeching instead (= as if the current sound was played for more than its intended duration).

After lots of tests and tweaking, I found the cause, that has NOTHING to do with Vanilla Music : at the same time I upgraded from 0.9.23 to 0.9.24 (back when I was in CM10.2), I also updated my firewall app, AFWall+, from 1.2.9 to 1.3.1.11, and it appears that due to a bug, that app hogs the CPU several times per minute while asking for root privileges, causing stuttering in Vanilla Music, but also in DeadBeef and even Android's notifications ! That's what hinted me into another direction than Vanilla Music.

Downgrading AFWall+ to a previous version fixed all my stuttering music problems... :-)

Thanks for your advice and return ! I'll send you an email regarding Voodoo sound in order not to hijack this thread.

from vanilla.

Funny. I use AFWall+, too! I am running the donation version (which should internally be identical to the free one) in whitelist mode, version 1.3.1.1. I did not have any problems with it and it and it does not require root access very often, so it seems like your observation is at least not the general solution to the sound problems.

But can it be that you had the option "active rules" on in your former installation and now it is deactivated? Because this option leads to very frequent root accesses. I also had this one activated for some time in the past until I noticed that I didn't need it. Perhaps this was the cause for my sputtering problems, too. This would explain why on my phone they stopped again after a while, because I had "active rules" disabled for several months now.

I will enable it again and report if the issues reappear on my device.

from vanilla.

I actually installed CM11 on top of CM10.2 without wiping first, because I was in a hurry and wanted to try your suggestions. :-)

However, I've since noticed several small system-wide problems, so I'm gonna do a clean CM11 install from scratch. I'll report back afterwards.

from vanilla.

Looks like I was wrong / confused about those AFWall+ settings. I could not reproduce the frequent root accesses that I wrote about earlier. I tried changing nearly all settings, but none of them led to root overuse or those strange sounds in Vanilla.

The only things that I can confirm is that the music playback tends to stutter when another app uses too much cpu (but only stuttering, as in "stopping and starting very frequently", not the shocking distorted screeching that some of us experienced), and that it just stops completely when another app uses too much ram.

Complete stopping and force closing without warning is apparently an expected behavior of Android's memory management system.
The literal "stuttering" can also be explained, at least partially: The weak cpu of the Nexus S cannot always dedicate itself to realtime music playback, so it sometimes has to temporarily (for a few ms) stop the playback to do tasks with a higher priority. If there is no significant cpu usage, this explanation is of course not applyable.
These two things seem to be unfixable by Vanilla, they are only problems of low-end devices.

Sadly, I still have no idea what the cause of that screeching sputtering could be.

I hope that we are talking about the same problem at all, though. My main concern is a sudden loud screeching noise, and after re-reading the whole the thread I am not really sure anymore if we are talking about the same issue. I mean, "sputtering", like the OP worded it, is not the same as "stuttering", is it? English is not my first language, excuse me, but in my dictionary "sputtering" is described as "making an explosive or spitting sound", which would be quite different to "stuttering" (rapidly discontinueing and recountinueing an utterance)...

from vanilla.