[ALSA] Summary of ALSA

1. layer-3 structure of ALSA:
(1) audio interface:
The audio interface is the sound card, which contains the hardware buffer. Note that the hardware buffer is in the sound card, not the memory.
(2) COMPUTER:
This refers to the computer kernel and driver (the driver is provided by ALSA). When (1) Audio interfacce causes an interruption, the kernel will capture it and then hand over the processing to ALSA.
(3) Application:
This is the program you write. If you open a buffer, such as playback, it is handed to ALSA for play.

In the above framework, the process is as follows:
(1) playback:
Application opens a buffer, fills in the data, calls the Alsa interface, ALSA copies the buffer data to the drive space, and then delivers the data to the hardware buffer.
(2) record:
Similar to playback.

Ii. Details:
According to the above process, there are many details that we can control. Here we only point out that the application needs to care about:
1) device operated:
At the Alsa driver layer, layer-4 devices have been abstracted so far:
One is like HW:, the other is plughw:, the third is default: 0, and the fourth is default. The first is clear, and the second and second can be used for data conversion, to support a dynamic range. For example, if you want to play something Hz, you can use two or more. If you use Hz as the parameter value and set one, an error is returned. SDK sound mixing is supported. I think default: 0 indicates mixing the first sound card software, and default indicates mixing the entire system software. Because I don't have multiple sound cards, I cannot test the effect of 4.
Two points are proposed here:
(1) generally, in order to enable the pronunciation of all programs, we choose 3 and 4 to use more default policies, which reduces control and makes it more convenient.
(2) For devices of different levels, the same function may have different results.
For example, set the period and buffer size in the hardware parameters. This is the hardware setting. Therefore, the default and default: 0 devices cannot be set.
For example, if you directly operate on HW:, then snd_pcm_writei can only write a frame, such as a frame multiple of 8, such as. Otherwise, the system will return the frame with no write, but default, we can write as much as we want, and we do not need to care about the specific policies in it.

2) hardware parameters:
Note: The reason for calling hardware parameters is that the Alsa layer of APIS is relatively low. It allows users to set both the audio interface and the computer layer of the layer-3 structure mentioned above. The settings for the computer, that is, the Alsa driver, are called software parameters, and the settings for the audio interface (Sound Card) are called hardware parameters. (Of course, to set the hardware parameters, it must be done through the Alsa driver, but which parameters are for the hardware, which are for the Alsa driver, and are set separately)
(1) sample rate: Needless to say (these can also be set for the default device, as mentioned above)
(2) sample format: Needless to say
(3) number of channels: Needless to say
(4) Data Access and layout: Simply put, that is, within a period, the data is ranked by channel1 and then channel2, or a frame or a frame (frame in alsa refers to a frame during a sampling time, where the data of the two channels is put together ). The default value is the second type.
(5) interrupt interval: the interrupt interval is determined by the periods. A function is used to set the periods. That is to say, the number of times the hardware buffer is interrupted within a traversal, to notify the kernel (eventually to the Alsa driver) to write or read data. For example, if the buffer size is 8192 frames, and the period value is set to 4 frames, playback will interrupt every time the space of the hardware buffer with four frames is empty, notify the kernel (ALSA driver) to write data. This is the key to affecting real-time Results !!! However, my computer's default period is
The four frames are 16 bytes. If they are two channels, they are 16 bytes! Therefore, the default value is real-time !! Generally, real-time programs are enough !! Generally, no adjustment is required.
(6) buffer size: the size of the hardware buffer. If the entire ALSA system mainly uses this buffer, the buffer size will affect the buffer effect, but it is generally not adjusted.

3) software parameters:
(1) snd_pcm_sw_params_set_avail_min (playback_handle, sw_params, 4096)
This is only used in interrupt-driven mode. This mode is the Alsa driver layer, not the hardware interrupt. It means that when a user uses snd_pcm_wait (), the actual encapsulation is the system's poll call, indicating that the user is waiting. What is waiting? For playback, it is to wait for a certain amount of space in the hardware buffer of the Sound Card below, and you can put new data into it. For record, it is waiting for the new data collected by the following sound card to reach a certain number. This quantity is set using snd_pcm_sw_params_set_avail_min. The Unit is frame. The actual operation did not read the driver code. It is not very clear. It may be the Alsa driver root.
According to this parameter set by the user, you can set the period in the hardware parameters. It may also be that the period of the hardware is not changed, and each hardware interruption is still copied to your own space, then the data is accumulated to a certain amount and then interrupt the application to get it out of wait. I don't know, and I don't have to go into it.
To use this mode, you need to call a common wirtei or READI function after snd_pcm_wait () to write or read the "certain amount" of data. If you do not need the interrupt-driven mode, you do not need to use this function.
(2) snd_pcm_sw_params_set_start_threshold (playback_handle, sw_params, 0u)
This function instructs you when to enable the AD/DA of the audio interface, that is, when to enable the sound card.
For playback, assume that the third parameter is set to 320. That is to say, when the user calls writei, the data written will be temporarily stored in the Alsa drive space. When the data volume reaches 320 frames, the ALSA driver starts writing data to the hardware buffer and starts the DA conversion. For a record, when the user calls READI and the data volume reaches 320 frames, the Alsa driver starts the adconversion and captures the data. I usually set it to 0. I have never tried non-0. If it is not 0, I think the number of writei and READI must be sufficient for the first time; otherwise, the device will not start.
This is required for real-time effect. Set the third parameter to 0 to ensure that the sound card starts immediately.
(3) What to do about xruns:
Xrun indicates that the sound card period has triggered an interruption and tells the Alsa driver to fill in data or read data. However, the problem lies in the read and write operations of ALSA, it seems that the user must call writei and READI to cache data !!!, Therefore, if no user calls writei and READI on the upper layer, overrun (data is full during recording and not read by ALSA driver) and underrun (data is required for playing) will be generated, the ALSA driver does not write data), collectively referred to as xrun. What I understand is that not an interruption caused by a period is called xrun, but the whole hardware
When the buffer is full (when record is used) or empty (when play is used), xrun is used only when the buffer is interrupted. It doesn't matter. You can solve the problem without affecting programming :)
You need to use some functions to set this item. For example, snd_pcm_sw_params_set_silence_threshold () is for playback, that is, when XXX is set, silence is used to write data to the hardware buffer. I am not very clear about XXX and the number of silence writes. Also, for example, when xrun can stop this device and other functions. I have never tried the parameters involved in this (3). Generally, use the default xrun processing policy of the Alsa driver. After an error occurs, and it is not mentioned in the example.
However, for xrun, it is best to write it like this during programming:
While (pcmreturn = snd_pcm_writei (pcm_handle, Data, frames) <0 ){
Snd_pcm_prepare (pcm_handle );
Fprintf (stderr, "<buffer underrun >>>>>>>>>>>>>>>>> \ n ");
}
That is to say, if the read/write distance from the last read/write may be too long, the device has been xrun during this read/write operation, if you do not know the Default policy of the Alsa driver for xrun, it is best to call snd_pcm_prepare () to re-Prepare the device and then start the next read/write operation. I think, prepare () means that it may be a reset, but it is not clear. I think the driver of the API under windows must already have a set of processing policies for xrun, and the user has no interface to adjust it, I think its strategy, such as playback encountering underrun, is to fill in silence.
(4) Transfer Chunk Size:
This should not be used. I did not find any useful document.

Iii. Encoding mode:
Todo List: Add the following two points in the future:
(1) General read/write mode:
(2) interrupt-Driven Mode: I recommend this mode. I decided to use this mode.
I guess the reason is: it clearly tells the user that you need to read or write data! This allows the user to perform operations in real time: for example, if the user needs to write data from wait (), the user can decide to write real data or write data such as silence, or others. In general read/write mode, you do not know the requirements of lower layers in real time !! Therefore, it is equivalent that you can only judge whether there is xrun during your next read/write. You can't do anything else :) (and in the case of low real-time requirements, setting a large interrupt interval will make ALSA more efficient. In addition, this interrupt mode can be used in other systems using interrupt by simply modifying the code generation, as described by the author)
Todo?

4. Comparison with Windows APIs:
The buffer to be added for the Windows Audio interface belongs to the buffer of the application. In Windows, you can add the Buffer Queue to set the buffer. ALSA does not provide the interface for you to set the buffer at the application layer, the role of the buffer zone is to weaken or eliminate the impact of occasional fast or slow data streams or user operations. Therefore, ALSA must have a buffer zone, is the hardware buffer solely responsible for the buffer role in ALSA?
The writei and READI of ALSA can be changed
Todo: based on the actual programming results, check whether the effect is good.

V. Others:
The sound card programming is the process of guiding two devices. The following three points are described:
1. About mixer programming.
The sound card I learned has three main parts:
(1) Mixer
(2) DSP (AD, DA)
(3) buffer
They can be considered to be connected in the order above (1) (2) (3), while the buffer is indirectly connected to the computer bus.
The principle is as follows:
(1) Figure 1 shows a mixer. Figure 2 contains many mixers, but in fact, there are at least two mixers in the sound card, one is input mixer and the other is output mixer. input mixer receives external analog signals, and output mixer receives analog signals from the DSP. you need to know that the input and output of mixer are both analog signals. The input and output lines are also called sound mixing channels. I think this is the category of physical lines, this is why a program adjusts mixer to affect another program, because I think it adjusts physical parameters. the blue box in the figure is the place where the gain can be adjusted (in short,
I think they are hardware line parameters that can be adjusted by software)
(2) the output of one mixer can be used as the input of another mixer. For example, how to mix the CD with your own voice in such a scenario? I guess it is the digital signal of CD. First go to buffer, and input a source line of "output mixer" through DSP's D/A conversion, and then come out of destination line, instead of the speaker, the speaker is sent to the "input mixer" sound mixing channel, which is used to mix with the voice (from the microphone sound mixing channel of "input mixer") and then from the destination line, to the DSP for A/D conversion, and finally to the buffer.
The gain of each source line/destination line is adjusted, and route Souce line and destination line are implemented by mixer, which can also be adjusted by software.
As for the difference between the master and PCM on the system mixer panel, I think PCM is the analog signal output by DSP, that is, the source line gain of outmixer, the master may be the gain of the destination line of outmixer. in fact, it is difficult to figure out the specific sound card structure.
2. About DSP programming.
This is a default process in the above Mixer System. for users, the DSP device is used to complete basic playback and recording functions.
The user should, of course, guide the DSP to complete the work, just like guiding mxier. the guiding parameters provided by the user to the DSP are mainly the number of formats (frame/s and bits/frame) and channels. Otherwise, how can the DSP convert D/A or A/D.
3. About buffer.
There are three buffer involved: one is the buffer of the sound card, the other is the driver's kernel buffer, and the third is the user buffer specified by the user. data is copied one by one, or one by one. The copied signal is the interrupt signal of the sound card. when the buffer is full (read) or the buffer is empty (write), it will lead to interruption.