On 10/14/2011 12:40 PM, Feng Wei wrote: > 2011/10/14 David Henningsson<david.henningsson at canonical.com>: >> On 10/14/2011 11:42 AM, Feng Wei wrote: >>> >>> 2011/10/14 David Henningsson<david.henningsson at canonical.com>: >>>> >>>> On 10/14/2011 09:39 AM, Feng Wei wrote: >>>>> >>>>> 2011/10/14 David Henningsson<david.henningsson at canonical.com>: >>>>>> >>>>>> On 10/14/2011 04:47 AM, Feng Wei wrote: >>>>>>> >>>>>>> Hi Liam, Mark, Colin, and all, >>>>>>> I study the codes in pulseaudio and alsa ucm patch recently, and >>>>>>> create a page of my study result. I appreciate your feedback. The page >>>>>>> is at >>>>>>> >>>>>>> >>>>>>> https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1111/AudioIntegration/UCMPulseAudio/Analyzation. >>>>>>> Also if needed, I'm glad to contribute to the integration of alsa >>>>>>> ucm in pulseaudio. >>>>>>> Thank you. >>>>>> >>>>>> Oh, nice diagrams :-) Some of them might be useful additions to the >>>>>> PulseAudio wiki. >>>>> >>>>> Thanks :-) >>>>>> >>>>>> I think the modelling of UCM concepts onto PulseAudio concepts is an >>>>>> important discussion. In PulseAudio, profiles are mainly connected to >>>>>> device >>>>>> strings, how to open the devices, channels supported, whereas ports are >>>>>> just >>>>>> alsa mixer kcontrol changes. UCM verbs, as I understand it, contain >>>>>> both. >>>>> >>>>> My understanding is profile:port and verb:device/modifier are both >>>>> hierarchical. e.g. we have an alsa device string hw:0,0, and some >>>>> mixer controls for route speaker or headset. In pa profile, we >>>>> describe a profile output:analog-stereo with two ports, one for >>>>> speaker, and the other for headset. In ucm, we define verb "hifi" and >>>>> two excluded devices speaker and headset, both of the devices have >>>>> PlaybackPCM hw:0,0. And we can also define two modifiers to switch >>>>> between speaker and headset. So we can create profile by verb and >>>>> create profile input/output mappings by devices(merge the same hw >>>>> device) and create ports by modifier. I'm not sure if it break the >>>>> original ucm concepts, but I think it can work. >>>> >>>> There is also the "Use Case" concept in UCM, Is there always exactly one >>>> verb for every use case? If not, one might wonder if "Use Case" or "Verb" >>>> is >>>> what should correspond to the "Profile" concept. >>> >>> verb is equal to use case. "use case" is a concept and verb is in the >>> source code. >> >> Ok. >> >>>> Card, Sink/Source, Profile and Port are the core concepts in PulseAudio. >>>> I >>>> think UCM should use alsa-sink, alsa-card and alsa-source, but the rest >>>> of >>>> the stuff: pa_alsa_profile_*, pa_alsa_path_*, pa_alsa_mapping - in short, >>>> everything in alsa-mixer.h, I don't think the UCM implementation should >>>> touch them. They are too tightly coupled with the existing ideas of how >>>> to >>>> map ALSA kcontrols to Profiles and Ports, something that UCM does in its >>>> own >>>> way. So in my opinion, you should forget about mappings - it's Profile >>>> and >>>> Port (and Sink/Source) we need to match against. >>> >>> Actually we must map the concepts because ucm is designed for abstract >>> the complicated kcontrol. In my mind, if we use ucm in pa, the >>> original profile configuration files and mixer configuration files >>> will be replaced by ucm configuration files. >> >> I beg to differ: In UCM, PulseAudio is not modifying the mixer controls >> directly, it's just doing calls to alsa ucm library to enable and disable >> stuff verbs/devices/etc. > I absolutely agree. mixer controls are hidden behind the ucm. >> That's why we should not map against existing >> routines that are mainly for modifying mixer controls. > If not mapping port, I just can't find the way to do extra things as > switching mutually exclusive device in pa client. Do you mean still > using original alsa mixer configurations, not the alsa ucm? Aha, I think this is a misunderstanding of the word "mapping". There is an object "pa_alsa_mapping" which IMO should not be used when UCM is used (it does this in the existing UCM patch set, and I think this is wrong). When I said "forget about mappings" I meant "forget about using pa_alsa_mapping in PulseAudio's UCM implementation". We should probably use the "pa_device_port" object. Exactly how depends on how Mark answers to my question about constraints/concurrency. >> Removing the original profile configuration files might be possible in an >> embedded scenario, but for all hundreds of different snd-hda-intel/AC'97/etc >> configurations out there, writing UCM configurations to fit all of them is >> just not scalable. (If so, one would have to write an auto-UCM tool that >> autogenerates UCM profiles based on present hardware.) > So I suggest to add a new module alsa ucm card, so that platform > provider can choose which module to use. If some platform uses alsa > ucm module, then the mixer configurations in alsa module will be > ignored. Have you had a look at the patches for UCM already posted several months ago, and that I spent quite some time reviewing? Or are you planning to start over from scratch? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
