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