Re: Using UCM with PulseAudio

[Arun Raghavan <arun.raghavan@collabora.co.uk>]

Liam,
Thanks for clearing things up.

On Fri, 2012-06-15 at 18:08 +0100, Liam Girdwood wrote:
[...]
> > The first problem is mutual exclusivity of verbs. From what I can
> > understand, verbs are intended to be mutually exclusive -- if you have a
> > HiFi verb and a VoiceCall verb, only one may be used at a time. We have
> > mapped verbs to card profiles, which offer the same guarantee. However,
> > on Android (which is a fair example of the kind of audio policy we might
> > want), the HiFi verb PCMs maybe used while the VoiceCall PCMs are open.
> > This is done, for example, to play an end-of-call tone from the CPU
> > while the modem PCMs are still held open. Is there some way to do this
> > with UCM?
> > 
> 
> A verb is not tied to any specific PCM device here. It's intended to be
> the highest level of audio use case where it can configure any audio
> resource (including multiple cards) to enable the use case action.
> 
> So for OMAP4 we would have the HiFi verb for all use case where we are
> playing or capturing HiFi quality and the voice call verb where we are
> making a telephone voice call.
> 
> UCM provides the "modifier" to allow ad-hoc modifications to the audio
> use case like above where we want to play an end of call tone. In this
> case the verb is still VoiceCall, but PA would enable the "PlayTone"
> modifer to play the tone (UCM can also tell Pulseaudio the sink PCM and
> volume control for the tone data).

Just as an observation, I think the Android HAL just uses PCM 0 and not
the PCM 3, but in the PA case, I'll do it the way you describe since
that makes more sense.

> > The second problem is having separate PCMs for modifiers. In the OMAP4
> > profile, ringtone playback is exposed via a PlayTone modifier which
> > corresponds to a separate PCM from regular HiFi playback. In the UCM-PA
> > mapping we decided on, modifiers were implemented as device intended
> > roles on a sink, so that when a stream with that role came in, we could
> > enable the modifier, and disable it when such a stream ends. However,
> > this doesn't account for switching the PCM on which playback is
> > occurring. Should we be creating a separate sink for such modifiers
> > (with lower priority, so they're not routed to unless there's a stream
> > with the required role coming in)? Or should we be reopening the PCM for
> > this?
> 
> The intention for modifiers that use separate ALSA PCM sinks/sources
> from the verb is to keep the main stream on the verb PCM source/sink and
> the modifier stream will use the modifier PCM sink/source (this can be
> the same PCM for some hardware).
> 
> e.g. MP3 will be played to pcm 0 sink and ringtone to pcm 1 sink. The HW
> will then mix both streams before they are rendered.

Okay, so what this means is that we need to extend the current UCM work
to create a second, lower priority sink for each modifier that has a
distinct PlaybackPCM, and let the role-based routing pick that in cases
where it makes sense. It's good that this doesn't change how we've
mapped existing concepts -- just adds to it.

Cheers,
Arun