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
