On Thu, 26 Mar 2020 21:04:15 +0100, sylvain.bertrand@xxxxxxxxx wrote: > > 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. The tstamp type handling in dmix is certainly buggy, yes. It should have been restricted with the slave PCM unless it's compatible. Takashi
