[alsa-devel] M-Audio Audiophile 192 (ice1724)'s broken spdif capture
Jonas Petersen
jnsptrsn1 at gmail.com
Tue Jan 29 20:14:47 CET 2013
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
More information about the Alsa-devel
mailing list