[PATCH 1/2] ALSA: ca0106 - add Sound Blaster 5.1vx info.

[PATCH 1/2] ALSA: ca0106 - add Sound Blaster 5.1vx info.

[andy-alsa]

From: Andy Owen <andy-alsa@ultra-premium.com>

---
 sound/pci/ca0106/ca0106_main.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/sound/pci/ca0106/ca0106_main.c b/sound/pci/ca0106/ca0106_main.c
index 8e69620..6dc9a5d 100644
--- a/sound/pci/ca0106/ca0106_main.c
+++ b/sound/pci/ca0106/ca0106_main.c
@@ -239,6 +239,16 @@ static struct snd_ca0106_details ca0106_chip_details[] = {
 	   .gpio_type = 1,
 	   .i2c_adc = 1,
 	   .spi_dac = 1 } ,
+	/* Sound Blaster 5.1vx
+	 * Tested: Playback on front, rear, center/lfe speakers
+	 * Not-Tested: Capture
+	 */
+	{ .serial = 0x10041102,
+	  .name   = "Sound Blaster 5.1vx [SB1070]",
+	  .gpio_type = 1,
+	  .i2c_adc = 0,
+	  .spi_dac = 1
+	 } ,
 	 /* MSI K8N Diamond Motherboard with onboard SB Live 24bit without AC97 */
 	 /* SB0438
 	  * CTRL:CA0106-DAT
-- 
1.7.0.4

[PATCH 2/2] ALSA: ca0106: Fix mixer and dac channel assignments.

[andy-alsa]

From: Andy Owen <andy-alsa@ultra-premium.com>

---
 sound/pci/ca0106/ca0106_main.c  |   14 +++++++-------
 sound/pci/ca0106/ca0106_mixer.c |    6 +++---
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/sound/pci/ca0106/ca0106_main.c b/sound/pci/ca0106/ca0106_main.c
index 6dc9a5d..a98df19 100644
--- a/sound/pci/ca0106/ca0106_main.c
+++ b/sound/pci/ca0106/ca0106_main.c
@@ -493,16 +493,16 @@ static void snd_ca0106_pcm_free_substream(struct snd_pcm_runtime *runtime)
 }
 
 static const int spi_dacd_reg[] = {
-	[PCM_FRONT_CHANNEL]	= SPI_DACD4_REG,
-	[PCM_REAR_CHANNEL]	= SPI_DACD0_REG,
+	[PCM_FRONT_CHANNEL]	= SPI_DACD0_REG,
+	[PCM_REAR_CHANNEL]	= SPI_DACD1_REG,
 	[PCM_CENTER_LFE_CHANNEL]= SPI_DACD2_REG,
-	[PCM_UNKNOWN_CHANNEL]	= SPI_DACD1_REG,
+	[PCM_UNKNOWN_CHANNEL]	= SPI_DACD4_REG,
 };
 static const int spi_dacd_bit[] = {
-	[PCM_FRONT_CHANNEL]	= SPI_DACD4_BIT,
-	[PCM_REAR_CHANNEL]	= SPI_DACD0_BIT,
+	[PCM_FRONT_CHANNEL]	= SPI_DACD0_BIT,
+	[PCM_REAR_CHANNEL]	= SPI_DACD1_BIT,
 	[PCM_CENTER_LFE_CHANNEL]= SPI_DACD2_BIT,
-	[PCM_UNKNOWN_CHANNEL]	= SPI_DACD1_BIT,
+	[PCM_UNKNOWN_CHANNEL]	= SPI_DACD4_BIT,
 };
 
 static void restore_spdif_bits(struct snd_ca0106 *chip, int idx)
@@ -553,7 +553,7 @@ static int snd_ca0106_pcm_open_playback_channel(struct snd_pcm_substream *substr
                 return err;
 	snd_pcm_set_sync(substream);
 
-	if (chip->details->spi_dac && channel_id != PCM_FRONT_CHANNEL) {
+	if (chip->details->spi_dac) {
 		const int reg = spi_dacd_reg[channel_id];
 
 		/* Power up dac */
diff --git a/sound/pci/ca0106/ca0106_mixer.c b/sound/pci/ca0106/ca0106_mixer.c
index 85fd315..bafb9c8 100644
--- a/sound/pci/ca0106/ca0106_mixer.c
+++ b/sound/pci/ca0106/ca0106_mixer.c
@@ -689,13 +689,13 @@ static struct snd_kcontrol_new snd_ca0106_volume_i2c_adc_ctls[] __devinitdata =
 static struct snd_kcontrol_new snd_ca0106_volume_spi_dac_ctls[]
 __devinitdata = {
 	SPI_SWITCH("Analog Front Playback Switch",
-		   SPI_DMUTE4_REG, SPI_DMUTE4_BIT),
-	SPI_SWITCH("Analog Rear Playback Switch",
 		   SPI_DMUTE0_REG, SPI_DMUTE0_BIT),
+	SPI_SWITCH("Analog Rear Playback Switch",
+		   SPI_DMUTE1_REG, SPI_DMUTE1_BIT),
 	SPI_SWITCH("Analog Center/LFE Playback Switch",
 		   SPI_DMUTE2_REG, SPI_DMUTE2_BIT),
 	SPI_SWITCH("Analog Side Playback Switch",
-		   SPI_DMUTE1_REG, SPI_DMUTE1_BIT),
+		   SPI_DMUTE4_REG, SPI_DMUTE4_BIT),
 };
 
 static int __devinit remove_ctl(struct snd_card *card, const char *name)
-- 
1.7.0.4

Re: [PATCH 1/2] ALSA: ca0106 - add Sound Blaster 5.1vx info.

[Takashi Iwai]

At Tue, 21 Sep 2010 23:51:18 +1000,
andy-alsa@ultra-premium.com wrote:
> 
> From: Andy Owen <andy-alsa@ultra-premium.com>

Could you give your sign-off?


thanks,

Takashi

> 
> ---
>  sound/pci/ca0106/ca0106_main.c |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/sound/pci/ca0106/ca0106_main.c b/sound/pci/ca0106/ca0106_main.c
> index 8e69620..6dc9a5d 100644
> --- a/sound/pci/ca0106/ca0106_main.c
> +++ b/sound/pci/ca0106/ca0106_main.c
> @@ -239,6 +239,16 @@ static struct snd_ca0106_details ca0106_chip_details[] = {
>  	   .gpio_type = 1,
>  	   .i2c_adc = 1,
>  	   .spi_dac = 1 } ,
> +	/* Sound Blaster 5.1vx
> +	 * Tested: Playback on front, rear, center/lfe speakers
> +	 * Not-Tested: Capture
> +	 */
> +	{ .serial = 0x10041102,
> +	  .name   = "Sound Blaster 5.1vx [SB1070]",
> +	  .gpio_type = 1,
> +	  .i2c_adc = 0,
> +	  .spi_dac = 1
> +	 } ,
>  	 /* MSI K8N Diamond Motherboard with onboard SB Live 24bit without AC97 */
>  	 /* SB0438
>  	  * CTRL:CA0106-DAT
> -- 
> 1.7.0.4
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: [PATCH 2/2] ALSA: ca0106: Fix mixer and dac channel assignments.

[Takashi Iwai]

At Tue, 21 Sep 2010 23:51:19 +1000,
andy-alsa@ultra-premium.com wrote:
> 
> From: Andy Owen <andy-alsa@ultra-premium.com>

I wonder whether this can regress on other boards.
The front channel is the obvious channel so this must have been
tested.  Maybe we should change the mapping only for your specific
model by adding some flag.


thanks,

Takashi

> ---
>  sound/pci/ca0106/ca0106_main.c  |   14 +++++++-------
>  sound/pci/ca0106/ca0106_mixer.c |    6 +++---
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/sound/pci/ca0106/ca0106_main.c b/sound/pci/ca0106/ca0106_main.c
> index 6dc9a5d..a98df19 100644
> --- a/sound/pci/ca0106/ca0106_main.c
> +++ b/sound/pci/ca0106/ca0106_main.c
> @@ -493,16 +493,16 @@ static void snd_ca0106_pcm_free_substream(struct snd_pcm_runtime *runtime)
>  }
>  
>  static const int spi_dacd_reg[] = {
> -	[PCM_FRONT_CHANNEL]	= SPI_DACD4_REG,
> -	[PCM_REAR_CHANNEL]	= SPI_DACD0_REG,
> +	[PCM_FRONT_CHANNEL]	= SPI_DACD0_REG,
> +	[PCM_REAR_CHANNEL]	= SPI_DACD1_REG,
>  	[PCM_CENTER_LFE_CHANNEL]= SPI_DACD2_REG,
> -	[PCM_UNKNOWN_CHANNEL]	= SPI_DACD1_REG,
> +	[PCM_UNKNOWN_CHANNEL]	= SPI_DACD4_REG,
>  };
>  static const int spi_dacd_bit[] = {
> -	[PCM_FRONT_CHANNEL]	= SPI_DACD4_BIT,
> -	[PCM_REAR_CHANNEL]	= SPI_DACD0_BIT,
> +	[PCM_FRONT_CHANNEL]	= SPI_DACD0_BIT,
> +	[PCM_REAR_CHANNEL]	= SPI_DACD1_BIT,
>  	[PCM_CENTER_LFE_CHANNEL]= SPI_DACD2_BIT,
> -	[PCM_UNKNOWN_CHANNEL]	= SPI_DACD1_BIT,
> +	[PCM_UNKNOWN_CHANNEL]	= SPI_DACD4_BIT,
>  };
>  
>  static void restore_spdif_bits(struct snd_ca0106 *chip, int idx)
> @@ -553,7 +553,7 @@ static int snd_ca0106_pcm_open_playback_channel(struct snd_pcm_substream *substr
>                  return err;
>  	snd_pcm_set_sync(substream);
>  
> -	if (chip->details->spi_dac && channel_id != PCM_FRONT_CHANNEL) {
> +	if (chip->details->spi_dac) {
>  		const int reg = spi_dacd_reg[channel_id];
>  
>  		/* Power up dac */
> diff --git a/sound/pci/ca0106/ca0106_mixer.c b/sound/pci/ca0106/ca0106_mixer.c
> index 85fd315..bafb9c8 100644
> --- a/sound/pci/ca0106/ca0106_mixer.c
> +++ b/sound/pci/ca0106/ca0106_mixer.c
> @@ -689,13 +689,13 @@ static struct snd_kcontrol_new snd_ca0106_volume_i2c_adc_ctls[] __devinitdata =
>  static struct snd_kcontrol_new snd_ca0106_volume_spi_dac_ctls[]
>  __devinitdata = {
>  	SPI_SWITCH("Analog Front Playback Switch",
> -		   SPI_DMUTE4_REG, SPI_DMUTE4_BIT),
> -	SPI_SWITCH("Analog Rear Playback Switch",
>  		   SPI_DMUTE0_REG, SPI_DMUTE0_BIT),
> +	SPI_SWITCH("Analog Rear Playback Switch",
> +		   SPI_DMUTE1_REG, SPI_DMUTE1_BIT),
>  	SPI_SWITCH("Analog Center/LFE Playback Switch",
>  		   SPI_DMUTE2_REG, SPI_DMUTE2_BIT),
>  	SPI_SWITCH("Analog Side Playback Switch",
> -		   SPI_DMUTE1_REG, SPI_DMUTE1_BIT),
> +		   SPI_DMUTE4_REG, SPI_DMUTE4_BIT),
>  };
>  
>  static int __devinit remove_ctl(struct snd_card *card, const char *name)
> -- 
> 1.7.0.4
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: [PATCH 2/2] ALSA: ca0106: Fix mixer and dac channel assignments.

[Andy Owen]

On Tue, 2010-09-21 at 16:00 +0200, Takashi Iwai wrote:
> I wonder whether this can regress on other boards.
> The front channel is the obvious channel so this must have been
> tested.  Maybe we should change the mapping only for your specific
> model by adding some flag.

The behaviour I was seeing was that if I just added the device id, then
the front channel would work fine, but I would get no sound from the
rears, and the mixer controls didn't quite match the labels. 

I was a bit suspect of this change:

> -     if (chip->details->spi_dac && channel_id != PCM_FRONT_CHANNEL) {
> +     if (chip->details->spi_dac) {

But I convinced myself that it was a hack to work around the registers
being wrong in other places, and the card in its default state had the
front dac already powered up. Looking at the code, I can see similar
logic in the snd_ca0106_pcm_close_playback() function, which has a
special case for the front channel, and I think should also be modified.

I'll put together some revised patches (with sign offs and the proposed
fix) hopefully tomorrow.

If anyone has a ca0106 card that they can test this with, it would be
much appreciated.

Andy

Re: [PATCH 2/2] ALSA: ca0106: Fix mixer and dac channel assignments.

[Takashi Iwai]

At Wed, 22 Sep 2010 00:24:56 +1000,
Andy Owen wrote:
> 
> On Tue, 2010-09-21 at 16:00 +0200, Takashi Iwai wrote:
> > I wonder whether this can regress on other boards.
> > The front channel is the obvious channel so this must have been
> > tested.  Maybe we should change the mapping only for your specific
> > model by adding some flag.
> 
> The behaviour I was seeing was that if I just added the device id, then
> the front channel would work fine, but I would get no sound from the
> rears, and the mixer controls didn't quite match the labels. 

Hrm, but you changed the DAC number of the front channel.  Doesn't change
the front channel behavior...?

> I was a bit suspect of this change:
> 
> > -     if (chip->details->spi_dac && channel_id != PCM_FRONT_CHANNEL) {
> > +     if (chip->details->spi_dac) {
> 
> But I convinced myself that it was a hack to work around the registers
> being wrong in other places, and the card in its default state had the
> front dac already powered up. Looking at the code, I can see similar
> logic in the snd_ca0106_pcm_close_playback() function, which has a
> special case for the front channel, and I think should also be modified.

No, take a look at git commit 485100706b4b397f8072c756839878f634e21f85:

   [ALSA] ca0106: power down SPI DAC channels when not in use
    
    For cards with an SPI DAC (SB Live 24-bit / Audigy SE), power down channels
    0-2 when not in use.  They are powered up on PCM open and down again on PCM
    close.  Channel 4 (== Front) is not powered down, as it is used for capture
    feedback.  Powering it down would effectively kill line in pass-through.
    
So, it's the designed behavior.

Judging from the fact that this mapping hasn't been changed since that
time, I feel that it's not safe to change the mapping unconditionally
for your device.  That's why I suggest for some new flag.


Takashi

Re: [PATCH 2/2] ALSA: ca0106: Fix mixer and dac channel assignments.

[Andy Owen]

[-- Attachment #1: Type: text/plain, Size: 4865 bytes --]

> Hrm, but you changed the DAC number of the front channel.  Doesn't
change
> the front channel behavior...?

The behaviour I get is as follows:

0) Without either of my patches:
 * Distorted output, however once the soundcard has been initialised by
a working driver, this can only be reproduced by turning off the
computer (I think - I can test this later if it is useful, I'm basing it
off reports on forums about the card working for people after they
booted into windows and then restarted).
 * Capture fails (more on this later)

1) With the first patch (adding card info to the table):
 * "speaker-test -Dsurround51 -c6": silence for rear channels, others ok
 * "speaker-test -Drear -c2"      : silence
 * "speaker-test -Dfront -c2"     : silence
 * "speaker-test -Dcenter_lfe -c2": ok (sound+mute+volume)
 * "speaker-test -Dsurround51 -c6": mute for rear controls front
                                  : volume for front is correct
                                  : volume/mute for C/LFE is correct
 * Capture fails (more on this later again)

To me, this suggested that something was flipped with the front and
rear, hence I ended up changing some registers. The case halfway between
(1) and (2) would be before I modified the 'if' statement below so the
front channel isn't a special case.  The results are identical to (2),
except the front channel is always silent.

2) With the second patch:
* "speaker-test -Dsurround51 -c6": ok (sound+mute+volume)
* "speaker-test -Drear -c2"      : ok (sound+mute+volume)
* "speaker-test -Dfront -c2"     : ok (sound+mute+volume)
* "speaker-test -Dcenter_lfe -c2": ok (sound+mute+volume)
* Capture still broken

I'm using arecord to test capture, and I'm not sure if I'm driving it
wrong, as I can't get it to work for either of my cards (the other card
works slightly better, but I always get silence). The failure I'm
describing here is what I get for every version described above (the
only editing I've done here is remove mentions of the other sound
cards):

~% arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: CA0106 [CA0106], device 0: ca0106 [CA0106]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 1: ca0106 [CA0106]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 2: ca0106 [CA0106]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 3: ca0106 [CA0106]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
~% arecord -D hw:0,0 -f dat out.wav
Recording WAVE 'out.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
arecord: pcm_read:1629: read error: Input/output error
(1)~% arecord -D hw:0,1 -f dat out.wav
Recording WAVE 'out.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
arecord: pcm_read:1629: read error: Input/output error
(1)~% arecord -D hw:0,2 -f dat out.wav
Recording WAVE 'out.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
arecord: pcm_read:1629: read error: Input/output error

Note that it fails after 10 seconds of me running arecord, suggesting
some sort of timeout somewhere. If I try to record at 44.1kHz, I get a
warning:

Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz)
         please, try the plug plugin

followed by the same error.


> No, take a look at git commit
485100706b4b397f8072c756839878f634e21f85:
> 
>    [ALSA] ca0106: power down SPI DAC channels when not in use
>     
>     For cards with an SPI DAC (SB Live 24-bit / Audigy SE), power down
channels
>     0-2 when not in use.  They are powered up on PCM open and down
again on PCM
>     close.  Channel 4 (== Front) is not powered down, as it is used
for capture
>     feedback.  Powering it down would effectively kill line in
pass-through.
>     
> So, it's the designed behavior.

Judging by that commit, Trent actually had a datasheet to work with, so
I'm inclined to trust it more. However, I just wonder if the other cards
have had full testing of all their outputs - only the "X-Fi Extreme
Audio" claims to have had all 6 channels tested.


> Judging from the fact that this mapping hasn't been changed since that
> time, I feel that it's not safe to change the mapping unconditionally
> for your device.  That's why I suggest for some new flag.

So if it is a new flag. I'd be tempted to instead include the mappings
in the chip_details struct, rather than a single purpose flag for one
device (which will surely be difficult to name well). The other change
I'd be tempted to make would be to avoid exposing channels that don't
exist (like the side channels, or spdif for this device). Is that a
sensible step? Do any other drivers have to solve a similar problem?

I've attached the first patch with the sign-off line if you want to put
it in now. Otherwise, I'm happy to wait until everything is sorted out,
and put it all in together.

Andy
> 
> 
> Takashi

[-- Attachment #2: 0001-ALSA-ca0106-add-Sound-Blaster-5.1vx-info.patch --]
[-- Type: text/x-patch, Size: 1076 bytes --]

>From 7ebb81b4cc7268acbd0b6074667ad66ccf3d1a96 Mon Sep 17 00:00:00 2001
From: Andy Owen <andy-alsa@ultra-premium.com>
Date: Tue, 21 Sep 2010 23:21:02 +1000
Subject: [PATCH] ALSA: ca0106 - add Sound Blaster 5.1vx info.

Signed-off-by: Andy Owen <andy-alsa@ultra-premium.com>
---
 sound/pci/ca0106/ca0106_main.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/sound/pci/ca0106/ca0106_main.c b/sound/pci/ca0106/ca0106_main.c
index 8e69620..6dc9a5d 100644
--- a/sound/pci/ca0106/ca0106_main.c
+++ b/sound/pci/ca0106/ca0106_main.c
@@ -239,6 +239,16 @@ static struct snd_ca0106_details ca0106_chip_details[] = {
 	   .gpio_type = 1,
 	   .i2c_adc = 1,
 	   .spi_dac = 1 } ,
+	/* Sound Blaster 5.1vx
+	 * Tested: Playback on front, rear, center/lfe speakers
+	 * Not-Tested: Capture
+	 */
+	{ .serial = 0x10041102,
+	  .name   = "Sound Blaster 5.1vx [SB1070]",
+	  .gpio_type = 1,
+	  .i2c_adc = 0,
+	  .spi_dac = 1
+	 } ,
 	 /* MSI K8N Diamond Motherboard with onboard SB Live 24bit without AC97 */
 	 /* SB0438
 	  * CTRL:CA0106-DAT
-- 
1.7.0.4


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 2/2] ALSA: ca0106: Fix mixer and dac channel assignments.

[Takashi Iwai]

At Thu, 23 Sep 2010 00:09:02 +1000,
Andy Owen wrote:
> 
> > Hrm, but you changed the DAC number of the front channel.  Doesn't change
> > the front channel behavior...?
> 
> The behaviour I get is as follows:
> 
> 0) Without either of my patches:
>  * Distorted output, however once the soundcard has been initialised by
> a working driver, this can only be reproduced by turning off the
> computer (I think - I can test this later if it is useful, I'm basing it
> off reports on forums about the card working for people after they
> booted into windows and then restarted).
>  * Capture fails (more on this later)
> 
> 1) With the first patch (adding card info to the table):
>  * "speaker-test -Dsurround51 -c6": silence for rear channels, others ok
>  * "speaker-test -Drear -c2"      : silence
>  * "speaker-test -Dfront -c2"     : silence
>  * "speaker-test -Dcenter_lfe -c2": ok (sound+mute+volume)
>  * "speaker-test -Dsurround51 -c6": mute for rear controls front
>                                   : volume for front is correct
>                                   : volume/mute for C/LFE is correct
>  * Capture fails (more on this later again)
> 
> To me, this suggested that something was flipped with the front and
> rear, hence I ended up changing some registers. The case halfway between
> (1) and (2) would be before I modified the 'if' statement below so the
> front channel isn't a special case.  The results are identical to (2),
> except the front channel is always silent.

Yes, it sounds so.


> 2) With the second patch:
> * "speaker-test -Dsurround51 -c6": ok (sound+mute+volume)
> * "speaker-test -Drear -c2"      : ok (sound+mute+volume)
> * "speaker-test -Dfront -c2"     : ok (sound+mute+volume)
> * "speaker-test -Dcenter_lfe -c2": ok (sound+mute+volume)
> * Capture still broken
> 
> I'm using arecord to test capture, and I'm not sure if I'm driving it
> wrong, as I can't get it to work for either of my cards (the other card
> works slightly better, but I always get silence). The failure I'm
> describing here is what I get for every version described above (the
> only editing I've done here is remove mentions of the other sound
> cards):
> 
> ~% arecord -l
> **** List of CAPTURE Hardware Devices ****
> card 0: CA0106 [CA0106], device 0: ca0106 [CA0106]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: CA0106 [CA0106], device 1: ca0106 [CA0106]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: CA0106 [CA0106], device 2: ca0106 [CA0106]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: CA0106 [CA0106], device 3: ca0106 [CA0106]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> ~% arecord -D hw:0,0 -f dat out.wav
> Recording WAVE 'out.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
> Stereo
> arecord: pcm_read:1629: read error: Input/output error
> (1)~% arecord -D hw:0,1 -f dat out.wav
> Recording WAVE 'out.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
> Stereo
> arecord: pcm_read:1629: read error: Input/output error
> (1)~% arecord -D hw:0,2 -f dat out.wav
> Recording WAVE 'out.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
> Stereo
> arecord: pcm_read:1629: read error: Input/output error

This usually implies that the DMA doesn't work.  So, the DAC/ADC
mapping seems wrong.


> Note that it fails after 10 seconds of me running arecord, suggesting
> some sort of timeout somewhere. If I try to record at 44.1kHz, I get a
> warning:
> 
> Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz)
>          please, try the plug plugin
> 
> followed by the same error.

This is no issue.  Use plughw:0,x instead hw:0,x.


> > No, take a look at git commit 485100706b4b397f8072c756839878f634e21f85:
> > 
> >    [ALSA] ca0106: power down SPI DAC channels when not in use
> >     
> >     For cards with an SPI DAC (SB Live 24-bit / Audigy SE), power down channels
> >     0-2 when not in use.  They are powered up on PCM open and down again on PCM
> >     close.  Channel 4 (== Front) is not powered down, as it is used for capture
> >     feedback.  Powering it down would effectively kill line in pass-through.
> >     
> > So, it's the designed behavior.
> 
> Judging by that commit, Trent actually had a datasheet to work with, so
> I'm inclined to trust it more. However, I just wonder if the other cards
> have had full testing of all their outputs - only the "X-Fi Extreme
> Audio" claims to have had all 6 channels tested.

Maybe not all boards have been tested.  I don't disagree with your
change.  My suggestion is to apply it only for devices that are known
to work with your change.  Other can follow later if it suits better.


> > Judging from the fact that this mapping hasn't been changed since that
> > time, I feel that it's not safe to change the mapping unconditionally
> > for your device.  That's why I suggest for some new flag.
> 
> So if it is a new flag. I'd be tempted to instead include the mappings
> in the chip_details struct, rather than a single purpose flag for one
> device (which will surely be difficult to name well).

Yeah, I thought of a similar thing later :)
We can have a single integer, such as 0x0123, indicating the DAC slot
of each channel.

> The other change
> I'd be tempted to make would be to avoid exposing channels that don't
> exist (like the side channels, or spdif for this device). Is that a
> sensible step? Do any other drivers have to solve a similar problem?

Sounds good.

> I've attached the first patch with the sign-off line if you want to put
> it in now. Otherwise, I'm happy to wait until everything is sorted out,
> and put it all in together.

Let's merge all together.


thanks,

Takashi