Re: UCM ConflictingDevice/Priority concepts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux