[pulseaudio-discuss] [RFC] Alsa UCM integration.

[Liam Girdwood]

On Mon, 2011-02-28 at 22:34 +0200, Tanu Kaskinen wrote:
> On Sun, 2011-02-27 at 22:53 -0600, Margarita Olaya wrote:
> > Hi Tanu,
> > 
> > On Sat, Feb 26, 2011 at 2:07 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > > On Fri, 2011-02-25 at 14:09 -0600, Margarita Olaya wrote:
> > >> > Make sense.
> > >> > But I am not sure the profiles as defined today in PulseAudio can work
> > >> > with modifiers. What we discussed yesterday is that when a profile is
> > >> > selected then you would set the UCM verb and know about all possible
> > >> > sinks. We would need additional logic to have profile modifiers, or we
> > >> > would need extra profiles to represent all possible combinations
> > >> > (speech, speech+tone, speech+music, etc).
> > >>
> > >> The initial idea is to use the UCM data to generate the card profiles,
> > >> then when the stream is open PA will use his method to select the
> > >> profile and set the verb. e.g when UCM is present: profile = verb.
> > >>
> > >> In the UCM module the data is store in a proplist per verb, the
> > >> proplist has the following info:
> > >>         PA_PROP_UCM_SINK ->      "PlaybackPCM"
> > >>         PA_PROP_UCM_SOURCE ->         "CapturePCM"
> > >>         PA_PROP_UCM_PLAYBACK_VOLUME ->  "PlaybackVolume"
> > >>         PA_PROP_UCM_PLAYBACK_SWITCH -> "PlaybackSwitch"
> > >>         PA_PROP_UCM_CAPTURE_VOLUME ->  "CaptureVolume"
> > >>         PA_PROP_UCM_CAPTURE_SWITCH -> "CaptureSwitch"
> > >>         PA_PROP_UCM_QOS -> "TQ"
> > >
> > > This means that there's only one sink and source per verb. That's
> > > probably ok, but if profile = verb, then this also means that there's
> > > only one sink and source per profile.
> > 
> > Yes, this correct.
> 
> 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.

> 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 ?

> 
> I hope you're able to follow that explanation. If not, feel free to ask
> questions :)
> 
> One thing that I'd like to clarify is that am I right that all the verb,
> device and modifier names can be chosen freely by the person who writes
> the UCM configuration? That is, the strings defined in use-case.h are
> just suggestions?
> 

Yes :) the strings defined in use-case.h are the most commonly used
examples and can be expanded to include other use case verb, devices and
modifiers.

Thanks !

Liam