Am 28.01.2013 13:36, schrieb Pavel Hofman:
> Right, looks like a bug in snd_ak4114_create. Nevertheless the 7th reg
> RCS0 is read-only, writing anything bogus should not affect the operation.
Ok. I once filled it with a zero with no effect.

> 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?


>> @Pavel, btw. I also have an ESI Juli@. Spdif capture with this one does not
>> work at all (as compared to "kind of working" with the Audiophile 192).
> Interesting. I am pretty sure I tested the SPDIF input of Juli quite
> extensively. It even reported the incoming samplerate correctly. How did
> you test it? Please list amixer contents and ak4114 regs here. Thanks.

I just tried again. The Juli just seem to freeze the whole alsa when I 
try to access the spdif input.

See attached Juli files. There _is_ an ak4114 file.

- Jonas