'Twas brillig, and Niels Mayer at 23/09/10 08:18 did gyre and gimble: > IMHO, such a layer could obviate the need for pulseaudio and instead > dynamically invoke the appropriate ALSA constructs (dmix, dsnoop, > plug, etc) needed to satisfy application constraints against hardware > limitations. I completely fail to see how this construct replaces PulseAudio.. The UCM support is intended to be implemented in PA. We currently already have a "poor man's UCM" in PA as we probe many popular configurations on init to determine a list of "Profiles" the user can select. Once the UCM stuff is available in ALSA, we (or rather Liam :p) can try and use UCM instead of htis probing scheme. As not all h/w will instantly support UCM metadata, the probing scheme will still be used as a fall back. But obtaining these profiles is actually a very small part of PA. There are many other things that PA does that is totally beyond this scope and I see no way for ontologies or otherwise to implement those capabilities and features. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
