Audioflinger of Android audio System (i)

http://blog.csdn.net/xuesen_lin/article/details/8805068

1.1 Audioflinger

In the above frame diagram, we can see that Audioflinger (hereinafter referred to as AF) is the core and difficulty of the entire audio system. As an audio hub in an Android system, it is also a system service that restarts (providing access to the upper layer) to the boot (to manage audio devices through the HAL). Only by understanding the Audioflinger can we use this as a basis for better depth to other modules, so we put it in front of the analysis.

1.1.1 Audioflinger Service Start-up and operation

We know that the system services in Android are divided into two categories, the Java layer and the native layer. Among them Audioflinger and Surfaceflinger, all belong to the latter. Java layer services are typically started in Systemserver.java, such as the audioservice that you'll see later. The native layer service is usually the service side in accordance with their own specific deployment to determine when to start, how to start. For example, Audioflinger is created indirectly using a Linux program, as follows:

/*frameworks/av/media/mediaserver/main_mediaserver.cpp*/

int main (int argc, char** argv)

{

Sp<processstate>proc (Processstate::self ());

SP<ISERVICEMANAGER>SM = Defaultservicemanager ();

Alogi ("ServiceManager:%p", Sm.get ());

Audioflinger::instantiate ();

Mediaplayerservice::instantiate ();

Cameraservice::instantiate ();

Audiopolicyservice::instantiate ();

Processstate::self ()->startthreadpool ();

Ipcthreadstate::self ()->jointhreadpool ();

}

This MediaServer directory has only one file, its task is simple, is to put all media-related native layer services (including Audioflinger,mediaplayerservice, Cameraservice and Audiopolicyservice) can be started by referring to their android.mk:

local_src_files:= \

Main_mediaserver.cpp

Local_shared_libraries: = \

Libaudioflinger\

Libcameraservice\

Libmediaplayerservice\

Libutils \

Libbinder

...

local_module:= MediaServer

According to the previous analysis, Audioflinger's source code implementation is placed in the Libaudioflinger library, so when compiling mediaserver to reference the library, other services are the same practice. The compiled generated mediaserver will be burned to the/system/bin/mediaserver path of the device and then initiated by the INIT process at system startup, and its configuration in init.rc is:

Service Media/system/bin/mediaserver

Class Main

User Media

Group Audio camera INETNET_BT net_bt_admin Net_bw_acct drmrpc

Ioprio RT 4

It is worth mentioning that this audioflinger::instantiate () is not a static class within Audioflinger, but rather an implementation of the Binderservice class. Several services, including Audioflinger, Audiopolicyservice, etc., are inherited from this unified binder service class, such as:

Class Audioflinger:

Public binderservice<audioflinger>

Public Bnaudioflinger ...

From the name, Binderservice should be implemented binder cross-process communication related functions, it is a template class, where the function instantiate will be the template specified by the service created, and added to ServiceManager:

/*frameworks/native/include/binder/binderservice.h*/

Template<typename service> ...

Static status_t publish (bool allowisolated = False) {

sp<iservicemanager> SM (Defaultservicemanager ());

Returnsm->addservice (String16 (Service::getservicename ()), New SERVICE (), allowisolated);

}

static void Instantiate () {Publish ();}//Call Publish

Looking back at Audioflinger's constructor, I found that it simply initialized some of the internal variables, except that there was no code:

Audioflinger::audioflinger ()

: Bnaudioflinger (), Mprimaryhardwaredev (NULL),

Mhardwarestatus (Audio_hw_idle),//See Alsoonfirstref ()

Mmastervolume (1.0f), MMASTERVOLUMESUPPORTLVL (Mvs_none), Mmastermute (false),

Mnextuniqueid (1), Mmode (Audio_mode_invalid), Mbtnrecisoff (false)

{

}

People may feel puzzled, so under what circumstances will Audioflinger start to carry out the actual work? Yes, it is in Onfirstref (). Bnaudioflinger is inherited from the refbase layer, and the second parameter of Iservicemanager::addservice is actually a strong pointer reference (constsp<ibinder>&), Thus Audioflinger has the program logic to invoke ONFIRSTREF when the strong pointer is first quoted. If you are not very clear about these details, you can refer to the next book of the strong Pointers section, here no longer repeat.

void Audioflinger::onfirstref ()

{

int rc = 0;

Mutex::autolock _l (MLock);

Charval_str[property_value_max] = {0};

if (Property_get ("Ro.audio.flinger_standbytime_ms", Val_str, NULL) >=0) {

uint32_t Int_val;

if (1 ==sscanf (val_str, "%u", &int_val)) {

mstandbytimeinnsecs= milliseconds (int_val);

Alogi ("using%u MSec as Standby time.", Int_val);

} else {

Mstandbytimeinnsecs = Kdefaultstandbytimeinnsecs;

...

}

}

Mmode = Audio_mode_normal;

MMASTERVOLUMESW = 1.0;

Mmastervolume = 1.0;

Mhardwarestatus =audio_hw_idle;

}

The Ro.audio.flinger_standbytime_ms property provides an interface for the user to adjust the standby time, which is fixed in earlier versions. The next step is to initialize several important internal variables, unlike constructors, where the values given are valid.

From this point on, Audioflinger is a "meaningful" entity, because someone has used it. Next, other processes can be accessed through ServiceManager, and a series of interfaces, such as Createtrack, Openoutput, are invoked to drive Audioflinger to perform audio processing operations, which we will explain in a later chapter.

Audioflinger of Android audio System (i)