You are welcome! There are threads in mediaserver, and threads in each
client app.
I'll start with mediaserver.
This adb shell command will show the pid of mediaserver:
ps mediaserver
Then to see the threads, do
ps -t pid
The primary output thread is usually named AudioOut_2 or similar.
This should always be present.
The primary output thread may have a companion FastMixer thread, which
works under its supervision.
The primary output thread may go into idle (standby) when there is no audio
to be output,
but it usually never exits.
Then there are direct output, offloaded output, and duplicating threads.
These are created and destroyed as needed.
Direct output is used when no mixing is needed, for example for HDMI output.
Offloaded output is for MP3/AAC playback in low-power mode to a DSP,
without requiring decode to PCM on app processor.
Duplicating output is a kind of fake output, used as a sub-mix for
Bluetooth A2DP notifications + music.
The number of output threads is mainly limited by the number of available
output sinks (devices or virtual devices).
Input is similar to output, but there is no concept of a primary input
thread that is always active.
There are also many other threads in mediaserver, but I'm not experienced
in that area.
On the client app side, there is one AudioTrack thread per AudioTrack
object.
It services callback handlers.
I can't answer the processing power question; there is no easy formula that
I know of.
On Thursday, June 12, 2014 12:05:01 PM UTC-7, Andrei wrote:
>
> I'm trying to find out how the number of playback threads grows under
> different usage conditions.
>
> I've been following AudioFlinger code, but some things are less apparent
> than others. So far, Glenn Kasten has been very helpful with his responses,
> so thanks a ton!
>
> From some debugging messages I've inserted into AudioFlinger, I see that
> one thread gets created when I play audio using a browser or a media
> player. This one persists, and I believe never gets destroyed even if I
> don't play any audio for a while. Then there are other threads that get
> created and destroyed pretty frequently. Those threads are responsible for
> system sounds, e.g. button clicks. I believe I've also seen another thread
> created when I turn on navigation (is this true?). Navigation audio lives
> alongside media playback and uses "ducking" whenever it needs to play
> something back. So far, I haven't seen more than three PlaybackThread
> instances actively processing audio at a given time.
>
> Is there a theoretical or practical limit to how many playback threads can
> be actively processing audio at once? I'm inserting some audio processing
> into playback before audio goes out to hardware, and I'd like to know how
> much processing power my algorithms may need in reality.
>
>
>
--
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-porting+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
