[pulseaudio-discuss] [alsa-devel] Using UCM with PulseAudio

[Arun Raghavan]

On Mon, 2012-06-25 at 07:01 +0530, Arun Raghavan wrote:
> On Thu, 2012-06-21 at 16:30 +0800, Feng Wei wrote:
> > 2012/6/20 Arun Raghavan <arun.raghavan at 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.
> > Sounds fine to me. The only problem is can we always open the modifier
> > pcm when modifier is not enabled. If not, I prefer to create/destroy
> > the sink by events.
> 
> The alternative is to always add the sink and enable/disable the
> modifier in the I/O thread since we will get a message when a sink-input
> is added/removed. I'm just hacking this bit up, and will post patches if
> it all works out.
> 
> There is another question here -- whether the modifier sink should have
> any ports or not. If I understand this correctly, we could let the
> actual routing be handled by the "main" sink's port and have the
> modifier sinks not touch that at all by not having any ports. In the
> ideal world though, it would be nice to have the ability to mark ports
> as being "dependent" somehow, so that port changes on the main sink
> would reflect in all others. This would be particularly useful for sinks
> and sources that have correlated paths like they do in the OMAP4 case.

Seems things a bit more complicated. There's a PlaybackChannels field on
each UCM device -- and it is possible that this might be different
between devices? If so, then it would become necessary to expose the
devices as ports on the modifier's sink as well, to make sure these
things stay in sync. Or am I interpreting things as being more
complicated than they really are?

-- Arun