On Ju 7 2017 17:09, Takashi Iwai wrote:
The second field represents id of each rule applied to the runtime, and
the total number of rules added to the runtime. Basically, when the rule
is applied to the runtime, these events are probed, but lines with id 0
are exceptions. They're application of constraints to the runtime.
The third field is name of parameter in the runtime. The rest fields
depends on type of the parameter (mask/interval).
In ALSA PCM core, runtimes get 22 (or 21) rules as a default. In a below
sample, the 21st rule is added by driver (snd-soc-imx-ssi.ko). The rest is
added by snd-pcm.ko. In detail, please see 'snd_pcm_hw_constraints_init()'
and 'snd_pcm_hw_constraints_complete()' in 'sound/core/pcm_native.c'.
hw_interval_param: 0,0,0,0 019/023 PERIOD_TIME 0 0 [0 4294967295] 0 0 (166 4095875]
hw_interval_param: 0,0,0,0 020/023 BUFFER_TIME 0 0 [0 4294967295] 0 0 (333 4096000]
hw_interval_param: 0,0,0,0 021/023 PERIOD_SIZE 0 1 [16 32767] 0 1 [16 32766]
hw_interval_param: 0,0,0,0 022/023 BUFFER_BYTES 0 1 [128 65536] 0 1 [128 65536]
hw_interval_param: 0,0,0,0 023/023 RATE 0 0 [8000 96000] 0 0 [8000 96000]
hw_mask_param: 0,0,0,0 001/023 FORMAT 00000000000000000000001000000044 00000000000000000000001000000044
Could you add these explanations in Documentation? The cover letter
is gone at merging.
Hm. Could I postpone the task for my later work in this development
period? Text writing takes me a bit time, but I have patches for the
rest of my RFC and firewire stack.
It's fine if you can promise to submit the document patch in this
development cycle :)
I promise.
Regards
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
