All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.