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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
