Re: [alsa-devel] Using UCM with PulseAudio
On Thu, 2012-06-21 at 16:30 +0800, Feng Wei wrote:
2012/6/20 Arun Raghavan arun.raghavan@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.
-- Arun
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@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
participants (1)
-
Arun Raghavan