05-09-2012 10:41 PM - edited 05-09-2012 10:42 PM
A couple of weeks ago when I was finishing my "Flix" app and adjusting thread priorities, I noticed that the high priority audio thread interfered with the PlayBook's volume buttons. More specifically, you could press a volume button and nothing would happen, at least, not for a second or two. It was as if the priority of the audio thread was so high that it was preventing the OS from responding to the user's press of the hardware button.
This week, the behavior is quite different: The volume controls work just fine, but as soon as you press one of them, the audio thread starts to struggle, and the audio gets all "poppy/static'y".
The really strange thing is that even after the volume change notification disappears off of the screen, the audio remains "poppy/static'y", as if the volume change event permanently interferes with the audio thread.
I wondered whether the OS was lowering the priority of the thread upon a volume change event, but I think I've ruled that out... when I ask the audio thread for its priority, it stays at 63 before and after the volume change events.
So this is obviously very puzzling... how on earth could a single volume change event interfere with the app's audio thread for the remainder of the app's execution? (Even if the app gets a "breather" due to needing to buffer additional audio/video, as soon as the audio resumes, it's still static'y)
The other thing which may or may not be related is that last week my PlayBook prompted me that there was an OS update. The strange thing is that the version of the update seemed to be the exact same as the version of the OS I already had, and it was only 3 MB. I can't help but wonder whether this is somehow related to the change in behavior I am seeing.
Any help would be most appreciated.
Solved! Go to Solution.
05-09-2012 11:13 PM - edited 05-09-2012 11:14 PM
I have noticed similar behaviour when the PB is just sitting in the homescreen with no apps running. Sometimes when pressing and holding the volume buttons there is a delay of approx 1 sec, then volume control appears and the volume shoots up to 100% (or down to 0%), like a stuck key repeat on a keyboard.
05-10-2012 02:10 PM
The delay you see when pressing volume buttons after leaving the device for a while may be related to the paging that is happening on-device. Reportedly there may be a performance bump coming in the future to the pager.
05-10-2012 08:08 PM
Any thoughts on my particular predicament? (which is no longer laggy volume buttons)
05-11-2012 10:15 AM
Are you running a release build, or debug? Try a Device Release build.
There are a number of ways you could approach debugging this... since you are driving pcm directly (I presume), you could try hacking out your input audio stream and replacing it with a repeating fixed buffer (eg. a sine wave) to eliminate potential underruns caused by whatever thread is feeding/decompressing/streaming data to your audio thread.
05-13-2012 04:13 PM
Yup, running a Device Release build...
Although, now the PlayBook has reverted to the old behavior whereby the volume buttons are laggy. For the most part. I'm still finding that after I change the volume, there is a much higher incidence of "pops" in the audio. (But they are perhaps one every couple of seconds, rather than many pops per second as it was before)
The BB 10 Dev Alpha is still behaving in the manner where the volume control works but the audio gets extremely poppy after I change the volume.
Interesting thought to do a test where I take all of the other threads out of play and see if the volume control interferes with a single thread playing audio. Maybe I'll try and do that... although, even if that test "passes" and the volume control doesn't cause a problem, does that tell me anything? ie. It's very possible that the problem only occurs when the device is under heavy load.
05-25-2012 08:26 PM
I eventually figured out how to prevent the volume control from causing audio problems.
Here's the long winded answer:
- My app plays WAV files back to back. There was a slight "seam" in the audio that I was trying to get rid of.
- Something I tried was removing the calls to snd_pcm_open and snd_mixer_open every time a WAV file was played, thinking that might have something to do with the slight gap in the audio.
- I didn't realize it at the time, but I believe this is when changing the volume started causing distortions on the audio.
- The distortions are prevented by listening for volume change events, and when one is received, ensuring that I call snd_pcm_open and snd_mixer_open upon playing the next WAV file.
05-27-2012 09:22 AM
Unless you're trying to play multiple audio streams at the same time, you just need to open the pcm once. So if you are playing mulitple audio files back to back, the best thing to do is have a thread write to an intermediate buffer (like what Sean proposed in another thread, pun unintended).
Back to topic: I do notice popping when changing volume. In fact, sometimes the PB would just pop and click playing long wave files. I don't know what is really going on.
05-27-2012 01:42 PM
That's what I would have thought too -- that the pcm only needs to be opened once. But my experience would seem to suggest otherwise. It would be interesting to do some more testing. For example, what happens if you run the PlayWav code and adjust the volume while the audio is playing?
I'm not going to spend the time to try and isolate this problem any further since I have it working suitibly.