04-23-2012 11:58 PM
I'm in the middle of making my fist NDK PlayBook app...
I have three threads in addition to the main thread:
1) A graphics thread decoding and displaying images.
2) An audio thread playing a WAV file.
3) A network thread downloading data.
As I've been working on this app, up until now I've only had the graphics thread and the network thread running. That worked great. I get a nice frame rate.
I then started working on the audio thread, and likewise, that seemed to work along side the network thread.
However, when I have all three threads running, everything falls apart. The audio constantly cuts out. The video constantly freezes, etc, etc.
This is the first time I've tried creating such a demanding app, and I was really hoping the PlayBook was up to it given that it's C code, and the PlayBook is dual core. For example, I wouldn't think that playing a WAV file would be very much work for a thread, so I was hoping the network transfers and audio could be handled easily by 1 CPU core, while the jpeg decoding could be handled by the other.
Any thoughts / recommendations?
Any help would be most appreciated.
Solved! Go to Solution.
04-24-2012 06:27 AM
I'm using the code from the "PlayWav" example app:
... except that I've adapted it to read from an in-memory buffer instead of a file stream.
04-24-2012 07:36 AM
i'm using openAl without any loss of frames (50-60 fps), also during rendering and some network connection in the background.
04-25-2012 12:56 AM
Have you tried tuning your thread priorities? Give the audio thread higher priority.
Scheduling is round-robin if the threads are all at the same priority, and if you have 3 threads on 2 cores, 2 threads will be competing at some point.
Read up on using pthread_attr_t with pthread_create(). See pthread_attr_setschedpolicy() and pthread_attr_setschedparam(). Setting priority to getprio(getpid()) + 1 will probably be sufficient.
I would also suggest investigating using larger audio block sizes, but it looks like the PlayWav example may already be using the max frag size advertised by the pcm device. Smaller block sizes means your thread has to wake up more often in order to keep the pcm pipeline full.
04-25-2012 07:16 AM
Thanks for your help. I tried just that yesterday and it seemed to do the trick. I also discovered a bug in that the network transfers buffers were running out, which was causing gaps in the audio and video, so I should turn off the thread priorities and see how much of the issue was due to the network bug...