Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[David Henningsson <david.henningsson-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>]

On 10/14/2011 12:40 PM, Feng Wei wrote:
> 2011/10/14 David Henningsson<david.henningsson-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>:
>> On 10/14/2011 11:42 AM, Feng Wei wrote:
>>>
>>> 2011/10/14 David Henningsson<david.henningsson-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>:
>>>>
>>>> On 10/14/2011 09:39 AM, Feng Wei wrote:
>>>>>
>>>>> 2011/10/14 David Henningsson<david.henningsson-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>:
>>>>>>
>>>>>> 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