[alsa-devel] [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