[alsa-devel] RFC: ice1712 virtual devices
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 } }
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 routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD
type asymplayback.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.format S32_LEslave.channels 10}capture.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.format S32_LEslave.channels 12 }}
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/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 routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD
type asymplayback.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.format S32_LEslave.channels 10}capture.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.format S32_LEslave.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
[ 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 } }
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 routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD
type asymplayback.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.format S32_LEslave.channels 10}capture.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.format S32_LEslave.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
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 routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD
type asymplayback.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.format S32_LEslave.channels 10}capture.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.format S32_LEslave.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
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 } }
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 routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD
type asymplayback.pcm {type routettable.0.0 1ttable.1.1 1slave.pcm {type hwcard $CARD}slave.channels 10 }}
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (4)
-
Alan Horstmann -
Arno Schuring -
Raymond Yau -
Takashi Iwai