ALSA Programming Detail Analysis---Linux sound tuning __arduino

[Loong]: Previously written based on ALSA WAV playback recording program, see Http://blog.csdn.net/sepnic/archive/2011/01/14/6140824.aspx. Now I want to do a good job of ALSA programming ideas, but Google a bit, found that there have been similar work to do the same, it reproduced it, and add some of my doubts and supplements (will continue to add, the original text many important ALSA parameters are not mentioned).

Original: http://blogold.chinaunix.net/u3/112227/showart_2251390.html

I. Programming Details

Following the procedure above, there are many details that we can control, and here we just point out what the application needs to be concerned about:

1.1 Equipment Level

At Alsa Drive this layer, so far, 4 layers of equipment are abstracted:

One is hw:0,0;

Second, the plughw:0,0;

Three is default:0;

Four is default.

As for one is clear, two and two can do data conversion to support a dynamic range, such as you want to play 7000hz things, then you can use two and more than two. And you use 7000hz as a parameter, to set one, you will be an error. Three and four, support software mix. I think default:0 represents a mix of software for the first sound card, and default represents a mix of software for the entire system.

Here two points are presented:

1.1.1 Generally in order to make all the programs can pronounce, in order to use more default strategy, we choose three and four, so less control, more convenient.

1.1.2 to different levels of the device, the same function, the result may not be the same. For example, to set the period and buffer size in the hardware parameters, this is the hardware settings, so the default and default:0 devices are not set.

If the direct operation of hw:0,0, then Snd_pcm_writei can only write 8 multiples of the frame, such as 16, 24, or else there will be left a point does not write and return, and default, you can want to write how much, we do not have to care about the specific strategy.

[Loong]: It used to be default, and I didn't really notice the difference between the devices.

1.2 Hardware Parameters

Description: This is called hardware Parameters because ALSA is a layer API that allows users to set the audio interface and Alsa-core two levels. The setting for Alsa-core is called Software Parameters, and the audio interface setting is called Hardware Parameters. (Of course to set the hardware parameters, it is definitely through the ALSA drive to complete, but which parameters are the guidance of hardware, which is to guide the Alsa-core, separate set)

1.2.1 Sample rate: Sample rate

1.2.2 Sample format: Using format

1.2.3 Number of channels: channels

1.2.4 Data Access and layout:

To put it simply, in a period, the data is in accordance with Channel1 row Channel2, or a frame of the row (frame in alsa refers to a sampling time, Two channel data is put together as a frame). The default is the second type.

1.2.5 Interrupt interval:

Interrupt interval, is depend on periods decision, have function to set periods, that is to say this hardware buffer in a traversal, how many times to interrupt, to notify Alsa-driver to write or read data. For example, buffer is 8,192 frame large, and period set to 4 frame large, then such as playback, then whenever there are 4 frame large hardware buffer space vacated, will be interrupted, notify the kernel (ALSA driver) to write such as data. This is the key to impact real-time effects. Generally do not need to adjust.

1.2.6 Buffer Size:

Hardware buffer size, if the ALSA system mainly rely on this to do the buffer, then this size will affect the buffering effect, but generally do not adjust.

[Loong]: missing parameters such as buffer time, peroid time, peroid size, and so on, these parameters are generally set.

1.3 Software Parameters

1.3.1 Snd_pcm_sw_params_set_avail_min (Playback_handle, Sw_params, 4096)

This is only used in Interrupt-driven mode. This mode is ALSA drive layer, not hardware interrupt. It means that when the user uses snd_pcm_wait (), the actual encapsulation is the system's poll call, which means that the user is waiting, so what is waiting for. For playback, is waiting for the following sound card hardware buffer has a certain amount of space, you can put new data, for the record, is waiting for the following sound card newly collected data reached a certain number. This a certain number, is to use Snd_pcm_sw_params_set_avail_min to set, Unit is frame. The actual operation, not read the driver code, is not very clear, may be the ALSA driver according to the user set this parameter, to set hardware parameters inside of the period, it may not change the hardware period, each hardware interruption or copy to their own space, Then the data accumulates to a certain number of interrupt applications to make it come out of wait (). I don't know, and I don't have to delve into it.

The use of this pattern requires the user to write or read a certain amount of data after snd_pcm_wait (), calling a normal Wirtei or Readi function. If the user does not use Interrupt-driven mode, then this function is not required.

[Loong]: What is the Interrupt-driven mode.

1.3.2 Snd_pcm_sw_params_set_start_threshold (Playback_handle, Sw_params, 0U)

This function instructs when to turn on the Ad/da of audio interface, which is when to start the sound card.

For playback, suppose that the third parameter is set to 320, that is, when the user invokes Writei, the written data will temporarily exist in the ALSA drive space, and when the amount of data reaches 320 frames, the ALSA driver begins to write the data to hardware buffer, and start the DA transformation. For a record, when the user invokes Readi, the amount of data reaches 320 frames, the ALSA driver starts the ad transformation and captures the data. I generally set it to 0, I did not try not 0, if it is 0, I think the first Writei and Readi must be enough to do, otherwise the device will not start.

This is required for real-time effects, set the third parameter to 0, and ensure that the sound card starts immediately.

1.4 What to do about Xruns

Xrun refers to the sound card period, which triggers an interrupt that tells the ALSA driver to fill in the data, or read the data, but the problem is that ALSA read and write operations must be invoked by the user Writei and Readi to occur, it does not cache data. If the upper layer does not have user calls Writei and Readi, then will produce overrun (recording, the data is full, has not been ALSA driver read away) and underrun (need data to play, ALSA Drive but not write data), collectively known as Xrun.

This thing, need to use some functions to set, such as Snd_pcm_sw_params_set_silence_threshold (), is for playback, is set up when the case of XXX, with silence to write hardware Buffer As for the xxx case, and write how many silence, I am not very clear, and, for example, xrun to what circumstances, can stop this device and so on function. In general, the default Xrun processing strategy is driven by ALSA.

But for Xrun, it's best to write this:

while ((Pcmreturn = Snd_pcm_writei (pcm_handle, data, frames)) < 0) {

Snd_pcm_prepare (Pcm_handle);

fprintf (stderr, "<<<<<<<<<<<<<<< Buffer underrun >>>>> >>>>>>>>>>/n ");

}

That is, if this read/write distance last read/write, time may be too long, so this time to read/write, device has been xrun, without knowing ALSA driver to xrun default policy, it is best to invoke Snd_pcm_prepare () to prepare the device, And then start the next read and write.

1.5 transfer Chunk size

This should not be used, I did not find the document useful in this.

[Loong]: This is actually very important, if Snd_pcm_writei/snd_pcm_readi not write chunk size data every time, then the playback/recording is not the sound you expect. See more: Http://alsa-project.org/main/index.php/FramesPeriods

Configure Volume
# cd/home/work/alsa-utils-1.0.4
# Alsamixer
(At this point, the graphical interface, you can select and modify the volume by the key, through the M key to determine whether to mute)
# Alsactl Store
(Save volume configuration)
To set the system to load automatically when it starts:
The first method (simplest, to the system to join the Alsasound service, using the script of the ALSA itself to control, first recommended):
Perform:
Chkconfig--add Alsasound
Then reboot.
The second method (also very simple):
Edit/etc/rc.d/rc.local
Add this line:
Alsactl Restore
The long-awaited wonderful music finally came into being.