[alsa-devel] [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()

[Takashi Iwai]

On Thu, 04 Apr 2019 12:18:33 +0200,
Timo Wischer wrote:
> 
> >>> In principle, the PCM ops is supposed to be safe for operating a
> >>> certain stuff.  If a state change may happen during the operation,
> >>> this should be called inside PCM stream lock.  So the design of the
> >>> new callback itself is fragile.
> >>>
> >>> then, it comes to a point to re-setup the timer at the link change.
> >>> The idea is interesting, but it's a wrong usage of PCM link feature,
> >>> to be honest.
> >>>
> >>> That said, I find the changes up to patch 8 are acceptable (with some
> >>> fixes expected), but the link feature isn't.
> 
> Hi Takashi,
> 
> could you provide your feedback to the other patches?

The patch 4 must be superfluous, at least.  The trigger callback is
called within the stream lock, so you really don't need to save
flags.

The patch 8 needs more consideration.  I'm not fond of the current way
to select the timer source.  For example, the ALSA timer source isn't
necessarily bound with cards.  It can be a hrtimer, or system timer
backend ALSA global timer, too.  This can't be chosen in the suggested
way.  Also, the use of tasklet is superfluous.  The timer instance can
be called via tasklet by itself if you pass the flag properly.

> I would like to apply these 8 patches first and then I would provide
> an addition patch to get an ALSA control to select the sound timer.
> I fear this would be the best idea (replacing the snd_pcm_link()
> feature) because the ALSA control is accessible by any audio user and
> we could use ALSA hooks to select the right sound timer when opening
> an ALSA device.

It depends on the implementation.  Usually you "lock" such a control
that is bound with a PCM stream at opening, so that other process
won't be able to change.  Such a trick is used for the dynamic routing
via control element for emu10k1, for example.

But, whether it's really usable, I don't know.  Let's see.


thanks,

Takashi