* UCM questions @ 2011-01-20 22:06 pl bossart 2011-01-21 11:37 ` Mark Brown 0 siblings, 1 reply; 16+ messages in thread From: pl bossart @ 2011-01-20 22:06 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-20 22:06 UCM questions pl bossart @ 2011-01-21 11:37 ` Mark Brown 2011-01-21 15:12 ` pl bossart 2011-01-21 15:24 ` Liam Girdwood 0 siblings, 2 replies; 16+ messages in thread From: Mark Brown @ 2011-01-21 11:37 UTC (permalink / raw) To: pl bossart; +Cc: alsa-devel, lrg 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 11:37 ` Mark Brown @ 2011-01-21 15:12 ` pl bossart 2011-01-21 16:43 ` Mark Brown 2011-01-21 15:24 ` Liam Girdwood 1 sibling, 1 reply; 16+ messages in thread From: pl bossart @ 2011-01-21 15:12 UTC (permalink / raw) To: Mark Brown; +Cc: alsa-devel, lrg 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 15:12 ` pl bossart @ 2011-01-21 16:43 ` Mark Brown 2011-01-21 20:53 ` pl bossart 0 siblings, 1 reply; 16+ messages in thread From: Mark Brown @ 2011-01-21 16:43 UTC (permalink / raw) To: pl bossart; +Cc: alsa-devel, lrg 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 16:43 ` Mark Brown @ 2011-01-21 20:53 ` pl bossart 2011-01-21 23:37 ` Liam Girdwood ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: pl bossart @ 2011-01-21 20:53 UTC (permalink / raw) To: Mark Brown; +Cc: alsa-devel, lrg >> 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 20:53 ` pl bossart @ 2011-01-21 23:37 ` Liam Girdwood 2011-01-22 5:22 ` Raymond Yau 2011-01-23 0:41 ` Mark Brown 2011-01-23 13:49 ` Jaroslav Kysela 2 siblings, 1 reply; 16+ messages in thread From: Liam Girdwood @ 2011-01-21 23:37 UTC (permalink / raw) To: pl bossart; +Cc: alsa-devel, Mark Brown 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 23:37 ` Liam Girdwood @ 2011-01-22 5:22 ` Raymond Yau 0 siblings, 0 replies; 16+ messages in thread From: Raymond Yau @ 2011-01-22 5:22 UTC (permalink / raw) To: ALSA Development Mailing List 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" ? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 20:53 ` pl bossart 2011-01-21 23:37 ` Liam Girdwood @ 2011-01-23 0:41 ` Mark Brown 2011-01-23 13:49 ` Jaroslav Kysela 2 siblings, 0 replies; 16+ messages in thread From: Mark Brown @ 2011-01-23 0:41 UTC (permalink / raw) To: pl bossart; +Cc: alsa-devel, lrg 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 20:53 ` pl bossart 2011-01-21 23:37 ` Liam Girdwood 2011-01-23 0:41 ` Mark Brown @ 2011-01-23 13:49 ` Jaroslav Kysela 2 siblings, 0 replies; 16+ messages in thread From: Jaroslav Kysela @ 2011-01-23 13:49 UTC (permalink / raw) To: pl bossart; +Cc: alsa-devel, Mark Brown, lrg 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 11:37 ` Mark Brown 2011-01-21 15:12 ` pl bossart @ 2011-01-21 15:24 ` Liam Girdwood 2011-01-21 21:03 ` pl bossart 1 sibling, 1 reply; 16+ messages in thread From: Liam Girdwood @ 2011-01-21 15:24 UTC (permalink / raw) To: pl bossart; +Cc: alsa-devel, Mark Brown [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 15:24 ` Liam Girdwood @ 2011-01-21 21:03 ` pl bossart 2011-01-21 23:37 ` Liam Girdwood 2011-01-23 13:39 ` Jaroslav Kysela 0 siblings, 2 replies; 16+ messages in thread From: pl bossart @ 2011-01-21 21:03 UTC (permalink / raw) To: Liam Girdwood; +Cc: alsa-devel, Mark Brown > 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.. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 21:03 ` pl bossart @ 2011-01-21 23:37 ` Liam Girdwood 2011-01-23 13:39 ` Jaroslav Kysela 1 sibling, 0 replies; 16+ messages in thread From: Liam Girdwood @ 2011-01-21 23:37 UTC (permalink / raw) To: pl bossart; +Cc: alsa-devel, Mark Brown 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-21 21:03 ` pl bossart 2011-01-21 23:37 ` Liam Girdwood @ 2011-01-23 13:39 ` Jaroslav Kysela 2011-01-24 22:31 ` pl bossart 1 sibling, 1 reply; 16+ messages in thread From: Jaroslav Kysela @ 2011-01-23 13:39 UTC (permalink / raw) To: pl bossart; +Cc: ALSA development, Mark Brown, Liam Girdwood 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-23 13:39 ` Jaroslav Kysela @ 2011-01-24 22:31 ` pl bossart 2011-01-25 12:13 ` Liam Girdwood 0 siblings, 1 reply; 16+ messages in thread From: pl bossart @ 2011-01-24 22:31 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: ALSA development, Mark Brown, Liam Girdwood > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-24 22:31 ` pl bossart @ 2011-01-25 12:13 ` Liam Girdwood 2011-01-25 21:58 ` pl bossart 0 siblings, 1 reply; 16+ messages in thread From: Liam Girdwood @ 2011-01-25 12:13 UTC (permalink / raw) To: pl bossart; +Cc: ALSA development, Mark Brown 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: UCM questions 2011-01-25 12:13 ` Liam Girdwood @ 2011-01-25 21:58 ` pl bossart 0 siblings, 0 replies; 16+ messages in thread From: pl bossart @ 2011-01-25 21:58 UTC (permalink / raw) To: Liam Girdwood; +Cc: ALSA development, Mark Brown >> 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-01-25 21:58 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-01-20 22:06 UCM questions pl bossart 2011-01-21 11:37 ` Mark Brown 2011-01-21 15:12 ` pl bossart 2011-01-21 16:43 ` Mark Brown 2011-01-21 20:53 ` pl bossart 2011-01-21 23:37 ` Liam Girdwood 2011-01-22 5:22 ` Raymond Yau 2011-01-23 0:41 ` Mark Brown 2011-01-23 13:49 ` Jaroslav Kysela 2011-01-21 15:24 ` Liam Girdwood 2011-01-21 21:03 ` pl bossart 2011-01-21 23:37 ` Liam Girdwood 2011-01-23 13:39 ` Jaroslav Kysela 2011-01-24 22:31 ` pl bossart 2011-01-25 12:13 ` Liam Girdwood 2011-01-25 21:58 ` pl bossart
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.