Dne 27. 03. 20 v 9:08 Takashi Iwai napsal(a):
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.
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@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
