[alsa-devel] [PATCH v2 0/8] [PATCH 0/8] ALSA: pcm: code refactoring for snd_pcm_hw_refine()

Takashi Iwai tiwai at suse.de
Thu Jun 8 23:44:45 CEST 2017


On Thu, 08 Jun 2017 23:36:58 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> This patchset is revised version of my previous one.
> 
> [alsa-devel] [PATCH 0/8] ALSA: pcm: code refactoring for snd_pcm_hw_refine()
> http://mailman.alsa-project.org/pipermail/alsa-devel/2017-June/121443.html
> 
> Changes from v1:
>  - get rid of __may_unused keyword
>  - remove subtle changes
> 
> Here, I repeat a description on my former message.
> 
> In ALSA PCM interface, applications can get hardware capability as
> 'struct snd_pcm_hw_params' type of data returned by a call of ioctl(2)
> with SNDRV_PCM_IOCTL_HW_REFINE/SNDRV_PCM_IOCTL_HW_PARAMS' commands. In
> kernel land, the data is prepared in 'snd_pcm_hw_refine()' in
> 'sound/core/pcm_native.c'. This patchset is a code refactoring to this
> function.
> 
> When applications execute open(2) to any PCM character device, runtime
> of corresponding PCM substream is created in kernel land. Then, the
> runtime gets information to configure the parameter data. When
> applications execute ioctl(2) with the above commands, the given
> parameter data is actually changed according to the information.
> 
> The parameter data structure includes several types of information. 
> Major part of the parameter data is represented by two kinds of shape;
> mask ('struct snd_mask') and interval ('struct snd_interval'). 15
> types of data is pre-defined as 'SNDRV_PCM_HW_PARAM_XXX' macros with
> the two types.
> 
> The runtime has several constraints, which is a kind of information to
> configure the parameters. There're two types of constraints; independent
> and dependent. The independent constrain is for each of single parameters.
> On the other hand, the dependent constrain is for each of combination
> between parameters, thus has specific structure, 'snd_pcm_hw_rule'. This
> structure describes relationships between several parameters.
> 
> In 'sound/core/pcm_native.c', the above constraints and rules are
> applied to parameter data for userspace. This processing is done
> in 'snd_pcm_hw_refine()'. In this patchset, I attempt to clean up the
> processing so that developers easily understand it.
> 
> This is a kind of refactoring, thus behaviour of the processing is not
> changed. Tracepoints added in my previous patchset is helpful for your
> test to check it. I wrote an application as low level program and
> it shall satisfies your interests about the above mechanism[1].
> 
> [1] refine-pcm-params.c
> https://github.com/takaswie/alsa-ioctl-test/
> 
> Takashi Sakamoto (8):
>   ALSA: pcm: add a helper function to constrain mask-type parameters
>   ALSA: pcm: add a helper function to constrain interval-type parameters
>   ALSA: pcm: add a helper function to apply parameter rules
>   ALSA: pcm: use goto statement instead of while statement to reduce
>     indentation
>   ALSA: pcm: remove function local variable with alternative evaluation
>   ALSA: pcm: adaption of code formatting
>   ALSA: pcm: use helper functions to check whether parameters are
>     determined
>   ALSA: pcm: add comment about application of rule to PCM parameters
> 
>  sound/core/pcm_native.c | 241 +++++++++++++++++++++++++++++++++---------------
>  1 file changed, 169 insertions(+), 72 deletions(-)

Now looks better, and I merged all eight patches.
Thanks!


Takashi


More information about the Alsa-devel mailing list