ANDROID音頻系統散記之四：4.0音頻系統HAL初探

昨天（2011-11-15）發佈了Android4.0的源碼，今天download下來，開始挺進4.0時代。簡單看了一下，發現音頻系統方面與2.3的有較多地方不同，下面逐一描述。

一、代碼模塊位置

1、AudioFlinger

frameworks/base/services/audioflinger/
+-- Android.mk
+-- AudioBufferProvider.h
+-- AudioFlinger.cpp
+-- AudioFlinger.h
+-- AudioMixer.cpp
+-- AudioMixer.h
+-- AudioPolicyService.cpp
+-- AudioPolicyService.h
+-- AudioResampler.cpp
+-- AudioResamplerCubic.cpp
+-- AudioResamplerCubic.h
+-- AudioResampler.h
+-- AudioResamplerSinc.cpp
+-- AudioResamplerSinc.h

AudioFlinger相關代碼，好像這部分與2.3相差不大，至少接口是兼容的。值得注意的是：2.3位於這裏的還有AudioHardwareGeneric、AudioHardwareInterface、A2dpAudioInterface等一系列接口代碼，現在都移除了。實際上，這些接口變更爲legacy（有另外更好的實現方式，但也兼容之前的方法），取而代之的是要實現hardware/libhardware/include/hardware/audio.h提供的接口，這是一個較大的變化。

兩種Audio Hardware HAL接口定義：

1/ legacy：hardware/libhardware_legacy/include/hardware_legacy/AudioHardwareInterface.h

2/ current：hardware/libhardware/include/hardware/audio.h

2、audio_hw

hardware/libhardware_legacy/audio/
+-- A2dpAudioInterface.cpp
+-- A2dpAudioInterface.h
+-- Android.mk
+-- AudioDumpInterface.cpp
+-- AudioDumpInterface.h
+-- AudioHardwareGeneric.cpp
+-- AudioHardwareGeneric.h
+-- AudioHardwareInterface.cpp
+-- AudioHardwareStub.cpp
+-- AudioHardwareStub.h
+-- audio_hw_hal.cpp
+-- AudioPolicyCompatClient.cpp
+-- AudioPolicyCompatClient.h
+-- audio_policy_hal.cpp
+-- AudioPolicyManagerBase.cpp
+-- AudioPolicyManagerDefault.cpp
+-- AudioPolicyManagerDefault.h

上面提及的AudioHardwareGeneric、AudioHardwareInterface、A2dpAudioInterface等都放到libhardware_legacy裏。

事實上legacy也要封裝成current中的audio.h，確切的說需要一個聯繫legacy interface和not legacy interface的中間層，這裏的audio_hw_hal.cpp就充當這樣的一個角色了。因此，我們其實也可以把2.3之前的alsa_sound這一套東西也搬過來。

hardware/libhardware/modules/audio/
+-- Android.mk
+-- audio_hw.c
+-- audio_policy.c

這是一個stub（類似於2.3中的AudioHardwareStub），大多數函數只是簡單的返回一個值，並沒有實際操作，只是保證Android能得到一個audio hardware hal實例，從而啓動運行，當然聲音沒有輸出到外設的。在底層音頻驅動或audio hardware hal還沒有實現好的情況下，可以使用這個stub device，先讓Android跑起來。

device/samsung/tuna/audio/
+-- Android.mk
+-- audio_hw.c
+-- ril_interface.c
+-- ril_interface.h

這是Samsung Tuna的音頻設備抽象層，很有參考價值，計劃以後就在它的基礎上進行移植。它調用tinyalsa的接口，可見這個方案的底層音頻驅動是alsa。

3、tinyalsa

external/tinyalsa/
+-- Android.mk
+-- include
|   +-- tinyalsa
|       +-- asoundlib.h
+-- mixer.c      ##類alsa-lib的control，作用音頻部件開關、音量調節等
+-- pcm.c        ##類alsa-lib的pcm，作用音頻pcm數據回放錄製
+-- README
+-- tinycap.c    ##類alsa_arecord
+-- tinymix.c    ##類alsa_amixer
+-- tinyplay.c   ##類alsa_aplay

在2.3時代，Android還隱晦把它放在android2.3.1-gingerbread/device/samsung/crespo/libaudio，現在終於把alsa-lib一腳踢開，小三變正室了，正名tinyalsa。

這其實是歷史的必然了，alsa-lib太過複雜繁瑣了，我看得也很不爽；更重要的商業上面的考慮，必須移除被GNU GPL授權證所約束的部份，alsa-lib並不是個例。

注意：上面的hardware/libhardware_legacy/audio/、hardware/libhardware/modules/audio/、device/samsung/tuna/audio/是同層的。之一是legacy audio，用於兼容2.2時代的alsa_sound；之二是stub audio接口；之三是Samsung Tuna的音頻抽象層實現。調用層次：AudioFlinger -> audio_hw -> tinyalsa。

二、Audio Hardware HAL加載

1、AudioFlinger

//加載audio hardware hal
static int load_audio_interface(const char *if_name, const hw_module_t **mod,
                                audio_hw_device_t **dev)
{
    int rc;
    
    //根據classid和if_name找到指定的動態庫並加載，這裏加載的是音頻動態庫，如libaudio.primary.tuna.so
    rc = hw_get_module_by_class(AUDIO_HARDWARE_MODULE_ID, if_name, mod);
    if (rc)
        goto out;

    //加載好的動態庫模塊必有個open方法，調用open方法打開音頻設備模塊
    rc = audio_hw_device_open(*mod, dev);
    LOGE_IF(rc, "couldn't open audio hw device in %s.%s (%s)",
            AUDIO_HARDWARE_MODULE_ID, if_name, strerror(-rc));
    if (rc)
        goto out;

    return 0;

out:
    *mod = NULL;
    *dev = NULL;
    return rc;
}

//音頻設備接口，hw_get_module_by_class需要根據這些字符串找到相關的音頻模塊庫
static const char *audio_interfaces[] = {
    "primary", //主音頻設備，一般爲本機codec
    "a2dp",    //a2dp設備，藍牙高保真音頻
    "usb",     //usb-audio設備，這個東東我2.3就考慮要實現了，現在終於支持了
};
#define ARRAY_SIZE(x) (sizeof((x))/sizeof(((x)[0])))

// ----------------------------------------------------------------------------

AudioFlinger::AudioFlinger()
    : BnAudioFlinger(),
        mPrimaryHardwareDev(0), mMasterVolume(1.0f), mMasterMute(false), mNextUniqueId(1),
        mBtNrecIsOff(false)
{
}

void AudioFlinger::onFirstRef()
{
    int rc = 0;

    Mutex::Autolock _l(mLock);

    /* TODO: move all this work into an Init() function */
    mHardwareStatus = AUDIO_HW_IDLE;

    //打開audio_interfaces數組定義的所有音頻設備
    for (size_t i = 0; i < ARRAY_SIZE(audio_interfaces); i++) {
        const hw_module_t *mod;
        audio_hw_device_t *dev;

        rc = load_audio_interface(audio_interfaces[i], &mod, &dev);
        if (rc)
            continue;

        LOGI("Loaded %s audio interface from %s (%s)", audio_interfaces[i],
             mod->name, mod->id);
        mAudioHwDevs.push(dev); //mAudioHwDevs是一個Vector，存儲已打開的audio hw devices

        if (!mPrimaryHardwareDev) {
            mPrimaryHardwareDev = dev;
            LOGI("Using '%s' (%s.%s) as the primary audio interface",
                 mod->name, mod->id, audio_interfaces[i]);
        }
    }

    mHardwareStatus = AUDIO_HW_INIT;

    if (!mPrimaryHardwareDev || mAudioHwDevs.size() == 0) {
        LOGE("Primary audio interface not found");
        return;
    }

    //對audio hw devices進行一些初始化，如mode、master volume的設置
    for (size_t i = 0; i < mAudioHwDevs.size(); i++) {
        audio_hw_device_t *dev = mAudioHwDevs[i];

        mHardwareStatus = AUDIO_HW_INIT;
        rc = dev->init_check(dev);
        if (rc == 0) {
            AutoMutex lock(mHardwareLock);

            mMode = AUDIO_MODE_NORMAL;
            mHardwareStatus = AUDIO_HW_SET_MODE;
            dev->set_mode(dev, mMode);
            mHardwareStatus = AUDIO_HW_SET_MASTER_VOLUME;
            dev->set_master_volume(dev, 1.0f);
            mHardwareStatus = AUDIO_HW_IDLE;
        }
    }
}

以上對AudioFlinger進行的分析，主要是通過hw_get_module_by_class()找到模塊接口名字if_name相匹配的模塊庫，加載，然後audio_hw_device_open()調用模塊的open方法，完成音頻設備模塊的初始化。

留意AudioFlinger的構造函數只有簡單的私有變量的初始化操作了，把音頻設備初始化放到onFirstRef()，Android終於改進了這一點，好的設計根本不應該把可能會失敗的操作放到構造函數中。onFirstRef是RefBase類的一個虛函數，在構造sp的時候就會被調用。因此，在構造sp<AudioFlinger>的時候就會觸發onFirstRef方法，從而完成音頻設備模塊初始化。

2、hw_get_module_by_class

我們接下來看看hw_get_module_by_class，實現在hardware/libhardware/ hardware.c中，它作用加載指定名字的模塊庫（.so文件），這個應該是用於加載所有硬件設備相關的庫文件，並不只是音頻設備。

int hw_get_module_by_class(const char *class_id, const char *inst,
                           const struct hw_module_t **module)
{
    int status;
    int i;
    const struct hw_module_t *hmi = NULL;
    char prop[PATH_MAX];
    char path[PATH_MAX];
    char name[PATH_MAX];

    if (inst)
        snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
    else
        strlcpy(name, class_id, PATH_MAX);
        
    //這裏我們以音頻庫爲例，AudioFlinger調用到這個函數時，
    //class_id=AUDIO_HARDWARE_MODULE_ID="audio"，inst="primary"(或"a2dp"或"usb")
    //那麼此時name="audio.primary"

    /*
     * Here we rely on the fact that calling dlopen multiple times on
     * the same .so will simply increment a refcount (and not load
     * a new copy of the library).
     * We also assume that dlopen() is thread-safe.
     */

    /* Loop through the configuration variants looking for a module */
    for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
        if (i < HAL_VARIANT_KEYS_COUNT) {
        	  //通過property_get找到廠家標記如"ro.product.board=tuna"，這時prop="tuna"
            if (property_get(variant_keys[i], prop, NULL) == 0) {
                continue;
            }
            snprintf(path, sizeof(path), "%s/%s.%s.so",
                     HAL_LIBRARY_PATH2, name, prop); //#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"
            if (access(path, R_OK) == 0) break;

            snprintf(path, sizeof(path), "%s/%s.%s.so",
                     HAL_LIBRARY_PATH1, name, prop); //#define HAL_LIBRARY_PATH1 "/system/lib/hw"
            if (access(path, R_OK) == 0) break;
        } else {
            snprintf(path, sizeof(path), "%s/%s.default.so", //如沒有指定的庫文件，則加載default.so，即stub-device
                     HAL_LIBRARY_PATH1, name);
            if (access(path, R_OK) == 0) break;
        }
    }
    //到這裏，完成一個模塊庫的完整路徑名稱，如path="/system/lib/hw/audio.primary.tuna.so"
    //如何生成audio.primary.tuna.so？請看相關的Android.mk文件，其中有定義LOCAL_MODULE := audio.primary.tuna

    status = -ENOENT;
    if (i < HAL_VARIANT_KEYS_COUNT+1) {
        /* load the module, if this fails, we're doomed, and we should not try
         * to load a different variant. */
        status = load(class_id, path, module); //加載模塊庫
    }

    return status;
}

load()函數不詳細分析了，它通過dlopen加載庫文件，然後dlsym找到hal_module_info的首地址。我們先看看hal_module_info的定義：

/**
 * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM
 * and the fields of this data structure must begin with hw_module_t
 * followed by module specific information.
 */
typedef struct hw_module_t {
    /** tag must be initialized to HARDWARE_MODULE_TAG */
    uint32_t tag;

    /** major version number for the module */
    uint16_t version_major;

    /** minor version number of the module */
    uint16_t version_minor;

    /** Identifier of module */
    const char *id;

    /** Name of this module */
    const char *name;

    /** Author/owner/implementor of the module */
    const char *author;

    /** Modules methods */
    struct hw_module_methods_t* methods;

    /** module's dso */
    void* dso;

    /** padding to 128 bytes, reserved for future use */
    uint32_t reserved[32-7];

} hw_module_t;

typedef struct hw_module_methods_t {
    /** Open a specific device */
    int (*open)(const struct hw_module_t* module, const char* id,
            struct hw_device_t** device);

} hw_module_methods_t;

這個結構體很重要，註釋很詳細。dlsym拿到這個結構體的首地址後，就可以調用Modules methods進行設備模塊的初始化了。設備模塊中，都應該按照這個格式初始化好這個結構體，否則dlsym找不到它，也就無法調用Modules methods進行初始化了。

例如，在audio_hw.c中，它是這樣定義的：

static struct hw_module_methods_t hal_module_methods = {
    .open = adev_open,
};

struct audio_module HAL_MODULE_INFO_SYM = {
    .common = {
        .tag = HARDWARE_MODULE_TAG,
        .version_major = 1,
        .version_minor = 0,
        .id = AUDIO_HARDWARE_MODULE_ID,
        .name = "Tuna audio HW HAL",
        .author = "The Android Open Source Project",
        .methods = &hal_module_methods,
    },
};

3、audio_hw

好了，經過一番周折，又dlopen又dlsym的，終於進入我們的audio_hw。這部分沒什麼好說的，按照hardware/libhardware/include/hardware/audio.h定義的接口實現就行了。這些接口全扔到一個結構體裏面的，這樣做的好處是：不必用大量的dlsym來獲取各個接口函數的地址，只需找到這個結構體即可，從易用性和可擴充性來說，都是首選方式。

接口定義如下：

struct audio_hw_device {
    struct hw_device_t common;

    /**
     * used by audio flinger to enumerate what devices are supported by
     * each audio_hw_device implementation.
     *
     * Return value is a bitmask of 1 or more values of audio_devices_t
     */
    uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);

    /**
     * check to see if the audio hardware interface has been initialized.
     * returns 0 on success, -ENODEV on failure.
     */
    int (*init_check)(const struct audio_hw_device *dev);

    /** set the audio volume of a voice call. Range is between 0.0 and 1.0 */
    int (*set_voice_volume)(struct audio_hw_device *dev, float volume);

    /**
     * set the audio volume for all audio activities other than voice call.
     * Range between 0.0 and 1.0. If any value other than 0 is returned,
     * the software mixer will emulate this capability.
     */
    int (*set_master_volume)(struct audio_hw_device *dev, float volume);

    /**
     * setMode is called when the audio mode changes. AUDIO_MODE_NORMAL mode
     * is for standard audio playback, AUDIO_MODE_RINGTONE when a ringtone is
     * playing, and AUDIO_MODE_IN_CALL when a call is in progress.
     */
    int (*set_mode)(struct audio_hw_device *dev, int mode);

    /* mic mute */
    int (*set_mic_mute)(struct audio_hw_device *dev, bool state);
    int (*get_mic_mute)(const struct audio_hw_device *dev, bool *state);

    /* set/get global audio parameters */
    int (*set_parameters)(struct audio_hw_device *dev, const char *kv_pairs);

    /*
     * Returns a pointer to a heap allocated string. The caller is responsible
     * for freeing the memory for it.
     */
    char * (*get_parameters)(const struct audio_hw_device *dev,
                             const char *keys);

    /* Returns audio input buffer size according to parameters passed or
     * 0 if one of the parameters is not supported
     */
    size_t (*get_input_buffer_size)(const struct audio_hw_device *dev,
                                    uint32_t sample_rate, int format,
                                    int channel_count);

    /** This method creates and opens the audio hardware output stream */
    int (*open_output_stream)(struct audio_hw_device *dev, uint32_t devices,
                              int *format, uint32_t *channels,
                              uint32_t *sample_rate,
                              struct audio_stream_out **out);

    void (*close_output_stream)(struct audio_hw_device *dev,
                                struct audio_stream_out* out);

    /** This method creates and opens the audio hardware input stream */
    int (*open_input_stream)(struct audio_hw_device *dev, uint32_t devices,
                             int *format, uint32_t *channels,
                             uint32_t *sample_rate,
                             audio_in_acoustics_t acoustics,
                             struct audio_stream_in **stream_in);

    void (*close_input_stream)(struct audio_hw_device *dev,
                               struct audio_stream_in *in);

    /** This method dumps the state of the audio hardware */
    int (*dump)(const struct audio_hw_device *dev, int fd);
};
typedef struct audio_hw_device audio_hw_device_t;

注：這是比較標準的C接口設計方法了，但是個人感覺還是用C++比較好，直觀易讀。2.3之前都是用C++實現這些接口設計的，到了4.0，不知道爲何採納用C？不會理由是做底層的不懂C++吧？！

三、Audio Hardware HAL的legacy實現

之前提到兩種Audio Hardware HAL接口定義：
1/ legacy：hardware/libhardware_legacy/include/hardware_legacy/AudioHardwareInterface.h
2/ current：hardware/libhardware/include/hardware/audio.h
前者是2.3及之前的音頻設備接口定義，後者是4.0的接口定義。

爲了兼容以前的設計，4.0實現一箇中間層：hardware/libhardware_legacy/audio/audio_hw_hal.cpp，結構與其他的audio_hw.c大同小異，差別在於open方法：

static int legacy_adev_open(const hw_module_t* module, const char* name,
                            hw_device_t** device)
{
    ......

    ladev->hwif = createAudioHardware();
    if (!ladev->hwif) {
        ret = -EIO;
        goto err_create_audio_hw;
    }

    ......
}

看到那個熟悉的createAudioHardware()沒有？這是以前我提到的Vendor Specific Audio接口，然後新的接口再調用ladev->hwif的函數就是了。

因此老一套的alsa-lib、alsa-utils和alsa_sound也可以照搬過來，這裏的文件被編譯成靜態庫的，因此你需要修改alsa_sound裏面的Android.mk文件，鏈接這個靜態庫。還有alsa_sound的命名空間原來是“android”，現在需要改成“android_audio_legacy”。

四、a2dp Audio HAL的實現

4.0的a2dp audio hal放到bluez裏實現了，我找了好一會才找到：
external/Bluetooth/bluez/audio/android_audio_hw.c
大致與上面提到的audio_hw.c類似，因爲都是基於audio.h定義的接口來實現的。
如果需要編譯這個庫，須在BoardConfig.mk裏定義：
BOARD_HAVE_BLUETOOTH := true

開始還提到現在支持3種audio設備了，分別是primary、a2dp和usb。目前剩下usb audio hal我沒有找到，不知是否需要自己去實現？其實alsa-driver都支持大部分的usb-audio設備了，因此上層也可調用tinyalsa的接口，就像samsung tuna的audio_hw.c那樣。

五、音質改進？？？

可使用audio echo cancel和更好的resampler（SRC）？？？

--to be continued…