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

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