On Thu, Mar 26, 2020 at 03:36:23PM +0100, Jaroslav Kysela wrote:
I agree. Also, the snd_pcm_direct_sw_params() does nothing, because the sw_params are already cached in the pcm structure (see comment). It means that the dmix (direct) plugins operates with those cached values. Just set sw_params like for any other PCM handle. The dmix uses those values (if possible).
This is the "if possible" which would impacts the way how code should do setup right, but:
Let's take the case of a classic plugin "pipeline": pcm:plug->...->direct::dmix->hw
From the top plugin (usually plug) to the direct::plugin, the "sw_params" pcm
op is usually pcm_generic.c:snd_pcm_generic_sw_params which does recurse down. This recursion down will stop once pcm_direct.c:snd_pcm_direct_sw_params is reached, then will recurse up, without error.
But pcm.c:snd_pcm_sw_params will copy anyway the provided sw_params into each recursed back pcm if the "sw_params" pcm op return no error code, which is the case.
Then looking at pcm.c:snd_pcm_sw_params_current, I get those "wrong" sw_params, then I get no way to know something went wrong.
Why "wrong", because they may significantly differ from the bottom hw plugin sw_params which some fields are used to configure the kernel driver.
for instance, a fast_op status call will recurse down to pcm_dmix.c:snd_pcm_dmix_status, which will call the hw plugin fast op status function which will use _its_ tstamp_type field for the ioctl call, but will "override" the trigger_tstamp field computed with the "wrong" sw_params tstamp_type!
It happens that the monotonic_raw and monotonic clocks can have audio significant difference. Additionally, the other sw_params field might cause similar issues.
regards,