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