On 2.2.2013 02:22, Jonas Petersen wrote:
:-)
I've got some progress here. The AK4114_ADDR was wrong. I changed it from 0x02 to 0x00 (according to datasheet).
Fantastic, congrats.
Now I had some meat in the ak4114 file, but no signal was coming in. Then I found that the wrong spdif receiver channel was selected (the AK4114 has 4). After selecting the right one (0 instead of 1) I got the signal!
Yes, that is a common issue, every card uses a different ak411X input :) Great you found it.
Its at the right level (-12dB) and the L/R channels match. But it's somehow capturing twice the rate. The 1 kHz come in as 2 kHz. There must still be something wrong.
That is actually quite common too :) Please take a look at the initial comment section of prodigy192.c where I describe the setup I had to figure out experimentally. You will have to play with OCKS0/1 of ak4114 (initial chip config in ap192_ak4114_init). Should you not be able to find the right combination suitable for all incoming samplerates, you can play with VT1724_MT_I2S_MCLK_128X of ice1724 (default defined in ice1724.c:stdclock_set_spdif_clock , can be overriden in ice->set_spdif_clock for the ap192).
Regarding the sample rate detection. It seems it's the channel status bits that get interpreted by the windows driver. The fs bits from the AK4114 seem to be unused. But the channel status definitely changes some bits on sample rate changes.
Good catch. Would the FSx registers provide correct info, or interpretation of the RX Channel status bytes will have to implemented into ak4114.c:snd_ak4114_rate_get?
Back to the light indicating "sync source" in the windows driver. I think it is reading status of GPIO06 as you reported "INT0 (pin36) -- GPIO6 pin 58". It would be possible to add a new read-only control for sync source to revo.c for ap192. It might be useful. Of course a generic method for ak4114.c would be more suitable but we would have to abstract the reading method.
Thanks a lot for your effort.
Best regards,
Pavel.