[RFC] Alsa UCM integration.

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

 



On Tue, 2011-03-01 at 15:20 +0000, Liam Girdwood wrote:
> On Mon, 2011-02-28 at 22:34 +0200, Tanu Kaskinen wrote:
> > What if one card has two playback devices - one for handsfree and one
> > for a headset - and I want to play a ringtone to both simultaneously?
> > 
> > What if one card has two playback devices - one for handset and one for
> > TV-out - and I want to play music to the TV while a call is ongoing, and
> > the call audio to the handset?
> > 
> > I'm not saying that this kind of hardware exists, or that anyone
> > actually wants to play music while having a call, but it would be nice
> > if a solution would be found that would support also these cases.
> > 
> > Hmm, I found now use-case.h via the link that you gave. That, together
> > with your explanations, is making this more clear. Apparently those
> > cases that I mentioned are supported by UCM via modifiers.
> > 
> > So, if I've understood correctly, UCM dictates that there is always
> > exactly one verb ("main stream") and exactly one device ("main device")
> > selected per card. Additional streams and devices can be used by
> > activating any number of modifiers.
> > 
> 
> UCM supports between 0..n active devices per verb. e.g. it is possible
> to enable both the headphone device and speaker device at the same time.

Right, I missed this. But these multiple devices must share the PCM
device, because there can be only one PCM device associated with a verb.

> > For example, if I wanted to play a ringtone to both the handsfree
> > speaker and to a headset, I could select verb "ringtone" and device
> > "speaker", and then I'd activate modifier "headset-ringtone", after
> > which I could open the headset device in addition to the speaker device.
> > In pulseaudio this would map to two sinks, and I'd use module-combine to
> > play the ringtone to both.
> > 
> > For another example, if I wanted to hear to music from the TV while
> > talking to the phone, I could select the "Voice Call" verb and the
> > "Handset" device, and then I'd activate modifier "tv-music", after which
> > I could open the TV-out device in addition to the handset device. Or
> > since I probably was listening to the music before the call started,
> > maybe I'd continue with the "HiFi"+"TV-out" combination and use a
> > modifier for the call audio.
> > 
> > My proposal is that profiles are generated for each available verb
> > +device pair. I think the concept of a profile is going to need to be
> > altered in some way to accommodate modifiers, because activating a
> > modifier can enable a new PCM device (not always, though). A new PCM
> > device means a new sink or source, but creating such sink or source
> > needs to be possible without tearing down and recreating other sinks and
> > sources of the profile, and that's not possible with current profiles.
> > 
> > I propose that profiles stay as they are, with the difference that each
> > sink and source of the profile can be enabled and disabled
> > independently. The configuration defines which sinks and sources are
> > activated by default. module-card-restore would remember user choices,
> > though, so the defaults would be relevant only when the user hasn't done
> > any changes, or when module-card-restore isn't used. (I don't think we
> > actually need to have any UI for enabling and disabling the devices in a
> > profile, at least initially, so for non-UCM configurations there
> > wouldn't need to be any observable changes in behavior.)
> > 
> > So, the verb+device pair would define the default sink and/or source
> > that are always created when the profile is activated, and modifiers
> > that have different PCM device than the device of the main use case
> > would create additional devices to the profile. Modifiers that have the
> > same PCM device as the main use case would add ports to the main use
> > case sink and/or source. And if the main use case uses for example pcm0
> > and two modifiers use pcm2, then the two modifiers are exposed as ports
> > on the sink of pcm2.
> 
> If we have verb+device pairs, how would we enable the Music verb and
> play to more than one device at the same time ?

With modifiers that enable more devices. But yeah, since UCM supports
defining multiple devices per verb as long as they use the same PCM
device, it would be good if Pulseaudio would support this kind of
configuration too. So, I hereby change my proposal: there would be one
profile per verb, not per verb+device. This is then the same approach
that Margarita started with :) If a verb has multiple devices defined
for it, ports would be generated for the sink/source for each possible
combination of those devices.

Otherwise my proposal stays the same: modifiers are modeled using
mappings or ports, depending on whether the modifier PCM device is
different or the same that is already associated with some already
existing mapping in the profile. Profiles will have to be changed so
that mappings can be activated independently, without interrupting
streams going to already activated mappings.

-- 
Tanu




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux