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

[Tanu Kaskinen]

On Wed, 2011-03-02 at 20:52 -0600, Margarita Olaya wrote:
> On Tue, Mar 1, 2011 at 9:20 AM, Liam Girdwood <lrg at slimlogic.co.uk> wrote:
> > 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.)
> >>
> 
> The list of profiles and mappings are populated using the
> pa_profile_set_new @pa__init, after the list is built the profiles are
> probed but if ucm is present this function can be skipped.
> 
> In order to create the profiles I could modify pa_profile_set_new to
> pass the flag "is_ucm" then I can use the UCM data to fill the
> structure pa_alsa_profile so:
> pa_alsa_profile->name = verb_name;
> pa_alsa_profile->supported = 1;
> 
> But what would be used as input_mapping_names and/or output_mapping_names?

The same names that are stored in pa_alsa_mapping->name. The mapping
name could be the PCM device name, or something derived from the fact
that one mapping is the main mapping of a verb and others are created by
modifiers. I would go with the PCM device name, because if some mapping
is used by multiple modifiers, the naming logic probably will get hairy
and/or the names become ugly if you use the main mapping / modifier
mapping logic.

> Now for sinks and sources, using the UCM:
> pa_alsa_mapping->sink->name = PlaybackPCM
> pa_alsa_mapping->source->name = CapturePCM

You shouldn't need to care about the sink and source names. The sink and
source fields are NULL at the time you generate the profiles - they are
set in module-alsa-card.c when a profile is activated. The sink and
source names are created by alsa-sink.c, so you don't need to care about
those.

> or it would be better to add new functions to create the UCM profiles?

I don't know the answer to this. I would guess that you can reuse quite
a lot of the functionality in alsa-mixer.c, so I would start by just
replacing the parts where configuration files are read with code that
reads the UCM information.

> Do you see any issue by only having two fields of the profile?

What do you mean? To me it looks like you should be able to set any
field of pa_alsa_profile, except description. Note that if you want to
populate pa_alsa_profile->input_mappings and ->output_mappings yourself,
input_mapping_names and output_mapping_names must be NULL. And vice
versa: you can also let profile_verify() to populate input_mappings and
output_mappings based on input_mapping_names and output_mapping_names,
in which case input_mappings and output_mappings must be NULL at the
time you call profile_verify().

-- 
Tanu