| .. | .. |
|---|
| 34 | 34 | interaction between applications and ALSA PCM core. Once decided, runtime of |
|---|
| 35 | 35 | the PCM substream keeps the parameters. |
|---|
| 36 | 36 | |
|---|
| 37 | | -The parameters are described in :c:type:`struct snd_pcm_hw_params`. This |
|---|
| 37 | +The parameters are described in struct snd_pcm_hw_params. This |
|---|
| 38 | 38 | structure includes several types of parameters. Applications set preferable |
|---|
| 39 | 39 | value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE |
|---|
| 40 | 40 | or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available |
|---|
| 41 | 41 | set of parameters. The latter is used for an actual decision of the parameters. |
|---|
| 42 | 42 | |
|---|
| 43 | | -The :c:type:`struct snd_pcm_hw_params` structure has below members: |
|---|
| 43 | +The struct snd_pcm_hw_params structure has below members: |
|---|
| 44 | 44 | |
|---|
| 45 | 45 | ``flags`` |
|---|
| 46 | 46 | Configurable. ALSA PCM core and some drivers handle this flag to select |
|---|
| 47 | 47 | convenient parameters or change their behaviour. |
|---|
| 48 | 48 | ``masks`` |
|---|
| 49 | 49 | Configurable. This type of parameter is described in |
|---|
| 50 | | - :c:type:`struct snd_mask` and represent mask values. As of PCM protocol |
|---|
| 50 | + struct snd_mask and represent mask values. As of PCM protocol |
|---|
| 51 | 51 | v2.0.13, three types are defined. |
|---|
| 52 | 52 | |
|---|
| 53 | 53 | - SNDRV_PCM_HW_PARAM_ACCESS |
|---|
| .. | .. |
|---|
| 55 | 55 | - SNDRV_PCM_HW_PARAM_SUBFORMAT |
|---|
| 56 | 56 | ``intervals`` |
|---|
| 57 | 57 | Configurable. This type of parameter is described in |
|---|
| 58 | | - :c:type:`struct snd_interval` and represent values with a range. As of |
|---|
| 58 | + struct snd_interval and represent values with a range. As of |
|---|
| 59 | 59 | PCM protocol v2.0.13, twelve types are defined. |
|---|
| 60 | 60 | |
|---|
| 61 | 61 | - SNDRV_PCM_HW_PARAM_SAMPLE_BITS |
|---|
| .. | .. |
|---|
| 78 | 78 | are going to be changed. |
|---|
| 79 | 79 | ``cmask`` |
|---|
| 80 | 80 | Read-only. After returning from ioctl(2), buffer in user space for |
|---|
| 81 | | - :c:type:`struct snd_pcm_hw_params` includes result of each operation. |
|---|
| 81 | + struct snd_pcm_hw_params includes result of each operation. |
|---|
| 82 | 82 | This mask represents which mask/interval parameter is actually changed. |
|---|
| 83 | 83 | ``info`` |
|---|
| 84 | 84 | Read-only. This represents hardware/driver capabilities as bit flags |
|---|
| .. | .. |
|---|
| 110 | 110 | value to this parameter but some drivers intentionally set zero with |
|---|
| 111 | 111 | a care of hardware design or data transmission protocol. |
|---|
| 112 | 112 | |
|---|
| 113 | | -ALSA PCM core handles buffer of :c:type:`struct snd_pcm_hw_params` when |
|---|
| 113 | +ALSA PCM core handles buffer of struct snd_pcm_hw_params when |
|---|
| 114 | 114 | applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS. |
|---|
| 115 | 115 | Parameters in the buffer are changed according to |
|---|
| 116 | | -:c:type:`struct snd_pcm_hardware` and rules of constraints in the runtime. The |
|---|
| 116 | +struct snd_pcm_hardware and rules of constraints in the runtime. The |
|---|
| 117 | 117 | structure describes capabilities of handled hardware. The rules describes |
|---|
| 118 | 118 | dependencies on which a parameter is decided according to several parameters. |
|---|
| 119 | 119 | A rule has a callback function, and drivers can register arbitrary functions |
|---|
| .. | .. |
|---|
| 121 | 121 | runtime as a default. |
|---|
| 122 | 122 | |
|---|
| 123 | 123 | Each driver can join in the interaction as long as it prepared for two stuffs |
|---|
| 124 | | -in a callback of :c:type:`struct snd_pcm_ops.open`. |
|---|
| 124 | +in a callback of struct snd_pcm_ops.open. |
|---|
| 125 | 125 | |
|---|
| 126 | 126 | 1. In the callback, drivers are expected to change a member of |
|---|
| 127 | | - :c:type:`struct snd_pcm_hardware` type in the runtime, according to |
|---|
| 127 | + struct snd_pcm_hardware type in the runtime, according to |
|---|
| 128 | 128 | capacities of corresponding hardware. |
|---|
| 129 | 129 | 2. In the same callback, drivers are also expected to register additional rules |
|---|
| 130 | 130 | of constraints into the runtime when several parameters have dependencies |
|---|
| 131 | 131 | due to hardware design. |
|---|
| 132 | 132 | |
|---|
| 133 | 133 | The driver can refers to result of the interaction in a callback of |
|---|
| 134 | | -:c:type:`struct snd_pcm_ops.hw_params`, however it should not change the |
|---|
| 134 | +struct snd_pcm_ops.hw_params, however it should not change the |
|---|
| 135 | 135 | content. |
|---|
| 136 | 136 | |
|---|
| 137 | 137 | Tracepoints in this category are designed to trace changes of the |
|---|
| .. | .. |
|---|
| 163 | 163 | type, the fields represent hexadecimal dump of content of the parameter. For |
|---|
| 164 | 164 | parameters of interval type, the fields represent values of each member of |
|---|
| 165 | 165 | ``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in |
|---|
| 166 | | -:c:type:`struct snd_interval` in this order. |
|---|
| 166 | +struct snd_interval in this order. |
|---|
| 167 | 167 | |
|---|
| 168 | 168 | Tracepoints in drivers |
|---|
| 169 | 169 | ====================== |
|---|