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