On Mon, 2011-02-28 at 22:34 +0200, Tanu Kaskinen wrote: > On Sun, 2011-02-27 at 22:53 -0600, Margarita Olaya wrote: > > Hi Tanu, > > > > On Sat, Feb 26, 2011 at 2:07 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: > > > On Fri, 2011-02-25 at 14:09 -0600, Margarita Olaya wrote: > > >> > Make sense. > > >> > But I am not sure the profiles as defined today in PulseAudio can work > > >> > with modifiers. What we discussed yesterday is that when a profile is > > >> > selected then you would set the UCM verb and know about all possible > > >> > sinks. We would need additional logic to have profile modifiers, or we > > >> > would need extra profiles to represent all possible combinations > > >> > (speech, speech+tone, speech+music, etc). > > >> > > >> The initial idea is to use the UCM data to generate the card profiles, > > >> then when the stream is open PA will use his method to select the > > >> profile and set the verb. e.g when UCM is present: profile = verb. > > >> > > >> In the UCM module the data is store in a proplist per verb, the > > >> proplist has the following info: > > >> PA_PROP_UCM_SINK -> "PlaybackPCM" > > >> PA_PROP_UCM_SOURCE -> "CapturePCM" > > >> PA_PROP_UCM_PLAYBACK_VOLUME -> "PlaybackVolume" > > >> PA_PROP_UCM_PLAYBACK_SWITCH -> "PlaybackSwitch" > > >> PA_PROP_UCM_CAPTURE_VOLUME -> "CaptureVolume" > > >> PA_PROP_UCM_CAPTURE_SWITCH -> "CaptureSwitch" > > >> PA_PROP_UCM_QOS -> "TQ" > > > > > > This means that there's only one sink and source per verb. That's > > > probably ok, but if profile = verb, then this also means that there's > > > only one sink and source per profile. > > > > Yes, this correct. > > What if one card has two playback devices - one for handsfree and one > for a headset - and I want to play a ringtone to both simultaneously? > > What if one card has two playback devices - one for handset and one for > TV-out - and I want to play music to the TV while a call is ongoing, and > the call audio to the handset? > > I'm not saying that this kind of hardware exists, or that anyone > actually wants to play music while having a call, but it would be nice > if a solution would be found that would support also these cases. > > Hmm, I found now use-case.h via the link that you gave. That, together > with your explanations, is making this more clear. Apparently those > cases that I mentioned are supported by UCM via modifiers. > > So, if I've understood correctly, UCM dictates that there is always > exactly one verb ("main stream") and exactly one device ("main device") > selected per card. Additional streams and devices can be used by > activating any number of modifiers. > UCM supports between 0..n active devices per verb. e.g. it is possible to enable both the headphone device and speaker device at the same time. > For example, if I wanted to play a ringtone to both the handsfree > speaker and to a headset, I could select verb "ringtone" and device > "speaker", and then I'd activate modifier "headset-ringtone", after > which I could open the headset device in addition to the speaker device. > In pulseaudio this would map to two sinks, and I'd use module-combine to > play the ringtone to both. > > For another example, if I wanted to hear to music from the TV while > talking to the phone, I could select the "Voice Call" verb and the > "Handset" device, and then I'd activate modifier "tv-music", after which > I could open the TV-out device in addition to the handset device. Or > since I probably was listening to the music before the call started, > maybe I'd continue with the "HiFi"+"TV-out" combination and use a > modifier for the call audio. > > My proposal is that profiles are generated for each available verb > +device pair. I think the concept of a profile is going to need to be > altered in some way to accommodate modifiers, because activating a > modifier can enable a new PCM device (not always, though). A new PCM > device means a new sink or source, but creating such sink or source > needs to be possible without tearing down and recreating other sinks and > sources of the profile, and that's not possible with current profiles. > > I propose that profiles stay as they are, with the difference that each > sink and source of the profile can be enabled and disabled > independently. The configuration defines which sinks and sources are > activated by default. module-card-restore would remember user choices, > though, so the defaults would be relevant only when the user hasn't done > any changes, or when module-card-restore isn't used. (I don't think we > actually need to have any UI for enabling and disabling the devices in a > profile, at least initially, so for non-UCM configurations there > wouldn't need to be any observable changes in behavior.) > > So, the verb+device pair would define the default sink and/or source > that are always created when the profile is activated, and modifiers > that have different PCM device than the device of the main use case > would create additional devices to the profile. Modifiers that have the > same PCM device as the main use case would add ports to the main use > case sink and/or source. And if the main use case uses for example pcm0 > and two modifiers use pcm2, then the two modifiers are exposed as ports > on the sink of pcm2. If we have verb+device pairs, how would we enable the Music verb and play to more than one device at the same time ? > > I hope you're able to follow that explanation. If not, feel free to ask > questions :) > > One thing that I'd like to clarify is that am I right that all the verb, > device and modifier names can be chosen freely by the person who writes > the UCM configuration? That is, the strings defined in use-case.h are > just suggestions? > Yes :) the strings defined in use-case.h are the most commonly used examples and can be expanded to include other use case verb, devices and modifiers. Thanks ! Liam