On 10/14/2011 12:40 PM, Feng Wei wrote:
2011/10/14 David Henningsson<david.hennings...@canonical.com>:
On 10/14/2011 11:42 AM, Feng Wei wrote:
2011/10/14 David Henningsson<david.hennings...@canonical.com>:
On 10/14/2011 09:39 AM, Feng Wei wrote:
2011/10/14 David Henningsson<david.hennings...@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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
