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
