[alsa-devel] M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

in ap192_ak4114_init() of revo.c I see this:

----
    static const unsigned char ak4114_init_vals[] = {
        AK4114_RST | AK4114_PWN | AK4114_OCKS0 | AK4114_OCKS1,
        AK4114_DIF_I24I2S,
        AK4114_TX1E,
        AK4114_EFH_1024 | AK4114_DIT | AK4114_IPS(1),
        0,
        0
    };
    static const unsigned char ak4114_init_txcsb[] = {
        0x41, 0x02, 0x2c, 0x00, 0x00
    };
----

Something wrong here maybe?

I noticed that the ak4114_init_vals array has 6 values but in
ap192_ak4114_init() 7 values get written to ak4114.regmap.

@Pavel, btw. I also have an ESI Juli at . Spdif capture with this one does not
work at all (as compared to "kind of working" with the Audiophile 192).

- Jonas



2013/1/26 Pavel Hofman <pavel.hofman at ivitera.com>

> > Date 26.1.2013 17:35, Jonas Petersen wrote:
> >> Hi there,
> >>
> >> I'm trying to get spdif capture to work properly on the M-Audio
> >> Audiophile
> >> 192 (VT1724/Envy24HT). It is generally working, but I don't get a clean
> >> signal.
> >>
> >> I have "Multi Track Internal Clock" set to "IEC958 In" (spdif in). When
> >> I
> >> capture via Jack, arecord or Audacity I experience the following two
> >> phenomenons (always):
> >>
> >> 1.) The captured signal ends up 6 dB(FS) to loud (200%)! Everything
> >> above
> >> -6 dB is distorting. A 1 kHz sine test signal at -12 dB (25%) will be
> >> captured as -6 dB (50%).
> >>
> >> 2.) The left and right channels are shifted by one sample! When I feed a
> >> 1
> >> kHz test signal (L+R are _exactly_ the same signal), the right channel
> >> will
> >> be offset by exactly one sample. Zooming into the waveform clearly shows
> >> that. Analyzing the signal with a goniometer shows a (slight but
> >> obvious)
> >> vertical eliptical shape and not the expected single vertical line.
> >>
> >> To make sure the hardware actually works fine, I did install a Windows 7
> >> on
> >> the exact same machine, installed the drivers from M-Audio and did some
> >> recording with audacity. The result is as expected: the -12 dB signal
> >> ends
> >> up as -12 dB and the left and right channel exactly match each other. So
> >> the hardware is willing.
> >>
> >> I am running a Lubuntu 12.10 and I'm am able to compile and run the
> >> current
> >> alsa-driver source with the 3.5.0-22 kernel. I played around a bit with
> >> the
> >> alsa driver source (e.g. pci/ice1712/ice1724.c, pci/ice1712/revo.c) and
> >> I
> >> am able to compile and load a modified driver. So far I only was able to
> >> make the problem worse though.
> >>
> >> I'd now like to ask for some advice on how to approach the problem. I
> >> guess
> >> the fact that the left and right channel differ - even though they
> >> shouldn't - might be a thing to look for. This must be happening at some
> >> stage in the capturing. Is there a way to hook in at different places to
> >> narrow down what causes this?
> >>
> >> Maybe this even already rings somebody's bells?
> >>
> >> I'll be glad to deliver more information when needed.
> >
> > I believe that there must be a S/PDIF receiver IC somewhere on the board
> > and this IC may be wrongly configured.
>
> http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg
> reveals it is AK4114, just like in ESI Juli. Its default serial data
> protocol  is not 24bit I2S, the format expected by ICE1724.
>
> It should be feasible to trace the GPIOs from ICE1724 to AK4114 and add
> the config code.
>
> Regards,
>
> Pavel.
>
>