M-Audio Audiophile 192 (ice1724)'s broken spdif capture

M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

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.

Thanks and regards,
Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jaroslav Kysela]

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. This IC is not handled in the
current ALSA driver at all. Could you look to your board and check the
used chips? From pictures on internet, a suspicious IC is in the middle
of top on this PCI card. The AKM IC's are for analog audio outputs.

The ICE1724 chip has only serial SPDIF input and SPDIF input clock pins.
The input samples should be copied to the DMA without any modifications
(no volume control etc.).

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

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

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Hi Jaroslav,

I think I found it. I followed the spdif in and it leads to U19 which is an
AKM AK4114VQ ("High Feature 192kHz 24bit Digital Audio Interface
Transceiver"). It's the topmost of the very right of the card (below the
"M-AUDIO" lettering).

There is code for this chip in the driver-source (i2c/other/ak4114.c) and
it's also referenced in the code for the Audiophile 192 (see revo.c and
revo.h).

Or do you think there's another chip involved?

- Jonas


2013/1/26 Jaroslav Kysela <perex@perex.cz>

>
> I believe that there must be a S/PDIF receiver IC somewhere on the board
> and this IC may be wrongly configured. This IC is not handled in the
> current ALSA driver at all. Could you look to your board and check the
> used chips? From pictures on internet, a suspicious IC is in the middle
> of top on this PCI card. The AKM IC's are for analog audio outputs.
>
> The ICE1724 chip has only serial SPDIF input and SPDIF input clock pins.
> The input samples should be copied to the DMA without any modifications
> (no volume control etc.).
>
>                                         Jaroslav
>
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project; Red Hat, Inc.
>

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

In revo.c I found this:

/* AK4114 support on Audiophile 192 */
/* CDTO (pin 32) -- GPIO2 pin 52
 * CDTI (pin 33) -- GPIO3 pin 53 (shared with AK4358)
 * CCLK (pin 34) -- GPIO1 pin 51 (shared with AK4358)
 * CSN  (pin 35) -- GPIO7 pin 59
 */
#define AK4114_ADDR 0x02

I verified these mappings and can confirm that they're correct.

I found one more connection:

INT0 (pin36) -- GPIO6 pin 58

So the complete (?) list with complete pin names on the AK4114 would be:

ICE1724 -> AK4114

GPIO1 -> OCKS1/CCLK/SCL
GPIO2 -> CM0/CDTO/CAD1
GPIO3 -> CM1/CDTI/SDA
GPIO6 -> INT0
GPIO7 -> OCKS0/CSN/CAD0

I can not rule out that there are more connections! If you think there
should be more connections I'll do some more tracing.
It is a bit tedious <http://www.dict.cc/englisch-deutsch/tedious.html> because
not all connections can be traced visually. I did that with a multimeter.

If anybody needs datasheets for the VT1724 or AK4114, I have them available.

What would be next? Right now I have no idea how to verify that in the
existing code.

- Jonas


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

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

Re: 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@. 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@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.
>
>

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jaroslav Kysela]

Date 27.1.2013 16:49, Jonas Petersen wrote:
> 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.

Looking to the AK4114 datasheet. I would try the clock mode 2
(CM1=1,CM0=0) and also, check if there is a 11.2896Mhz crystal used for
the reference clock (XTL1, XTL0).

Also, the note in revo.c that the input rate reported by AK4114 is
unstable, clearly shows that the clock logic is screwed (misconfigured).

					Jaroslav

> 
> @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).
> 
> - Jonas
> 
> 
> 
> 2013/1/26 Pavel Hofman <pavel.hofman@ivitera.com
> <mailto:pavel.hofman@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.
> 
> 


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 27.1.2013 16:49, Jonas Petersen wrote:
> 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?

These values look correct.

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

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.

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.

> 
> @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.

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 28.1.2013 10:29, Jaroslav Kysela wrote:
> Date 27.1.2013 16:49, Jonas Petersen wrote:
>> 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.
> 
> Looking to the AK4114 datasheet. I would try the clock mode 2 
> (CM1=1,CM0=0) and also, check if there is a 11.2896Mhz crystal used
> for the reference clock (XTL1, XTL0). Also, the note in revo.c that
> the input rate reported by AK4114 is unstable, clearly shows that the
> clock logic is screwed (misconfigured).


The crystal is not used
http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg
. IME ak411x cards without the auxiliary Xiling fpga do not provide the
independent clock from ak411X and thus cannot report the input rate
correctly. That is why I do not make use of the value in the driver
(ak->check_flags = AK4114_CHECK_NO_RATE)

Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are
connected to logical high? They should be :)

Regards,

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Am 28.01.2013 13:52, schrieb Pavel Hofman:
> On 28.1.2013 10:29, Jaroslav Kysela wrote:
>> Date 27.1.2013 16:49, Jonas Petersen wrote:
>>> 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.
>> Looking to the AK4114 datasheet. I would try the clock mode 2
>> (CM1=1,CM0=0) and also, check if there is a 11.2896Mhz crystal used
>> for the reference clock (XTL1, XTL0). Also, the note in revo.c that
>> the input rate reported by AK4114 is unstable, clearly shows that the
>> clock logic is screwed (misconfigured).
>
> The crystal is not used
> http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg
> . IME ak411x cards without the auxiliary Xiling fpga do not provide the
> independent clock from ak411X and thus cannot report the input rate
> correctly. That is why I do not make use of the value in the driver
> (ak->check_flags = AK4114_CHECK_NO_RATE)
>
> Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are
> connected to logical high? They should be :)

Physically they're both on ground. I don't know what active state that 
chip has though.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

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



[-- Attachment #2: Audiophile192-amixer.txt --]
[-- Type: text/plain, Size: 1554 bytes --]

Simple mixer control 'PCM',0
  Capabilities: pvolume penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 79 [62%] [-24.00dB]
  Front Right: Playback 79 [62%] [-24.00dB]
Simple mixer control 'IEC958',0
  Capabilities: penum
  Items: 'PCM Out' 'H/W In 0' 'H/W In 1' 'IEC958 In L' 'IEC958 In R'
  Item0: 'PCM Out'
Simple mixer control 'IEC958 Output',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',1
  Capabilities: penum
  Items: 'PCM Out' 'H/W In 0' 'H/W In 1' 'IEC958 In L' 'IEC958 In R'
  Item0: 'PCM Out'
Simple mixer control 'Deemphasis',0
  Capabilities: enum
  Items: '44.1kHz' 'Off' '48kHz' '32kHz'
  Item0: 'Off'
Simple mixer control 'H/W',0
  Capabilities: penum
  Items: 'PCM Out' 'H/W In 0' 'H/W In 1' 'IEC958 In L' 'IEC958 In R'
  Item0: 'PCM Out'
Simple mixer control 'H/W',1
  Capabilities: penum
  Items: 'PCM Out' 'H/W In 0' 'H/W In 1' 'IEC958 In L' 'IEC958 In R'
  Item0: 'PCM Out'
Simple mixer control 'Multi Track Internal Clock',0
  Capabilities: enum
  Items: '8000' '9600' '11025' '12000' '16000' '22050' '24000' '32000' '44100' '48000' '64000' '88200' '96000' '176400' '192000' 'IEC958 In'
  Item0: 'IEC958 In'
Simple mixer control 'Multi Track Rate Locking',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'Multi Track Rate Reset',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]

[-- Attachment #3: Audiophile192-proc.txt --]
[-- Type: text/plain, Size: 5619 bytes --]


/proc/asound/Audiophile192/oss_mixer

VOLUME "" 0
BASS "" 0
TREBLE "" 0
SYNTH "" 0
PCM "PCM" 0
SPEAKER "" 0
LINE "" 0
MIC "" 0
CD "" 0
IMIX "" 0
ALTPCM "" 0
RECLEV "" 0
IGAIN "" 0
OGAIN "" 0
LINE1 "" 0
LINE2 "" 0
LINE3 "" 0
DIGITAL1 "IEC958" 0
DIGITAL2 "" 0
DIGITAL3 "" 0
PHONEIN "" 0
PHONEOUT "" 0
VIDEO "" 0
RADIO "" 0
MONITOR "" 0

/proc/asound/Audiophile192/id

Audiophile192

/proc/asound/Audiophile192/ice1724

M Audio Audiophile192 at 0xd080, irq 20

EEPROM:
  Subvendor        : 0x12143236
  Size             : 19 bytes
  Version          : 2
  System Config    : 0x68
  ACLink           : 0x80
  I2S              : 0xf8
  S/PDIF           : 0xc3
  GPIO direction   : 0x7fffba
  GPIO mask        : 0x45
  GPIO state       : 0x4000b5
  Extra #18        : 0x0

Registers:
  PSDOUT03 : 0x00000000
  CCS00    : 0x00
  CCS01    : 0xa0
  CCS02    : 0x20
  CCS03    : 0x00
  CCS04    : 0x68
  CCS05    : 0x80
  CCS06    : 0xf8
  CCS07    : 0xc3
  CCS08    : 0x00
  CCS09    : 0x00
  CCS0a    : 0x00
  CCS0b    : 0x00
  CCS0c    : 0x00
  CCS0d    : 0x0b
  CCS0e    : 0x01
  CCS0f    : 0x00
  CCS10    : 0xa0
  CCS11    : 0x12
  CCS12    : 0x40
  CCS13    : 0x80
  CCS14    : 0xfa
  CCS15    : 0x08
  CCS16    : 0x45
  CCS17    : 0x00
  CCS18    : 0xba
  CCS19    : 0xff
  CCS1a    : 0x7f
  CCS1b    : 0x00
  CCS1c    : 0x00
  CCS1d    : 0x00
  CCS1e    : 0x40
  CCS1f    : 0x00
  MT00     : 0x00
  MT01     : 0x10
  MT02     : 0x00
  MT03     : 0x08
  MT04     : 0x00
  MT05     : 0x00
  MT06     : 0x00
  MT07     : 0x00
  MT08     : 0x00
  MT09     : 0x00
  MT0a     : 0x00
  MT0b     : 0x00
  MT0c     : 0x00
  MT0d     : 0x00
  MT0e     : 0x00
  MT0f     : 0x00
  MT10     : 0x00
  MT11     : 0x00
  MT12     : 0x00
  MT13     : 0x00
  MT14     : 0x00
  MT15     : 0x00
  MT16     : 0x00
  MT17     : 0x00
  MT18     : 0x00
  MT19     : 0x00
  MT1a     : 0x00
  MT1b     : 0x00
  MT1c     : 0x00
  MT1d     : 0x00
  MT1e     : 0x00
  MT1f     : 0x00
  MT20     : 0x00
  MT21     : 0x00
  MT22     : 0x00
  MT23     : 0x00
  MT24     : 0x00
  MT25     : 0x00
  MT26     : 0x00
  MT27     : 0x00
  MT28     : 0x00
  MT29     : 0x00
  MT2a     : 0x00
  MT2b     : 0x00
  MT2c     : 0x00
  MT2d     : 0x00
  MT2e     : 0x00
  MT2f     : 0x00

/proc/asound/Audiophile192/ak4358

chip 0: 0x00 = 0x06
chip 0: 0x01 = 0x01
chip 0: 0x02 = 0x4e
chip 0: 0x03 = 0x01
chip 0: 0x04 = 0xcf
chip 0: 0x05 = 0xcf
chip 0: 0x06 = 0x00
chip 0: 0x07 = 0x00
chip 0: 0x08 = 0x00
chip 0: 0x09 = 0x00
chip 0: 0x0a = 0x00
chip 0: 0x0b = 0x00
chip 0: 0x0c = 0x00
chip 0: 0x0d = 0x00
chip 0: 0x0e = 0x00
chip 0: 0x0f = 0x00

/proc/asound/Audiophile192/midi0

ICE1724 MIDI

Output 0
  Tx bytes     : 0
Input 0
  Rx bytes     : 0

/proc/asound/Audiophile192/pcm1c/oss


/proc/asound/Audiophile192/pcm1c/sub0/prealloc_max

256

/proc/asound/Audiophile192/pcm1c/sub0/prealloc

256

/proc/asound/Audiophile192/pcm1c/sub0/status

closed

/proc/asound/Audiophile192/pcm1c/sub0/sw_params

closed

/proc/asound/Audiophile192/pcm1c/sub0/hw_params

closed

/proc/asound/Audiophile192/pcm1c/sub0/info

card: 0
device: 1
subdevice: 0
stream: CAPTURE
id: ICE1724 IEC958
name: ICE1724 IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Audiophile192/pcm1c/info

card: 0
device: 1
subdevice: 0
stream: CAPTURE
id: ICE1724 IEC958
name: ICE1724 IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Audiophile192/pcm1p/oss


/proc/asound/Audiophile192/pcm1p/sub0/prealloc_max

256

/proc/asound/Audiophile192/pcm1p/sub0/prealloc

256

/proc/asound/Audiophile192/pcm1p/sub0/status

closed

/proc/asound/Audiophile192/pcm1p/sub0/sw_params

closed

/proc/asound/Audiophile192/pcm1p/sub0/hw_params

closed

/proc/asound/Audiophile192/pcm1p/sub0/info

card: 0
device: 1
subdevice: 0
stream: PLAYBACK
id: ICE1724 IEC958
name: ICE1724 IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Audiophile192/pcm1p/info

card: 0
device: 1
subdevice: 0
stream: PLAYBACK
id: ICE1724 IEC958
name: ICE1724 IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Audiophile192/pcm0c/oss


/proc/asound/Audiophile192/pcm0c/sub0/prealloc_max

256

/proc/asound/Audiophile192/pcm0c/sub0/prealloc

256

/proc/asound/Audiophile192/pcm0c/sub0/status

closed

/proc/asound/Audiophile192/pcm0c/sub0/sw_params

closed

/proc/asound/Audiophile192/pcm0c/sub0/hw_params

closed

/proc/asound/Audiophile192/pcm0c/sub0/info

card: 0
device: 0
subdevice: 0
stream: CAPTURE
id: ICE1724
name: ICE1724
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Audiophile192/pcm0c/info

card: 0
device: 0
subdevice: 0
stream: CAPTURE
id: ICE1724
name: ICE1724
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Audiophile192/pcm0p/oss


/proc/asound/Audiophile192/pcm0p/sub0/prealloc_max

256

/proc/asound/Audiophile192/pcm0p/sub0/prealloc

256

/proc/asound/Audiophile192/pcm0p/sub0/status

closed

/proc/asound/Audiophile192/pcm0p/sub0/sw_params

closed

/proc/asound/Audiophile192/pcm0p/sub0/hw_params

closed

/proc/asound/Audiophile192/pcm0p/sub0/info

card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: ICE1724
name: ICE1724
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Audiophile192/pcm0p/info

card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: ICE1724
name: ICE1724
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

[-- Attachment #4: Juli-amixer.txt --]
[-- Type: text/plain, Size: 2637 bytes --]

Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 127
  Mono: Playback 87 [69%] [-20.00dB] [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 127 [100%] [0.00dB]
  Front Right: Playback 127 [100%] [0.00dB]
Simple mixer control 'IEC958',0
  Capabilities: penum
  Items: 'PCM Out' 'H/W In 0' 'H/W In 1' 'IEC958 In L' 'IEC958 In R'
  Item0: 'PCM Out'
Simple mixer control 'IEC958 Output',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',1
  Capabilities: penum
  Items: 'PCM Out' 'H/W In 0' 'H/W In 1' 'IEC958 In L' 'IEC958 In R'
  Item0: 'PCM Out'
Simple mixer control 'Deemphasis',0
  Capabilities: enum
  Items: '44.1kHz' 'Off' '48kHz' '32kHz'
  Item0: 'Off'
Simple mixer control 'H/W',0
  Capabilities: penum
  Items: 'PCM Out' 'H/W In 0' 'H/W In 1' 'IEC958 In L' 'IEC958 In R'
  Item0: 'PCM Out'
Simple mixer control 'H/W',1
  Capabilities: penum
  Items: 'PCM Out' 'H/W In 0' 'H/W In 1' 'IEC958 In L' 'IEC958 In R'
  Item0: 'PCM Out'
Simple mixer control 'Monitor Analog In',0
  Capabilities: volume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 127
  Front Left: 0 [0%] [-99999.99dB] Playback [off]
  Front Right: 0 [0%] [-99999.99dB] Playback [off]
Simple mixer control 'Monitor Digital In',0
  Capabilities: volume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 127
  Front Left: 0 [0%] [-99999.99dB] Playback [off]
  Front Right: 0 [0%] [-99999.99dB] Playback [off]
Simple mixer control 'Monitor Digital Out',0
  Capabilities: volume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 127
  Front Left: 0 [0%] [-99999.99dB] Playback [off]
  Front Right: 0 [0%] [-99999.99dB] Playback [off]
Simple mixer control 'Multi Track Internal Clock',0
  Capabilities: enum
  Items: '16000' '22050' '24000' '32000' '44100' '48000' '64000' '88200' '96000' '176400' '192000' 'IEC958 In'
  Item0: 'IEC958 In'
Simple mixer control 'Multi Track Rate Locking',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'Multi Track Rate Reset',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]

[-- Attachment #5: Juli-proc.txt --]
[-- Type: text/plain, Size: 5682 bytes --]


/proc/asound/Juli/oss_mixer

VOLUME "Master" 0
BASS "" 0
TREBLE "" 0
SYNTH "" 0
PCM "PCM" 0
SPEAKER "" 0
LINE "" 0
MIC "" 0
CD "" 0
IMIX "" 0
ALTPCM "" 0
RECLEV "" 0
IGAIN "" 0
OGAIN "" 0
LINE1 "" 0
LINE2 "" 0
LINE3 "" 0
DIGITAL1 "IEC958" 0
DIGITAL2 "" 0
DIGITAL3 "" 0
PHONEIN "" 0
PHONEOUT "" 0
VIDEO "" 0
RADIO "" 0
MONITOR "" 0

/proc/asound/Juli/id

Juli

/proc/asound/Juli/ice1724

ESI Juli@ at 0xd080, irq 20

EEPROM:
  Subvendor        : 0x31305345
  Size             : 19 bytes
  Version          : 2
  System Config    : 0x2b
  ACLink           : 0x80
  I2S              : 0xf8
  S/PDIF           : 0xc3
  GPIO direction   : 0x7fff9f
  GPIO mask        : 0x7f0060
  GPIO state       : 0x1a
  Extra #18        : 0x0

Registers:
  PSDOUT03 : 0x00000000
  CCS00    : 0x00
  CCS01    : 0xa0
  CCS02    : 0x20
  CCS03    : 0x00
  CCS04    : 0x2b
  CCS05    : 0x80
  CCS06    : 0xf8
  CCS07    : 0xc3
  CCS08    : 0x00
  CCS09    : 0x00
  CCS0a    : 0x00
  CCS0b    : 0x00
  CCS0c    : 0x00
  CCS0d    : 0x0b
  CCS0e    : 0x01
  CCS0f    : 0x00
  CCS10    : 0x20
  CCS11    : 0x06
  CCS12    : 0x10
  CCS13    : 0x80
  CCS14    : 0x79
  CCS15    : 0x00
  CCS16    : 0x60
  CCS17    : 0x00
  CCS18    : 0x9f
  CCS19    : 0xff
  CCS1a    : 0x7f
  CCS1b    : 0x00
  CCS1c    : 0x00
  CCS1d    : 0x00
  CCS1e    : 0x00
  CCS1f    : 0x7f
  MT00     : 0x00
  MT01     : 0x10
  MT02     : 0x00
  MT03     : 0x08
  MT04     : 0x00
  MT05     : 0x00
  MT06     : 0x00
  MT07     : 0x00
  MT08     : 0x00
  MT09     : 0x00
  MT0a     : 0x00
  MT0b     : 0x00
  MT0c     : 0x00
  MT0d     : 0x00
  MT0e     : 0x00
  MT0f     : 0x00
  MT10     : 0x00
  MT11     : 0x00
  MT12     : 0x00
  MT13     : 0x00
  MT14     : 0x00
  MT15     : 0x00
  MT16     : 0x00
  MT17     : 0x00
  MT18     : 0x00
  MT19     : 0x00
  MT1a     : 0x00
  MT1b     : 0x00
  MT1c     : 0x00
  MT1d     : 0x00
  MT1e     : 0x00
  MT1f     : 0x00
  MT20     : 0x00
  MT21     : 0x00
  MT22     : 0x00
  MT23     : 0x00
  MT24     : 0x00
  MT25     : 0x00
  MT26     : 0x00
  MT27     : 0x00
  MT28     : 0x00
  MT29     : 0x00
  MT2a     : 0x00
  MT2b     : 0x00
  MT2c     : 0x00
  MT2d     : 0x00
  MT2e     : 0x00
  MT2f     : 0x00

/proc/asound/Juli/ak4358

chip 0: 0x00 = 0x06
chip 0: 0x01 = 0x01
chip 0: 0x02 = 0x4e
chip 0: 0x03 = 0x01
chip 0: 0x04 = 0xd7
chip 0: 0x05 = 0xd7
chip 0: 0x06 = 0x00
chip 0: 0x07 = 0x00
chip 0: 0x08 = 0x00
chip 0: 0x09 = 0x00
chip 0: 0x0a = 0x00
chip 0: 0x0b = 0x00
chip 0: 0x0c = 0x00
chip 0: 0x0d = 0x00
chip 0: 0x0e = 0x00
chip 0: 0x0f = 0x00

/proc/asound/Juli/ak4114

0x00 = 0x0f
0x01 = 0x70
0x02 = 0x80
0x03 = 0x49
0x04 = 0x00
0x05 = 0x00
0x06 = 0x10
0x07 = 0x10
0x08 = 0x00
0x09 = 0x00
0x0a = 0x00
0x0b = 0x00
0x0c = 0x00
0x0d = 0x41
0x0e = 0x02
0x0f = 0x2c
0x10 = 0x00
0x11 = 0x00
0x12 = 0x00
0x13 = 0x00
0x14 = 0x00
0x15 = 0x00
0x16 = 0x00
0x17 = 0x00
0x18 = 0x00
0x19 = 0x00
0x1a = 0x00
0x1b = 0x00
0x1c = 0x00
0x1d = 0x00
0x1e = 0x00
0x1f = 0x00

/proc/asound/Juli/midi0

ICE1724 MIDI

Output 0
  Tx bytes     : 0
Input 0
  Rx bytes     : 0

/proc/asound/Juli/pcm1c/oss


/proc/asound/Juli/pcm1c/sub0/prealloc_max

256

/proc/asound/Juli/pcm1c/sub0/prealloc

256

/proc/asound/Juli/pcm1c/sub0/status

closed

/proc/asound/Juli/pcm1c/sub0/sw_params

closed

/proc/asound/Juli/pcm1c/sub0/hw_params

closed

/proc/asound/Juli/pcm1c/sub0/info

card: 0
device: 1
subdevice: 0
stream: CAPTURE
id: ICE1724 IEC958
name: ICE1724 IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Juli/pcm1c/info

card: 0
device: 1
subdevice: 0
stream: CAPTURE
id: ICE1724 IEC958
name: ICE1724 IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Juli/pcm1p/oss


/proc/asound/Juli/pcm1p/sub0/prealloc_max

256

/proc/asound/Juli/pcm1p/sub0/prealloc

256

/proc/asound/Juli/pcm1p/sub0/status

closed

/proc/asound/Juli/pcm1p/sub0/sw_params

closed

/proc/asound/Juli/pcm1p/sub0/hw_params

closed

/proc/asound/Juli/pcm1p/sub0/info

card: 0
device: 1
subdevice: 0
stream: PLAYBACK
id: ICE1724 IEC958
name: ICE1724 IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Juli/pcm1p/info

card: 0
device: 1
subdevice: 0
stream: PLAYBACK
id: ICE1724 IEC958
name: ICE1724 IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Juli/pcm0c/oss


/proc/asound/Juli/pcm0c/sub0/prealloc_max

256

/proc/asound/Juli/pcm0c/sub0/prealloc

256

/proc/asound/Juli/pcm0c/sub0/status

closed

/proc/asound/Juli/pcm0c/sub0/sw_params

closed

/proc/asound/Juli/pcm0c/sub0/hw_params

closed

/proc/asound/Juli/pcm0c/sub0/info

card: 0
device: 0
subdevice: 0
stream: CAPTURE
id: ICE1724
name: ICE1724
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Juli/pcm0c/info

card: 0
device: 0
subdevice: 0
stream: CAPTURE
id: ICE1724
name: ICE1724
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Juli/pcm0p/oss


/proc/asound/Juli/pcm0p/sub0/prealloc_max

256

/proc/asound/Juli/pcm0p/sub0/prealloc

256

/proc/asound/Juli/pcm0p/sub0/status

closed

/proc/asound/Juli/pcm0p/sub0/sw_params

closed

/proc/asound/Juli/pcm0p/sub0/hw_params

closed

/proc/asound/Juli/pcm0p/sub0/info

card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: ICE1724
name: ICE1724
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

/proc/asound/Juli/pcm0p/info

card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: ICE1724
name: ICE1724
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

[-- Attachment #6: Type: text/plain, Size: 0 bytes --]

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 29.1.2013 01:32, Jonas Petersen wrote:
> 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.

That is what I thought. We will fix the code though.
> 
>> 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?

First, please tell us your alsa version (/proc/asound/version)

Please move the ak4114 init call from the controls section to the init
section (just like in juli.c) and test:

diff --git a/sound/pci/ice1712/revo.c b/sound/pci/ice1712/revo.c
index 7641080..bb6c82a 100644
--- a/sound/pci/ice1712/revo.c
+++ b/sound/pci/ice1712/revo.c
@@ -562,6 +562,9 @@ static int revo_init(struct snd_ice1712 *ice)
                                               ice);
                if (err < 0)
                        return err;
+               err = ap192_ak4114_init(ice);
+               if (err < 0)
+                       return err;

                /* unmute all codecs */
                snd_ice1712_gpio_write_bits(ice, VT1724_REVO_MUTE,
@@ -597,9 +600,6 @@ static int revo_add_controls(struct snd_ice1712 *ice)
                err = snd_ice1712_akm4xxx_build_controls(ice);
                if (err < 0)
                        return err;
-               err = ap192_ak4114_init(ice);
-               if (err < 0)
-                       return err;
                break;
        }
        return 0;

> 
> 
>>> @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.

OK, let's do some troubleshooting. Do you have SPDIF signal present at
Juli's input when you try to capture?

Does it lock the moment you open the capture stream (i.e. start the
capturing), or when you switch the rate selector to IEC958-In?


What is your kernel (uname -a)?

Regards,

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 28.1.2013 22:25, Jonas Petersen wrote:
>> Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are
>> connected to logical high? They should be :)
> 
> Physically they're both on ground. I don't know what active state that
> chip has though.
> 

Let 's wait until we get the ak4114 register dump file :)

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Am 29.01.2013 10:39, schrieb Pavel Hofman:
> @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.
> OK, let's do some troubleshooting. Do you have SPDIF signal present at
> Juli's input when you try to capture?

Yes, normally I have a 1 kHz Sine/-12dB(25%)/44100 coming in when testing.

> Does it lock the moment you open the capture stream (i.e. start the
> capturing), or when you switch the rate selector to IEC958-In?

I have the Juli card in another machine right now. I'm using the analog 
out there, which is working fine. It's running a Ubuntu 12.10. 'uname 
-a' says

Linux rakete 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:41:11 UTC 2013 
i686 i686 i686 GNU/Linux

/proc/asound/version says:

Advanced Linux Sound Architecture Driver Version 1.0.25.

I behaves like this:

If I switch 'Multi Track Internal Clock' to 'IEC958 In', the whole 
system goes crazy. Not instantly, but when I start alsamixer it locks up 
(only alsamixer, it can not be killed -9 then). When doing 'ps -aux' it 
locks up somewhere in the middle of the list.
This is all with a signal going in the spdif input.
When I reboot (still with signal), the login screen locks up. I can move 
the mouse, but I can not input the password. Also the background image 
does not load (which normally does). I can switch to another terminal 
(e.g. ctrl-alt-f1) and log in. But it will hang sooner or later.
No way switch back the 'Multi Track Internal Clock' to a fixed rate.
Only if I disconnect the signal from the spdif input and reboot, then I 
can switch it back and bring the system back to reason. Pew...

- Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Am 29.01.2013 10:39, schrieb Pavel Hofman:
>>> 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?
> First, please tell us your alsa version (/proc/asound/version)

~$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.25.
Compiled on Jan 28 2013 for kernel 3.5.0-22-generic (SMP).

~$ uname -a
Linux proto2c 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:41:11 UTC 
2013 i686 athlon i686 GNU/Linux

By the way, I'm compiling a driver snapshot from 24-01-2013. The plain 
1.0.25 gives errors.


> Please move the ak4114 init call from the controls section to the init
> section (just like in juli.c) and test:
>
> diff --git a/sound/pci/ice1712/revo.c b/sound/pci/ice1712/revo.c
> index 7641080..bb6c82a 100644
> --- a/sound/pci/ice1712/revo.c
> +++ b/sound/pci/ice1712/revo.c
> @@ -562,6 +562,9 @@ static int revo_init(struct snd_ice1712 *ice)
>                                                 ice);
>                  if (err < 0)
>                          return err;
> +               err = ap192_ak4114_init(ice);
> +               if (err < 0)
> +                       return err;
>
>                  /* unmute all codecs */
>                  snd_ice1712_gpio_write_bits(ice, VT1724_REVO_MUTE,
> @@ -597,9 +600,6 @@ static int revo_add_controls(struct snd_ice1712 *ice)
>                  err = snd_ice1712_akm4xxx_build_controls(ice);
>                  if (err < 0)
>                          return err;
> -               err = ap192_ak4114_init(ice);
> -               if (err < 0)
> -                       return err;
>                  break;
>          }
>          return 0;

I did that with no success. Same behaviour, no change, still no ak4114. 
The only difference I got was:

$ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt
90c90
<   MT05     : 0x08
---
 >   MT05     : 0x00

I printk'ed a message in ap192_ak4114_init() and it's definitely being 
called.

Any other ideas?

- Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 29.1.2013 20:14, Jonas Petersen wrote:
> Am 29.01.2013 10:39, schrieb Pavel Hofman:
> 
> I did that with no success. Same behaviour, no change, still no ak4114.
> The only difference I got was:
> 
> $ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt
> 90c90
> <   MT05     : 0x08
> ---
>>   MT05     : 0x00
> 
> I printk'ed a message in ap192_ak4114_init() and it's definitely being
> called.
> 

I see, ak4114 support in revo.c is incomplete. ak4114 controls incl. the
proc file are never built. Please try the following patch (applicable to
clean git checkout):

diff --git a/sound/pci/ice1712/revo.c b/sound/pci/ice1712/revo.c
index 7641080..3f39c42 100644
--- a/sound/pci/ice1712/revo.c
+++ b/sound/pci/ice1712/revo.c
@@ -35,6 +35,7 @@
 struct revo51_spec {
        struct snd_i2c_device *dev;
        struct snd_pt2258 *pt2258;
+       struct ak4114 *ak4114;
 };

 static void revo_i2s_mclk_changed(struct snd_ice1712 *ice)
@@ -487,10 +488,10 @@ static int ap192_ak4114_init(struct snd_ice1712 *ice)
                                 ap192_ak4114_read,
                                 ap192_ak4114_write,
                                 ak4114_init_vals, ak4114_init_txcsb,
-                                ice, &ak);
+                                ice, &spec->ak4114);
        /* AK4114 in Revo cannot detect external rate correctly.
         * No reason to stop capture stream due to incorrect checks */
-       ak->check_flags = AK4114_CHECK_NO_RATE;
+       spec->ak4114->check_flags = AK4114_CHECK_NO_RATE;

        return 0; /* error ignored; it's no fatal error */
 }
@@ -562,6 +563,9 @@ static int revo_init(struct snd_ice1712 *ice)
                                               ice);
                if (err < 0)
                        return err;
+               err = ap192_ak4114_init(ice);
+               if (err < 0)
+                       return err;

                /* unmute all codecs */
                snd_ice1712_gpio_write_bits(ice, VT1724_REVO_MUTE,
@@ -597,9 +601,13 @@ static int revo_add_controls(struct snd_ice1712 *ice)
                err = snd_ice1712_akm4xxx_build_controls(ice);
                if (err < 0)
                        return err;
-               err = ap192_ak4114_init(ice);
+               /* only capture SPDIF over AK4114 */
+               spec = ice->spec;
+               err = snd_ak4114_build(spec->ak4114, NULL,
+
ice->pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream);
                if (err < 0)
-                       return err;
+               return err;
+
                break;
        }
        return 0;


Thanks,

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 29.1.2013 14:10, Jonas Petersen wrote:
> 
> If I switch 'Multi Track Internal Clock' to 'IEC958 In', the whole
> system goes crazy. Not instantly, but when I start alsamixer it locks up
> (only alsamixer, it can not be killed -9 then). When doing 'ps -aux' it
> locks up somewhere in the middle of the list.
> This is all with a signal going in the spdif input.
> When I reboot (still with signal), the login screen locks up. I can move
> the mouse, but I can not input the password. Also the background image
> does not load (which normally does). I can switch to another terminal
> (e.g. ctrl-alt-f1) and log in. But it will hang sooner or later.
> No way switch back the 'Multi Track Internal Clock' to a fixed rate.
> Only if I disconnect the signal from the spdif input and reboot, then I
> can switch it back and bring the system back to reason. Pew...

Thanks a lot for the description. I faintly recall I have heard about
this problem once (but never got hold of the reporter to solve). I will
take a look, and most likely ask you for more troubleshooting as I do
not have the card available. Thanks a lot.

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 30.1.2013 11:26, Pavel Hofman wrote:
> On 29.1.2013 20:14, Jonas Petersen wrote:
>> Am 29.01.2013 10:39, schrieb Pavel Hofman:
>>
>> I did that with no success. Same behaviour, no change, still no ak4114.
>> The only difference I got was:
>>
>> $ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt
>> 90c90
>> <   MT05     : 0x08
>> ---
>>>   MT05     : 0x00
>>
>> I printk'ed a message in ap192_ak4114_init() and it's definitely being
>> called.
>>
> 
> I see, ak4114 support in revo.c is incomplete. ak4114 controls incl. the
> proc file are never built. Please try the following patch (applicable to
> clean git checkout):


Sorry, of course

> +               err = snd_ak4114_build(ice->spec->ak4114, NULL,


instead of

> +               spec = ice->spec;
> +               err = snd_ak4114_build(spec->ak4114, NULL,

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

Am 30.01.2013 11:26, schrieb Pavel Hofman:
> On 29.1.2013 20:14, Jonas Petersen wrote:
>> Am 29.01.2013 10:39, schrieb Pavel Hofman:
>>
>> I did that with no success. Same behaviour, no change, still no ak4114.
>> The only difference I got was:
>>
>> $ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt
>> 90c90
>> <   MT05     : 0x08
>> ---
>>>    MT05     : 0x00
>> I printk'ed a message in ap192_ak4114_init() and it's definitely being
>> called.
>>
> I see, ak4114 support in revo.c is incomplete. ak4114 controls incl. the
> proc file are never built. Please try the following patch (applicable to
> clean git checkout):
>

Pavel, I applied your patch (including the correction in the other 
post). It did not work out of the box. I had to do a lot of debugging 
and changes to it to make it compile and then more of that fun to make 
it not crash alsa. One of the problems was that ice->spec is initialized 
in revo51_i2c_init(), but it is never called with the ap192. So I copied 
the initialization to ap192_ak4114_init(). I'll attach a patch of my 
final version.

When it finally compiled and was running, I had an ak4114 file in proc.

Unfortunately it's full of 0x00's:

/proc/asound/Audiophile192/ak4114:

0x00 = 0x00
0x02 = 0x00
[...]
0x1e = 0x00
0x1f = 0x00

(32 lines total)

There is also no change in the spdif capture behaviour.

Btw. before all of that it took me already some time to make the patch 
working. Pasting patches in the mail body converts tabs to spaces and 
also breaks long lines. I can use -l but still it messes up the original 
content. Is it bad to attach .patch files to mails in this list?

Ok, now I need some help regarding the git sources. I applied all this 
to my alsa-driver source that I got from here:

ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz

This is so far the only source that I was able to compile. The 1.0.25 
release source won't compile with my ubuntu 12.10 (symbol errors). The 
alsa-compile.sh from 
http://www.alsa-project.org/main/index.php/Driver_Compilation will also 
complain about some missing stuff. The git stuff was confusing me a bit. 
Do I need alsa-kernel or alsa-driver? Or both? The alsa-driver (branch 
'release') complains about missing alsa-kernel. But alsa-kernel is a 
huge package. Is that really necessary?

This snapshot package has some nice ./configure and will make and make 
install against the ubuntu kernel-headers quite smoothly. So I was using 
this all the time.

How do I create (or get) a package that compiles against the 
kernel-headers from my distribution?

- Jonas

[-- Attachment #2: ap192-ak4114-2013-01-30.patch --]
[-- Type: text/x-patch, Size: 2025 bytes --]

diff --git a/sound/pci/ice1712/revo.c.orig b/sound/pci/ice1712/revo.c
index 7641080..13aab89 100644
--- a/sound/pci/ice1712/revo.c.orig
+++ b/sound/pci/ice1712/revo.c
@@ -35,6 +35,7 @@
 struct revo51_spec {
 	struct snd_i2c_device *dev;
 	struct snd_pt2258 *pt2258;
+	struct ak4114 *ak4114;
 };
 
 static void revo_i2s_mclk_changed(struct snd_ice1712 *ice)
@@ -480,17 +481,23 @@ static int ap192_ak4114_init(struct snd_ice1712 *ice)
 	static const unsigned char ak4114_init_txcsb[] = {
 		0x41, 0x02, 0x2c, 0x00, 0x00
 	};
-	struct ak4114 *ak;
 	int err;
 
+	struct revo51_spec* spec;
+	spec = kzalloc(sizeof(*spec), GFP_KERNEL);
+	if (!spec)
+		return -ENOMEM;
+	ice->spec = spec;
+
+
 	err = snd_ak4114_create(ice->card,
 				 ap192_ak4114_read,
 				 ap192_ak4114_write,
 				 ak4114_init_vals, ak4114_init_txcsb,
-				 ice, &ak);
+				 ice, &spec->ak4114);
 	/* AK4114 in Revo cannot detect external rate correctly.
 	 * No reason to stop capture stream due to incorrect checks */
-	ak->check_flags = AK4114_CHECK_NO_RATE;
+	spec->ak4114->check_flags = AK4114_CHECK_NO_RATE;
 
 	return 0; /* error ignored; it's no fatal error */
 }
@@ -562,6 +569,9 @@ static int revo_init(struct snd_ice1712 *ice)
 					       ice);
 		if (err < 0)
 			return err;
+		err = ap192_ak4114_init(ice);
+		if (err < 0)
+			return err;
 		
 		/* unmute all codecs */
 		snd_ice1712_gpio_write_bits(ice, VT1724_REVO_MUTE,
@@ -575,7 +585,7 @@ static int revo_init(struct snd_ice1712 *ice)
 
 static int revo_add_controls(struct snd_ice1712 *ice)
 {
-	struct revo51_spec *spec;
+	struct revo51_spec *spec = ice->spec;
 	int err;
 
 	switch (ice->eeprom.subvendor) {
@@ -597,7 +607,9 @@ static int revo_add_controls(struct snd_ice1712 *ice)
 		err = snd_ice1712_akm4xxx_build_controls(ice);
 		if (err < 0)
 			return err;
-		err = ap192_ak4114_init(ice);
+		/* only capture SPDIF over AK4114 */
+		err = snd_ak4114_build(spec->ak4114, NULL,
+		   ice->pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream);
 		if (err < 0)
 			return err;
 		break;

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Am 29.01.2013 10:44, schrieb Pavel Hofman:
> On 28.1.2013 22:25, Jonas Petersen wrote:
>>> Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are
>>> connected to logical high? They should be :)
>> Physically they're both on ground. I don't know what active state that
>> chip has though.
> Let 's wait until we get the ak4114 register dump file :)

Can't wait. :) I did a quick test in Windows 7. This driver is able to 
detect the sample rate. If I set the clock source to "spdif in" at the 
control pannel, then I can see the rate changing when I switch to 
another rate on the spdif source.

- Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 31.1.2013 02:19, Jonas Petersen wrote:
> Am 29.01.2013 10:44, schrieb Pavel Hofman:
>> On 28.1.2013 22:25, Jonas Petersen wrote:
>>>> Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are
>>>> connected to logical high? They should be :)
>>> Physically they're both on ground. I don't know what active state that
>>> chip has though.

That would mean the chip is fed 11.2896MHz clock. I do not see any
crystal on
http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg
. Is it the same card you have, with the crystal position empty? Are you
really sure they are not on power supply?

>> Let 's wait until we get the ak4114 register dump file :)
> 
> Can't wait. :) 

Did the patch work?


I did a quick test in Windows 7. This driver is able to
> detect the sample rate. If I set the clock source to "spdif in" at the
> control pannel, then I can see the rate changing when I switch to
> another rate on the spdif source.

Did you test 192kHz and 176,4kHz? The receiver can work in two modes.
Either it knows it is fed an independent clock and detects the sample
rate precisely, or it simply reads the sample rate from SPDIF preamble
of the incoming stream. The mode is select by the XTL0,1 pins. Often the
streams do not contain correct information, especially for consumer mode
which does not have room for the larger samplerates code. Could you
please test both consumer and professional modes, all common samplerates?

Thanks,

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 31.1.2013 01:29, Jonas Petersen wrote:
> Am 30.01.2013 11:26, schrieb Pavel Hofman:
>> On 29.1.2013 20:14, Jonas Petersen wrote:
>>
> 
> Pavel, I applied your patch (including the correction in the other
> post). It did not work out of the box. I had to do a lot of debugging
> and changes to it to make it compile and then more of that fun to make
> it not crash alsa. 

Sorry, I did not test any compilation/running. The changes were rather
simple though. Thanks for sorting out.
> 
> When it finally compiled and was running, I had an ak4114 file in proc.
> 
> Unfortunately it's full of 0x00's:
> 
> /proc/asound/Audiophile192/ak4114:
> 
> 0x00 = 0x00
> 0x02 = 0x00
> [...]
> 0x1e = 0x00
> 0x1f = 0x00
> 
> (32 lines total)
> 
> There is also no change in the spdif capture behaviour.

OK, it looks we have a problem in communication with the chip. IMO the
4wire_start and 4wire_finish code is incorrect. As chip-select it takes
VT1724_REVO_CS1, but for ak4114 it should be VT1724_REVO_CS3 (as defined
in revo.h)

IMO the two methods should be:
static unsigned int ap192_4wire_start(struct snd_ice1712 *ice)
{
	unsigned int tmp;

	snd_ice1712_save_gpio_status(ice);
	tmp = snd_ice1712_gpio_read(ice);
	tmp |= VT1724_REVO_CCLK; /* high at init */
	tmp |= VT1724_REVO_CS0;
	tmp &= ~VT1724_REVO_CS3;
	snd_ice1712_gpio_write(ice, tmp);
	udelay(1);
	return tmp;
}

static void ap192_4wire_finish(struct snd_ice1712 *ice, unsigned int tmp)
{
	tmp |= VT1724_REVO_CS0;
	tmp |= VT1724_REVO_CS3;
	snd_ice1712_gpio_write(ice, tmp);
	udelay(1);
	snd_ice1712_restore_gpio_status(ice);
}

Provided that VT1724_REVO_CS0 is chip-select for AK4358 DAC and
VT1724_REVO_CS3 chip-select for AK4114. The AK5385 ADC has no control.


IMO the ak4xxx config section should use VT1724_REVO_CS3 instead of
VT1724_REVO_CS1 too:

static struct snd_ak4xxx_private akm_ap192_priv = {
	.caddr = 2,
	.cif = 0,
	.data_mask = VT1724_REVO_CDOUT,
	.clk_mask = VT1724_REVO_CCLK,
	.cs_mask = VT1724_REVO_CS0 | VT1724_REVO_CS3,
	.cs_addr = VT1724_REVO_CS3,
	.cs_none = VT1724_REVO_CS0 | VT1724_REVO_CS3,
	.add_flags = VT1724_REVO_CCLK, /* high at init */
	.mask_flags = 0,
};

If I am not mistaken VT1724_REVO_CS1 is not used on ap192 at all. Is
that correct?

Sorry for not using proper patches but I cannot test the result anyway.


Thanks,

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Am 31.01.2013 10:04, schrieb Pavel Hofman:
> On 31.1.2013 02:19, Jonas Petersen wrote:
>> Am 29.01.2013 10:44, schrieb Pavel Hofman:
>>> On 28.1.2013 22:25, Jonas Petersen wrote:
>>>>> Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are
>>>>> connected to logical high? They should be :)
>>>> Physically they're both on ground. I don't know what active state that
>>>> chip has though.
> That would mean the chip is fed 11.2896MHz clock. I do not see any
> crystal on
> http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg
> . Is it the same card you have, with the crystal position empty? Are you
> really sure they are not on power supply?

I double-checked. There is zero ohms between these pins and ground (e.g. 
outer of the spdif connectors, or pin B3 of PCI). The adjacent pins are 
also on ground which are "VIN" (12), "P/SN" (9) and "IPS1/IIC" (8).

Yeah, pretty much excactly the same card. The crystal position is empty, 
like on the picture from nix.ru.



> I did a quick test in Windows 7. This driver is able to
>> detect the sample rate. If I set the clock source to "spdif in" at the
>> control pannel, then I can see the rate changing when I switch to
>> another rate on the spdif source.
> Did you test 192kHz and 176,4kHz?
>   The receiver can work in two modes.
> Either it knows it is fed an independent clock and detects the sample
> rate precisely, or it simply reads the sample rate from SPDIF preamble
> of the incoming stream.

You mean probably this from the datasheet:

The AK4114 has two methods for detecting the sampling frequency as follows.
1. Clock comparison between recovered clock and X’tal oscillator
2. Sampling frequency information on channel status
Those could be selected by XTL1, 0 bits. And the detected frequency is 
reported on FS3-0 bits.

It is indeed strange. There is an example system design in the datasheet 
that also has XTL0,1 on ground, but there is a 11 MHz Crystal on XTI and 
XTO.

>   The mode is select by the XTL0,1 pins. Often the
> streams do not contain correct information, especially for consumer mode
> which does not have room for the larger samplerates code. Could you
> please test both consumer and professional modes, all common samplerates?

I tested 32, 44.1, 48, 64, 88.2, and 92 kHz with both modes. All rates 
except 64 kHz are always reliably detected (64 kHz is not in the list of 
supported frequencies of the chip). They are detected no matter what 
mode I select (prof/consumer) on both sides, even if they do not match. 
I tried all combinations.

For these tests I was using an RME Multiface. I guess one can expect 
correct streams from this device...

Now I checked the spdif signal from a dbx 376 tube channel strip. 44.1, 
48, 88.2 and 96 are detected properly.

Ok.. and now I just connected the ESI Juli(a) spdif out to the ap192 
spdif in. I'm chaning the internal clock rate in alsamixer. Everything 
is detected, only 176.4 and 192 result in 88.2 and 96... But this might 
as well be the Juli failing, doesn't it? I wasn't able to play any sound 
at these rates neither.

By the way, the Windows 7 "M-Audio Delta Control Panel" has this "sync 
source" lamp. It is normally green an says "locked" if there is any 
detected signal. When I change the rate it will become red for a moment 
and say "rate missmatch", then it will display the detected rate and 
turn green again.

If I do nothing with a green "locked", it will periodically (about every 
6 seconds) show a red "unlocked !" for maybe half a second. Only if I 
use the signal in a program (e.g. audacity) it will stay "locked" and green.

- Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Am 31.01.2013 11:33, schrieb Pavel Hofman:
> OK, it looks we have a problem in communication with the chip. IMO the
> 4wire_start and 4wire_finish code is incorrect. As chip-select it takes
> VT1724_REVO_CS1, but for ak4114 it should be VT1724_REVO_CS3 (as defined
> in revo.h)
>
> IMO the two methods should be:
> static unsigned int ap192_4wire_start(struct snd_ice1712 *ice)
> {
> 	unsigned int tmp;
>
> 	snd_ice1712_save_gpio_status(ice);
> 	tmp = snd_ice1712_gpio_read(ice);
> 	tmp |= VT1724_REVO_CCLK; /* high at init */
> 	tmp |= VT1724_REVO_CS0;
> 	tmp &= ~VT1724_REVO_CS3;
> 	snd_ice1712_gpio_write(ice, tmp);
> 	udelay(1);
> 	return tmp;
> }


Btw. is it really intended that CS0 is set and CS3 is unset in 
4wire_start? (In 4wire_finish CS0 is set again.)


> static void ap192_4wire_finish(struct snd_ice1712 *ice, unsigned int tmp)
> {
> 	tmp |= VT1724_REVO_CS0;
> 	tmp |= VT1724_REVO_CS3;
> 	snd_ice1712_gpio_write(ice, tmp);
> 	udelay(1);
> 	snd_ice1712_restore_gpio_status(ice);
> }
>
> Provided that VT1724_REVO_CS0 is chip-select for AK4358 DAC and
> VT1724_REVO_CS3 chip-select for AK4114. The AK5385 ADC has no control.

CS0 (0x10) is GPIO4 and CS3 (0x80) is GPIO7, right?

Physically GPIO7 goes to CSN (pin 35) of the AK4114, as I confirmed before.

GPIO4 goes to CSN (pin 21) of the AK4358. I just did a physical check to 
confirm that also!

So I guess (hope) that would confirm that "VT1724_REVO_CS0 is 
chip-select for AK4358 DAC and
VT1724_REVO_CS3 chip-select for AK4114"

One question: What do you mean by "The AK5385 ADC has no control."? Is 
that by nature of the chip?


> IMO the ak4xxx config section should use VT1724_REVO_CS3 instead of
> VT1724_REVO_CS1 too:
>
> static struct snd_ak4xxx_private akm_ap192_priv = {
> 	.caddr = 2,
> 	.cif = 0,
> 	.data_mask = VT1724_REVO_CDOUT,
> 	.clk_mask = VT1724_REVO_CCLK,
> 	.cs_mask = VT1724_REVO_CS0 | VT1724_REVO_CS3,
> 	.cs_addr = VT1724_REVO_CS3,
> 	.cs_none = VT1724_REVO_CS0 | VT1724_REVO_CS3,
> 	.add_flags = VT1724_REVO_CCLK, /* high at init */
> 	.mask_flags = 0,
> };
>
> If I am not mistaken VT1724_REVO_CS1 is not used on ap192 at all. Is
> that correct?

That woud be GPIO5, right? I'm not sure. If this is the case, wouldn't 
that pin not be tied to some level (high or low)?


> Sorry for not using proper patches but I cannot test the result anyway.

No problem. I tested, but still no succes.. :(

I noticed one more thing:

VT1724_REVO_CDIN (GPIO2) goes to CDTO and
VT1724_REVO_CDOUT (GPIO3) goes to CDTI of the AK4114. "IN" is "O" and 
"OUT" is "I". Ist that correct? I tried to swap them once but that 
didn't help either.

- Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

:-)

I've got some progress here. The AK4114_ADDR was wrong. I changed it 
from 0x02 to 0x00 (according to datasheet).

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!

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.

Here is some content of the ak4114:

/proc/asound/Audiophile192/ak4114

0x00 = 0x0f
0x01 = 0x70
0x02 = 0x80
0x03 = 0x49
0x04 = 0x00
0x05 = 0x00
0x06 = 0x10
0x07 = 0x10
0x08 = 0x45
0x09 = 0x02
0x0a = 0x2c
0x0b = 0x00
0x0c = 0x00
0x0d = 0x41
0x0e = 0x02
0x0f = 0x2c
0x10 = 0x00
0x11 = 0x00
0x12 = 0x00
0x13 = 0x00
0x14 = 0x00
0x15 = 0x00
0x16 = 0x00
0x17 = 0x00
0x18 = 0x00
0x19 = 0x00
0x1a = 0x00
0x1b = 0x00
0x1c = 0x00
0x1d = 0x00
0x1e = 0x00
0x1f = 0x00

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.

The Clock Source seems to be PLL (CM1-0 = 0,0).

I'll keep on debugging.

- Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

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.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Am 02.02.2013 11:44, schrieb Pavel Hofman:
>> 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).

Yeah, I found the right combination, it's OCKS0=1,OCKS1=0. Now the spdif 
input works, thank you!

I wonder why there is no level controls for the analog input (e.g. in 
alsamixer). Is that because the "AK5385 ADC chip has no control"? The 
ESI Juli doesn't have an analog input level control as well.


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

Ok, to make it clear, on the ap192 the FSx registers are always at their 
default (0001). So far I've never seen them on any other value. Only the 
corresponding Channel Status bits do change.

Well, I guess by default snd_ak4114_rate_get should still interpret the 
FSx bits. Other cards might work as expected (see 'Observation C' below).
In the case of the ap192 it might make sense to read the Channel Status. 
Maybe it needs a flag that gets set on card initializing indicating what 
should be used?

But, after all it seems there is still something obscure in the rate 
detection. Because while watching the ak4114 registers when switching 
sample rates I made the following observations:

Observation A:

RME Multiface spdif out goes to AP192 spdif in. In Linux the FSx bits 
are alwas "0001" and the Channel Status bis are set according to sample 
rate and mode (consumer/professional).

Observation B:

ESI Julia spdif out goes to AP192 spdif in. (Recall that in windows the 
AP192 _does_ detect sample rate changes!)
In Linux the FSx bits are alwas "0001" and the Channel Status bis are 
(almost) always _all_ "0". It seems the ESI does not send Channel Status 
at all (could it be the misconfiguration of the ESI?). It looks like this:

0x07 = 0x10 (00010000) [FS3,2,1,0 etc.]
0x08 = 0x00 (00000000) [CS0]
0x09 = 0x00 (00000000) [CS1]
0x0a = 0x00 (00000000) [CS2]
0x0b = 0x00 (00000000) [CS3]
0x0c = 0x00 (00000000) [CS4]

There is one strange exception. When I switch the output to spdif in the 
(I think it is) pulseaudio GUI. Then register 0x09 will be '00000010' 
for 5 second and switch back to '00000000'. When I play the test sound, 
then register 0x09 _and_ register 0x0b will be '00000010' for 5 second 
and switch back. Other than that the Channel Status does not change.

Now, how is the windows driver detecting the rate if there is a) no 
crystal in there and b) no Channel Status available? Might it be the 
clock being on PLL (I'm not realy aware of what that means right now)?

One thing might be of interest here: when switching the sample rates, 
register 0x06 does the following: Bit 0, bit 4 and flash to 1 for a 
short moment and back to zero (sometimes 2 times in a row).

0x06 = 0x11 (00010001) [flash to 1]
0x06 = 0x00 (00000000) [and back to 0]

Bit 0 is "PAR: Parity Error or Biphase Error Status"
Bit 4 is "PLL Lock Status" (1 being "Out of Lock")

Observation C (this is regarding ESI Juli):

dbx 376 tube channel strip spdif out goes to ESI Juli spdif in.
The FSx bits in register 0x07 of ESI Juli's AK4114 _do_ change on 
different sample rates. They do not match those in the datasheet though:

1000 - 44kHz (expected: 0000)
1010 - 48kHz (expected: 0010)
1100 - 88.2kHz (expected: 1000)
1110 - 96kHz (expected: 1010)

So maybe this is another symptom of the ESI's misconfiguration?


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

Ok, why not adding a control for that. But first explain something to 
me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in 
ak4114.c. How are they accessed? Where can I read for example the 
"IEC958 External Rate" value? In the proc dir they do not show up. 
Neither at Juli nor at AP192. Are these only API functions?

- Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 2.2.2013 23:47, Jonas Petersen wrote:
> Am 02.02.2013 11:44, schrieb Pavel Hofman:
> 
> Yeah, I found the right combination, it's OCKS0=1,OCKS1=0. Now the spdif
> input works, thank you!

Congrats.
> 
> I wonder why there is no level controls for the analog input (e.g. in
> alsamixer). Is that because the "AK5385 ADC chip has no control"? The
> ESI Juli doesn't have an analog input level control as well.

Right, ak5385 offers no attenuation control.

> 
> 
> Ok, to make it clear, on the ap192 the FSx registers are always at their
> default (0001). So far I've never seen them on any other value. Only the
> corresponding Channel Status bits do change.

OK

> 
> Well, I guess by default snd_ak4114_rate_get should still interpret the
> FSx bits. Other cards might work as expected (see 'Observation C' below).
> In the case of the ap192 it might make sense to read the Channel Status.
> Maybe it needs a flag that gets set on card initializing indicating what
> should be used?
> 
> But, after all it seems there is still something obscure in the rate
> detection. Because while watching the ak4114 registers when switching
> sample rates I made the following observations:
> 
> Observation A:
> 
> RME Multiface spdif out goes to AP192 spdif in. In Linux the FSx bits
> are alwas "0001" and the Channel Status bis are set according to sample
> rate and mode (consumer/professional).

That means the RME driver configured the SPDIF-out preamble correctly.
In alsa e.g. using the iecset tool.

> 
> Observation B:
> 
> ESI Julia spdif out goes to AP192 spdif in. (Recall that in windows the
> AP192 _does_ detect sample rate changes!)
> In Linux the FSx bits are alwas "0001" and the Channel Status bis are
> (almost) always _all_ "0". It seems the ESI does not send Channel Status
> at all (could it be the misconfiguration of the ESI?). It looks like this:
> 
> 0x07 = 0x10 (00010000) [FS3,2,1,0 etc.]
> 0x08 = 0x00 (00000000) [CS0]
> 0x09 = 0x00 (00000000) [CS1]
> 0x0a = 0x00 (00000000) [CS2]
> 0x0b = 0x00 (00000000) [CS3]
> 0x0c = 0x00 (00000000) [CS4]
> 
> There is one strange exception. When I switch the output to spdif in the
> (I think it is) pulseaudio GUI. Then register 0x09 will be '00000010'
> for 5 second and switch back to '00000000'. When I play the test sound,
> then register 0x09 _and_ register 0x0b will be '00000010' for 5 second
> and switch back. Other than that the Channel Status does not change.

I do not know in windows, but in alsa the SPDIF bits can be set
explicitly by user space. See the AESx params in
/usr/share/alsa/pcm/iec958.conf , /usr/share/alsa/cards/ICE1724.conf
(setting the alsa control "IEC958 Playback Default"). ICE1724 datasheet
says the integrated SPDIF transmitter should set the corresponding SPDIF
bits (reg MT3C) automatically:

quote

These bits declare the S/PDIF transmitter clock rate (64*fs) in the
Channel Status Byte 3, low
nibble if Consumer mode (MT3C_0 = 0) and Byte 0 (bits 7-6) and Byte 4
(bits 6-3) if
Professional mode (MT3C_0 = 1). It will be set automatically by MT01 low
nibble if master. In
slave mode (MT01_4 = 1), to display the correct sampling rate, it must
be written to reflect the
external clock recovered.

endquote


> 
> Now, how is the windows driver detecting the rate if there is a) no
> crystal in there and b) no Channel Status available? Might it be the
> clock being on PLL (I'm not realy aware of what that means right now)?

I do not know, are you sure there is really no channel status available?

> 
> One thing might be of interest here: when switching the sample rates,
> register 0x06 does the following: Bit 0, bit 4 and flash to 1 for a
> short moment and back to zero (sometimes 2 times in a row).
> 
> 0x06 = 0x11 (00010001) [flash to 1]
> 0x06 = 0x00 (00000000) [and back to 0]
> 
> Bit 0 is "PAR: Parity Error or Biphase Error Status"
> Bit 4 is "PLL Lock Status" (1 being "Out of Lock")
> 
> Observation C (this is regarding ESI Juli):
> 
> dbx 376 tube channel strip spdif out goes to ESI Juli spdif in.
> The FSx bits in register 0x07 of ESI Juli's AK4114 _do_ change on
> different sample rates. They do not match those in the datasheet though:
> 
> 1000 - 44kHz (expected: 0000)
> 1010 - 48kHz (expected: 0010)
> 1100 - 88.2kHz (expected: 1000)
> 1110 - 96kHz (expected: 1010)
> 
> So maybe this is another symptom of the ESI's misconfiguration?


When I tested the driver of Juli the values worked correctly. Let's
figure out AP192 first and then attack Juli :)


> 
> 
>> 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.
> 
> Ok, why not adding a control for that. But first explain something to
> me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in
> ak4114.c. How are they accessed? Where can I read for example the
> "IEC958 External Rate" value? In the proc dir they do not show up.
> Neither at Juli nor at AP192. Are these only API functions?

see output of amixer contents. They are defined as PCM-type controls
(not MIXER type and do not apper e.g. in alsamixer.

Regards,

Pavel.

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Jonas Petersen]

Ok, let's keep this going... I'll post a patch of the current state that 
I got (for the M-Audio Audiophile 192). I think it's already worth a 
review/commit since spdif input is now working properly.

There is still potential for more improvements, concerning the sample 
frequency detection.


Am 04.02.2013 17:56, schrieb Pavel Hofman:
> On 2.2.2013 23:47, Jonas Petersen wrote:
>> Now, how is the windows driver detecting the rate if there is a) no
>> crystal in there and b) no Channel Status available? Might it be the
>> clock being on PLL (I'm not realy aware of what that means right now)?
> I do not know, are you sure there is really no channel status available?

Quite sure. It seems to be an ESI Juli phenomenon. I did plug my several 
devices into the AP192 spdif input while observing the channel status. 
The ESI is not sending any channel status, the others are...

But, as you suggested let's address the Juli later, maybe in a separate 
thread.


>>> 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.
>> Ok, why not adding a control for that. But first explain something to
>> me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in
>> ak4114.c. How are they accessed? Where can I read for example the
>> "IEC958 External Rate" value? In the proc dir they do not show up.
>> Neither at Juli nor at AP192. Are these only API functions?
> see output of amixer contents. They are defined as PCM-type controls
> (not MIXER type and do not apper e.g. in alsamixer.

Thanks, found it. Would that help in finding out how the card is 
detecting rate without any clue?

I once read somwhere about a kind of hackish way of detecting sampling 
frequency by just capturing some samples (at a fixed rate) and 
calculating by comparing what you get to what you're supposed to get (or 
something like that, don't remember exactly). Can't find it anywhere 
right now though.

Might it be that the windows driver is doing something like that as a 
fallback (or even always) when there is no channel status?

I'd like to once send the card a - let's say - 44.1 kHz signal with a - 
let's say - 96 kHz info in the channel status and see what the windows 
driver says. :)

- Jonas

Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman]

On 23.2.2013 23:13, Jonas Petersen wrote:
> 
>>> Ok, why not adding a control for that. But first explain something to
>>> me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in
>>> ak4114.c. How are they accessed? Where can I read for example the
>>> "IEC958 External Rate" value? In the proc dir they do not show up.
>>> Neither at Juli nor at AP192. Are these only API functions?
>> see output of amixer contents. They are defined as PCM-type controls
>> (not MIXER type and do not apper e.g. in alsamixer.
> 
> Thanks, found it. Would that help in finding out how the card is
> detecting rate without any clue?

Hopefully. It shows you values of all ak4114 registers. The same
information as available to the windows driver.

Now can you please look at the regs if you can spot any hint of the
incoming sample rate from Juli (specifically the spdif channel status
regs and the incoming fs regs)? Thanks.

> 
> I once read somwhere about a kind of hackish way of detecting sampling
> frequency by just capturing some samples (at a fixed rate) and
> calculating by comparing what you get to what you're supposed to get (or
> something like that, don't remember exactly). Can't find it anywhere
> right now though.
>
> Might it be that the windows driver is doing something like that as a
> fallback (or even always) when there is no channel status?

Well, it is certainly feasible but I very much doubt the driver does it.


> 
> I'd like to once send the card a - let's say - 44.1 kHz signal with a -
> let's say - 96 kHz info in the channel status and see what the windows
> driver says. :)

Take a look at the iecset utility. It sets the IEC958 channel status
bits of the spdif transmitter (e.g. of your Juli or AP192). I would
start a 44.1kHz stream and try to rewrite the values using iecset. You
can check in regs list of your ice1724 card in
/proc/asound/yourcard/ice1724 if the change took place (register MT3C).
The playback may lock the IEC958 channel status controls. If it is the
case, try to comment out the IEC958 Playback Default "lock true" in
/usr/share/alsa/cards/ICE1724.conf.

Instead of iecset you can use amixer to manipulate IEC958 Playback
Default directly, but you will have to figure out correct bit values.

Good luck and thanks for the patch you sent :)

Pavel.