Re: [alsa-devel] [PATCH 0/3] alsa-lib: UCM - Use Case Manager
On Tue, 7 Sep 2010, Liam Girdwood wrote:
Hi Jaroslav,
Any update on this ? I have someone scheduled to write new use case files and someone else ready to add PA support.
Hi,
I'm working on this. Unfortunately, I have other things which interrupts this work. The actual code is at:
http://git.alsa-project.org/?p=alsa-lib.git;a=shortlog;h=ucm
During coding, it appears that even the handling of controls might be changed. Your code has everything build-in. I'm not sure why to restrict the card/verb/modifier/transition definitions only for the universal control API. I think that it might be more "easy to understand" and universal to define just sequence of commands like:
SectionDefaults [ exec "amixer cset name='Master Playback Switch',index=2 1,1" exec "amixer cset name='Master Playback Volume',index=2 25,25" exec "amixer cset name='Master Mono Playback',index=1 0" exec "amixer cset name='Master Mono Playback Volume',index=1 0" msleep 50 # or: exec "usleep 50000" exec "amixer cset name='PCM Switch',index=2 1,1" ........ ]
Because "amixer cset" command will be probably most used command, we can eventually move the amixer code to alsa-lib to not create so much processes and speed-up things.
It means that the ucm should not track card controls, but commands for transitions.
The only thing which might "broke" things is calling fork from a pthread:
http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2003-09/0672.html
But it seems that fork/immediate-exec is an acceptable way.
Comments?
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, Sep 07, 2010 at 04:42:57PM +0200, Jaroslav Kysela wrote:
control API. I think that it might be more "easy to understand" and universal to define just sequence of commands like:
SectionDefaults [ exec "amixer cset name='Master Playback Switch',index=2 1,1"
...
Because "amixer cset" command will be probably most used command, we can eventually move the amixer code to alsa-lib to not create so much processes and speed-up things.
It means that the ucm should not track card controls, but commands for transitions.
I don't understand the motivation here - what does this buy us?
Looking at this from the embedded perspective I really would much rather see a use case manager that understands what it's doing (rather than essentially just running shell script). This allows us to do things like specify target states (rather than having to have full sequences for all transitions, which is one of the things it'd be good to avoid) and will allow us to take advantage of any additions to the ALSA APIs for things like batching operations without changes to the per machine configurations.
Having the facility to shell out in case some non-ALSA stuff needs to be done might be handy but I'd expect that for things within ALSA a tool like the use case manager would understand ALSA natively.
For embedded systems, especially those like mobile phones with extensive use case requirements, the usability issues mostly come from the very large numbers of controls which is at best orthogonal to shelling out to amixer (or whatever) commands.
On Tue, 7 Sep 2010, Mark Brown wrote:
On Tue, Sep 07, 2010 at 04:42:57PM +0200, Jaroslav Kysela wrote:
control API. I think that it might be more "easy to understand" and universal to define just sequence of commands like:
SectionDefaults [ exec "amixer cset name='Master Playback Switch',index=2 1,1"
...
Because "amixer cset" command will be probably most used command, we can eventually move the amixer code to alsa-lib to not create so much processes and speed-up things.
It means that the ucm should not track card controls, but commands for transitions.
I don't understand the motivation here - what does this buy us?
Looking at this from the embedded perspective I really would much rather see a use case manager that understands what it's doing (rather than essentially just running shell script). This allows us to do things like specify target states (rather than having to have full sequences for all transitions, which is one of the things it'd be good to avoid) and will allow us to take advantage of any additions to the ALSA APIs for things like batching operations without changes to the per machine configurations.
Having the facility to shell out in case some non-ALSA stuff needs to be done might be handy but I'd expect that for things within ALSA a tool like the use case manager would understand ALSA natively.
For embedded systems, especially those like mobile phones with extensive use case requirements, the usability issues mostly come from the very large numbers of controls which is at best orthogonal to shelling out to amixer (or whatever) commands.
My idea is to have the most used commands working with the ALSA API built directly into the ucm code to not use fork/exec so much in embedded environments. But I can imagine that some system configurations can use this API to send events to another manager which can control another parts of the system like video, input devices, network devices and so on according the sound setup.
Also, the possibility to generate the alsa-lib's configuration files at run-time might be a nice feature for future. I take UCM like a way to integrate all things regarding PCM streams and mixer controls together and let users / system administrators / distribution makers create the abstract layers depending their requirements.
It's about flexibility.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, Sep 07, 2010 at 08:17:19PM +0200, Jaroslav Kysela wrote:
On Tue, 7 Sep 2010, Mark Brown wrote:
SectionDefaults [ exec "amixer cset name='Master Playback Switch',index=2 1,1"
My idea is to have the most used commands working with the ALSA API built directly into the ucm code to not use fork/exec so much in embedded environments. But I can imagine that some system
I'm not sure how this follows on from what you're proposing above? You appear to be proposing the replacement of the lists of control settings with shell commands, then later on optimising those forks busybox style by building the relevant binaries into the library.
Currently outside of the explict sequences provided to override the default transitions the use case manager configurations are declarative rather than ordering based. This lets the user specify end states and lets the use case manager code work out the best way to accomplish those configurations which seems like a valuable property.
configurations can use this API to send events to another manager which can control another parts of the system like video, input devices, network devices and so on according the sound setup.
I do agree that this may be useful but I don't see that we need to rewrite the ALSA control management bit of things for that, the declarative style seems like a win there. I also feel that it may make more sense to do this externally to this library in a higher level tool which controls both this and other things.
Also, the possibility to generate the alsa-lib's configuration files at run-time might be a nice feature for future. I take UCM like a
This might be useful, though I'd expect that Pulse might be more useful for a lot of systems.
way to integrate all things regarding PCM streams and mixer controls together and let users / system administrators / distribution makers create the abstract layers depending their requirements.
That's my understanding of what the idea is.
It's about flexibility.
As I said above I'm concerned that you're trying to move this into something which is much more of a system level use case manager than an audio specific one, and limiting the audio domain as part of that. If we're doing too much of that then we're into the domain of the system level software that would be driving the UCM.
On Tue, 7 Sep 2010, Mark Brown wrote:
Currently outside of the explict sequences provided to override the default transitions the use case manager configurations are declarative rather than ordering based. This lets the user specify end states and lets the use case manager code work out the best way to accomplish those configurations which seems like a valuable property.
I don't see any difference here. I checked the Liam's code and there is no intelligence regarding the ALSA controls API. The sequences are just processed in the serialized way and they must be (for example to satisfy the time delay requirements between control writes).
configurations can use this API to send events to another manager which can control another parts of the system like video, input devices, network devices and so on according the sound setup.
I do agree that this may be useful but I don't see that we need to rewrite the ALSA control management bit of things for that, the declarative style seems like a win there. I also feel that it may make more sense to do this externally to this library in a higher level tool which controls both this and other things.
Note that my proposal is just extension. It's like difference between full desktop system and a small optimized system (for example for small wireless hardware platforms). There are many differences in the boot style and root system trees, because not all things are required for small systems. Nobody forces the user to use the exec command.
Also, the possibility to generate the alsa-lib's configuration files at run-time might be a nice feature for future. I take UCM like a
This might be useful, though I'd expect that Pulse might be more useful for a lot of systems.
way to integrate all things regarding PCM streams and mixer controls together and let users / system administrators / distribution makers create the abstract layers depending their requirements.
That's my understanding of what the idea is.
It's about flexibility.
As I said above I'm concerned that you're trying to move this into something which is much more of a system level use case manager than an audio specific one, and limiting the audio domain as part of that. If we're doing too much of that then we're into the domain of the system level software that would be driving the UCM.
My motivation is to make UCM useable also for the desktop systems. In this environment might be useful to send external events to another layers when an app requests specific audio device. For example, HDMI is connected with the video link so the X11 server might be notified about this request.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Wed, Sep 08, 2010 at 09:54:50AM +0200, Jaroslav Kysela wrote:
On Tue, 7 Sep 2010, Mark Brown wrote:
Currently outside of the explict sequences provided to override the default transitions the use case manager configurations are declarative rather than ordering based. This lets the user specify end states and lets the use case manager code work out the best way to accomplish those configurations which seems like a valuable property.
I don't see any difference here. I checked the Liam's code and there is no intelligence regarding the ALSA controls API. The sequences
Right, just now it's not doing anything because at the minute we don't have much option but it does mean that the control format doesn't lock us into this and allows room for expansion.
are just processed in the serialized way and they must be (for example to satisfy the time delay requirements between control writes).
I'd really expect the driver to be finiessing stuff.
Note that my proposal is just extension. It's like difference between full desktop system and a small optimized system (for example for small wireless hardware platforms). There are many
See below.
My motivation is to make UCM useable also for the desktop systems. In this environment might be useful to send external events to another layers when an app requests specific audio device. For example, HDMI is connected with the video link so the X11 server might be notified about this request.
Right, but the expectation is that the system management service which is driving UCM will able to also drive other subsysems, and it's not entirely obvious that the audio use case selection should drive too much non-audio stuff directly.
This and some of your other comments make me concerned that you aren't aware of the complexity of the audio subsystems on high end embedded devices like smartphones. Things like the video use case you describe above are not at all unusual for smartphones - I actually currently have a smartphone sitting plugged into my AV system at home and able to deliver audio and video to it (though only with composite).
A modern smartphone can have multiple independant independantly routeable audio streams between the CPU and primary audio CODEC, plus separate digital audio streams between the CODEC and the cellular modem and bluetooth. There will be headphones, an earpiece speaker, possibly one or more separate music/speakerphone speakers, at least one on-board microphone and a headset microphone. Add on to this a separate audio CODEC for HDMI, A2DP, and accessory handling (including stuff like muxing composite video out onto the same jack pins used for headset microphone) and you've got a very flexible system.
When thinking about these issues it is generally safe to assume that embedded systems can have software that's at least as complex as that on PC class hardware. I would be very surprised if a software model which meets the needs of complex embedded systems is not also capable of doing everything a desktop needs.
Creating another thread .... state locking ...
I understand the motivation to create a layer for phone or similar embedded devices which uses usually all streams from the one process.
But what about more concurrent processes? The state handling in the current implementation is per process, so another process just overwrite blindly the control values set by the first process.
I think that the layer should have some locking mechanism and state persistency (IPC semaphores / IPC shared memory) or a file and inotify?
Another question is how to handle collisions.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Wed, Sep 08, 2010 at 10:19:45AM +0200, Jaroslav Kysela wrote:
I understand the motivation to create a layer for phone or similar embedded devices which uses usually all streams from the one process.
But what about more concurrent processes? The state handling in the current implementation is per process, so another process just overwrite blindly the control values set by the first process.
You really need one single thing to own the physical audio device configuration, even on a desktop. On a desktop system that'd be PulseAudio normally since applications end up talking to PulseAudio rather than the hardware directly so only PulseAudio is actually directly concerned with the hardware setup. On an embedded system it'd quite frequently be PulseAudio as well but obviously it will differ on some systems.
Another question is how to handle collisions.
This is the core issue which forces some central thing owning the policy decisions on a system wide basis - something needs to take policy decisions about what's happening.
The focus for UCM is providing a model for thinking about configurations and the mechanics of applying them, which are the areas of the problem which are well understood and shared by all implementations. Mechanisms for actually deciding on what the policy is and dealing with contention for the hardware are very much open questions at the minute even on desktops so keeping the solutions in that area separate to the bits that are well understood allows flexibility in these more contentious areas.
Again, assuming that there's a substantial difference between embedded and desktop systems isn't really reflecting the reality of actual systems these days - they're all on a continuum and in many cases the standardisation of hardware in desktop systems means they will be more simple rather than less simple than embedded systems.
On Tue, 2010-09-07 at 20:17 +0200, Jaroslav Kysela wrote:
On Tue, 7 Sep 2010, Mark Brown wrote:
On Tue, Sep 07, 2010 at 04:42:57PM +0200, Jaroslav Kysela wrote:
control API. I think that it might be more "easy to understand" and universal to define just sequence of commands like:
SectionDefaults [ exec "amixer cset name='Master Playback Switch',index=2 1,1"
...
Because "amixer cset" command will be probably most used command, we can eventually move the amixer code to alsa-lib to not create so much processes and speed-up things.
It means that the ucm should not track card controls, but commands for transitions.
I don't understand the motivation here - what does this buy us?
Looking at this from the embedded perspective I really would much rather see a use case manager that understands what it's doing (rather than essentially just running shell script). This allows us to do things like specify target states (rather than having to have full sequences for all transitions, which is one of the things it'd be good to avoid) and will allow us to take advantage of any additions to the ALSA APIs for things like batching operations without changes to the per machine configurations.
Having the facility to shell out in case some non-ALSA stuff needs to be done might be handy but I'd expect that for things within ALSA a tool like the use case manager would understand ALSA natively.
For embedded systems, especially those like mobile phones with extensive use case requirements, the usability issues mostly come from the very large numbers of controls which is at best orthogonal to shelling out to amixer (or whatever) commands.
My idea is to have the most used commands working with the ALSA API built directly into the ucm code to not use fork/exec so much in embedded environments.
What does this really buy us over the current (direct alsa-lib API) code ?
Fwiw, UCM was never intended to replace any of the alsa-utils, but to complement them in complex audio systems (like phones).
But I can imagine that some system configurations can use this API to send events to another manager which can control another parts of the system like video, input devices, network devices and so on according the sound setup.
UCM is purely to abstract the audio hardware for higher level middle-ware and applications. It's really up to the system middle-ware and daemons here to configure/control the other subsystems in line with the system use case.
Also, the possibility to generate the alsa-lib's configuration files at run-time might be a nice feature for future.
Fwiw, UCM is _needed_ now and I really can't emphasise this strongly enough atm. Some embedded ODMs are even now using and shipping closed source proprietary software for audio hardware UCM.
The UCM configuration files for embedded system will likely be very specific to the hardware and not really suited to run time generation. However, there is nothing stopping runtime generation with the original file format.
I take UCM like a way to integrate all things regarding PCM streams and mixer controls together and let users / system administrators / distribution makers create the abstract layers depending their requirements.
It's about flexibility.
Exactly, but there is nothing stopping flexibility with the current code base.
Liam
On Tue, Sep 07, 2010 at 09:02:35PM +0100, Liam Girdwood wrote:
On Tue, 2010-09-07 at 20:17 +0200, Jaroslav Kysela wrote:
Also, the possibility to generate the alsa-lib's configuration files at run-time might be a nice feature for future.
Fwiw, UCM is _needed_ now and I really can't emphasise this strongly enough atm. Some embedded ODMs are even now using and shipping closed source proprietary software for audio hardware UCM.
Now you mention this I feel remiss for not pointing it out before. I'm also working with many system manufacturers including smartphone vendors (they're the people who are *really* suffering here) and a lot of them have a use case problem to some degree. There's two key issues I see people having problems with:
- Coming up with an abstraction for an audio use case which can be used to think about the possbilities for configuring ALSA and implementing the mechanics of it. UCM pretty much deals with this.
- Generating and maintaining use cases. UCM provides a good start on this in itself - simply having the suggested way of thinking about things is a win, never mind the tools - and having the standard format is pretty much a requirement for doing any more tools work.
A procedural approach is a common solution but it makes both problems harder, especially the second one since it means that every time you think about a use case you must think about the mechanics of moving into and out of it rather than just thinking about the configuration you want to achieve.
The UCM configuration files for embedded system will likely be very specific to the hardware and not really suited to run time generation. However, there is nothing stopping runtime generation with the original file format.
For an example of the sort of system complexity one is dealing with in the smartphone use case the WM8994 is an example of the sort of feature set you can see in the audio CODEC alone:
http://www.wolfsonmicro.com/products/WM8994
Trying to autogenerate the configuration for a system like this is likely at best give a first pass result since the actual configurations end up depending on not only your current use case but also the other use cases you might want to use in the future.
Hi Jaroslav,
'Twas brillig, and Jaroslav Kysela at 07/09/10 15:42 did gyre and gimble:
On Tue, 7 Sep 2010, Liam Girdwood wrote:
Hi Jaroslav,
Any update on this ? I have someone scheduled to write new use case files and someone else ready to add PA support.
Hi,
I'm working on this. Unfortunately, I have other things which interrupts this work. The actual code is at:
http://git.alsa-project.org/?p=alsa-lib.git;a=shortlog;h=ucm
Has there been any progress on the UCM stuff? I'm quite interested to see how this will develop from a PA perspective. It does have some impact on work that I've been wanting to do for a while in PA so the sooner this is available in ALSA the sooner I can start thinking about some of the knock on effects. I know Liam is intending to do some work on PA too to integrate UCM once the API has stabilised, so I'm obviously keen to encourage that too :D
Cheers
Col
On Mon, Sep 20, 2010 at 11:26 AM, Colin Guthrie gmane@colin.guthr.ie wrote:
Hi Jaroslav,
'Twas brillig, and Jaroslav Kysela at 07/09/10 15:42 did gyre and gimble:
On Tue, 7 Sep 2010, Liam Girdwood wrote:
Hi Jaroslav,
Any update on this ? I have someone scheduled to write new use case files and someone else ready to add PA support.
Hi,
I'm working on this. Unfortunately, I have other things which interrupts this work. The actual code is at:
http://git.alsa-project.org/?p=alsa-lib.git;a=shortlog;h=ucm
Has there been any progress on the UCM stuff? I'm quite interested to see how this will develop from a PA perspective. It does have some impact on work that I've been wanting to do for a while in PA so the sooner this is available in ALSA the sooner I can start thinking about some of the knock on effects. I know Liam is intending to do some work on PA too to integrate UCM once the API has stabilised, so I'm obviously keen to encourage that too :D
Since progress on UCM seems to have stalled, I'd also like to chip in and say that it would be great to see UCM pushed to mainline as soon as possible. I'm a software engineer at Garmin, responsible for system-level audio support on Linux-based personal navigation devices, and UCM would *really* help to simplify the management of audio state on those devices. In fact, I've been hurting for something like UCM for so long that I'm already developing against the version that Liam has posted to the list.
I not entirely convinced that Jaroslav's proposed changes to UCM will add much value to overall functionality. The reworked API seems more clumsy and confusing to me, and I think it's a bad idea to make UCM responsible for coordinating audio state management throughout userspace -- as Mark B. said, that responsibility would seem to be better left to some other entity who would be the sole consumer of UCM API in the system (e.g., pulseaudio), which is really no different from the current situation for basic playback or capture through Alsa, i.e., if multiple processes want to playback/capture PCM data at the same time, then some other entity must coordinate access (e.g., dmix, pulseaudio).
_From the PND perspective, there is often a complex intermix of business logic and asynchronous system events (from both hardware and software) driving the audio hardware state changes. I can tell you from experience that it is a nightmare to have to pass such arbitrary information between processes for the purposes of making even the simplest of policy decisions for system-wide audio state. If it is truly desired to turn UCM into userspace's central manager and coordinator for audio state, then it absolutely must provide a clear and flexible way to pass arbitrary state variables through the system, and also a generic mechanism for specifying how the audio policy must change based on those state variables. A superb and worthy ideal, perhaps, but it's a tall order, and I don't see it becoming a viable reality any time soon.
I think the proposed switch to using alsa-lib's present conf file parser code may be worth doing (even though I find the syntax to be uglier). Otherwise, the only thing I would really like to see added to UCM (after it gets mainlined!) is a more generic mechanism for aliasing mixer control names, instead of how it is currently limited to aliasing master playback/capture volumes and master playback/capture switches. On PNDs at least, it is often necessary to read/write some mixer controls directly, e.g., for mic gain, and so it's a pain when mixer control names differ across codecs. It would be great if Alsa provided for such aliasing, instead of leaving developers to rely on custom solutions.
Regards,
Chris Winter
On Tue, Sep 21, 2010 at 12:13:33PM -0500, Chris Winter wrote:
I think the proposed switch to using alsa-lib's present conf file parser code may be worth doing (even though I find the syntax to be uglier). Otherwise, the only thing I would really like to see added to UCM (after it gets mainlined!) is a more generic mechanism for aliasing mixer control names, instead of how it is currently limited to aliasing master playback/capture volumes and master
This was discussed when the original review round happened a while ago and is the reason why the interfaces support other names even though the implementation can't - it means someone can just substitute in different library code without disrupting applications. Definitely on the list to do.
On Tue, 21 Sep 2010, Chris Winter wrote:
On Mon, Sep 20, 2010 at 11:26 AM, Colin Guthrie gmane@colin.guthr.ie wrote:
Hi Jaroslav,
'Twas brillig, and Jaroslav Kysela at 07/09/10 15:42 did gyre and gimble:
On Tue, 7 Sep 2010, Liam Girdwood wrote:
Hi Jaroslav,
Any update on this ? I have someone scheduled to write new use case files and someone else ready to add PA support.
Hi,
I'm working on this. Unfortunately, I have other things which interrupts this work. The actual code is at:
http://git.alsa-project.org/?p=alsa-lib.git;a=shortlog;h=ucm
Has there been any progress on the UCM stuff? I'm quite interested to see how this will develop from a PA perspective. It does have some impact on work that I've been wanting to do for a while in PA so the sooner this is available in ALSA the sooner I can start thinking about some of the knock on effects. I know Liam is intending to do some work on PA too to integrate UCM once the API has stabilised, so I'm obviously keen to encourage that too :D
Since progress on UCM seems to have stalled, I'd also like to chip in and say that it would be great to see UCM pushed to mainline as soon as possible. I'm a software engineer at Garmin, responsible for system-level audio support on Linux-based personal navigation devices, and UCM would *really* help to simplify the management of audio state on those devices. In fact, I've been hurting for something like UCM for so long that I'm already developing against the version that Liam has posted to the list.
Hi all,
I'm sorry to be silent in the last week, but the reason was quite simple - vacation. As my life goes, my second son was born and I decided to be with my family, so I was able to handle only really urgent things.
I not entirely convinced that Jaroslav's proposed changes to UCM will add much value to overall functionality. The reworked API seems more clumsy and confusing to me, and I think it's a bad idea to make UCM responsible for coordinating audio state management throughout userspace -- as Mark B. said, that responsibility would seem to be better left to some other entity who would be the sole consumer of UCM API in the system (e.g., pulseaudio), which is really no different from the current situation for basic playback or capture through Alsa, i.e., if multiple processes want to playback/capture PCM data at the same time, then some other entity must coordinate access (e.g., dmix, pulseaudio).
There are two things and I think that we both talking about different ones.
1) Which devices can be used simultaneously in the system (basically determining the number of handled streams). 2) Physical output (or input) switching (I mean physical jacks etc.).
I don't want to add any complex manager. I just think that the UCM layer should give the information to the application which PCM streams can be used concurrently for a named card. Something like stream grouping.
The problem is that you think in the "ASoC" way to handle just one input and output stream for phones etc. and I think in "multiple independant streams" per card way.
From the PND perspective, there is often a complex intermix of
business logic and asynchronous system events (from both hardware and software) driving the audio hardware state changes. I can tell you from experience that it is a nightmare to have to pass such arbitrary information between processes for the purposes of making even the simplest of policy decisions for system-wide audio state. If it is truly desired to turn UCM into userspace's central manager and coordinator for audio state, then it absolutely must provide a clear and flexible way to pass arbitrary state variables through the system, and also a generic mechanism for specifying how the audio policy must change based on those state variables. A superb and worthy ideal, perhaps, but it's a tall order, and I don't see it becoming a viable reality any time soon.
I agree.
I think the proposed switch to using alsa-lib's present conf file parser code may be worth doing (even though I find the syntax to be uglier). Otherwise, the only thing I would really like to see added to UCM (after it gets mainlined!) is a more generic mechanism for aliasing mixer control names, instead of how it is currently limited to aliasing master playback/capture volumes and master playback/capture switches. On PNDs at least, it is often necessary to read/write some mixer controls directly, e.g., for mic gain, and so it's a pain when mixer control names differ across codecs. It would be great if Alsa provided for such aliasing, instead of leaving developers to rely on custom solutions.
This is really point why I switched from "many functions returning just values" to "one function with a universal string identifier returning requested value". It makes API much flexible for future extensions and the library will not export a next bunch of similar functions.
The question is how we can make much flexible the passing of these values from the configuration files. I think that we may use just a direct way between the "identifier" from the snd_use_case_get/set function and the configuration files, having syntax something like:
SectionDevice."Headphones".0 { ... Value."_ctl_/_pctlsw" "name='Master Playback Switch'" ... }
Note that we may talk about the API, identifier names etc.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
'Twas brillig, and Jaroslav Kysela at 21/09/10 19:11 did gyre and gimble:
I'm sorry to be silent in the last week, but the reason was quite simple - vacation. As my life goes, my second son was born and I decided to be with my family, so I was able to handle only really urgent things.
Call that an excuse??? Oh wait, it is actually a *very* good excuse :D
Congratulations to you and yours!
/me wonders if he was born with headphones already in his ears :p
Col
On Tue, Sep 21, 2010 at 08:11:35PM +0200, Jaroslav Kysela wrote:
There are two things and I think that we both talking about different ones.
- Which devices can be used simultaneously in the system (basically determining the number of handled streams).
- Physical output (or input) switching (I mean physical jacks etc.).
I don't want to add any complex manager. I just think that the UCM layer should give the information to the application which PCM streams can be used concurrently for a named card. Something like stream grouping.
This is what the snd_use_case_*_pcm() functions are all about - identifying which of the many available streams should be used for a given output stream. With modern mobile audio architectures the ability to route different kind of audio to different PCM streams is essential.
Now, it's true that it doesn't explicitly support grouping multiple PCMs together into a single use case which is probably a good extension to think about - perhaps returning arrays would cover it, though to be honest I'm not sure how often that'd get used (and I'd expect apps to fail to cope).
The problem is that you think in the "ASoC" way to handle just one input and output stream for phones etc. and I think in "multiple independant streams" per card way.
This is not the case at all. As I said previously the sort of systems that run ASoC already support pretty much all the use cases you have on PCs and then some to the point where PC audio requirements are generally noticably less complex than those for mobile platforms. PCs have much more regular hardware than the more complex embedded systems which helps a lot with software complexity.
I previously pointed you at the WM8994 as an example of the sort of device one sees in modern smartphones:
http://www.wolfsonmicro.com/products/WM8994
This supports many bidirectional audio streams, with two being delivered using TDM on one physical audio interface intended for connection to the CPU and a more complex routing arragement available on the other two physical audio interfaces for connection with the radios though it's also possible to connect additional links to the CPU if the application demands it.
These sorts of features aren't that new - even something several years old like the Marvell Zylonite reference platform offers multiple streams to the CPU.
This is really point why I switched from "many functions returning just values" to "one function with a universal string identifier returning requested value". It makes API much flexible for future extensions and the library will not export a next bunch of similar functions.
I think there's a balance here in interface complexity terms - there's value in having some structure provided by default with a more advanced interface for more general use. This provides some guidance and code simplification for basic use while providing room for more complex use cases.
The question is how we can make much flexible the passing of these values from the configuration files. I think that we may use just a direct way between the "identifier" from the snd_use_case_get/set function and the configuration files, having syntax something like:
There's some scaling issues that need to be dealt with - for example, if you're asking for the controls for an EQ you likely want to be able to get an array back with the per-band gains and possibly trimming options for the bands since there's quite a bit of range in the control offered by EQs. This means we will need to be able to return a variably sized set of controls.
SectionDevice."Headphones".0 { ... Value."_ctl_/_pctlsw" "name='Master Playback Switch'" ... }
This sort of thing is quite different to what you were suggesting previously and much less problematic.
On Wed, 22 Sep 2010, Mark Brown wrote:
On Tue, Sep 21, 2010 at 08:11:35PM +0200, Jaroslav Kysela wrote:
There are two things and I think that we both talking about different ones.
- Which devices can be used simultaneously in the system (basically determining the number of handled streams).
- Physical output (or input) switching (I mean physical jacks etc.).
I don't want to add any complex manager. I just think that the UCM layer should give the information to the application which PCM streams can be used concurrently for a named card. Something like stream grouping.
This is what the snd_use_case_*_pcm() functions are all about - identifying which of the many available streams should be used for a given output stream. With modern mobile audio architectures the ability to route different kind of audio to different PCM streams is essential.
But it's not possible to guess if streams are independant from the PCM device name. Some hardware has restrictions or driver can offer more PCM devices for one hardware (for example stereo only devices and multichannel devices sharing same hardware portion).
Now, it's true that it doesn't explicitly support grouping multiple PCMs together into a single use case which is probably a good extension to think about - perhaps returning arrays would cover it, though to be honest I'm not sure how often that'd get used (and I'd expect apps to fail to cope).
Maybe a simple extension to the current API might cover also this issue: Add a third state for devices and modifiers - "blocked". This state will be active when hardware has inter-device/modifier contraints or when another application uses hardware in the blocking way.
The question is how we can make much flexible the passing of these values from the configuration files. I think that we may use just a direct way between the "identifier" from the snd_use_case_get/set function and the configuration files, having syntax something like:
There's some scaling issues that need to be dealt with - for example, if you're asking for the controls for an EQ you likely want to be able to get an array back with the per-band gains and possibly trimming options for the bands since there's quite a bit of range in the control offered by EQs. This means we will need to be able to return a variably sized set of controls.
Sure, but you can describe this array in a string with some delimiters.
SectionDevice."Headphones".0 { ... Value."_ctl_/_pctlsw" "name='Master Playback Switch'" ... }
This sort of thing is quite different to what you were suggesting previously and much less problematic.
I just finished the implementation for all functions in my GIT tree (except card listing). Also, the "Value {}" section is implemented as I proposed - it means that users can pass any read-only values to the API user.
The code is not tested, I need to write a simple command line tool for testing the API and also move the control/mixer ID and value handling code from the alsa-utils/amixer utility to alsa-lib.
So, please, check the use-case.h again:
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/use-case.h;h=fd...
Note that this code is almost complete rewrite to use the kernel style lists (alsa-lib/include/list.h).
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Wed, Sep 22, 2010 at 04:06:56PM +0200, Jaroslav Kysela wrote:
On Wed, 22 Sep 2010, Mark Brown wrote:
This is what the snd_use_case_*_pcm() functions are all about - identifying which of the many available streams should be used for a given output stream. With modern mobile audio architectures the ability to route different kind of audio to different PCM streams is essential.
But it's not possible to guess if streams are independant from the PCM device name. Some hardware has restrictions or driver can offer more PCM devices for one hardware (for example stereo only devices and multichannel devices sharing same hardware portion).
That sounds like an annotation for...
Now, it's true that it doesn't explicitly support grouping multiple PCMs together into a single use case which is probably a good extension to think about - perhaps returning arrays would cover it, though to be honest I'm not sure how often that'd get used (and I'd expect apps to fail to cope).
Maybe a simple extension to the current API might cover also this issue: Add a third state for devices and modifiers - "blocked". This state will be active when hardware has inter-device/modifier contraints or when another application uses hardware in the blocking way.
...this, though I think the blocking concept is most likely a higher level one than UCM since there's a lot of of overlap between this and policy decisons about which outputs are active. It might be easier to implement blocking by setting up the use case with a /dev/null stream instead of a real one so applications don't need to cope, though obviously some things will want to know if their audio is being blackholed.
The question is how we can make much flexible the passing of these values from the configuration files. I think that we may use just a direct way between the "identifier" from the snd_use_case_get/set function and the configuration files, having syntax something like:
There's some scaling issues that need to be dealt with - for example, if you're asking for the controls for an EQ you likely want to be able to get an array back with the per-band gains and possibly trimming options for the bands since there's quite a bit of range in the control offered by EQs. This means we will need to be able to return a variably sized set of controls.
Sure, but you can describe this array in a string with some delimiters.
That's not going to be terribly pleasant as an API, though - I'd expect the library to have demangled the data before applications are expected to work with it. Otherwise you end up with lots of people implementing the same parsing code.
I just finished the implementation for all functions in my GIT tree (except card listing). Also, the "Value {}" section is implemented as I proposed - it means that users can pass any read-only values to the API user.
The code is not tested, I need to write a simple command line tool for testing the API and also move the control/mixer ID and value handling code from the alsa-utils/amixer utility to alsa-lib.
So, please, check the use-case.h again:
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/use-case.h;h=fd...
Random points since there's no patch to quote:
- For the list of known identifiers would it not make sense to just say that standard ALSA control names are used for things like Capture Volume? Just say something like "Use standard ALSA control names or one of the following additional things with an optional /modifier"
- For standard string identifiers it'd be nice to provide definitions to provide compile time checking for typos - if we just use strings then they'll only be noticed at runtime, if there's standard defines the build will fail if people use them with typos.
- As I said above I don't like the idea of returning just a string for _get() - if the string needs any sort of parsing to be intelligable we shouldn't be forcing users to do all that.
In general I'm nervous about the usability and robustness here; there's an awful lot of stuff getting passed around as strings which may or may not need parsing. This is much more of a concern for me on the output side than on the input side since it pushes complexity onto client code without any safety features at all and causes clients to have to implement very similar code to understand the more complex strings.
What might work here would be to use this as a core API for advanced users then layer on more specific APIs which make stronger guarantees about what comes back (eg, guaranteeing to return only a single control name). We could perhaps merge something like what you've got here and then add such features incrementally.
On Wed, 22 Sep 2010, Mark Brown wrote:
On Wed, Sep 22, 2010 at 04:06:56PM +0200, Jaroslav Kysela wrote:
On Wed, 22 Sep 2010, Mark Brown wrote:
This is what the snd_use_case_*_pcm() functions are all about - identifying which of the many available streams should be used for a given output stream. With modern mobile audio architectures the ability to route different kind of audio to different PCM streams is essential.
But it's not possible to guess if streams are independant from the PCM device name. Some hardware has restrictions or driver can offer more PCM devices for one hardware (for example stereo only devices and multichannel devices sharing same hardware portion).
That sounds like an annotation for...
Now, it's true that it doesn't explicitly support grouping multiple PCMs together into a single use case which is probably a good extension to think about - perhaps returning arrays would cover it, though to be honest I'm not sure how often that'd get used (and I'd expect apps to fail to cope).
Maybe a simple extension to the current API might cover also this issue: Add a third state for devices and modifiers - "blocked". This state will be active when hardware has inter-device/modifier contraints or when another application uses hardware in the blocking way.
...this, though I think the blocking concept is most likely a higher level one than UCM since there's a lot of of overlap between this and policy decisons about which outputs are active. It might be easier to implement blocking by setting up the use case with a /dev/null stream instead of a real one so applications don't need to cope, though obviously some things will want to know if their audio is being blackholed.
If the blocking state can be set only from the ucm code (not from an application), there is no policy. It's just a reflection about actual hardware state. Yours and other comments persuaded me that we should not apply any policy in the ucm level.
The question is how we can make much flexible the passing of these values from the configuration files. I think that we may use just a direct way between the "identifier" from the snd_use_case_get/set function and the configuration files, having syntax something like:
There's some scaling issues that need to be dealt with - for example, if you're asking for the controls for an EQ you likely want to be able to get an array back with the per-band gains and possibly trimming options for the bands since there's quite a bit of range in the control offered by EQs. This means we will need to be able to return a variably sized set of controls.
Sure, but you can describe this array in a string with some delimiters.
That's not going to be terribly pleasant as an API, though - I'd expect the library to have demangled the data before applications are expected to work with it. Otherwise you end up with lots of people implementing the same parsing code.
See bellow.
I just finished the implementation for all functions in my GIT tree (except card listing). Also, the "Value {}" section is implemented as I proposed - it means that users can pass any read-only values to the API user.
The code is not tested, I need to write a simple command line tool for testing the API and also move the control/mixer ID and value handling code from the alsa-utils/amixer utility to alsa-lib.
So, please, check the use-case.h again:
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/use-case.h;h=fd...
Random points since there's no patch to quote:
- For the list of known identifiers would it not make sense to just say that standard ALSA control names are used for things like Capture Volume? Just say something like "Use standard ALSA control names or one of the following additional things with an optional /modifier"
I don't have any trouble to use the usuall control naming. These rules must be documented somewhere, otherwise they might be useless. I made this information completely optional and the names are not fixed (my code does not look to these values at all).
- For standard string identifiers it'd be nice to provide definitions to provide compile time checking for typos - if we just use strings then they'll only be noticed at runtime, if there's standard defines the build will fail if people use them with typos.
It's a cosmetic issue - I think that I leave this change to someone other.
- As I said above I don't like the idea of returning just a string for _get() - if the string needs any sort of parsing to be intelligable we shouldn't be forcing users to do all that.
In general I'm nervous about the usability and robustness here; there's an awful lot of stuff getting passed around as strings which may or may not need parsing. This is much more of a concern for me on the output side than on the input side since it pushes complexity onto client code without any safety features at all and causes clients to have to implement very similar code to understand the more complex strings.
What might work here would be to use this as a core API for advanced users then layer on more specific APIs which make stronger guarantees about what comes back (eg, guaranteeing to return only a single control name). We could perhaps merge something like what you've got here and then add such features incrementally.
Basically, it's my idea. The major thing for ucm is the verb / device / modifier / transition handling and device listing. All other optional data might have many usages and it depends on the final purpose. So call strings like data containers. We can even carry XML or so if necessary :-)
Also, I plan to add to alsa-lib all parsers for the control ID, control value stuff, but to the right API - the control API (snd_ctl_*). So there is no requirement to implement these parsers in applications. The parsers will return standard structures like 'snd_ctl_elem_id_t' or so.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Wed, Sep 22, 2010 at 08:05:12PM +0200, Jaroslav Kysela wrote:
On Wed, 22 Sep 2010, Mark Brown wrote:
...this, though I think the blocking concept is most likely a higher level one than UCM since there's a lot of of overlap between this and policy decisons about which outputs are active. It might be easier to implement blocking by setting up the use case with a /dev/null stream instead of a real one so applications don't need to cope, though obviously some things will want to know if their audio is being blackholed.
If the blocking state can be set only from the ucm code (not from an application), there is no policy. It's just a reflection about actual hardware state. Yours and other comments persuaded me that we should not apply any policy in the ucm level.
OK, I think we agree here - my suggestion for using a /dev/null stream is just an example of something the policy level could configure in the UCM rather than UCM functionality.
Random points since there's no patch to quote:
- For the list of known identifiers would it not make sense to just say
that standard ALSA control names are used for things like Capture Volume? Just say something like "Use standard ALSA control names or one of the following additional things with an optional /modifier"
I don't have any trouble to use the usuall control naming. These rules must be documented somewhere, otherwise they might be useless. I made this information completely optional and the names are not fixed (my code does not look to these values at all).
Right, broadly agree but think we should be providing guidance to users otherwise the API might be overwhelming - look at the issues we have with selecting appropriate control names with the current APIs.
Basically, it's my idea. The major thing for ucm is the verb / device / modifier / transition handling and device listing. All other optional data might have many usages and it depends on the final purpose. So call strings like data containers. We can even carry XML or so if necessary :-)
I'm all for having the ability to annoate the use cases with other data but I do feel that this should be within a much more structured framework than is present here. However...
Also, I plan to add to alsa-lib all parsers for the control ID, control value stuff, but to the right API - the control API (snd_ctl_*). So there is no requirement to implement these parsers in applications. The parsers will return standard structures like 'snd_ctl_elem_id_t' or so.
...this is pretty much exactly what I was suggesting with layering on higher level APIs which provide more useful formats to users. I'm therefore not sure if this would actually be resolved or not. If we're going to have these more packaged APIs then it would probably be good to steer people away from the UCM API itself through a combination of documentation and API naming - make it clear that this is for advanced users and that for basic usage you're supposed to go via the simpler APIs.
Does that sound like a good plan to you?
Having looked at the implementation briefly I also note that you've kept the procedural specification of the control settings in your configuration file format. As I outlined previously I do have serious concerns about this as a model for users to work with (orthogonally to the actual implementation which must come down to a procedure at present due to the ALSA API, something I hope to provide features to avoid in the future).
If we make everything procedural now it will become much harder to back out of it later, and I would hope that one of the things that use case management can do is ensure that users only need to specify their goal states and don't need to deal with the mechanics of how to achieve them except in exceptional circumstances.
On Wed, Sep 22, 2010 at 11:48 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Having looked at the implementation briefly I also note that you've kept the procedural specification of the control settings in your configuration file format. As I outlined previously I do have serious concerns about this as a model for users to work with (orthogonally to the actual implementation which must come down to a procedure at present due to the ALSA API, something I hope to provide features to avoid in the future).
If we make everything procedural now it will become much harder to back out of it later, and I would hope that one of the things that use case management can do is ensure that users only need to specify their goal states and don't need to deal with the mechanics of how to achieve them except in exceptional circumstances.
I completely agree. This problem seems best solved by "logic programming" and ontologies describing both hardware capabilities, constraints, as well as the applications needs and requirements. Such problems tend to have multiple solutions and often require a way for constraints to be loosely, or multiply satisfied -- including asking the user after narrowing down the search space to just a few equally weighted choices (e.g. do i match the channel count of the source to the device by duplicating channels or sending blank channels?).
There is much literature and many industry solutions employing such simple "AI" techniques, and there's no reason why declarative programming capabilities couldn't be built into any C-based library -- e.g. http://clipsrules.sourceforge.net http://www.gprolog.org etc. Certainly, there is no need to "reinvent the wheel" hacking language constructs and concepts that already exist and have some formalisms behind them.
Example literature from a slightly different domain that could be applied here include: http://ebiquity.umbc.edu/get/a/publication/466.pdf ("Towards a Declarative Framework for Managing Application and Network Adaptations") .................. Abstract—Cross layer optimizations are increasingly being used in a variety of applications to improve application perfor- mance. However most of these implementations are ad hoc and performed on a per application basis. In this paper we propose a declarative framework for managing application and network adaptations. The declarative paradigm provides a much needed clean line of separation between the high level goals and the low level implementations. Our framework exposes the tunable features of both the application and the network across layers of the network stack which can then be jointly optimized. We allow operators to control the adaptation process through operator specified policies. [...] To support evolution, we pursue an ontological approach and use semantic web languages such as OWL and RDF in our framework for the policy and declarative specifications, thereby also leveraging the inherent reasoning and conflict resolution features of these languages. ... .....................
Nepomuk Desktop ontologies are relevant here as well: http://library.gnome.org/devel/ontology/unstable/nmm-ontology.html http://library.gnome.org/devel/ontology/unstable/nfo-ontology.html ... what's needed is similar ontologies abstractly describing hardware and providing the semantics of constraints on using the hardware -- whether it be locking semantics for concurrent or multiple access, bit depth or sample rate matching, etc. Thus the application constraints would need to match up against constraints posed by a "media hardware ontology." Solving the constraint problem between application and hardware may thus dynamically invoke sample-rate conversion, bit-depth conversion, channel duplication or reduction, stream mixing, etc.
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.
-- Niels http://nielsmayer.com
On Thu, Sep 23, 2010 at 12:18:33AM -0700, Niels Mayer wrote:
On Wed, Sep 22, 2010 at 11:48 AM, Mark Brown
If we make everything procedural now it will become much harder to back out of it later, and I would hope that one of the things that use case management can do is ensure that users only need to specify their goal states and don't need to deal with the mechanics of how to achieve them except in exceptional circumstances.
I completely agree. This problem seems best solved by "logic programming" and ontologies describing both hardware capabilities, constraints, as well as the applications needs and requirements. Such
A strong note of caution here: this is a very difficult task which nobody is currently attempting to do except for very constrained sets of systems such as standard PC hardware. Nothing anyone is discussing here involves the automatic generation of settings, it's all about how we manage sets of explicitly defined settings.
'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
On Wed, 2010-09-22 at 16:06 +0200, Jaroslav Kysela wrote:
I just finished the implementation for all functions in my GIT tree (except card listing). Also, the "Value {}" section is implemented as I proposed - it means that users can pass any read-only values to the API user.
Not had a good look yet, I assume all the functionality from the old API is preserved ?
The code is not tested, I need to write a simple command line tool for testing the API and also move the control/mixer ID and value handling code from the alsa-utils/amixer utility to alsa-lib.
Fwiw, there is some command line code for the old API that may be useful here :-
git://git.slimlogic.co.uk/alsa-utils.git ucm-upstream
Liam
participants (6)
-
Chris Winter -
Colin Guthrie -
Jaroslav Kysela -
Liam Girdwood -
Mark Brown -
Niels Mayer