pcm	PCM handle
	buffer	frames containing buffer
	size	frames to be read

Write interleaved frames to a PCM.

Parameters:

	pcm	PCM handle
	buffer	frames containing buffer
	size	frames to be written

Returns:

a positive number of frames actually written otherwise a negative error code

Return values:

	-EBADFD	PCM is not in the right state (SND_PCM_STATE_PREPARED orSND_PCM_STATE_RUNNING)
	-EPIPE	an underrun occurred
	-ESTRPIPE	a suspend event occurred (stream is suspended and waiting for an application recovery)

If the blocking behaviour is selected and it is running, then routine waits until all requested frames are played or put to the playback ring buffer. The returned number of frames can be less only if a signal or underrun occurred.

If the non-blocking behaviour is selected, then routine doesn’t wait at all.

一. 编程细节

按照上面的流程，其中有许多细节我们可以加以控制，这里仅仅指出应用程序需要关心的：

1.1 设备层次

在alsa驱动这一层，目前为止，抽象出了4层设备：

一是hw:0,0；

二是plughw:0,0；

三是default:0；

四是default。

至于一是清楚了，二和二以上可以做数据转换，以支持一个动态的范围，比如你要播放7000hz的东西，那么就可以用二和二以上的。而你用7000hz作为参数，去设置一，就会报错。三和四，支持软件混音。我觉得default:0表示对第一个声卡软件混音，default表示对整个系统软件混音。

这里提出两点：

1.1.1 一般为了让所有的程序都可以发音，为使用更多的默认策略，我们选用三和四，这样少一些控制权，多一些方便。

1.1.2 对不同的层次的设备，相同的函数，结果可能是不一样的。比如，设置Hardware Parameters里的period和buffer size，这个是对硬件的设置，所以，default和default:0这两种设备是不能设置的。

如果直接操作hw:0,0，那么snd_pcm_writei只能写如8的倍数的frame，比如16、24等，否则就会剩下一点不写入而退回，而 default，就可以想写多少就写多少，我们也不必要关心里面具体的策略。

【Loong：之前都是使用了default，还真没留意过这些设备有何区别。】

1.2 Hardware Parameters

说明：之所以叫做Hardware Parameters，是因为alsa这一层api是较为底层的，它允许用户对audio interface和alsa-core两层都做设置。其中对alsa-core设置，叫做Software Parameters，而对audio interface的设置叫做Hardware Parameters。（当然要设置hardware parameters，也肯定是通过alsa驱动来完成，只不过哪些参数是指导硬件的，哪些是指导alsa-core的，分开设置了）

1.2.1 Sample rate： 采样率

1.2.2 Sample format： 采用格式

1.2.3 Number of channels： 声道数

1.2.4 Data access and layout：

简单点说，在一个period以内，数据是按照channel1排完了再排channel2呢，还是一个frame一个frame的来排（frame在alsa里指的是一次采样时间内，两个channel的数据放一块儿就是一个frame）。默认是第二种。

1.2.5 Interrupt interval：

中断间隔，就是靠periods决定的，有函数来设置periods，也就是说这个hardware buffer在一次遍历之内，要中断多少次，来通知alsa-driver来写入或读走数据。比如buffer是8192个frame大，而 period设为4个frame大，那么比如playback，则每当有4个frame大的hardware buffer空间空出，就会中断，通知内核（alsa驱动）来写如数据。这个是影响实时效果的关键。一般不用调整。

1.2.6 Buffer size：

hardware buffer的大小，如果alsa整套体系主要靠这个来做缓冲，那么这个的大小，将影响缓冲效果，但是一般也不调整。

【Loong：缺少buffer time、peroid time、peroid size等参数说明，这些参数一般情况下都要设置的。】

1.3 Software Parameters

1.3.1 snd_pcm_sw_params_set_avail_min (playback_handle, sw_params, 4096)

这个仅用在interrupt-driven模式。这个模式是alsa驱动层的，不是硬件interrupt。它的意思是，用户使用 snd_pcm_wait()时，这个实际封装的是系统的poll调用，表示用户在等待，那么在等待什么呢？对于playback来讲，就是等待下面的声卡的hardware buffer里有一定数量的空间，可以放入新的数据了，对于record来讲，就是等待下面声卡新采集的数据达到了一定数量了。这个一定数量，就是用 snd_pcm_sw_params_set_avail_min来设置，单位是frame。实际运作，没读驱动代码，不是很清楚，可能是alsa驱动根据用户设的这个参数，来设置Hardware Parameters里面的period，也可能是不改变硬件的period，每次硬件中断还是copy到自己的空间，然后数据积累到一定数量再 interrupt应用程序，使之从wait()出来。我不知道，也不必深究。

这种模式的使用，需要用户在snd_pcm_wait()出来以后，调用一个平常的wirtei或readi函数，来写入或读取一定数量的数据。如果用户不用interrupt-driven模式，那么这个函数不必使用。

【Loong：什么是interrupt-driven模式？】

1.3.2 snd_pcm_sw_params_set_start_threshold (playback_handle, sw_params, 0U)

这个函数指导什么时候开启audio interface的AD/DA，就是什么时候启动声卡。

对于playback，假设第三个参数设为320,那么就是说，当用户调用writei，写入的数据，将暂时存在alsa驱动空间里，当这个数据量达到 320帧时，alsa驱动才开始将数据写入hardware buffer，并启动DA转换。对于record，当用户调用readi，这个数据量达到320帧时，alsa驱动才开始启动AD转换，捕捉数据。我一般把它设为0,我没试过非0,如果是非0, 我想第一次的writei和readi一定得够数量才行，否则设备不启动。

这个对实时效果是需要的，将第三个参数设置为0，保证声卡的立即启动。

1.4 what to do about xruns

xrun指的是，声卡period一到，引发一个中断，告诉alsa驱动，要填入数据，或读走数据，但是，问题在于alsa的读取和写入操作必须用户调用writei和readi才会发生的，它不会去缓存数据。如果上层没有用户调用writei和readi，那么就会产生 overrun（录制时，数据都满了，还没被alsa驱动读走）和underrun（需要数据来播放，alsa驱动却不写入数据），统称为xrun。

这个东西，需要用一些函数来设置，比如snd_pcm_sw_params_set_silence_threshold()，是针对playback 的，就是设置当xxx的情况下，就用silence来写入hardware buffer。至于xxx情况，以及写入多少silence，我都不是很清楚，还有，比如xrun到什么情况下，可以停止这个设备等等函数。一般情况下用alsa驱动的默认的xrun处理策略。

但是关于xrun，最好这样写：

while ((pcmreturn = snd_pcm_writei(pcm_handle, data, frames)) < 0) {

snd_pcm_prepare(pcm_handle);

fprintf(stderr, “<<<<<<<<<<<<<<< Buffer Underrun >>>>>>>>>>>>>>>/n”);

}

就是说，如果这次读/写距离上次读/写，时间可能过长，那么这次去读/写的时候，device已经xrun了，在不知道alsa驱动对xrun的默认策略的情况下，最好调用snd_pcm_prepare()来重新准备好设备，然后再开始下一次读写。

1.5 transfer chunk size

这个应该是用不上的，我没找到文档里有用这个的。

【Loong：这个其实是非常重要的，如果snd_pcm_writei/ snd_pcm_readi不是每次写入chunk size数据的话，那么放音/录音不是你所期望的声音。详细见：http://alsa-project.org/main/index.php/FramesPeriods】

二. 编程细节

TODO LIST：以后把下面两点补上：

2.1 一般读写模式

2.2 interrupt-driven

它非常清晰的告诉了用户，你需要读取数据或写入数据了。这样允许用户即时的作出操作：比如现在让用户从wait()出来，用户知道需要比如写入数据了，它可以决定写入真实的数据，或者写如silence，或者其他。而用一般读写模式，你不会即时知道下层的需求，所以相当于你只能在你下一次读/写的时候，判断有没有xrun，其他你什么都做不了。

TODO: 再好好想想这个模式，其实我不确定实际使用上有什么好？