BB(Z10 - 10.2.1.537) issue since Neutron 1.77.3.2

Report bugs and unexpected behavior here.
Post Reply
Spoony
Posts: 6
Joined: Sat Aug 03, 2013 5:30 pm

BB(Z10 - 10.2.1.537) issue since Neutron 1.77.3.2

Post by Spoony » Mon Feb 24, 2014 7:35 pm

Hello,

I've been running Neutron for some time now, in general I love the application. However it seems like your latest release has borderline broken your application. My Z10 is running 10.2.1.537 and Neutron is up to date (1.77.3.2). I have a set of shure E535's hooked up to the Z10.

When listening to music with Neutron if I open any other application (BBM for ex) and type to a contact, artifacts and popping are introduced into the audio stream (it's not subtle at all), the same types of noises are observed when moving between applications. The very same problem does not happen when using the default "music" application on my device. The problem doesn't appear to always show up immediately (if Neutron has been running for awhile it's pretty much a guarantee), if I reboot my device and load neutron it will run without issue for a few minutes but eventually it will be back in the same state as before, to sum it up:

Typing in a screen = noise in my headphones
Minimizing screens, moving between applications = noise in my headphones
Notifications are also not processed normally, half the time they start with clicking and popping. it sounds as if the notifications and Neutron are fighting for the same audio stream.

I've also noticed weird volume inconsistencies via Bluetooth (when hooked up to my 2011 Subaru WRX's HU) this is also a problem that has surfaced since the most recent Neutron release. Seems like if notifications are not silent and one comes in the device responds by lowering the music volume for 2-3 seconds (I have not tested this I've just noticed my volume flopping all over the place when my notifications are turned on).

This whole noise in my headphone deal pretty much kills the entire experience for me and as a result I've had to revert to my old BB music app (which - sucks). I don't see any other reports of this so I assume I'm somehow a unique snowflake. When this issue starts typically closing Neutron and re-opening it will resolve the problem temporarily.

Spoony
Posts: 6
Joined: Sat Aug 03, 2013 5:30 pm

Re: BB(Z10 - 10.2.1.537) issue since Neutron 1.77.3.2

Post by Spoony » Fri Feb 28, 2014 6:48 pm

Nothing...? I can't possibly be the only person experiencing this...having to restart this application every 15-20minutes is quite poor.

Spoony
Posts: 6
Joined: Sat Aug 03, 2013 5:30 pm

Re: BB(Z10 - 10.2.1.537) issue since Neutron 1.77.3.2

Post by Spoony » Mon Mar 03, 2014 6:05 pm

This seems massively improved with today's update (1.77.4.2). Not hearing anymore artifacts in the audiostream upon typing / switching frames. I briefly tested bluetooth - which sounded better (previously I was getting a fair amount of clipping when using Neutron over bluetooth).

I've only had a couple hours to listen but so far so good. Thanks very much for the update.

Spoony
Posts: 6
Joined: Sat Aug 03, 2013 5:30 pm

Re: BB(Z10 - 10.2.1.537) issue since Neutron 1.77.3.2

Post by Spoony » Mon Mar 10, 2014 2:20 pm

Update on this - it's still happening it just takes longer to occur.

Issue Description:
Upon launching Neutron all is well and actually stays that way for as little as 10minutes and as much as ~60 (unsure of exact time frame ... from my limited testing. During this time the audiostream is completely unaffected by anything you do on the device as far as I can tell. At some point *noise* (pops, clicks, clipping) will begin to enter the noise stream while attempting to use the device and listen to music through Neutron. This isn't slight noise in the background it's extremely obvious especially through my Shure e535's.

Workaround:
I've been working around this by closing and re-opening the application; at which point the above process is reset.

I assume the work done around active frames in the last couple updates is likely what improved this experience.

I love Neutron but this software bug is quite frustrating; I'll just get into a playlist or album and be interrupted by this nonsense...need to restart the software. The cyclic process makes it a little more difficult than usual to sit, listen to music and be productive - which is a major use case of mine for Neutron and indeed my Z10.

Please let me know if there's any information I can provide you from on my device to assist in pinpointing this - though I assume this experience would be uniform across all BB10 devices; I have no problem providing logging captures from a "normal" session and a "noisy" session; but I'm not sure if they would capture anything of use.

dmitrykos
Site Admin
Posts: 1847
Joined: Mon Apr 25, 2011 6:15 pm

Re: BB(Z10 - 10.2.1.537) issue since Neutron 1.77.3.2

Post by dmitrykos » Mon Mar 10, 2014 8:02 pm

Active Frame is just an UI issue and it does not affect audio stream stability. Interruptions are caused inside the audio layer of the OS (debugged) and the problem comes from the fact that BB10 OS is decreasing priority for the background process. There is not possibility / OS API which allows to revert to foreground priority. Even in such situation Neutron is OK and is delivering audio data on time to the OS audio layer but pops and clicks start to happen inside the OS later on. E.g. CPU time starvation is affecting OS core.

Also it was noticed that once interruptions start happening the device restart fixes the problem for some days.

Spoony
Posts: 6
Joined: Sat Aug 03, 2013 5:30 pm

Re: BB(Z10 - 10.2.1.537) issue since Neutron 1.77.3.2

Post by Spoony » Fri Mar 28, 2014 1:48 pm

Thanks for the response.

I'm now running Z10 SW - 10.2.1.2102 and Neutron - 1.77.7.2

This issue persists

I used to work for BlackBerry and still have some contacts in development. I have asked they take a look at this behavior. You should be able to guarantee priority to media focused applications. Yesterday I was driving home with nothing but neutron playing via BT over Subaru's H/U and the application was struggling to playback the media without stuttering and droping out; a few times it outright paused as if it was so overburdened it just had to wait (despite the fact that the device was doing nothing else).

This problem is infuriating (not directing my anger towards you - if you cannot control your applications priority there's not much you can do) However a smartphone should not have this much trouble with clear audio playback. It's worth noting the default music application does not seem to have this issue (likely because they've given their native applications highest priority).

Testing so far shows I get about 2.5 hours of music listening before the device decides to down-rank priority and at that point I'm forced to reboot or have my audio stream constantly interrupted.

This is a very stupid problem to have and I wouldn't be surprised if the OS was doing something it should not be.

dmitrykos
Site Admin
Posts: 1847
Joined: Mon Apr 25, 2011 6:15 pm

Re: BB(Z10 - 10.2.1.537) issue since Neutron 1.77.3.2

Post by dmitrykos » Fri Mar 28, 2014 3:52 pm

> It's worth noting the default music application does not seem to have this issue (likely because they've given their native applications highest priority)

Yes, exactly. Built-in music player has system priority and is not affected by OS scheduling issue for 3-rd party background apps (confirmed by BB10 audio team dev). Pauses usually happen when tracks are changing. Normally when new music file is opened there is some work to do: read data from storage, analyze headers, fill the memory buffers with data and so on. It causes spike in CPU consumption and at this point sluttering starts happening. But, there is no underrun in Neutron, e.g. rendered audio data is sent to OS on time (ALSA backend does not report underruns) but pauses are happening somewhere inside the OS. The interesting thing is that streaming audio is never affected, so probably file I/O is one of the reasons.

On Android such situation is possible as well, background processes have decreased CPU priority (done by OS) but there is possibility to assign foreground priority to the process and signal to OS that decreasing priority for this process is not desired and all is working well, even on single core 800 Mhz CPU.

iOS is probably forcing priority to the process when one of the audio output back-ends is set to running state and there are no problems with sluttering on this platform as well.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest