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

[Margarita Olaya]

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?

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

or it would be better to add new functions to create the UCM profiles?
Do you see any issue by only having two fields of the profile?

Regards,
Margarita

>> 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
>
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>