Re: [PATCH] ALSA: pcm: reinvent the stream synchronization ID API

[Jaroslav Kysela <perex@xxxxxxxx>]

On 01. 05. 24 13:44, Takashi Sakamoto wrote:
> 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@xxxxxxxxxx>
> > Signed-off-by: Jaroslav Kysela <perex@xxxxxxxx>
> > ---
> >   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?

Sorry, but I really do not follow your intention. You're proposing to remove 
something which can be used in pipewire those days and I just proposed to use 
this sync_id scheme. If you propose different API, implement it as first and 
then remove the current proposed and implemented scheme (at least in the old 
drivers).

Removal and no replacement looks as no good solution. If you have a better API 
proposal, just go ahead.

					Jaroslav

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