* RFC: ice1712 virtual devices @ 2009-10-29 17:48 Arno Schuring 2009-10-30 0:36 ` Raymond Yau 2009-10-30 9:23 ` Alan Horstmann 0 siblings, 2 replies; 8+ messages in thread From: Arno Schuring @ 2009-10-29 17:48 UTC (permalink / raw) To: alsa-devel Hello list, This is basically a resend of http://thread.gmane.org/gmane.linux.alsa.devel/59481/focus=59672 , which fixed the front: device of ice1712 cards to accept two-channel input. Currently, the front: device is exposed through the route plugin, which requires all clients to mmap all 10 channels, even though the front device is supposed to be a stereo device. This patch changes the front: device definition such that it matches the definition of iec958 in the same file. Additionally, I'm tempted to remove the surround* definitions because the chip does not really offer surround-style multichannel: it basically just offers multiple stereo channels, and does not provide any channel mapping beyond stereo. Finally, I'm also experimenting with the dshare plugin to allow applications to access the iec958: and front: devices simultaneously. Can anyone point me to a working example for this? From reading the alsa-lib documentation, it is not clear to me how I should nest the different plugins. Many thanks, Arno Schuring -- diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf index 01e50d2..d7acb81 100644 --- a/src/conf/cards/ICE1712.conf +++ b/src/conf/cards/ICE1712.conf @@ -32,12 +32,28 @@ ICE1712.pcm.front.0 { @args.CARD { type string } - type route - ttable.0.0 1 - ttable.1.1 1 - slave.pcm { - type hw - card $CARD + type asym + playback.pcm { + type route + ttable.0.0 1 + ttable.1.1 1 + slave.pcm { + type hw + card $CARD + } + slave.format S32_LE + slave.channels 10 + } + capture.pcm { + type route + ttable.0.0 1 + ttable.1.1 1 + slave.pcm { + type hw + card $CARD + } + slave.format S32_LE + slave.channels 12 } } ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: RFC: ice1712 virtual devices 2009-10-29 17:48 RFC: ice1712 virtual devices Arno Schuring @ 2009-10-30 0:36 ` Raymond Yau 2009-10-30 9:23 ` Alan Horstmann 1 sibling, 0 replies; 8+ messages in thread From: Raymond Yau @ 2009-10-30 0:36 UTC (permalink / raw) To: alsa-devel In the past when dmix is used , default device is defined in those .conf for each card. i.e. front device is not used for capturing. e.g. emu10k1 has special hook for playback with the front device and those hook should not be used for capture. 2009/10/30 Arno Schuring <aelschuring@hotmail.com> > Hello list, > > This is basically a resend of > http://thread.gmane.org/gmane.linux.alsa.devel/59481/focus=59672 , which > fixed the front: device of ice1712 cards to accept two-channel input. > Currently, the front: device is exposed through the route plugin, which > requires all clients to mmap all 10 channels, even though the front > device is supposed to be a stereo device. > > This patch changes the front: device definition such that it matches the > definition of iec958 in the same file. Additionally, I'm tempted to > remove the surround* definitions because the chip does not really offer > surround-style multichannel: it basically just offers multiple stereo > channels, and does not provide any channel mapping beyond stereo. > > Finally, I'm also experimenting with the dshare plugin to allow > applications to access the iec958: and front: devices simultaneously. > Can anyone point me to a working example for this? From reading the > alsa-lib documentation, it is not clear to me how I should nest the > different plugins. > > > Many thanks, > Arno Schuring > > > -- > > diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf > index 01e50d2..d7acb81 100644 > --- a/src/conf/cards/ICE1712.conf > +++ b/src/conf/cards/ICE1712.conf > @@ -32,12 +32,28 @@ ICE1712.pcm.front.0 { > @args.CARD { > type string > } > - type route > - ttable.0.0 1 > - ttable.1.1 1 > - slave.pcm { > - type hw > - card $CARD > + type asym > + playback.pcm { > + type route > + ttable.0.0 1 > + ttable.1.1 1 > + slave.pcm { > + type hw > + card $CARD > + } > + slave.format S32_LE > + slave.channels 10 > + } > + capture.pcm { > + type route > + ttable.0.0 1 > + ttable.1.1 1 > + slave.pcm { > + type hw > + card $CARD > + } > + slave.format S32_LE > + slave.channels 12 > } > } > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: ice1712 virtual devices 2009-10-29 17:48 RFC: ice1712 virtual devices Arno Schuring 2009-10-30 0:36 ` Raymond Yau @ 2009-10-30 9:23 ` Alan Horstmann 2009-10-30 11:29 ` Arno Schuring 2009-11-08 10:38 ` Takashi Iwai 1 sibling, 2 replies; 8+ messages in thread From: Alan Horstmann @ 2009-10-30 9:23 UTC (permalink / raw) To: Arno Schuring; +Cc: Takashi Iwai, ALSA devel On Thursday 29 October 2009 17:48, Arno Schuring wrote: > This is basically a resend of > http://thread.gmane.org/gmane.linux.alsa.devel/59481/focus=59672 , which > fixed the front: device of ice1712 cards to accept two-channel input. > Currently, the front: device is exposed through the route plugin, which > requires all clients to mmap all 10 channels, even though the front > device is supposed to be a stereo device. > > This patch changes the front: device definition such that it matches the > definition of iec958 in the same file. Additionally, I'm tempted to > remove the surround* definitions because the chip does not really offer > surround-style multichannel: it basically just offers multiple stereo > channels, and does not provide any channel mapping beyond stereo. > > Finally, I'm also experimenting with the dshare plugin to allow > applications to access the iec958: and front: devices simultaneously. > Can anyone point me to a working example for this? From reading the > alsa-lib documentation, it is not clear to me how I should nest the > different plugins. > > > Many thanks, > Arno Schuring > > > -- > > diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf > index 01e50d2..d7acb81 100644 > --- a/src/conf/cards/ICE1712.conf > +++ b/src/conf/cards/ICE1712.conf > @@ -32,12 +32,28 @@ ICE1712.pcm.front.0 { > @args.CARD { > type string > } > - type route > - ttable.0.0 1 > - ttable.1.1 1 > - slave.pcm { > - type hw > - card $CARD > + type asym > + playback.pcm { > + type route > + ttable.0.0 1 > + ttable.1.1 1 > + slave.pcm { > + type hw > + card $CARD > + } > + slave.format S32_LE > + slave.channels 10 > + } > + capture.pcm { > + type route > + ttable.0.0 1 > + ttable.1.1 1 > + slave.pcm { > + type hw > + card $CARD > + } > + slave.format S32_LE > + slave.channels 12 > } > } Bear in mind that the ice1712 has been used on a number of very different audio products aimed at different markets, from pro audio recording (DSP2000, Delta1010) to desktop multi-media (DMX6fire, Aureon7.1) and so the 'best' solution in each can be different. In the discussion you quoted, I suggested leaving the sample conversion out of the above definition of 'front', as unwanted conversion is always bad. If needed, use plug:front. The other issue is that capture from 'front' does not make sense on all products. The DMX6fire has a differnt routing, with CD, line & phone inputs. A configuration for this unit would not suit the others. So the most general approach is needed. Certainly adding the asym and slave parts to 'front' definition would be helpful in all cases IMO, as I proposed then, but preferably not format conversion. Alan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: ice1712 virtual devices 2009-10-30 9:23 ` Alan Horstmann @ 2009-10-30 11:29 ` Arno Schuring 2009-11-08 10:38 ` Takashi Iwai 1 sibling, 0 replies; 8+ messages in thread From: Arno Schuring @ 2009-10-30 11:29 UTC (permalink / raw) To: ALSA devel [ I've trimmed the CC-list. Please let me know if the list policy requires that I keep everybody personally CC'ed ] Alan, Raymond, Thanks for your comments. I'll remove the format conversion, and front: will be a playback-only device. I do have to leave in the channel conversion, otherwise front: will still require a 10-channel input. Revised patch is at the bottom. Alan Horstmann wrote: [...] > > Bear in mind that the ice1712 has been used on a number of very different > audio products aimed at different markets, from pro audio recording (DSP2000, > Delta1010) to desktop multi-media (DMX6fire, Aureon7.1) and so the 'best' > solution in each can be different. Ouch. Should have seen that one coming :) Ok, since at least the Aureon series do have defined surround-channels, I will leave them in. Is there a particular reason why surround71 is missing, or can I add it safely to the config? >> Finally, I'm also experimenting with the dshare plugin to allow >> applications to access the iec958: and front: devices simultaneously. >> Can anyone point me to a working example for this? From reading the >> alsa-lib documentation, it is not clear to me how I should nest the >> different plugins. I've come a little further with this now, and I can get simultaneous output on both front: and iec958: devices. There is just one issue left, I can't find a way to let the hooks plugin play nicely with the dshare plugin. My current config looks like this: ICE1712.pcm.iec958.0 { type asym playback.pcm { type hooks slave.pcm { type dshare ipc_key 10203 #testing only slave.pcm { type hw card $CARD } slave.channels 10 bindings { 0 8 1 9 } } #hooks.0 { #type ctl_elems #hook_args [ #{ #interface PCM #name "IEC958 Playback PCM Stream" #lock true #preserve true #value [ $AES0 $AES1 $AES2 $AES3 ] #} #] #} If I enable the hooks.0 section, I get the following error from aplay: aschuring@neminis:~$ aplay -v -D iec958:0 alsa/Noise.wav ALSA lib pcm_hooks.c:678:(_snd_pcm_hook_ctl_elems_install) No card for this PCM aplay: main:608: audio open error: Invalid argument And if I change the nesting order for hooks and dshare, I get the following: aschuring@neminis:~$ aplay -v -D plug:iec958:0 alsa/Noise.wav ALSA lib pcm_dshare.c:711:(snd_pcm_dshare_open) dshare plugin can be only connected to hw plugin Segmentation fault I'm really not familiar with the ctl_elems hook, and I'm hoping that there is a simple fix by changing the parameters for it. Can anyone point me in the right direction? Thanks again, Arno -- diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf index 01e50d2..1cd3773 100644 --- a/src/conf/cards/ICE1712.conf +++ b/src/conf/cards/ICE1712.conf @@ -32,12 +32,16 @@ ICE1712.pcm.front.0 { @args.CARD { type string } - type route - ttable.0.0 1 - ttable.1.1 1 - slave.pcm { - type hw - card $CARD + type asym + playback.pcm { + type route + ttable.0.0 1 + ttable.1.1 1 + slave.pcm { + type hw + card $CARD + } + slave.channels 10 } } ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: RFC: ice1712 virtual devices 2009-10-30 9:23 ` Alan Horstmann 2009-10-30 11:29 ` Arno Schuring @ 2009-11-08 10:38 ` Takashi Iwai 2009-11-08 21:13 ` Alan Horstmann 1 sibling, 1 reply; 8+ messages in thread From: Takashi Iwai @ 2009-11-08 10:38 UTC (permalink / raw) To: Alan Horstmann; +Cc: ALSA devel, Arno Schuring At Fri, 30 Oct 2009 09:23:37 +0000, Alan Horstmann wrote: > > On Thursday 29 October 2009 17:48, Arno Schuring wrote: > > This is basically a resend of > > http://thread.gmane.org/gmane.linux.alsa.devel/59481/focus=59672 , which > > fixed the front: device of ice1712 cards to accept two-channel input. > > Currently, the front: device is exposed through the route plugin, which > > requires all clients to mmap all 10 channels, even though the front > > device is supposed to be a stereo device. > > > > This patch changes the front: device definition such that it matches the > > definition of iec958 in the same file. Additionally, I'm tempted to > > remove the surround* definitions because the chip does not really offer > > surround-style multichannel: it basically just offers multiple stereo > > channels, and does not provide any channel mapping beyond stereo. > > > > Finally, I'm also experimenting with the dshare plugin to allow > > applications to access the iec958: and front: devices simultaneously. > > Can anyone point me to a working example for this? From reading the > > alsa-lib documentation, it is not clear to me how I should nest the > > different plugins. > > > > > > Many thanks, > > Arno Schuring > > > > > > -- > > > > diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf > > index 01e50d2..d7acb81 100644 > > --- a/src/conf/cards/ICE1712.conf > > +++ b/src/conf/cards/ICE1712.conf > > @@ -32,12 +32,28 @@ ICE1712.pcm.front.0 { > > @args.CARD { > > type string > > } > > - type route > > - ttable.0.0 1 > > - ttable.1.1 1 > > - slave.pcm { > > - type hw > > - card $CARD > > + type asym > > + playback.pcm { > > + type route > > + ttable.0.0 1 > > + ttable.1.1 1 > > + slave.pcm { > > + type hw > > + card $CARD > > + } > > + slave.format S32_LE > > + slave.channels 10 > > + } > > + capture.pcm { > > + type route > > + ttable.0.0 1 > > + ttable.1.1 1 > > + slave.pcm { > > + type hw > > + card $CARD > > + } > > + slave.format S32_LE > > + slave.channels 12 > > } > > } > > Bear in mind that the ice1712 has been used on a number of very different > audio products aimed at different markets, from pro audio recording (DSP2000, > Delta1010) to desktop multi-media (DMX6fire, Aureon7.1) and so the 'best' > solution in each can be different. > > In the discussion you quoted, I suggested leaving the sample conversion out of > the above definition of 'front', as unwanted conversion is always bad. If > needed, use plug:front. > > The other issue is that capture from 'front' does not make sense on all > products. The DMX6fire has a differnt routing, with CD, line & phone inputs. > A configuration for this unit would not suit the others. So the most general > approach is needed. > > Certainly adding the asym and slave parts to 'front' definition would be > helpful in all cases IMO, as I proposed then, but preferably not format > conversion. I agree that the capture from "front" PCM isn't considered as valid. The "front", "rear", "center_lfe" definitions are rather for multi-channel playbacks. The capture on these channels aren't useful in most cases. thanks, Takashi ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: ice1712 virtual devices 2009-11-08 10:38 ` Takashi Iwai @ 2009-11-08 21:13 ` Alan Horstmann 2009-11-16 19:32 ` Arno Schuring 0 siblings, 1 reply; 8+ messages in thread From: Alan Horstmann @ 2009-11-08 21:13 UTC (permalink / raw) To: Takashi Iwai; +Cc: ALSA devel On Sunday 08 November 2009 10:38, you wrote: > At Fri, 30 Oct 2009 09:23:37 +0000, > > Alan Horstmann wrote: > > On Thursday 29 October 2009 17:48, Arno Schuring wrote: > > > This is basically a resend of > > > http://thread.gmane.org/gmane.linux.alsa.devel/59481/focus=59672 , > > > which fixed the front: device of ice1712 cards to accept two-channel > > > input. Currently, the front: device is exposed through the route > > > plugin, which requires all clients to mmap all 10 channels, even though > > > the front device is supposed to be a stereo device. > > > > > > This patch changes the front: device definition such that it matches > > > the definition of iec958 in the same file. Additionally, I'm tempted to > > > remove the surround* definitions because the chip does not really offer > > > surround-style multichannel: it basically just offers multiple stereo > > > channels, and does not provide any channel mapping beyond stereo. > > > > > > Finally, I'm also experimenting with the dshare plugin to allow > > > applications to access the iec958: and front: devices simultaneously. > > > Can anyone point me to a working example for this? From reading the > > > alsa-lib documentation, it is not clear to me how I should nest the > > > different plugins. > > > > > > > > > Many thanks, > > > Arno Schuring > > > > > > > > > -- > > > > > > diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf > > > index 01e50d2..d7acb81 100644 > > > --- a/src/conf/cards/ICE1712.conf > > > +++ b/src/conf/cards/ICE1712.conf > > > @@ -32,12 +32,28 @@ ICE1712.pcm.front.0 { > > > @args.CARD { > > > type string > > > } > > > - type route > > > - ttable.0.0 1 > > > - ttable.1.1 1 > > > - slave.pcm { > > > - type hw > > > - card $CARD > > > + type asym > > > + playback.pcm { > > > + type route > > > + ttable.0.0 1 > > > + ttable.1.1 1 > > > + slave.pcm { > > > + type hw > > > + card $CARD > > > + } > > > + slave.format S32_LE > > > + slave.channels 10 > > > + } > > > + capture.pcm { > > > + type route > > > + ttable.0.0 1 > > > + ttable.1.1 1 > > > + slave.pcm { > > > + type hw > > > + card $CARD > > > + } > > > + slave.format S32_LE > > > + slave.channels 12 > > > } > > > } > > > > Bear in mind that the ice1712 has been used on a number of very different > > audio products aimed at different markets, from pro audio recording > > (DSP2000, Delta1010) to desktop multi-media (DMX6fire, Aureon7.1) and so > > the 'best' solution in each can be different. > > > > In the discussion you quoted, I suggested leaving the sample conversion > > out of the above definition of 'front', as unwanted conversion is always > > bad. If needed, use plug:front. > > > > The other issue is that capture from 'front' does not make sense on all > > products. The DMX6fire has a differnt routing, with CD, line & phone > > inputs. A configuration for this unit would not suit the others. So the > > most general approach is needed. > > > > Certainly adding the asym and slave parts to 'front' definition would be > > helpful in all cases IMO, as I proposed then, but preferably not format > > conversion. > > I agree that the capture from "front" PCM isn't considered as valid. > The "front", "rear", "center_lfe" definitions are rather for > multi-channel playbacks. The capture on these channels aren't useful > in most cases. Takashi, Arno's original post was just to the list, so I added your cc. His response was also only to the list, but has a patch at the bottom to do just playback asym with channels convertion, (which looks reasonable to me), so might be worth looking back at. BTW, for example in the case of ice1712, is there a way for different sound cards which use the same driver to have different default config files? The DMX6fire in particular would benefit from specific definitions for the particular mapping of its 6 analogue inputs. Alan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: ice1712 virtual devices 2009-11-08 21:13 ` Alan Horstmann @ 2009-11-16 19:32 ` Arno Schuring 2009-11-21 2:53 ` Raymond Yau 0 siblings, 1 reply; 8+ messages in thread From: Arno Schuring @ 2009-11-16 19:32 UTC (permalink / raw) To: Alan Horstmann; +Cc: Takashi Iwai, ALSA devel Hello again, Alan Horstmann wrote: > On Sunday 08 November 2009 10:38, you wrote: >> At Fri, 30 Oct 2009 09:23:37 +0000, >> >> Alan Horstmann wrote: >>> On Thursday 29 October 2009 17:48, Arno Schuring wrote: >>>> This is basically a resend of >>>> http://thread.gmane.org/gmane.linux.alsa.devel/59481/focus=59672 , >>>> which fixed the front: device of ice1712 cards to accept two-channel >>>> input. Currently, the front: device is exposed through the route >>>> plugin, which requires all clients to mmap all 10 channels, even though >>>> the front device is supposed to be a stereo device. [...] > > Arno's original post was just to the list, so I added your cc. His response > was also only to the list, but has a patch at the bottom to do just playback > asym with channels convertion, (which looks reasonable to me), so might be > worth looking back at. > > BTW, for example in the case of ice1712, is there a way for different sound > cards which use the same driver to have different default config files? The > DMX6fire in particular would benefit from specific definitions for the > particular mapping of its 6 analogue inputs. I apologize for the long delay. I'll reattach my latest proposed patch (copy-paste, hope it still applies). About my second question, is it even worth my time to try to implement multiple separate devices using the dshare plugin? I mean, even if I succeed in making front: and spdif: working together, does such a patch have even the slightest of getting accepted? Thanks, Arno -- diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf index 01e50d2..1cd3773 100644 --- a/src/conf/cards/ICE1712.conf +++ b/src/conf/cards/ICE1712.conf @@ -32,12 +32,16 @@ ICE1712.pcm.front.0 { @args.CARD { type string } - type route - ttable.0.0 1 - ttable.1.1 1 - slave.pcm { - type hw - card $CARD + type asym + playback.pcm { + type route + ttable.0.0 1 + ttable.1.1 1 + slave.pcm { + type hw + card $CARD + } + slave.channels 10 } } ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: RFC: ice1712 virtual devices 2009-11-16 19:32 ` Arno Schuring @ 2009-11-21 2:53 ` Raymond Yau 0 siblings, 0 replies; 8+ messages in thread From: Raymond Yau @ 2009-11-21 2:53 UTC (permalink / raw) To: alsa-devel Pulseaudio fail when using front device of emu10k1 for capturing I: module.c: Loaded "module-alsa-sink" (index: #0; argument: "device_id=0 sink_name=alsa_output.pci_1102_8_alsa_playback_0"). D: module-hal-detect.c: Loading module-alsa-source with arguments 'device_id=0 source_name=alsa_input.pci_1102_8_alsa_capture_0' D: alsa-util.c: Trying front:0... ALSA lib setup.c:96:(snd_sctl_install) Cannot *lock* *ctl* elem Each front , rear and lfe_center playback subdevice has two ctl hook with lock EMU10K1.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type hooks slave.pcm { type hw card $CARD } hooks.0 { type ctl_elems hook_args [ { interface PCM name "EMU10K1 PCM Send Volume" index { @func private_pcm_subdevice } lock true optional true value [ 255 255 0 0 255 0 0 0 0 255 0 0 ] } { # for compatibility with older drivers name "EMU10K1 PCM Send Volume" index { @func private_pcm_subdevice } lock true optional true value [ 255 255 0 0 255 0 0 0 0 255 0 0 ] } { interface PCM name "EMU10K1 PCM Send Routing" index { @func private_pcm_subdevice } lock true optional true value [ 8 9 0 0 8 9 0 0 8 9 0 0 ] } { # for compatibility with older drivers name "EMU10K1 PCM Send Routing" index { @func private_pcm_subdevice } lock true optional true value [ 8 9 0 0 8 9 0 0 8 9 0 0 ] } ] } } 2009/11/17 Arno Schuring <aelschuring@hotmail.com> > Hello again, > > Alan Horstmann wrote: > > On Sunday 08 November 2009 10:38, you wrote: > >> At Fri, 30 Oct 2009 09:23:37 +0000, > >> > >> Alan Horstmann wrote: > >>> On Thursday 29 October 2009 17:48, Arno Schuring wrote: > >>>> This is basically a resend of > >>>> http://thread.gmane.org/gmane.linux.alsa.devel/59481/focus=59672 , > >>>> which fixed the front: device of ice1712 cards to accept two-channel > >>>> input. Currently, the front: device is exposed through the route > >>>> plugin, which requires all clients to mmap all 10 channels, even > though > >>>> the front device is supposed to be a stereo device. > [...] > > > > Arno's original post was just to the list, so I added your cc. His > response > > was also only to the list, but has a patch at the bottom to do just > playback > > asym with channels convertion, (which looks reasonable to me), so might > be > > worth looking back at. > > > > BTW, for example in the case of ice1712, is there a way for different > sound > > cards which use the same driver to have different default config files? > The > > DMX6fire in particular would benefit from specific definitions for the > > particular mapping of its 6 analogue inputs. > > I apologize for the long delay. I'll reattach my latest proposed patch > (copy-paste, hope it still applies). > > About my second question, is it even worth my time to try to implement > multiple separate devices using the dshare plugin? I mean, even if I > succeed in making front: and spdif: working together, does such a patch > have even the slightest of getting accepted? > > > Thanks, > Arno > > > -- > diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf > index 01e50d2..1cd3773 100644 > --- a/src/conf/cards/ICE1712.conf > +++ b/src/conf/cards/ICE1712.conf > @@ -32,12 +32,16 @@ ICE1712.pcm.front.0 { > @args.CARD { > type string > } > - type route > - ttable.0.0 1 > - ttable.1.1 1 > - slave.pcm { > - type hw > - card $CARD > + type asym > + playback.pcm { > + type route > + ttable.0.0 1 > + ttable.1.1 1 > + slave.pcm { > + type hw > + card $CARD > + } > + slave.channels 10 > } > } > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-11-21 2:53 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-10-29 17:48 RFC: ice1712 virtual devices Arno Schuring 2009-10-30 0:36 ` Raymond Yau 2009-10-30 9:23 ` Alan Horstmann 2009-10-30 11:29 ` Arno Schuring 2009-11-08 10:38 ` Takashi Iwai 2009-11-08 21:13 ` Alan Horstmann 2009-11-16 19:32 ` Arno Schuring 2009-11-21 2:53 ` Raymond Yau
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.