[alsa-devel] ICE1712 softdevices fixes
The following patches fixes the default device as they appear for ICE1712-based cards. Without this cards, 'aplay -L' will show a series of devices like surround40 and surround71 that are not meaningful for this card, and a front device that would not work.
Diego E. 'Flameeyes' Pettenò (2): Remove definition for surround sound devices on ICE1712. Make the front:idx device work for ICE1712.
The ICE1712-based cards are non-surround cards with only stereo final output. It's not possible to use them as surround cards, so these devices don't make sense.
They also don't work since opening those devices with less than the amount of channels will fail.
Signed-off-by: Diego E. 'Flameeyes' Pettenò flameeyes@gmail.com --- src/conf/cards/ICE1712.conf | 40 ---------------------------------------- 1 files changed, 0 insertions(+), 40 deletions(-)
diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf index 01e50d2..5445920 100644 --- a/src/conf/cards/ICE1712.conf +++ b/src/conf/cards/ICE1712.conf @@ -39,46 +39,6 @@ ICE1712.pcm.front.0 { type hw card $CARD } -} - -confdir:pcm/surround40.conf - -ICE1712.pcm.surround40.0 { - @args [ CARD ] - @args.CARD { - type string - } - type route - ttable.0.0 1 - ttable.1.1 1 - ttable.2.2 1 - ttable.3.3 1 - slave.pcm { - type hw - card $CARD - } -} - -confdir:pcm/surround41.conf -confdir:pcm/surround50.conf -confdir:pcm/surround51.conf - -ICE1712.pcm.surround51.0 { - @args [ CARD ] - @args.CARD { - type string - } - type route - ttable.0.0 1 - ttable.1.1 1 - ttable.2.2 1 - ttable.3.3 1 - ttable.4.4 1 - ttable.5.5 1 - slave.pcm { - type hw - card $CARD - } }
The default definition of front:idx for ICE1712-based cards didn't work previously because the route plugin cannot change the number of channels between the hardware device (with 10 or 12 channels) and the soft-device (with 2 channels).
Signed-off-by: Diego E. 'Flameeyes' Pettenò flameeyes@gmail.com --- src/conf/cards/ICE1712.conf | 28 ++++++++++++++++++++++------ 1 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/src/conf/cards/ICE1712.conf b/src/conf/cards/ICE1712.conf index 5445920..bb93c1d 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.8 1 + ttable.1.9 1 + slave.pcm { + type hw + card $CARD + } + slave.format S32_LE + slave.channels 12 } }
On Tue, 20 Jan 2009, Diego E. 'Flameeyes' Petten? wrote:
The ICE1712-based cards are non-surround cards with only stereo final output. It's not possible to use them as surround cards, so these devices don't make sense.
ICE1712 has 8 independent outputs, so why surround definitions do not make sense?
They also don't work since opening those devices with less than the amount of channels will fail.
Probably slave.pcm.channels definition is missing? But I wonder why it does not work automatically.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela perex@perex.cz writes:
ICE1712 has 8 independent outputs, so why surround definitions do not make sense?
Because ICE1712-based cards have, physically, two RCA and one S/PDIF jacks for input, and the same amount for output.
On Tue, 20 Jan 2009, Diego E. 'Flameeyes' Petten? wrote:
Jaroslav Kysela perex@perex.cz writes:
ICE1712 has 8 independent outputs, so why surround definitions do not make sense?
Because ICE1712-based cards have, physically, two RCA and one S/PDIF jacks for input, and the same amount for output.
Do you have seen M-Audio Delta 1010 ? The problem is that we have hardware that can be used for surround output, but alsa-lib configuration files cannot describe the restrictions in detail now.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela perex@perex.cz writes:
Do you have seen M-Audio Delta 1010 ? The problem is that we have hardware that can be used for surround output, but alsa-lib configuration files cannot describe the restrictions in detail now.
I thought that was an ICE1724, rather than 1712; I was mistaken, sorry.
Still, as they are the devices are non-functional at least on my card, and I'm ready to bet that the same would happen on the Delta 1010 given that the number of channels is not coherent (you try to open surround71 as 8-channels and it'll fail because this minimal card has 10; if the 1010 has the same amount of channels, it'll still fail).
Maybe there's a way to describe different ICE1712-based cards with different configuration files so that the surround device appears only on surround-capable cards? Or let the user decide whether to load them?
Having them present and failing is not really nice.
On Tuesday 20 January 2009 13:49, Diego E. 'Flameeyes' Pettenò wrote:
Jaroslav Kysela perex@perex.cz writes:
Do you have seen M-Audio Delta 1010 ?
Or DMX6fire, or Hoontech/ST.Audio dsp2000, or rest of a list... It seems to me that only a few cut-down card versions have only 2 analogue in/out.
Still, as they are the devices are non-functional at least on my card, and I'm ready to bet that the same would happen on the Delta 1010 given that the number of channels is not coherent (you try to open surround71 as 8-channels and it'll fail because this minimal card has 10; if the 1010 has the same amount of channels, it'll still fail).
Here (on a rather old Alsa version) on DMX6fire:
aplay -Dfront try1.wav
does fail unless try1.wav is a 10-channel file, whereupon just the first 2 channels play out. A standard stereo wav file fails with a sample format error. So there is something not quite right with the config files.
Does the surround and front both need the asym slave.format & slave.channels definitions? Right now I can't do further testing; maybe later.
Alan
On Tue, 20 Jan 2009, Alan Horstmann wrote:
On Tuesday 20 January 2009 13:49, Diego E. 'Flameeyes' Petten? wrote:
Jaroslav Kysela perex@perex.cz writes:
Do you have seen M-Audio Delta 1010 ?
Or DMX6fire, or Hoontech/ST.Audio dsp2000, or rest of a list... It seems to me that only a few cut-down card versions have only 2 analogue in/out.
Still, as they are the devices are non-functional at least on my card, and I'm ready to bet that the same would happen on the Delta 1010 given that the number of channels is not coherent (you try to open surround71 as 8-channels and it'll fail because this minimal card has 10; if the 1010 has the same amount of channels, it'll still fail).
Here (on a rather old Alsa version) on DMX6fire:
aplay -Dfront try1.wav
does fail unless try1.wav is a 10-channel file, whereupon just the first 2 channels play out. A standard stereo wav file fails with a sample format error. So there is something not quite right with the config files.
Note that front and surround devices does not support automatic sample conversion. Use plug:front, plug:surround40 etc. devices.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela perex@perex.cz writes:
Note that front and surround devices does not support automatic sample conversion. Use plug:front, plug:surround40 etc. devices.
Using the correct format, front:IDX should work with two channels sound files, and it doesn't, nor surround40:IDX works with four channels or surround71:IDX with eight channels.
[I'm using IDX because I have it on :1 rather than :0]
At Tue, 20 Jan 2009 17:33:24 +0100, Diego E. 'Flameeyes' Pettenò wrote:
Jaroslav Kysela perex@perex.cz writes:
Note that front and surround devices does not support automatic sample conversion. Use plug:front, plug:surround40 etc. devices.
Using the correct format, front:IDX should work with two channels sound files, and it doesn't, nor surround40:IDX works with four channels or surround71:IDX with eight channels.
[I'm using IDX because I have it on :1 rather than :0]
I thought plug:front:IDX works, at least on 1.0.19, too...
Takashi
On Wednesday 21 January 2009 10:00, Takashi Iwai wrote:
At Tue, 20 Jan 2009 17:33:24 +0100,
Diego E. 'Flameeyes' Pettenò wrote:
Jaroslav Kysela perex@perex.cz writes:
Note that front and surround devices does not support automatic sample conversion. Use plug:front, plug:surround40 etc. devices.
Using the correct format, front:IDX should work with two channels sound files, and it doesn't, nor surround40:IDX works with four channels or surround71:IDX with eight channels.
[I'm using IDX because I have it on :1 rather than :0]
I thought plug:front:IDX works, at least on 1.0.19, too...
It does work here on older Alsa.
I think Diego's point though is that 'surround40:IDX' might be expected to be a 4-channel stream, whereas it is as dependant on the hardware as 'hw:IDX' is. In the later case it is clear that the user must provide audio in whatever format/channels the hardware uses. However it is unexpected that eg on ice1712 'surround40:IDX' requires a 10-channel playback stream and ignores 6 of them, and will not play a 4-channel stream.
It is also not symetrical, so if you capture it has to be a 12-channel stream, which it is then not possible to play without using the plug: devices.
Unless I am mistaken...
Alan
At Wed, 21 Jan 2009 16:45:29 +0000, Alan Horstmann wrote:
On Wednesday 21 January 2009 10:00, Takashi Iwai wrote:
At Tue, 20 Jan 2009 17:33:24 +0100,
Diego E. 'Flameeyes' Pettenò wrote:
Jaroslav Kysela perex@perex.cz writes:
Note that front and surround devices does not support automatic sample conversion. Use plug:front, plug:surround40 etc. devices.
Using the correct format, front:IDX should work with two channels sound files, and it doesn't, nor surround40:IDX works with four channels or surround71:IDX with eight channels.
[I'm using IDX because I have it on :1 rather than :0]
I thought plug:front:IDX works, at least on 1.0.19, too...
It does work here on older Alsa.
But, if it works with the latest version code, it makes no sense to fix the config of that tree. We aren't changing the old tree now.
I think Diego's point though is that 'surround40:IDX' might be expected to be a 4-channel stream, whereas it is as dependant on the hardware as 'hw:IDX' is. In the later case it is clear that the user must provide audio in whatever format/channels the hardware uses. However it is unexpected that eg on ice1712 'surround40:IDX' requires a 10-channel playback stream and ignores 6 of them, and will not play a 4-channel stream.
It is also not symetrical, so if you capture it has to be a 12-channel stream, which it is then not possible to play without using the plug: devices.
Unless I am mistaken...
Right, ice1712 is tricky as is. I myself feel having plug inside the front, etc, definitions would be more intuitive. However, the plug over plug doesn't (didn't? -- need checks) work. And, the definition should be as slim as possible. These are counter arguments.
Takashi
On Wednesday 21 January 2009 16:33, you wrote:
At Wed, 21 Jan 2009 16:45:29 +0000, Alan Horstmann wrote:
On Wednesday 21 January 2009 10:00, Takashi Iwai wrote:
At Tue, 20 Jan 2009 17:33:24 +0100, Diego E. 'Flameeyes' Pettenò wrote:
Using the correct format, front:IDX should work with two channels sound files, and it doesn't, nor surround40:IDX works with four channels or surround71:IDX with eight channels.
<snip>
I think Diego's point though is that 'surround40:IDX' might be expected to be a 4-channel stream, whereas it is as dependant on the hardware as 'hw:IDX' is. In the later case it is clear that the user must provide audio in whatever format/channels the hardware uses. However it is unexpected that eg on ice1712 'surround40:IDX' requires a 10-channel playback stream and ignores 6 of them, and will not play a 4-channel stream.
It is also not symetrical, so if you capture it has to be a 12-channel stream, which it is then not possible to play without using the plug: devices.
Unless I am mistaken...
Right, ice1712 is tricky as is. I myself feel having plug inside the front, etc, definitions would be more intuitive. However, the plug over plug doesn't (didn't? -- need checks) work. And, the definition should be as slim as possible. These are counter arguments.
It may be that you want to drop this completely, but I have done a little more testing and thinking, in case not.
The purpose of the 'front', 'surround' etc definitions is presumably to provide pre-configured routing to certain standard outputs where this is possible with the card hardware. Therefore it seems reasonable for the user to expect channel number conversion to be handled by these devices, as Diego's original proposal for 'front'. One might augue the format conversion should not be included since that really is the job of 'plug:front'.
In the case of ice1712 it is particularly useful due to the asymmetry of channels playback and capture. That raises another question -what is the meaning of capture from a device such as 'surround'? Would anyone want to do it and what would they expect (stereo/4-channel)? Should the devices be playback only? Capture would be very dependant on the specific board. Is there any way to handle different conf files dependant on different ice1712 cards?
I have tested a modified ICE1712.conf with front definition similar to Diego's, essentially:-
type asym playback.pcm { type route ttable.0.0 1 ttable.1.1 1 slave.pcm { type hw card $CARD } slave.channels 10 } capture.pcm { type route ttable.0.0 1 ttable.1.1 1 slave.pcm { type hw card $CARD } slave.channels 12 }
and can confirm playback of files with various channel numbers is possible fine. Also, plug:front in this case still works fine.
I wondered what your thoughts are on this?
Alan
participants (5)
-
Alan Horstmann -
Diego E. 'Flameeyes' Pettenò -
flameeyes＠gmail.com
-
Jaroslav Kysela -
Takashi Iwai