Day before yesterday I took a 65 mile trip mostly through areas with Sprint coverage. I was streaming (Bluetooth) music from my phone to my car audio system. Every now and then the stream was interrupted momentarily, perhaps 3 times per song. These interruptions are irritating. Wander was enabled.
Yesterday I made the return trip but with Wander disabled. My music stream wasn’t interrupted.
next time, try enabling Wander again on the return trip, see if the symptoms return.
I can’t prove Wander is causing this and I don’t spend that much time on the road but I’m wondering if Wander is doing a roaming check every 30 seconds or so that would interrupt the stream.
i actually check for roaming status every time the CELLID changes (app is triggered by changes to cell id) - i figure, if you don’t move to a new cell tower then your roaming status can’t possibly change. i suppose if you are in a really nasty area your cell id might change faster than once every 30 seconds (perhaps several times in a given second, but that would be really extreme).
regardless, when the cell id changes i just read a single global variable and either enable or disable mobile data.
nothing in Wander should ever be process intensive.
Anyone else experience these interrupts in their music stream? I’m using Wander on an X2. My phone wasn’t rebooted between trips.
i’d be interested to know if anyone else can reproduce this too, though i strongly doubt Wander is the culprit. i’m not even sure there is much i could do to improve the performance of the app. perhaps if i enable a persistent notification that would prevent Android from suspending the app and therefore speed up some operations while Android is under heavy load… doesn’t entirely likely to fix this though since your music player should run at a high priority and the bluetooth stack should run in kernel space and therefore not be affected by any of this.
p.s. The return trip was on a different path along a route parallel to, but 10 miles away from, Sprint coverage. I was in an area with solid roaming coverage according to the Sprint map. That path (the parallel portion) was roughly 30 miles long. ** The phone dropped in and out of roaming, was essentially useless, but did consume 1.6 Mb data. Sigh.**
1.6MB of roaming or native data? if roaming, perhaps your phone was under such heavy load that Wander couldn’t disable mobile data fast enough to prevent data consumption? this would suggest that being under heavy load was the problem rather than Wander itself causing some issue with bluetooth or music playback.
which music app do you use? was your phone in the exact same location in the car? (many Android 4.4.4 users have complained that bluetooth audio cuts out now and then on 4.4.4 while it worked fine for them on 4.4.2 - some have correlated this to a decrease in functional bluetooth range but i think it’s possible those folks are jumping to conclusions prematurely. still it would BEHAVE much like a reduced bluetooth range with respect to the old 1st gen moto X pre-4.4.4)
The highlighted road on this snippet of the Sprint map is entirely in the twilight zone:
perhaps it is the twilight zone itself that is the problem? you’ve mentioned before that the twilight zone causes all sorts of radio related problems for you (the phone trying to remain connected to sprint towers that it can’t actually use, etc). radio and modem functions would execute in kernel space and are fully capable of causing user code (like your music app) to starve for cpu cycles.
let me know if you can ever reproduce this. otherwise, watch for Wander’s battery usage in general - it should consume so little that it might not even show up in the list, but if it ever DOES consume a lot more battery then (and only then) it would make sense that Wander has a related bug that I could hopefully find and fix. not using power means not burning cpu cycles; since i don’t perform flash writes or network operations there really isnt’ any other way for me to slow down the system aside from burning too many cpu cycles.