UCM ConflictingDevice/Priority concepts

[Pierre-Louis Bossart]

>>> Also, we need to consider this to have the whole picture:
>>>
>>> Tanu (the pulseaudio maintainer) has also good question how to ensure,
>>> that the stream can be re-used for the multiple devices. Actually, PA
>>> does not re-open PCM device when the PCM device name and parameters
>>> are similar for the switched devices. I also think that this is also
>>> missing in the UCM specification to resolve this requirement. Usually,
>>> the stream transfer mechanism is separate from the routing control.
>>> But I can assume, that we may have the hardware which will need extra
>>> setup for the streaming (not routing) when the devices are switched.
>>>
>>> I think that adding something like "PlaybackStream" to "PlaybackPCM"
>>> for the stream identification might be sufficient to cover those
>>> cases. So, keep "PlaybackPCM" usage and if "PlaybackStream" exists,
>>> use this value to determine the stream identification. Similar
>>> situation is for the capture direction, of course.
>>
>> I am not sure I understand the notion of stream and stream transfer. Is
>> there a pointer to this so that I could understand the problem statement?
> 
> Example:
> 
> Device1:
>    ... some enable sequence ...
>    PlaybackPCM "hw:0"
>    PlaybackStream "DAC1"
> 
> Device2:
>    ... another enable sequence ...
>    PlaybackPCM "hw:0"
>    PlaybackStream "DAC2"
> 
> In this case, PCM names for alsa-lib are same, but there's a different 
> setup to route signal to different DAC which cannot be executed without 
> the PCM re-open task (when the PCM "hw:0" is active).

I see, thanks for the explanations.

Indeed in the past we had similar routing issues that required 
re-configuration and possibly stopping the stream or changing clock 
settings/ownership.

However I would argue that the solution is more to define additional 
steps than add additional qualifiers in the enable/disable steps.

FWIW in the Android solutions from Intel, we had 5 steps for each 
routing change:
- mute old paths
- disable streaming on old paths
- configure new paths
- enable streaming on new paths
- unmute new paths

At each step we could describe what actions were necessary or if the 
step could be skipped. That allowed us to deal nicely with transitions, 
I don't think we encountered any case that these steps couldn't handle.