alsa ucm in pulseaudio

alsa ucm in pulseaudio

[Feng Wei]

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.
-- 
Wei.Feng (irc wei_feng)
Linaro Multimedia Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[David Henningsson]

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.

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.

In this context, I have a question: Can more than verb be active at a 
time for a specific card (e g can both "hifi" and "record" be active for 
the panda), and if so, how is it described in UCM what verbs that can 
coexist and which ones are mutually exclusive? I believe PulseAudio is 
going to need that information in order to be able to know how to create 
its profiles.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Feng Wei]

2011/10/14 David Henningsson <david.henningsson@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.
>
> In this context, I have a question: Can more than verb be active at a time
> for a specific card (e g can both "hifi" and "record" be active for the
> panda), and if so, how is it described in UCM what verbs that can coexist
> and which ones are mutually exclusive? I believe PulseAudio is going to need
> that information in order to be able to know how to create its profiles.
In current alsa ucm implementation, only an active verb is permitted,
but it can have more than one devices enabled. In my mind, in "hifi"
mode, we can still record something because we have some devices
(playback or capture) available.
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic
>



-- 
Wei.Feng (irc wei_feng)
Linaro Multimedia Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[David Henningsson]

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.

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.

As for ports, this again depends on what is mutually exclusive and what 
could be used in parallel, I vaguely remember "Modifiers" as something 
that could be used in parallel with existing streams, if so, they need 
to be separate sinks/sources.

>> In this context, I have a question: Can more than verb be active at a time
>> for a specific card (e g can both "hifi" and "record" be active for the
>> panda), and if so, how is it described in UCM what verbs that can coexist
>> and which ones are mutually exclusive? I believe PulseAudio is going to need
>> that information in order to be able to know how to create its profiles.
> In current alsa ucm implementation, only an active verb is permitted,
> but it can have more than one devices enabled. In my mind, in "hifi"
> mode, we can still record something because we have some devices
> (playback or capture) available.

Hmm, for every sink/source, there can only be one active port at a time. 
Also, ports on the same sink/source can be changed on the fly without 
restarting the stream. Does this fit with the description of a UCM "Device"?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Mark Brown]

On Fri, Oct 14, 2011 at 10:57:08AM +0200, David Henningsson wrote:

> 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.

Yes, pretty much.

> As for ports, this again depends on what is mutually exclusive and
> what could be used in parallel, I vaguely remember "Modifiers" as
> something that could be used in parallel with existing streams, if
> so, they need to be separate sinks/sources.

Modifiers and Devices can both be used concurrently.

> Hmm, for every sink/source, there can only be one active port at a
> time. Also, ports on the same sink/source can be changed on the fly
> without restarting the stream. Does this fit with the description of
> a UCM "Device"?

Pretty much.

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Feng Wei]

2011/10/14 David Henningsson <david.henningsson@canonical.com>:
> On 10/14/2011 09:39 AM, Feng Wei wrote:
>>
>> 2011/10/14 David Henningsson<david.henningsson@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.
>
> 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.
>
> As for ports, this again depends on what is mutually exclusive and what
> could be used in parallel, I vaguely remember "Modifiers" as something that
> could be used in parallel with existing streams, if so, they need to be
> separate sinks/sources.
>
>>> In this context, I have a question: Can more than verb be active at a
>>> time
>>> for a specific card (e g can both "hifi" and "record" be active for the
>>> panda), and if so, how is it described in UCM what verbs that can coexist
>>> and which ones are mutually exclusive? I believe PulseAudio is going to
>>> need
>>> that information in order to be able to know how to create its profiles.
>>
>> In current alsa ucm implementation, only an active verb is permitted,
>> but it can have more than one devices enabled. In my mind, in "hifi"
>> mode, we can still record something because we have some devices
>> (playback or capture) available.
>
> Hmm, for every sink/source, there can only be one active port at a time.
> Also, ports on the same sink/source can be changed on the fly without
> restarting the stream. Does this fit with the description of a UCM "Device"?
As my example described, ucm device is more abstract than physical
device. mutually exclusive ucm device "speaker" and "headset" may
refer to same alsa device "hw:0,0", the only difference is the mixer
route. I'm not sure how to implement the active port switching, if
mapping port to modifier, it should call ucm enable/disable modifier,
but it's more reasonable to call ucm switch device in concept.
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic
>



-- 
Wei.Feng (irc wei_feng)
Linaro Multimedia Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[David Henningsson]

On 10/14/2011 11:39 AM, Mark Brown wrote:
> On Fri, Oct 14, 2011 at 10:57:08AM +0200, David Henningsson wrote:
>> As for ports, this again depends on what is mutually exclusive and
>> what could be used in parallel, I vaguely remember "Modifiers" as
>> something that could be used in parallel with existing streams, if
>> so, they need to be separate sinks/sources.
>
> Modifiers and Devices can both be used concurrently.

Could you elaborate on this, i e specify constraints for Devices and 
Modifiers, if any? E g, would UCM allow for three active Devices and 
four active Modifiers, all resulting in seven independent PCM streams 
running concurrently? Or are there constraints in that e g all Devices 
and/or Modifiers must share the same PCM stream?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[David Henningsson]

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. That's why we should not map against 
existing routines that are mainly for modifying mixer controls.

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.)

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Feng Wei]

2011/10/14 David Henningsson <david.henningsson@canonical.com>:
> On 10/14/2011 11:42 AM, Feng Wei wrote:
>>
>> 2011/10/14 David Henningsson<david.henningsson@canonical.com>:
>>>
>>> On 10/14/2011 09:39 AM, Feng Wei wrote:
>>>>
>>>> 2011/10/14 David Henningsson<david.henningsson@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?
>
> 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.
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic
>



-- 
Wei.Feng (irc wei_feng)
Linaro Multimedia Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[David Henningsson]

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

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Mark Brown]

On Fri, Oct 14, 2011 at 12:00:54PM +0200, David Henningsson wrote:
> On 10/14/2011 11:39 AM, Mark Brown wrote:
> >On Fri, Oct 14, 2011 at 10:57:08AM +0200, David Henningsson wrote:
> >>As for ports, this again depends on what is mutually exclusive and
> >>what could be used in parallel, I vaguely remember "Modifiers" as
> >>something that could be used in parallel with existing streams, if
> >>so, they need to be separate sinks/sources.

> >Modifiers and Devices can both be used concurrently.

> Modifiers, if any? E g, would UCM allow for three active Devices and
> four active Modifiers, all resulting in seven independent PCM
> streams running concurrently? Or are there constraints in that e g
> all Devices and/or Modifiers must share the same PCM stream?

There can be more than one PCM stream but there needn't be a PCM stream
per device (and that would fail to reflect what hardware can actually
implement).

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Mark Brown]

On Fri, Oct 14, 2011 at 12:19:53PM +0200, David Henningsson wrote:
> On 10/14/2011 11:42 AM, Feng Wei wrote:

> >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.

> 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.)

Yes, writing UCM files for PCs which have reasonably regular and
discoverable audio is silly - if UCM is used at all on most desktops it
should be with automatically generated configuration.

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Mark Brown]

On Fri, Oct 14, 2011 at 12:57:39PM +0200, David Henningsson wrote:

> 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?

Yeah, what's the status on those?  There didn't seem to be any major
issues anyone was raising last time (from memory, I didn't check the
archives) and I'm not seeing any clear route to actually getting them
merged.

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Arun Raghavan]

On Fri, 2011-10-14 at 13:18 +0100, Mark Brown wrote:
> On Fri, Oct 14, 2011 at 12:57:39PM +0200, David Henningsson wrote:
> 
> > 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?
> 
> Yeah, what's the status on those?  There didn't seem to be any major
> issues anyone was raising last time (from memory, I didn't check the
> archives) and I'm not seeing any clear route to actually getting them
> merged.

I spoke to Colin after LPC and he pointed out that David had posted a
bunch of review comments to Jorge's 3rd series. There was no follow-up
to those, and things seem to be stuck there. It's not clear who's
carrying that work forward, tbh, and there's some interesting things
coming up in this thread.

I don't know if Feng Wei will be at Prague for ELCE/LinuxCon/GstConf,
but perhaps this is something we can take up at one of the BoFs.

-- Arun

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Feng Wei]

Hi Arun,
  I won't be at Prague for ELCE, but I'll attend UDS/LDS Q4 at Orlando,FL.

-- 
Wei.Feng (irc wei_feng)
Linaro Multimedia Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[David Henningsson]

On 10/17/2011 09:14 AM, Arun Raghavan wrote:
> On Fri, 2011-10-14 at 13:18 +0100, Mark Brown wrote:
>> On Fri, Oct 14, 2011 at 12:57:39PM +0200, David Henningsson wrote:
>>
>>> 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?
>>
>> Yeah, what's the status on those?  There didn't seem to be any major
>> issues anyone was raising last time (from memory, I didn't check the
>> archives) and I'm not seeing any clear route to actually getting them
>> merged.
>
> I spoke to Colin after LPC and he pointed out that David had posted a
> bunch of review comments to Jorge's 3rd series. There was no follow-up
> to those, and things seem to be stuck there. It's not clear who's
> carrying that work forward, tbh, and there's some interesting things
> coming up in this thread.

Maybe it would be better trying to merge my jack detection first, so 
that jack detection mechanism can then be adapted (if needed) to fit 
UCM's needs?
And for the record, the jack detection upstreaming is currently waiting 
for Arun/Colin commenting or pushing my first jack detection patch.

> I don't know if Feng Wei will be at Prague for ELCE/LinuxCon/GstConf,
> but perhaps this is something we can take up at one of the BoFs.

Since both I and Feng (and possibly Mark Brown as well? He was present 
at previous UDS) it might make sense to schedule a UDS session for this? 
People not present can listen through icecast streams and join in on IRC 
for commenting back, something I don't think is possible on LinuxCon 
(but I don't know for sure?).

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Mark Brown]

On Mon, Oct 17, 2011 at 10:32:06AM +0200, David Henningsson wrote:
> On 10/17/2011 09:14 AM, Arun Raghavan wrote:

Arun, don't drop people from the CC list!

> Maybe it would be better trying to merge my jack detection first, so 
> that jack detection mechanism can then be adapted (if needed) to fit 
> UCM's needs?
> And for the record, the jack detection upstreaming is currently waiting 
> for Arun/Colin commenting or pushing my first jack detection patch.

Hopefully we can get both merged, they're both needed and this is all
taking far too long :(  Given the deployment in Ubuntu and your active
work on it your jack detection patch seems like the way forward for the
jack detection.

> > I don't know if Feng Wei will be at Prague for ELCE/LinuxCon/GstConf,
> > but perhaps this is something we can take up at one of the BoFs.

> Since both I and Feng (and possibly Mark Brown as well? He was present 
> at previous UDS) it might make sense to schedule a UDS session for this? 
> People not present can listen through icecast streams and join in on IRC 
> for commenting back, something I don't think is possible on LinuxCon 
> (but I don't know for sure?).

I'm not currently planning to attend UDS but I will be in Prague for
Kernel Summit, ELC-E and LinuxCon.

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Arun Raghavan]

On Mon, 2011-10-17 at 11:23 +0100, Mark Brown wrote:
> On Mon, Oct 17, 2011 at 10:32:06AM +0200, David Henningsson wrote:
> > On 10/17/2011 09:14 AM, Arun Raghavan wrote:
> 
> Arun, don't drop people from the CC list!

Sorry 'bout that -- I did hit reply-all, but Evolution has a mind of its
own sometimes.

> > Maybe it would be better trying to merge my jack detection first, so 
> > that jack detection mechanism can then be adapted (if needed) to fit 
> > UCM's needs?
> > And for the record, the jack detection upstreaming is currently waiting 
> > for Arun/Colin commenting or pushing my first jack detection patch.
> 
> Hopefully we can get both merged, they're both needed and this is all
> taking far too long :(  Given the deployment in Ubuntu and your active
> work on it your jack detection patch seems like the way forward for the
> jack detection.

The intention is to get this stuff merged for 2.0 (which won't be
anywhere near as long in the making as 1.0 was, don't worry :) )

> > > I don't know if Feng Wei will be at Prague for ELCE/LinuxCon/GstConf,
> > > but perhaps this is something we can take up at one of the BoFs.
> 
> > Since both I and Feng (and possibly Mark Brown as well? He was present 
> > at previous UDS) it might make sense to schedule a UDS session for this? 
> > People not present can listen through icecast streams and join in on IRC 
> > for commenting back, something I don't think is possible on LinuxCon 
> > (but I don't know for sure?).
> 
> I'm not currently planning to attend UDS but I will be in Prague for
> Kernel Summit, ELC-E and LinuxCon.

Let's discuss this at Prague anyway, and we can continue to flesh things
out over IRC/Icecast during UDS as David suggests.

-- Arun

Re: [pulseaudio-discuss] alsa ucm in pulseaudio

[Takashi Iwai]

At Mon, 17 Oct 2011 16:25:36 +0530,
Arun Raghavan wrote:
> 
> On Mon, 2011-10-17 at 11:23 +0100, Mark Brown wrote:
> > On Mon, Oct 17, 2011 at 10:32:06AM +0200, David Henningsson wrote:
> > > On 10/17/2011 09:14 AM, Arun Raghavan wrote:
> > 
> > Arun, don't drop people from the CC list!
> 
> Sorry 'bout that -- I did hit reply-all, but Evolution has a mind of its
> own sometimes.

Hrm, Cc list was screwed up in your mail...
Now fixed again manually.

> > > Maybe it would be better trying to merge my jack detection first, so 
> > > that jack detection mechanism can then be adapted (if needed) to fit 
> > > UCM's needs?
> > > And for the record, the jack detection upstreaming is currently waiting 
> > > for Arun/Colin commenting or pushing my first jack detection patch.
> > 
> > Hopefully we can get both merged, they're both needed and this is all
> > taking far too long :(  Given the deployment in Ubuntu and your active
> > work on it your jack detection patch seems like the way forward for the
> > jack detection.
> 
> The intention is to get this stuff merged for 2.0 (which won't be
> anywhere near as long in the making as 1.0 was, don't worry :) )
> 
> > > > I don't know if Feng Wei will be at Prague for ELCE/LinuxCon/GstConf,
> > > > but perhaps this is something we can take up at one of the BoFs.
> > 
> > > Since both I and Feng (and possibly Mark Brown as well? He was present 
> > > at previous UDS) it might make sense to schedule a UDS session for this? 
> > > People not present can listen through icecast streams and join in on IRC 
> > > for commenting back, something I don't think is possible on LinuxCon 
> > > (but I don't know for sure?).
> > 
> > I'm not currently planning to attend UDS but I will be in Prague for
> > Kernel Summit, ELC-E and LinuxCon.
> 
> Let's discuss this at Prague anyway, and we can continue to flesh things
> out over IRC/Icecast during UDS as David suggests.

A gstreamer / audio BoF is planned in Oct. 23, Sunday 17:00.
We can get an overview there, too.

Of course, another sound BoF can be taken later again spontaneously
during LinuxCon, e.g. for the detailed implementation discussion.


thanks,

Takashi