Forward

This Blog is stop. 

please to www.thinksrc.com for update.

这个博客停止更新了，请转移到www.thinksrc.com上查看更多的更新。

android的域名解析

android的域名解析

android 中的域名解析库， 一般来说叫（libresolve）是netbsd中抓取出来的，在应用程序的层次上， 调用gethostbyname， 而gethostbyname中就是调用了resolve库里面的东西，
里面主要用一个 _res的全局变量，

struct __res_state _res;

由res_send, res_init来改变这个值。 在netbsd的原来实现中， 是通过查看/etc/resolve.conf来得到这个DNS服务器的。

然后通过给这些dns服务器发UDP包来获取这个域名的地址。

后来这个库的发现上做了一些感动， 通过

struct __res_state *res_state(void);
#define _res (*(res_state())

来把这个全局变量替换成一个函数， 通过这个函数来返回这个变量， 这样可以做到线程安全。

android主要做了以下修改


他没有用_res把这个变量转换成函数res_get_state()， 这个函数会去监视一个prop(属性）：net.changed， 这个prop的值是最后改变了值的dns服务器的地址，如果这个值改变了， 他就会去重新刷新一下他的dns服务器的缓存， 而且，android没有使用/etc/resolve.conf， 而是去动态的获取一个叫做 net.dnsN 的prop， （N是DNS服务器地址的序号）， 通过这个来取得dns服务器的地址。

这就是为什么很多做android一直的人在gprs.ppp拨通了以后可以Ping到ip， 却不能解析域名的原因。

Android Audio System (1)

This post is talk about Android Audio system, and it's will be use audio recording as example, because I debug audio a recording bug these days, and I found there very few people talking about sound recording, I think I should do it.

This topic have 2 part: 1. Audio Abstract Layer; 2. Hardware Layer.

Let start the part 1:

I just assume that you can get a copy of android code, this topic use android 2.0 code. Maybe the arch will evolve in further.

* Related code:
[1]. droid/frameworks/bash/media/libmedia/AudioRecord*
[2]. droid/external/opencore/android/author/android_audio_input*
[3]. droid/hardware/frameworks/bash/libs/audioflinger/*

* Role:

** Control Server - AudioFlinger

(in System Server), For The Command such as create new AudioTrack,control hardware devices.

** Media Server - AudioRecord

(in Media server, for compress/decompress audio data, AudioRecord** Client Side - Application Using JNI & RPC to request media server to record/play sound.

* Communication between Role
AudioFlinger and mediaServer use shared memory (called Heap in android) to IPC, general idea was raw data in Heap, and use a semaphore to tell other data is ready or need more data.

Application and mediaServer use Binder RPC to communicate.

* Control Stream:

Application -> request recording -> Java -> jni -> mediaserver ->opencore ->opencore/android/author/android_audio_input*

** After Application RPC to media server

** MeidaServer Side: android_audio_input.cpp: audio_thread_func():

1.1 create and AudioRecord object pass AudioSource, SampleRate, Format, Channels, and buffer count, and flags, the class is defined in [1],

1.2 In AudioRecord.cpp:

This class then class the set member function, it will check the incoming prams, and get a AudioPolicyServericeClient from binder, compute the frame size in byte by formula:

frame Size(bytes) = channel Count * (format in byte(PCM 16 BIT is 2 bytes);

The recording buffer is set least 2 frame.

set() will call openRecord to PRC AudioFlinger->opencRecord()

** Into AudioFlinger
1.3 In AudioFlinger:

openRecord: The func will check the Premission first,and get a RecordThread in Recordthread Pool.

And create a new RecordTrack use the RecordTrack to create a RecordHandle return this Handler to caller. the cblk is a shared memory between AudioFlinger and it's user.

** Back MediaServer
1.4 Go Back to AudioRecord:

The openRecord very care about Cblk(control block of track).
back to set();

set() will new a ClientRecordThread, this thread will continue call the *this 's processAudioBuffer(), ProcessAudioBuffer first check whether the position reached marked position, when it reached, call the cblk() {the control block is very strange, can
get member and call the as function, very like the callable class in C++.

And then, it will call obtainBuffer(), this function will continue wait for the lock() of cblk, if the buffer was filled, audioFiliger will give up the lock, so here we can get the lock(), if can't get any data from device, in this function will print some log "obtainBuffer timed out (is the CPU pegged?) " message, normally when the log show up, you can't hear the voice
unless a real CPU pegged happened.

if get the buffer, the func will call the mCbf with event EVENT_MORE_DATA.

** AudioFlinger
1.5 back to AudioFlinger side:

After AudioFlinger Create a Track, it will start a Record thread, It will get into a loop, [Receive From Device] -> [Signal User] -> .. -> [Signal User]... When Receive from device, it will first lock the shared memory, read frames, and Unlock & signal users, in record mode, media server is the user.

This Figure show this process:

The archer in Figure show the sequence of state shift.

btw, you may noticed this post is have some like a org-mode , you are right, the original is written in org-mode.

重新开业

今天是一个特殊的日子，收到了亲爱的寄的川味香肠，开通了她和我的顶极域名，还去第一次玩了卡丁车。

所以决定今天把以前的老地盘重新开张，开始坚持写文章。

域名商是选择的 name.com， 要感谢云风的那篇文章。