sw_params for a direct-ed(dmix) hw pcm

[Jaroslav Kysela]

Dne 27. 03. 20 v 9:08 Takashi Iwai napsal(a):
> On Thu, 26 Mar 2020 21:04:15 +0100,
> sylvain.bertrand at gmail.com 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.

Yes, it's a bug which should be fixed in dmix instead to use a workaround in 
the app. The easiest way is to return an error in set sw_params, but it may 
cause problems for the app which assumes that this timestamp mode can be set 
freely. Perhaps, we can add a timestamp translation layer (not easy, I know).

						Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.