Am 29.01.2013 10:39, schrieb Pavel Hofman:
What does the ak4114 regs dump in /proc/asound... dir of your audiophile192 look like? The snd_ak4114_proc_regs_read method reads real values from the regs.
You know what, there ist no ak4114... See the attached Audiophile192-proc.txt. That's everything in proc. Before I was doing some printk's in snd_ak4114_create() and snd_ak4114_reg_write() and other places. They ended up in kern.log. Then was also fiddling around with the configuration (ak4114_init_vals) which didn't change anything in the capture behaviour. I even entirely removed the snd_ak4114_create() call. It was still just capturing spdif 6 dB to loud with the shifted signals as described before. So the ak4114 code is not in operation at all?
First, please tell us your alsa version (/proc/asound/version)
~$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.25. Compiled on Jan 28 2013 for kernel 3.5.0-22-generic (SMP).
~$ uname -a Linux proto2c 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:41:11 UTC 2013 i686 athlon i686 GNU/Linux
By the way, I'm compiling a driver snapshot from 24-01-2013. The plain 1.0.25 gives errors.
Please move the ak4114 init call from the controls section to the init section (just like in juli.c) and test:
diff --git a/sound/pci/ice1712/revo.c b/sound/pci/ice1712/revo.c index 7641080..bb6c82a 100644 --- a/sound/pci/ice1712/revo.c +++ b/sound/pci/ice1712/revo.c @@ -562,6 +562,9 @@ static int revo_init(struct snd_ice1712 *ice) ice); if (err < 0) return err;
err = ap192_ak4114_init(ice);if (err < 0)return err; /* unmute all codecs */ snd_ice1712_gpio_write_bits(ice, VT1724_REVO_MUTE,@@ -597,9 +600,6 @@ static int revo_add_controls(struct snd_ice1712 *ice) err = snd_ice1712_akm4xxx_build_controls(ice); if (err < 0) return err;
err = ap192_ak4114_init(ice);if (err < 0)return err; break; } return 0;
I did that with no success. Same behaviour, no change, still no ak4114. The only difference I got was:
$ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt 90c90 < MT05 : 0x08 ---
MT05 : 0x00
I printk'ed a message in ap192_ak4114_init() and it's definitely being called.
Any other ideas?
- Jonas