Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>
Cc: linux-sound@vger.kernel.org
Subject: Re: [PATCH] ALSA: pcm: reinvent the stream synchronization ID API
Date: Wed, 1 May 2024 20:44:24 +0900	[thread overview]
Message-ID: <20240501114424.GA100916@workstation.local> (raw)
In-Reply-To: <20240430161012.4011064-1-perex@perex.cz>

Hi,

On Tue, Apr 30, 2024 at 06:10:12PM +0200, Jaroslav Kysela wrote:
> Until the commit e11f0f90a626 ("ALSA: pcm: remove SNDRV_PCM_IOCTL1_INFO
> internal command"), there was a possibility to pass information
> about the synchronized streams to the user space. The mentioned
> commit removed blindly the appropriate code with an irrelevant comment.
> 
> The revert may be appropriate, but since this API was lost for several
> years without any complains, it's time to improve it. The hardware
> parameters may change the used stream clock source (e.g. USB hardware)
> so move this synchronization ID to hw_params as read-only field.
> 
> It seems that pipewire can benefit from this API (disable adaptive
> resampling for perfectly synchronized PCM streams) now.
> 
> Cc: Takashi Sakamoto <takaswie@kernel.org>
> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
> ---
>  include/sound/pcm.h         |  9 +++++++++
>  include/uapi/sound/asound.h |  8 +++++---
>  sound/core/pcm_lib.c        | 13 +++++++++++++
>  sound/core/pcm_native.c     |  6 ++++++
>  4 files changed, 33 insertions(+), 3 deletions(-)
 
Thanks for the reference to the commit to cancel exposing the data of
snd_pcm_sync_id union in runtime of PCM substream. I'm waiting for seven
years and it is time to delete it from the runtime structure and post the
series of changes for it[1].

I have no objection about the reinvention of some parts of UAPI to
provide any information between several PCM substreams. However, the reuse
of snd_pcm_sync_id union is a bit disapproving idea, since the data have
not been utilized effectively past 25 years or so. The re-introduction
would be a kind of 'history repeats'.

I think this is a good opportunity to invent for your purpose. Let us
work for more sophisticated way?

[1] https://lore.kernel.org/linux-sound/20240501113445.100817-1-o-takashi@sakamocchi.jp/


Regards

Takashi Sakamoto (not sound subsystem maintainer)

  reply	other threads:[~2024-05-01 11:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-30 16:10 [PATCH] ALSA: pcm: reinvent the stream synchronization ID API Jaroslav Kysela
2024-05-01 11:44 ` Takashi Sakamoto [this message]
2024-05-01 14:17   ` Jaroslav Kysela
2024-05-02  7:31 ` Takashi Iwai
2024-05-02  8:02   ` Jaroslav Kysela
2024-05-02 15:27     ` Takashi Iwai
2024-05-02 17:05       ` Jaroslav Kysela
2024-05-06  9:02 ` Amadeusz Sławiński
2024-05-06  9:12   ` Jaroslav Kysela

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=20240501114424.GA100916@workstation.local \
    --to=o-takashi@sakamocchi.jp \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox