All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: sylvain.bertrand@gmail.com
Cc: alsa-devel@alsa-project.org, Kai Vehmanen <kai.vehmanen@linux.intel.com>
Subject: Re: sw_params for a direct-ed(dmix) hw pcm
Date: Fri, 27 Mar 2020 09:08:46 +0100	[thread overview]
Message-ID: <s5hlfnmfcdt.wl-tiwai@suse.de> (raw)
In-Reply-To: <20200326200415.GA1321@freedom>

On Thu, 26 Mar 2020 21:04:15 +0100,
sylvain.bertrand@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.


Takashi

  reply	other threads:[~2020-03-27  8:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-21 15:53 monotonic raw setup seems buggy sylvain.bertrand
2020-03-25 17:44 ` sw_params for a direct-ed(dmix) hw pcm sylvain.bertrand
2020-03-26 12:02   ` Kai Vehmanen
2020-03-26 14:36     ` Jaroslav Kysela
2020-03-26 20:04       ` sylvain.bertrand
2020-03-27  8:08         ` Takashi Iwai [this message]
2020-03-27  9:40           ` Jaroslav Kysela
2020-03-28 18:26             ` sylvain.bertrand
2020-03-28 19:15               ` Pierre-Louis Bossart
2020-03-28 20:37                 ` sylvain.bertrand
2020-03-28 21:34                   ` Pierre-Louis Bossart
2020-03-28 22:20                     ` sylvain.bertrand
2020-03-29  7:43                       ` Takashi Iwai
2020-03-31 11:32                         ` Takashi Iwai
2020-04-01 15:25                           ` sylvain.bertrand
2020-04-01 15:59                             ` Takashi Iwai
2020-04-01 20:21                               ` sylvain.bertrand
2020-04-02 19:03                                 ` sylvain.bertrand
2020-04-06 13:49                                   ` sylvain.bertrand
2020-04-14 15:18                                     ` Takashi Iwai
2020-04-14 23:20                                       ` sylvain.bertrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hlfnmfcdt.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=sylvain.bertrand@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.