[alsa-devel] UCM questions
Hello all, I've been looking at the UCM code in git://git.alsa-project.org/alsa-lib.git branch ucm. Looks both simple/powerfl/useful, still I have a couple of questions (most likely for Liam and Mark):
- how would a USB device be handled? An audio use case is defined by a verb and device parameter. My understanding is for a USB headset used for music playback, we would still use the 'HiFi' verb, but then we would need a 'USB' device added in include/use-case.h ? Then how would I make a difference between a USB headset and USB speakers? - same question for remote displays/display port. - how useful is the notion of 'card list'? Seems to me that the verbs are the main entry points, and the notion of card is abstracted away. For a given use case, the application can query the string containing the device name. Or I am misled and verbs are only related to a given card? - If I want to enable a camcorder use case, possibly with multiple microphones, do I still use the 'HiFi' verb? Or do we need a new verb for capture cases? I don't see any mics as capture devices hence the question. - how would IEC-formatted data be handled for HDMI/SPDIF? It could be a different physical device for PCM and IEC-formatted data, and you would need to enable IEC-related switches in the alsa controls. Or would a modifier be more appropriate to provide additional information on the content type? - has anyone generated a typical configuration file for USB and HDAudio? I only see an OMAP conf.
Thanks for your feedback -Pierre
On Thu, Jan 20, 2011 at 04:06:55PM -0600, pl bossart wrote:
Hello all, I've been looking at the UCM code in git://git.alsa-project.org/alsa-lib.git branch ucm. Looks both simple/powerfl/useful, still I have a couple of questions (most likely for Liam and Mark):
CCing in Liam so he sees this. Below are my initial thoughts but Liam can give better answers.
- how would a USB device be handled? An audio use case is defined by a
verb and device parameter. My understanding is for a USB headset used for music playback, we would still use the 'HiFi' verb, but then we would need a 'USB' device added in include/use-case.h ? Then how would
The device/use case names there are just defaults, systems can add their own. The default set of use cases and devices are likely to handle most cases but there's going to be a dependence on the system integration.
I make a difference between a USB headset and USB speakers?
You'd probably need to handle identifying the different classes USB devices in whatever owns the use case configuration for the system. I'm not sure that's been looked at in much detail, USB host support is fairly unusual in the embedded systems this targets.
- same question for remote displays/display port.
A similar thing applies here - I'd imagine many applications would make the decision to use a display output based partly on use case.
- how useful is the notion of 'card list'? Seems to me that the verbs
are the main entry points, and the notion of card is abstracted away. For a given use case, the application can query the string containing the device name. Or I am misled and verbs are only related to a given card?
- If I want to enable a camcorder use case, possibly with multiple
microphones, do I still use the 'HiFi' verb? Or do we need a new verb for capture cases? I don't see any mics as capture devices hence the question.
I'd suggest that'd either be the HiFi verb or a new verb.
- how would IEC-formatted data be handled for HDMI/SPDIF? It could be
a different physical device for PCM and IEC-formatted data, and you would need to enable IEC-related switches in the alsa controls. Or would a modifier be more appropriate to provide additional information on the content type?
I'd guess modifier.
- has anyone generated a typical configuration file for USB and
HDAudio? I only see an OMAP conf.
Someone asked this at LPC as well - my thought there is that probably PC systems would be happier trying to work without explicit use case configuration as they are currently.
Thanks Mark for your answers.
The device/use case names there are just defaults, systems can add their own. The default set of use cases and devices are likely to handle most cases but there's going to be a dependence on the system integration.
I am fine with a system-specific configuration file for each use case, but if I have to change the defines in alsa-lib it's a bit of a pain. It'll imply branches and specific packages just for a stupid include file.
I make a difference between a USB headset and USB speakers?
You'd probably need to handle identifying the different classes USB devices in whatever owns the use case configuration for the system. I'm not sure that's been looked at in much detail, USB host support is fairly unusual in the embedded systems this targets.
I am thinking netbooks and tablets where USB is more likely to be present. For handsets I am not sure.
- has anyone generated a typical configuration file for USB and
HDAudio? I only see an OMAP conf.
Someone asked this at LPC as well - my thought there is that probably PC systems would be happier trying to work without explicit use case configuration as they are currently.
Humm, not sure people are totally happy with audio on Linux PC systems... we still don't have a simple solution for routing/configuration/policy, UCM could provide simple hooks for users (or PulseAudio) to do what they do most, e.g for a voice call the headset is used while for movies the HDMI output is used. -Pierre
On Fri, Jan 21, 2011 at 09:12:51AM -0600, pl bossart wrote:
The device/use case names there are just defaults, systems can add their own. The default set of use cases and devices are likely to handle most cases but there's going to be a dependence on the system integration.
I am fine with a system-specific configuration file for each use case, but if I have to change the defines in alsa-lib it's a bit of a pain. It'll imply branches and specific packages just for a stupid include file.
If the define isn't there you should just be able to use a string - no need to update the header file unless the thing being added is sufficiently general that it seems like a good idea.
- has anyone generated a typical configuration file for USB and
HDAudio? I only see an OMAP conf.
Someone asked this at LPC as well - my thought there is that probably PC systems would be happier trying to work without explicit use case configuration as they are currently.
Humm, not sure people are totally happy with audio on Linux PC systems... we still don't have a simple solution for routing/configuration/policy, UCM could provide simple hooks for users (or PulseAudio) to do what they do most, e.g for a voice call the headset is used while for movies the HDMI output is used.
It's certainly useful for overriding the default behaviour - I'm more worried about the idea of using it for the default.
I am fine with a system-specific configuration file for each use case, but if I have to change the defines in alsa-lib it's a bit of a pain. It'll imply branches and specific packages just for a stupid include file.
If the define isn't there you should just be able to use a string - no need to update the header file unless the thing being added is sufficiently general that it seems like a good idea.
I think I am missing something here. First I believe there's only one application (PulseAudio or resource management of some sort) that will talk to UCM. Player applications shouldn't know anything about UCM, right? You would end-up making conflicting decisions. Next, if everyone can add #defines and craft new strings to represent verbs, this central application/module will either ask for use cases that are not supported everywhere, or limit itself to 'common' use cases. Or do we expect to rewrite this on each and every platform? Wouldn't it make sense to avoid branches and proliferation by limiting the definition of use cases and instead only allow for changes in configuration files?
On Fri, 2011-01-21 at 14:53 -0600, pl bossart wrote:
I am fine with a system-specific configuration file for each use case, but if I have to change the defines in alsa-lib it's a bit of a pain. It'll imply branches and specific packages just for a stupid include file.
If the define isn't there you should just be able to use a string - no need to update the header file unless the thing being added is sufficiently general that it seems like a good idea.
I think I am missing something here. First I believe there's only one application (PulseAudio or resource management of some sort) that will talk to UCM. Player applications shouldn't know anything about UCM, right? You would end-up making conflicting decisions.
Yes, it's intended only Pulseaudio (or similar) will directly control the use case.
Next, if everyone can add #defines and craft new strings to represent verbs, this central application/module will either ask for use cases that are not supported everywhere, or limit itself to 'common' use cases. Or do we expect to rewrite this on each and every platform? Wouldn't it make sense to avoid branches and proliferation by limiting the definition of use cases and instead only allow for changes in configuration files?
The intention is to add all the reasonable use case types to the ucm header. We should still support bespoke use cases, but we should aim to include as many popular use cases as possible in ucm. I was only thinking of phone related use cases when devising the original verbs.
Please do send a patch for any additional verbs you can think off :)
Thanks
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
2011/1/22 Liam Girdwood lrg@slimlogic.co.uk
On Fri, 2011-01-21 at 14:53 -0600, pl bossart wrote:
I am fine with a system-specific configuration file for each use case, but if I have to change the defines in alsa-lib it's a bit of a pain. It'll imply branches and specific packages just for a stupid include file.
If the define isn't there you should just be able to use a string - no need to update the header file unless the thing being added is sufficiently general that it seems like a good idea.
I think I am missing something here. First I believe there's only one application (PulseAudio or resource management of some sort) that will talk to UCM. Player applications shouldn't know anything about UCM, right? You would end-up making conflicting decisions.
Yes, it's intended only Pulseaudio (or similar) will directly control the use case.
Do you mean that I cannot use my desktop to act as a karaoke by playing music to default device and singing to the mic with "Mic Playback Volume" of HDA codec until pulseaudio or Sound preference implement "Mic Playback Volume" ?
On Fri, Jan 21, 2011 at 02:53:30PM -0600, pl bossart wrote:
In addition to what Liam said...
Next, if everyone can add #defines and craft new strings to represent verbs, this central application/module will either ask for use cases that are not supported everywhere, or limit itself to 'common' use cases. Or do we expect to rewrite this on each and every platform?
Given the amount of OS integration involved and the way people do these things I'd imagine that the actual decision making module is probably going to be very OS specific - there's so much other infrastructure to hook into and so much variation in what that looks like that we will need to cope with random use cases being defined by the system. Making the values strings was largely a recognition of that, it means that people don't need to patch UCM if they want to go and do their own thing. This all makes it easier to adopt UCM and deploy new use cases.
Wouldn't it make sense to avoid branches and proliferation by limiting the definition of use cases and instead only allow for changes in configuration files?
I'm not 100% sure I'm parsing this correctly but if you're suggesting explicitly enumerating all use cases in the code I suspect you'd just see system integrators patching locally or abusing predefined use cases they don't currently need rather than working upstream to integrate their use cases. Distros and so on who need to work over a wide range of devices are more likely to be affected, I think the most effective thing for them is going to be to keep the standard repository of use case definitions actively maintained so that there's something for effort to coalesce around.
On Fri, 21 Jan 2011, pl bossart wrote:
I am fine with a system-specific configuration file for each use case, but if I have to change the defines in alsa-lib it's a bit of a pain. It'll imply branches and specific packages just for a stupid include file.
If the define isn't there you should just be able to use a string - no need to update the header file unless the thing being added is sufficiently general that it seems like a good idea.
I think I am missing something here. First I believe there's only one application (PulseAudio or resource management of some sort) that will talk to UCM. Player applications shouldn't know anything about UCM, right?
Because UCM (as another level on top of standard devices) nicely handles the mixer/pcm issues (volume control, signal routing, signal parameters), I would assue that this layer might be used everywhere.
You would end-up making conflicting decisions.
This is something which should be improved in the future UCM code updates. The UCM code should return an error and reduce returned UCM lists if another application uses some conflicting resources.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Fri, 2011-01-21 at 11:37 +0000, Mark Brown wrote:
On Thu, Jan 20, 2011 at 04:06:55PM -0600, pl bossart wrote:
Hello all, I've been looking at the UCM code in git://git.alsa-project.org/alsa-lib.git branch ucm. Looks both simple/powerfl/useful, still I have a couple of questions (most likely for Liam and Mark):
CCing in Liam so he sees this. Below are my initial thoughts but Liam can give better answers.
Adding to Mark's answers below.
- how would a USB device be handled? An audio use case is defined by a
verb and device parameter. My understanding is for a USB headset used for music playback, we would still use the 'HiFi' verb, but then we would need a 'USB' device added in include/use-case.h ? Then how would
The device/use case names there are just defaults, systems can add their own. The default set of use cases and devices are likely to handle most cases but there's going to be a dependence on the system integration.
I make a difference between a USB headset and USB speakers?
You'd probably need to handle identifying the different classes USB devices in whatever owns the use case configuration for the system. I'm not sure that's been looked at in much detail, USB host support is fairly unusual in the embedded systems this targets.
- same question for remote displays/display port.
A similar thing applies here - I'd imagine many applications would make the decision to use a display output based partly on use case.
As Mark says the applications would make the decision here based on use case and UCM could provide the correct PCM source and sink device and hw volume to use in each use case.
Fwiw, the USB and display port examples above are also fairly trivial wrt internal audio routing within their hardware. They should not really require any internal hardware routing support from UCM (as they likely both have direct path from DAC to transducer), but I expect they will have any PCM data routing performed in software by Pulseaudio (based on any Pulseaudio policy/configuration).
- how useful is the notion of 'card list'? Seems to me that the verbs
are the main entry points, and the notion of card is abstracted away. For a given use case, the application can query the string containing the device name. Or I am misled and verbs are only related to a given card?
Originally, verbs were mapped 1:1 with cards, however Jaroslav recently added support for multiple cards per verb.
- If I want to enable a camcorder use case, possibly with multiple
microphones, do I still use the 'HiFi' verb? Or do we need a new verb for capture cases? I don't see any mics as capture devices hence the question.
I'd suggest that'd either be the HiFi verb or a new verb.
Probably a "Camcorder" verb, with the Mics as it's devices.
- how would IEC-formatted data be handled for HDMI/SPDIF? It could be
a different physical device for PCM and IEC-formatted data, and you would need to enable IEC-related switches in the alsa controls. Or would a modifier be more appropriate to provide additional information on the content type?
I'd guess modifier.
- has anyone generated a typical configuration file for USB and
HDAudio? I only see an OMAP conf.
Someone asked this at LPC as well - my thought there is that probably PC systems would be happier trying to work without explicit use case configuration as they are currently.
I've attached a more recent configuration example. This shows all the configurations options, albeit with dummy values.
Liam
Originally, verbs were mapped 1:1 with cards, however Jaroslav recently added support for multiple cards per verb.
Does this mean for a given verb UCM will return a list of devices on different cards that can be used, and the application will choose from the list? Or are these multiple cards supposed to be used simultaneously? I probably need more expresso here..
On Fri, 2011-01-21 at 15:03 -0600, pl bossart wrote:
Originally, verbs were mapped 1:1 with cards, however Jaroslav recently added support for multiple cards per verb.
Does this mean for a given verb UCM will return a list of devices on different cards that can be used, and the application will choose from the list?
UCM does return the appropriate sink and source PCM device for the given use case if required. e.g the OMAP4 has multiple PCM devices, some are for high quality hifi whilst others are lower power tones.
Or are these multiple cards supposed to be used simultaneously? I probably need more expresso here..
It's to allow multiple cards to be used simultaneously, e.g. a use case could also involve aspects of two sound cards, maybe one for capture and the other for playback.
Liam
On Fri, 21 Jan 2011, pl bossart wrote:
Originally, verbs were mapped 1:1 with cards, however Jaroslav recently added support for multiple cards per verb.
Does this mean for a given verb UCM will return a list of devices on different cards that can be used, and the application will choose from the list? Or are these multiple cards supposed to be used simultaneously? I probably need more expresso here..
You may have for example USB microphone and USB speakers plugged to the system (each represents one card for the ALSA driver with different USB physical links). UCM can join these two cards as one "virtual", so if an app asks for playback device, USB speakers are returned and for capture device, USB MIC is returned. Only one alsa-lib's device should be returned for given verb/device/modifier identifiers. I admit that the PCM configuration for alsa-lib allows this too, but UCM handles also the mixer control mapping.
Anyway, your questions are mostly about the abstract mapping. The purpose of UCM is to allow any abstraction, so strings in the header file like "HiFi" or so are just common cases. But anyone can create own abstraction for different purposes.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
You may have for example USB microphone and USB speakers plugged to the system (each represents one card for the ALSA driver with different USB physical links). UCM can join these two cards as one "virtual", so if an app asks for playback device, USB speakers are returned and for capture device, USB MIC is returned. Only one alsa-lib's device should be returned for given verb/device/modifier identifiers. I admit that the PCM configuration for alsa-lib allows this too, but UCM handles also the mixer control mapping.
Makes sense now.
Anyway, your questions are mostly about the abstract mapping. The purpose of UCM is to allow any abstraction, so strings in the header file like "HiFi" or so are just common cases. But anyone can create own abstraction for different purposes.
Most of my questions are not really on the abstraction but really on how to handle devices that can be plugged or may not be active at all times. USB, HDMI, Wireless/remote displays fall in this category. So on top of the traditional local headset/speakers, I can either have a variety of devices that can be used for the same use case. It's still not clear to me if I would need to create a set of new verbs (hifi_usb, hifi_hdmi) or if I can stick to the existing verbs and add a modifier? Thanks for your comments, -Pierre
On Mon, 2011-01-24 at 14:31 -0800, pl bossart wrote:
Most of my questions are not really on the abstraction but really on how to handle devices that can be plugged or may not be active at all times. USB, HDMI, Wireless/remote displays fall in this category. So on top of the traditional local headset/speakers, I can either have a variety of devices that can be used for the same use case. It's still not clear to me if I would need to create a set of new verbs (hifi_usb, hifi_hdmi) or if I can stick to the existing verbs and add a modifier?
You should stick to the existing verb and use a new device in most cases above where your use case is the same but the output device is different.
Thanks
Liam
Most of my questions are not really on the abstraction but really on how to handle devices that can be plugged or may not be active at all times. USB, HDMI, Wireless/remote displays fall in this category. So on top of the traditional local headset/speakers, I can either have a variety of devices that can be used for the same use case. It's still not clear to me if I would need to create a set of new verbs (hifi_usb, hifi_hdmi) or if I can stick to the existing verbs and add a modifier?
You should stick to the existing verb and use a new device in most cases above where your use case is the same but the output device is different.
ok, thanks for clarifying.
participants (5)
-
Jaroslav Kysela -
Liam Girdwood -
Mark Brown -
pl bossart -
Raymond Yau