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

[Feng Wei]

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.
>
> Cheers,
> Arun
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



-- 
Wei.Feng (irc wei_feng)
Linaro Multimedia Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog