> 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"
plus the list of devices e.g headphone, headset and modifiers e.g
"play tone", "play music", etc.
Also, each profile has some on the following fields:
[Mapping id] e.g analog-mono
device-strings = hw:%f e.g hw:0 where %f is the card identifier
channel-map = e.g mono defined in src/pulse/channelmap.c
paths input/ouput =
priority
direction = in some cases it doesn't have the channel-map it only has
the direction
The profiles are probed and initialized in module-alsa-card @pa__init,
when ucm is present instead of taking the data from default.conf and
probe everything, when no rule is defined, the ucm data comes to
scene. Now, I would like to get some suggestion on how to map the
data, at least I can see that device-strings correspond PlaybackPCM or
CapturePCM.
Thanks & Regards,
Margarita
