Native Development

[sucroid]

All of a sudden, my app (which uses the asound library) is getting underruns that it didn't get before.

The same BAR for the PlayBook runs fine without underruns but it's getting underruns in both the Dev Alpha A and Dev Alpha B.  Has the audio changed?

Does setting thread priority no longer work in the latest OS?

[peter9477]

No idea about threads, but my own White Noise app uses libasound as well, and hasn't had any troubles with the latest version (which is really 10.0.9.2320... the one you show there is the "release" number but most times you'll see the OS Version report instead).

[arkadiamail]

Please check this patch for the latest correct way of working with the audio device:

http://trac.pjsip.org/repos/changeset?reponame=&old=4316%40pjproject%2Ftrunk&new=4316%40pjproject%2F...

You'll need to call:

if ((pb_result = snd_pcm_plugin_set_disable (pcm_handle, PLUGIN_DISABLE_MMAP)) < 0)

after openning audio device. Give it a try in your code.

[sucroid]

Thanks for the info.  It didn't seem to help though I'm interested in why disabling MMAP should be performed for BB10 and not the PlayBook.

Anyway, I think I have solved the problem by doubling the num_frags (thus doubling the latency) but am boggled why the PlayBook (which has a slower processor than both Dev Alpha A and B) would handle the low latency without sweat.

---

arkadiamail wrote:

Please check this patch for the latest correct way of working with the audio device:

http://trac.pjsip.org/repos/changeset?reponame=&old=4316%40pjproject%2Ftrunk&new=4316%40pjproject%2F...

You'll need to call:

if ((pb_result = snd_pcm_plugin_set_disable (pcm_handle, PLUGIN_DISABLE_MMAP)) < 0)

after openning audio device. Give it a try in your code.

---

[peter9477]

---

sucroid wrote:

Thanks for the info.  It didn't seem to help though I'm interested in why disabling MMAP should be performed for BB10 and not the PlayBook.

---

I don't know about the PlayBook, since my libasound code was never used there, but on BB10 the docs note that MMAP needs to be disabled if you want to use the "free" and/or "count" values from the snd_pcm_plugin_status() results.  If you're trying to build something that dynamically adjusts the amount of buffering, that may be a requirement.

[smcveigh]

it's possibly related to all the advanced power management going on in BB10 these days (cpu being put into low-power states when less active, cores being disabled, clocks being reduced, etc.)

If you can boil this down to a simple sample, I can pass it along to the audio team to debug.  might be a bug.

thread priorities still work as usual.

what sort of cpu load are you looking at?  I think the diagnostic overlay may be gone now, but maybe you remember how it looked on the last beta?

Cheers,

Sean

[sucroid]

---

smcveigh wrote:

it's possibly related to all the advanced power management going on in BB10 these days (cpu being put into low-power states when less active, cores being disabled, clocks being reduced, etc.)

If you can boil this down to a simple sample, I can pass it along to the audio team to debug.  might be a bug.

thread priorities still work as usual.

what sort of cpu load are you looking at?  I think the diagnostic overlay may be gone now, but maybe you remember how it looked on the last beta?

Cheers,

Sean

---

I can't get to the diagnostic overlay anymore.  (Before that I got to it by accident.  Never knew the exact gesture for bringing it up.)

The underrun occurs when the sound generation is doing more work than usual.  My app is a real-time synthesis app that synthesizes audio on the fly.  The more complicated the sound, the more work it has to do.  I'd say at medium workload I was already getting underruns (caused by inability to generate the sound fast enough).  There was not a problem (and is not a problem on the PlayBook) before.

If nothing has changed on the audio side, I suspect that the OS is trying to throttle my app.  But I can't really tell now because autoloader won't let me downgrade to the previous OS version for a comparison.

In any case, the problem could be sidestepped by increasing latency, which is still quite good.  If it does become an issue again, I'll cook up an example to illustrate the problem after this weekend's port-a-thon.

[smcveigh]

ok.

if you want to boil down one of your more problematic signal generators, that would be something we could look at.

is it a continuous underrun, or just sporradic?  there are some other system services which can periodically wake up at higher priority.  are you setting your generator thread priority up to like 50 or higher?

[sucroid]

Its mostly sporadic. Usually the first few seconds are fine. Then it becomes more frequent as time goes by. Sounds like things are being interrupted by other processes.

How high can I set the priority to? Currently, the audio threads were set to priority 50.

[smcveigh · Accepted solution]

not sure what the hard limit is.  some of the highest-priority threads in the system are part of the io-audio driver (most are 50, and at least one interrupt thread is 51).

definitely would be interesting to see code that works ok on playbook but not a dev alpha (which has a better cpu).

Cheers,

Sean