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 <ta...@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. 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. 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? -- Tanu _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss