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

[Liam Girdwood]

Sorry I couldn't make the meeting yesterday.

On Thu, 2011-02-24 at 23:34 -0600, Margarita Olaya wrote:
> Pierre,
> 
> On Thu, Feb 24, 2011 at 2:20 PM, pl bossart <bossart.nospam at gmail.com> wrote:
> >> The initial version of the UCM module is available at the following link:
> >> http://git.slimlogic.co.uk/cgi-bin/cgit.cgi/pulseaudio.git/log/?h=9.20-ucm_module
> >>
> >> I'm still working in the module, It is work in progress to verify the
> >> current verb when the stream is closed, also it is needed to add more
> >> code to work with the profiles and the use cases. Sink, source and
> >> device data could be taken from the proplist of the verb, and this is
> >> pending too.
> >
> > Hi Margarita,
> > I looked at your patches and have the following comments:
> 
> Thanks for the review and feedback on the meeting.
> 
> > - any reason why your version of PulseAudio is 1.3 years old. The
> > previous patches on your branch are from 2009-11-18, quite a while
> > ago. It'll make upstreaming difficult.
> 
> Well, I had some troubles at the begging so I started  by taking an
> stable rls but for sure I'll move soon the code to latest commit
> before upstream it.
> 
> > - you now have a separate module-alsa-ucm module, but it's called with
> > a device name as a parameter. So if I have one USB headphone and one
> > USB mic, this module will be called twice. It's not clear to me then
> > how the virtual device would be handled, and how this is different
> > from inserting all the code in module-alsa-card as you did it in your
> > previous version?
> 
> the idea was to have at least one card working, so yes this is pretty
> much the same approach than the code in module-alsa-card. Do you have
> any idea on how to manage virtual cards? I'm not clear on they way
> that ALSA manages virtual cards.
> 
> > - can you explain why you set the verb using the hook
> > PA_CORE_HOOK_SINK_INPUT_NEW, with priority PA_HOOK_EARLY+15. There are
> > other audio-policy related modules that may use different hooks, such
> > as PA_CORE_HOOK_SINK_INPUT_PUT. I would think you want to set the verb
> > at the UCM level after all this logic has made decisions, at the last
> > possible moment before data start flowing.
> 
> The initial approach was a bit different but after the IRC discussion
> I agree to use a different  hook so verb will be set after all the
> analysis with profiles has been done but it is needed first to map a
> profile with a verb instead of the current approach with roles.
> 
> > - how do we make use of modifiers?
> I have not really thought about this.
> 

Modifiers can be used in the following situations:-

1) Music is being played. Pulseaudio has configured the Music use case
verb via UCM. The system wants to play a tone, this could be a beep or
even a ring tone for an incoming call. Pulseaudio would then check for a
UCM "play tone" modifier for the current verb and then enable the
modifier if it exists. This "play tone" modifier would setup the
hardware to play both Music (i.e the verb) and additionally tones (the
modifier). The modifier may use a different ALSA pcm and hardware volume
controls to that of the main verb.

If no "play tone" modifier exists then Pulsewould mix the tone into the
music being played in software as it does atm.

2) Phone call is in progress. Pulseaudio has enabled the phone call UCM
verb. The user wants to play music on the phone call. The modifier would
be "Music" so Pulseaudio will check that a modifier exist for this when
the phone call verb is active and enable this modifier.

If no music modifier is available in the phone call verb configuration
then pulseaudio would mix the music and voice in software.

Liam