UCM questions

UCM questions

[pl bossart]

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

Re: UCM questions

[Mark Brown]

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.

Re: UCM questions

[pl bossart]

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

Re: UCM questions

[Liam Girdwood]

[-- Attachment #1: Type: text/plain, Size: 3766 bytes --]

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

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

[-- Attachment #2: hifi --]
[-- Type: text/x-tex, Size: 2596 bytes --]

# Example Use case verb section for HiFi music e.g. MP3 playback
# By Joe Blogs <joe@blogs.com>

SectionVerb {
  	
	# enable and disable sequences are compulsory
  	EnableSequence [
		
		#set the cdev for the following cset ops.
		cdev "hw:AudioPCI"
		cset "name='PCM Volume' 5,5"

		# run this command when we are finished
		exec "ls -l"
	]

	DisableSequence [
		cdev "hw:AudioPCI"
		cset "name='PCM Volume' 15,15"
	]

	# Optional QoS and ALSA PCMs
	TQ HiFi
	CapturePCM "hw:0,0"
	PlaybackPCM "hw:0,0"
}

SectionDevice."Headphones".0 {
	
	EnableSequence [
		cdev "hw:AudioPCI"
		cset "name='PCM Capture Switch' 1,1"
	]

	DisableSequence [
		cdev "hw:AudioPCI"
		cset "name='PCM Capture Switch' 0,0"
	]

	# the hardware volume controls for this device
	PlaybackVolume "name='Master Playback Volume',index=2"
	PlaybackSwitch "name='Master Playback Switch',index=2"
}

SectionDevice."Headset".0 {
	Comment "Blah Blah"
	EnableSequence [
		cdev "hw:AudioPCI"
		cset "name='PCM Capture Route' 1,1,1,1"
	]

	DisableSequence [
		cdev "hw:AudioPCI"
		cset "name='PCM Capture Route' 0,0,0,0"
	]

	# the hardware volume controls for this device
	PlaybackVolume "name='Master Playback Volume',index=2"
	PlaybackSwitch "name='Master Playback Switch',index=2"
}

SectionModifier."PlayTone".0 {
	Comment "Play tone to handset during music playback"
	SupportedDevice [
		"Headset.0"
	]

	EnableSequence [
		cdev "hw:AudioPCI"
		cset "name='Master Mono Playback Switch' 1"
		exec "echo pt headset"
	]

	DisableSequence [
		cdev "hw:AudioPCI"
		cset "name='Master Mono Playback Switch' 0"
	]

	# the PCM source for this modifier
	CapturePCM "hw:0,2"

	# the hardware volume controls for this device
	PlaybackVolume "name='Master Playback Volume',index=2"
	PlaybackSwitch "name='Master Playback Switch',index=2"
}

SectionDevice."Headset".1 {
	
	EnableSequence [
		cdev "hw:AudioPCI"
		cset "name='PCM Capture Route' 1,1,1,1"
	]

	DisableSequence [
		cdev "hw:AudioPCI"
		cset "name='PCM Capture Route' 0,0,0,0"
	]

	PlaybackVolume "name='Master Playback Volume',index=2"
	PlaybackSwitch "name='Master Playback Switch',index=2"
}

SectionModifier."PlayTone".1 {
	Comment "Play tone to headphones and ahndset during music playback"
	SupportedDevice [
		"Headphones.0"
	]

	EnableSequence [
		cdev "hw:AudioPCI"
		cset "name='Master Mono Playback Volume' 2"
		exec "echo pt headphones"
	]

	DisableSequence [
		cdev "hw:AudioPCI"
		cset "name='Master Mono Playback Volume' 0"
	]

	PlaybackPCM "hw:0,2"
	PlaybackVolume "name='Master Playback Volume',index=2"
	PlaybackSwitch "name='Master Playback Switch',index=2"
}


[-- Attachment #3: AudioPCI.conf --]
[-- Type: text/plain, Size: 492 bytes --]

SectionUseCase."HiFi" {
 		File "hifi"
 		Comment "Play and record HiFi quality Music."
}

# This file also store the default sound card state.

SectionDefaults [
cdev "hw:AudioPCI"
cset "name='Master Playback Switch' 1,1"
cset "name='Master Playback Volume' 10,25"
cset "name='Master Mono Playback Switch' 0"
cset "name='Master Mono Playback Volume' 0"
cset "name='PCM Switch' 1,1"
cset "name='PCM Volume' 25,25"
cset "name='PCM Playback Switch' 1,1"
cset "name='PCM Capture Switch' 0,0"
]


[-- Attachment #4: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: UCM questions

[Mark Brown]

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.

Re: UCM questions

[pl bossart]

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

Re: UCM questions

[pl bossart]

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

Re: UCM questions

[Liam Girdwood]

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

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: UCM questions

[Liam Girdwood]

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

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: UCM questions

[Raymond Yau]

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

Re: UCM questions

[Mark Brown]

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.

Re: UCM questions

[Jaroslav Kysela]

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.

Re: UCM questions

[Jaroslav Kysela]

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.

Re: UCM questions

[pl bossart]

> 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

Re: UCM questions

[Liam Girdwood]

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
 
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: UCM questions

[pl bossart]

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