On Fri, 2012-06-15 at 08:23 +0530, Arun Raghavan wrote: > Hello, > I've been working on porting PulseAudio to Android on the OMAP4-based > Galaxy Nexus, and have recently looking at the policy-bits. The basic > porting has been greatly simplified with Wei Feng's work to renew > PulseAudio UCM integration and Liam's help with fixing up some of the > UCM config for the Galaxy Nexus. I am, however, facing some trouble > mapping how the hardware is used to how UCM presents it (or, perhaps, > the UCM-PA mapping does). > > Some simplified background: the devices of interest on the OMAP4 SoC are > the main hifi PCM which can be routed to various outputs, the modem PCM > which is not used for actual output but to enable use of the modem > during calls, and the tones PCM which is intended to be used for playing > ringtones, aiui. You understanding is correct :) > > 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). > 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. > > Finally, a question also related to modifiers -- is it expected that > there will never be a case where a stream that requires no modifier is > being played while a stream that does require a modifier also exists? If > not, what kind of policy should we have for enabling the modifier or > not? Some verbs will not specify modifiers. In this case we should mix any tones etc within the Pulseaudio stream and render on the main sink/source. It's intended that we will try and enable a modifier for a verb (if the modifier exists) when a new PA client stream is opened and it's type can be matched to a modifier. Otherwise I would just mix the streams in PA and render to the current sink. Regards Liam > > Cheers, > Arun >
