[alsa-devel] M-Audio Audiophile 192 (ice1724)'s broken spdif capture
Pavel Hofman
pavel.hofman at ivitera.com
Sat Feb 2 11:44:36 CET 2013
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.
More information about the Alsa-devel
mailing list