M-Audio Delta 1010LT: S/PDIF clock source not working

M-Audio Delta 1010LT: S/PDIF clock source not working

[Jonas Petersen]

Hi,

I am trying to capture from S/PDIF. I get a signal but the clocking is 
broken somehow.

I have 'Multi Track Internal Clock' on 'ICE958 Input'.

'Word Clock Status' and 'Word Clock Sync' are 'Off'.

What happens is the following: It captures what comes in on S/PDIF but 
it seems it will always use the internal clock with the setting from 
'Multi Track Internal Clock Default'.

So even though 'Multi Track Internal Clock' is on 'ICE958 Input', the 
setting of 'Multi Track Internal Clock Default' will clock the signal.

A 1 kHz sine wave at 48 kHz samplerate captured with 'Multi Track 
Internal Clock Default' on 96 kHz will result in a 2 kHz sine. When the 
sample frequency rates are matched, it will capture at correct rate but 
with hiccups due to the rates not perfectly aligned.

What can I do narrow down the cause?

Reards
Jonas

Re: M-Audio Delta 1010LT: S/PDIF clock source not working

[Jonas Petersen]

Am 05.04.2013 17:34, schrieb Jonas Petersen:
> I am trying to capture from S/PDIF. I get a signal but the clocking is 
> broken somehow.
>
> I have 'Multi Track Internal Clock' on 'ICE958 Input'.
>
> 'Word Clock Status' and 'Word Clock Sync' are 'Off'.
>
> What happens is the following: It captures what comes in on S/PDIF but 
> it seems it will always use the internal clock with the setting from 
> 'Multi Track Internal Clock Default'.
>
> So even though 'Multi Track Internal Clock' is on 'ICE958 Input', the 
> setting of 'Multi Track Internal Clock Default' will clock the signal.
>
> A 1 kHz sine wave at 48 kHz samplerate captured with 'Multi Track 
> Internal Clock Default' on 96 kHz will result in a 2 kHz sine. When 
> the sample frequency rates are matched, it will capture at correct 
> rate but with hiccups due to the rates not perfectly aligned.

It seems it's related to the ICE1712... I now tried the Audiophile 2496. 
Same behaviour! There is no way to clock from external (S/PDIF). The 
'Multi Track Internal Clock Default' setting will always override the 
external clock rate and mess up the capturing.

I did tests on 2 very different systems: a) AMD with Xubuntu 12.10, b) 
Intel with Ubuntu 12.10.

- Jonas

Re: M-Audio Delta 1010LT: S/PDIF clock source not working

[Gabriel M. Beddingfield]

On 04/06/2013 05:52 PM, Jonas Petersen wrote:
>
> It seems it's related to the ICE1712... I now tried the Audiophile 2496.
> Same behaviour! There is no way to clock from external (S/PDIF). The
> 'Multi Track Internal Clock Default' setting will always override the
> external clock rate and mess up the capturing.

Well, it /should/ work -- according to the 1010's manual.  I'll bet it's 
some register setting that's missing on the ice1712 -- but I have no 
access to the specs/datasheets/schematics on these things.

I wonder -- did this ever work on Linux?

-gabriel

Re: M-Audio Delta 1010LT: S/PDIF clock source not working

[Alan Horstmann]

On Sunday 07 April 2013 18:03, Gabriel M. Beddingfield wrote:
> On 04/06/2013 05:52 PM, Jonas Petersen wrote:
> > It seems it's related to the ICE1712... I now tried the Audiophile 2496.
> > Same behaviour! There is no way to clock from external (S/PDIF). The
> > 'Multi Track Internal Clock Default' setting will always override the
> > external clock rate and mess up the capturing.
>
> Well, it /should/ work -- according to the 1010's manual.  I'll bet it's
> some register setting that's missing on the ice1712 -- but I have no
> access to the specs/datasheets/schematics on these things.
>
> I wonder -- did this ever work on Linux?

Can't confirm on Delta 1010 series, but this is/was working on Terratec 
DMX6fire and STaudio DSP2000 (other ice1712 cards) since at least about Alsa 
1.0.12.  More people have the 1010's, so I would expect it has been working 
on those.  However I do seem to remember some relatively recent changes 
related to external wordclock on the 1010; maybe it has been broken?

@Jonas - are you using 'envy24control' to toggle the settings?


Regards

Alan

Re: M-Audio Delta 1010LT: S/PDIF clock source not working

[Jonas Petersen]

Am 07.04.2013 22:35, schrieb Alan Horstmann:
> On Sunday 07 April 2013 18:03, Gabriel M. Beddingfield wrote:
>> On 04/06/2013 05:52 PM, Jonas Petersen wrote:
>>> It seems it's related to the ICE1712... I now tried the Audiophile 2496.
>>> Same behaviour! There is no way to clock from external (S/PDIF). The
>>> 'Multi Track Internal Clock Default' setting will always override the
>>> external clock rate and mess up the capturing.
>> Well, it /should/ work -- according to the 1010's manual.  I'll bet it's
>> some register setting that's missing on the ice1712 -- but I have no
>> access to the specs/datasheets/schematics on these things.
>>
>> I wonder -- did this ever work on Linux?

Yes! I while ago I was doing stuff with the Delta 66 and things were 
fine. That was back with Ubuntu 10.04 and Alsa 1.0.22 and also 1.0.23.
I just grabbed an old Ubuntu 10.04 ISO which contains Alsa 1.0.22 and 
live booted it on my machine. Tests show that it's working as expected 
with the 1010LT: It's properly externally clocked.


> However I do seem to remember some relatively recent changes related 
> to external wordclock on the 1010; maybe it has been broken?

I found commit b8b1a4cb6842fb33769be1ad636f062d31d588c3 from Jan 17 
23:20:03 2011. It's a patch on delta.c and it's regarding a clock issue 
(though not exactly wordclock). I reverted that patch and recompiled but 
no success.

I'm going to continue later on that topic. At least there must have been 
some change that broke it since 1.0.23.

> @Jonas - are you using 'envy24control' to toggle the settings?

I suppose this shouldn't make any difference. I'm using alsamixer, 
amixer and API calls most of the time. Sometimes envy24control, mostly 
for (visual) input feedback. Tried only using envy24control, but didn't 
make any difference.

- Jonas

Re: M-Audio Delta 1010LT: S/PDIF clock source not working

[Pavel Hofman]

On 9.4.2013 00:56, Jonas Petersen wrote:
> Am 07.04.2013 22:35, schrieb Alan Horstmann:
>> On Sunday 07 April 2013 18:03, Gabriel M. Beddingfield wrote:
>>> On 04/06/2013 05:52 PM, Jonas Petersen wrote:
>>>> It seems it's related to the ICE1712... I now tried the Audiophile
>>>> 2496.
>>>> Same behaviour! There is no way to clock from external (S/PDIF). The
>>>> 'Multi Track Internal Clock Default' setting will always override the
>>>> external clock rate and mess up the capturing.
>>> Well, it /should/ work -- according to the 1010's manual.  I'll bet it's
>>> some register setting that's missing on the ice1712 -- but I have no
>>> access to the specs/datasheets/schematics on these things.
>>>
>>> I wonder -- did this ever work on Linux?
> 
> Yes! I while ago I was doing stuff with the Delta 66 and things were
> fine. That was back with Ubuntu 10.04 and Alsa 1.0.22 and also 1.0.23.
> I just grabbed an old Ubuntu 10.04 ISO which contains Alsa 1.0.22 and
> live booted it on my machine. Tests show that it's working as expected
> with the 1010LT: It's properly externally clocked.
> 
> 
>> However I do seem to remember some relatively recent changes related
>> to external wordclock on the 1010; maybe it has been broken?
> 
> I found commit b8b1a4cb6842fb33769be1ad636f062d31d588c3 from Jan 17
> 23:20:03 2011. It's a patch on delta.c and it's regarding a clock issue
> (though not exactly wordclock). I reverted that patch and recompiled but
> no success.
> 
> I'm going to continue later on that topic. At least there must have been
> some change that broke it since 1.0.23.

Hi Jonas,

first - did you try with "Multi Track Rate Locking" on and off? This
control is a bit clumsy.

How about
http://git.alsa-project.org/?p=alsa-kmirror.git;a=blobdiff;f=pci/ice1712/ice1712.c;h=fb61943fc4dc9631853d76fa2524cd51880bcd9a;hp=c7cff6f8168a2d0159a0df20ea2c97550dafd6db;hb=b125bc8783367e3eb65312039a29bf2f25e931db;hpb=3e3911eb86fc7016c9cfef0525b9568c3106c4e4
?

It is from about that time.

pro_rate_locked is both when locked explicitly as well as when switched
to spdif clock

http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob;f=pci/ice1712/ice1712.c;h=5be2e120a14e25a03744b873e690f765eecb9545;hb=ec10d549379e10b38fe365fbf6bc13bf44f965ac#l133



Please check ice1712 register values, specifically MT RATE to make sure
ice1712 is switched to internal clocks when it should be clocked
externally instead (
http://ftp.sunet.se/pub/Linux/alsa/manuals/icensemble/envy24.pdf ). Or
just dump  ice1712 in proc here, I will check with the datasheet.

Unfortunately there is no /proc register dump coded for cs8427 yet. If
you want to investigate further, you can add it to i2c/cs8427.c in a
manner similar to e.g.
http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob;f=i2c/other/ak4114.c;h=fdf3c1b65e388414c995a597ef2b351b4ec2a220;hb=HEAD#l451

Thanks,

Pavel.

Re: M-Audio Delta 1010LT: S/PDIF clock source not working

[Jonas Petersen]

Am 09.04.2013 16:21, schrieb Pavel Hofman:
> On 9.4.2013 00:56, Jonas Petersen wrote:
>> Am 07.04.2013 22:35, schrieb Alan Horstmann:
>>> On Sunday 07 April 2013 18:03, Gabriel M. Beddingfield wrote:
>>>> On 04/06/2013 05:52 PM, Jonas Petersen wrote:
>>>>> It seems it's related to the ICE1712... I now tried the Audiophile
>>>>> 2496.
>>>>> Same behaviour! There is no way to clock from external (S/PDIF). The
>>>>> 'Multi Track Internal Clock Default' setting will always override the
>>>>> external clock rate and mess up the capturing.
>>>> Well, it /should/ work -- according to the 1010's manual.  I'll bet it's
>>>> some register setting that's missing on the ice1712 -- but I have no
>>>> access to the specs/datasheets/schematics on these things.
>>>>
>>>> I wonder -- did this ever work on Linux?
>> Yes! I while ago I was doing stuff with the Delta 66 and things were
>> fine. That was back with Ubuntu 10.04 and Alsa 1.0.22 and also 1.0.23.
>> I just grabbed an old Ubuntu 10.04 ISO which contains Alsa 1.0.22 and
>> live booted it on my machine. Tests show that it's working as expected
>> with the 1010LT: It's properly externally clocked.
>>
>>
>>> However I do seem to remember some relatively recent changes related
>>> to external wordclock on the 1010; maybe it has been broken?
>> I found commit b8b1a4cb6842fb33769be1ad636f062d31d588c3 from Jan 17
>> 23:20:03 2011. It's a patch on delta.c and it's regarding a clock issue
>> (though not exactly wordclock). I reverted that patch and recompiled but
>> no success.
>>
>> I'm going to continue later on that topic. At least there must have been
>> some change that broke it since 1.0.23.
> Hi Jonas,
>
> first - did you try with "Multi Track Rate Locking" on and off? This
> control is a bit clumsy.

I havn't tried so far, but did now. It has been 'off' all the time, but 
setting it to 'on' makes no difference.


> How about
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=blobdiff;f=pci/ice1712/ice1712.c;h=fb61943fc4dc9631853d76fa2524cd51880bcd9a;hp=c7cff6f8168a2d0159a0df20ea2c97550dafd6db;hb=b125bc8783367e3eb65312039a29bf2f25e931db;hpb=3e3911eb86fc7016c9cfef0525b9568c3106c4e4
> ?
>
> It is from about that time.

Yeah, that's getting closer I guess. When I undo that commit, then it's 
possible to capture with the external rate!

*But*... I'm afraid it's still clocked from internal. Because it's not 
capturing cleanly. It's got glitches sometimes (without having xruns).


> pro_rate_locked is both when locked explicitly as well as when switched
> to spdif clock
>
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob;f=pci/ice1712/ice1712.c;h=5be2e120a14e25a03744b873e690f765eecb9545;hb=ec10d549379e10b38fe365fbf6bc13bf44f965ac#l133

How strange.. but there's probably a reason for rate locking on spdif 
clock..

> Please check ice1712 register values, specifically MT RATE to make sure
> ice1712 is switched to internal clocks when it should be clocked
> externally instead (
> http://ftp.sunet.se/pub/Linux/alsa/manuals/icensemble/envy24.pdf ). Or
> just dump  ice1712 in proc here, I will check with the datasheet.

I'm not sure, is it 'Codec' in ice1712 that's 'PCI60: System 
Configuration Register' in the datasheet? From that the clock source 
would be '00: XIN2: 22.5792MHz crystal (44.1kHz*512)'.

Here's my ice1712:
-------------------------------------------
M Audio Delta 1010LT at 0xd040, irq 20

EEPROM:
   Subvendor        : 0x12143bd6
   Size             : 29 bytes
   Version          : 1
   Codec            : 0x1f
   ACLink           : 0x80
   I2S ID           : 0x72
   S/PDIF           : 0x3
   GPIO mask        : 0x4
   GPIO state       : 0x7e
   GPIO direction   : 0xfb
   AC'97 main       : 0x0
   AC'97 pcm        : 0x0
   AC'97 record     : 0x0
   AC'97 record src : 0x44
   DAC ID #0        : 0x3
   DAC ID #1        : 0x3
   DAC ID #2        : 0x3
   DAC ID #3        : 0x3
   ADC ID #0        : 0x3
   ADC ID #1        : 0x3
   ADC ID #2        : 0x3
   ADC ID #3        : 0x3
   Extra #28        : 0x0

Registers:
   PSDOUT03         : 0x0000
   CAPTURE          : 0x00000000
   SPDOUT           : 0x0000
   RATE             : 0x10
   GPIO_DATA        : 0x5a
   GPIO_WRITE_MASK  : 0x04
   GPIO_DIRECTION   : 0xfb
-------------------------------------------

With "Multi Track Internal Clock" on "IEC958 Input" the content of 
ice1712 has not changed at all, no matter what ("Default") rate I select 
or rate I capture. Also before and after reverting the patch it's the 
same content.

When I change "Multi Track Internal Clock" to some specific rate then 
(only) RATE and GPIO_DATA change. E.g.:

44100:
   RATE             : 0x08
   GPIO_DATA        : 0x52

48000:
   RATE             : 0x00
   GPIO_DATA        : 0x52

96000:
   RATE             : 0x07
   GPIO_DATA        : 0x53

For some reason GPIO_DATA will now stay on 0x53 when I switch to "IEC958 
Input" (before it was fixed on 0x5a).


> Unfortunately there is no /proc register dump coded for cs8427 yet. If
> you want to investigate further, you can add it to i2c/cs8427.c in a
> manner similar to e.g.
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob;f=i2c/other/ak4114.c;h=fdf3c1b65e388414c995a597ef2b351b4ec2a220;hb=HEAD#l451

I'm working on it...


- Jonas

Re: M-Audio Delta 1010LT: S/PDIF clock source not working

[Jonas Petersen]

Am 09.04.2013 16:21, schrieb Pavel Hofman:
> Please check ice1712 register values, specifically MT RATE to make sure
> ice1712 is switched to internal clocks when it should be clocked
> externally instead (
> http://ftp.sunet.se/pub/Linux/alsa/manuals/icensemble/envy24.pdf ). Or
> just dump  ice1712 in proc here, I will check with the datasheet.
>
> Unfortunately there is no /proc register dump coded for cs8427 yet. If
> you want to investigate further, you can add it to i2c/cs8427.c in a
> manner similar to e.g.
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob;f=i2c/other/ak4114.c;h=fdf3c1b65e388414c995a597ef2b351b4ec2a220;hb=HEAD#l451

All right. I got cs8427 in proc now! I included registers 0x00 to 0x1f 
plus 0x7f which "is I.D. and version". I'll post a patch later.

Now I have the following scenario: Delta 1010LT internal clock on 
'IEC958 Input', internal clock default is 44100. I got a 1 kHz sine 
signal at the S/PDIF input with 96kHz samplerate. Due to the reverted 
patch it is capturing with 96kHz. Rate Locking / Rate Reset / Wordclock 
Status / Wordclock Sync are all 'off'.

Using a jack app or recording directly from alsa with audacity shows 
that the signal is not clean. It's got errors. Specifically once in a 
while (about every 5 seconds) a single sample value will last over the 
time of two samples. The signal gets shifted.

cs8427 register 0x04 bits 1:0 (RDX1:0: Recovered Input Clock Source) says:

   01 - 256 * Fsi, where Fsi is derived from the AES3 input frame rate

Whatever that means. Other values are:

   00 - 256 * Fsi, where Fsi is derived from the ILRCK pin (only possible
        when the serial audio input port is in slave mode)

   10 - Bypass the PLL and apply an external 256 * Fsi clock through the
        RMCK pin. The AES3 receiver is held in synchronous reset. This
        setting is useful to prevent UNLOCK interrupts when using an
        external RMCK and inputting data through the serial audio input
        port.

Serial audio input and output ports are in slave mode.

Here's the full contents of the proc files (the binary representations 
are in parenthesis added by a little tool that I wrote):

/proc/asound/M1010LT/cs8427:
-------------------------------------------
0x00 = 0x00 (00000000)
0x01 = 0x81 (10000001)
0x02 = 0x00 (00000000)
0x03 = 0x0c (00001100)
0x04 = 0x41 (01000001)
0x05 = 0x05 (00000101)
0x06 = 0x05 (00000101)
0x07 = 0x00 (00000000)
0x08 = 0x00 (00000000)
0x09 = 0x00 (00000000)
0x0a = 0x00 (00000000)
0x0b = 0x00 (00000000)
0x0c = 0x00 (00000000)
0x0d = 0x00 (00000000)
0x0e = 0x00 (00000000)
0x0f = 0x41 (01000001)
0x10 = 0x00 (00000000)
0x11 = 0xff (11111111)
0x12 = 0x18 (00011000)
0x13 = 0x12 (00010010)
0x14 = 0x00 (00000000)
0x15 = 0x00 (00000000)
0x16 = 0x00 (00000000)
0x17 = 0x00 (00000000)
0x18 = 0x00 (00000000)
0x19 = 0x00 (00000000)
0x1a = 0x00 (00000000)
0x1b = 0x00 (00000000)
0x1c = 0x00 (00000000)
0x1d = 0x00 (00000000)
0x1e = 0x40 (01000000)
0x1f = 0x00 (00000000)
0x7f = 0x71 (01110001)
-------------------------------------------

/proc/asound/M1010LT/ak4524:
-------------------------------------------
chip 0: 0x00 = 0x07 (00000111)
chip 0: 0x01 = 0x03 (00000011)
chip 0: 0x02 = 0x60 (01100000)
chip 0: 0x03 = 0x19 (00011001)
chip 0: 0x04 = 0x7f (01111111)
chip 0: 0x05 = 0x7f (01111111)
chip 0: 0x06 = 0x00 (00000000)
chip 0: 0x07 = 0x00 (00000000)
chip 1: 0x00 = 0x07 (00000111)
chip 1: 0x01 = 0x03 (00000011)
chip 1: 0x02 = 0x60 (01100000)
chip 1: 0x03 = 0x19 (00011001)
chip 1: 0x04 = 0x00 (00000000)
chip 1: 0x05 = 0x00 (00000000)
chip 1: 0x06 = 0x00 (00000000)
chip 1: 0x07 = 0x00 (00000000)
chip 2: 0x00 = 0x07 (00000111)
chip 2: 0x01 = 0x03 (00000011)
chip 2: 0x02 = 0x60 (01100000)
chip 2: 0x03 = 0x19 (00011001)
chip 2: 0x04 = 0x00 (00000000)
chip 2: 0x05 = 0x00 (00000000)
chip 2: 0x06 = 0x00 (00000000)
chip 2: 0x07 = 0x00 (00000000)
chip 3: 0x00 = 0x07 (00000111)
chip 3: 0x01 = 0x03 (00000011)
chip 3: 0x02 = 0x60 (01100000)
chip 3: 0x03 = 0x19 (00011001)
chip 3: 0x04 = 0x00 (00000000)
chip 3: 0x05 = 0x00 (00000000)
chip 3: 0x06 = 0x00 (00000000)
chip 3: 0x07 = 0x00 (00000000)
-------------------------------------------

/proc/asound/M1010LT/ice1712
-------------------------------------------
M Audio Delta 1010LT at 0xd040, irq 20

EEPROM:
   Subvendor        : 0x12143bd6
   Size             : 29 bytes
   Version          : 1
   Codec            : 0x1f (00011111)
   ACLink           : 0x80 (10000000)
   I2S ID           : 0x72 (01110010)
   S/PDIF           : 0x3 (00000011)
   GPIO mask        : 0x4 (00000100)
   GPIO state       : 0x7e (01111110)
   GPIO direction   : 0xfb (11111011)
   AC'97 main       : 0x0 (00000000)
   AC'97 pcm        : 0x0 (00000000)
   AC'97 record     : 0x0 (00000000)
   AC'97 record src : 0x44 (01000100)
   DAC ID #0        : 0x3 (00000011)
   DAC ID #1        : 0x3 (00000011)
   DAC ID #2        : 0x3 (00000011)
   DAC ID #3        : 0x3 (00000011)
   ADC ID #0        : 0x3 (00000011)
   ADC ID #1        : 0x3 (00000011)
   ADC ID #2        : 0x3 (00000011)
   ADC ID #3        : 0x3 (00000011)
   Extra #28        : 0x0 (00000000)

Registers:
   PSDOUT03         : 0x0000
   CAPTURE          : 0x00000000
   SPDOUT           : 0x0000
   RATE             : 0x10 (00010000)
   GPIO_DATA        : 0x5a (01011010)
   GPIO_WRITE_MASK  : 0x04 (00000100)
   GPIO_DIRECTION   : 0xfb (11111011)

-------------------------------------------

- Jonas

Re: M-Audio Delta 1010LT: S/PDIF clock source not working

[Pavel Hofman]

On 12.4.2013 16:53, Jonas Petersen wrote:
> 
> All right. I got cs8427 in proc now! I included registers 0x00 to 0x1f
> plus 0x7f which "is I.D. and version". I'll post a patch later.

Great, thanks.
> 
> Now I have the following scenario: Delta 1010LT internal clock on
> 'IEC958 Input', internal clock default is 44100. I got a 1 kHz sine
> signal at the S/PDIF input with 96kHz samplerate. Due to the reverted
> patch it is capturing with 96kHz. Rate Locking / Rate Reset / Wordclock
> Status / Wordclock Sync are all 'off'.
> 
> Using a jack app or recording directly from alsa with audacity shows
> that the signal is not clean. It's got errors. Specifically once in a
> while (about every 5 seconds) a single sample value will last over the
> time of two samples. The signal gets shifted.
> 
> cs8427 register 0x04 bits 1:0 (RDX1:0: Recovered Input Clock Source) says:
> 
>   01 - 256 * Fsi, where Fsi is derived from the AES3 input frame rate

That should be correct.
> 
> Whatever that means. Other values are:
> 
>   00 - 256 * Fsi, where Fsi is derived from the ILRCK pin (only possible
>        when the serial audio input port is in slave mode)
> 
>   10 - Bypass the PLL and apply an external 256 * Fsi clock through the
>        RMCK pin. The AES3 receiver is held in synchronous reset. This
>        setting is useful to prevent UNLOCK interrupts when using an
>        external RMCK and inputting data through the serial audio input
>        port.
> 
> Serial audio input and output ports are in slave mode.

I wondered if we should not try seeting this to master mode as the
receiver supplies clock to Envy24. Quoting from the datasheet

====
A Serial Audio port may operate in either Master or
Slave mode. When a port is a Master, it supplies
the left-right clock and the serial clock to the external
device that is sending or receiving the serial data.
A port in slave mode must have its left-right clock
and its serial clock supplied by an external device
so that it may send or receive serial audio data.
===

BUT the fs selector for master mode offers only 64xfs and 128fs, no
256xfs. Therefore IMO the slave mode is OK


> 
> Here's the full contents of the proc files (the binary representations
> are in parenthesis added by a little tool that I wrote):
> 
> /proc/asound/M1010LT/cs8427:
> -------------------------------------------
> 0x00 = 0x00 (00000000)
> 0x01 = 0x81 (10000001)
> 0x02 = 0x00 (00000000)
> 0x03 = 0x0c (00001100)
> 0x04 = 0x41 (01000001)
> 0x05 = 0x05 (00000101)
> 0x06 = 0x05 (00000101)
> 0x07 = 0x00 (00000000)
> 0x08 = 0x00 (00000000)
> 0x09 = 0x00 (00000000)
> 0x0a = 0x00 (00000000)
> 0x0b = 0x00 (00000000)
> 0x0c = 0x00 (00000000)
> 0x0d = 0x00 (00000000)
> 0x0e = 0x00 (00000000)
> 0x0f = 0x41 (01000001)
> 0x10 = 0x00 (00000000)
> 0x11 = 0xff (11111111)
> 0x12 = 0x18 (00011000)
> 0x13 = 0x12 (00010010)
> 0x14 = 0x00 (00000000)
> 0x15 = 0x00 (00000000)
> 0x16 = 0x00 (00000000)
> 0x17 = 0x00 (00000000)
> 0x18 = 0x00 (00000000)
> 0x19 = 0x00 (00000000)
> 0x1a = 0x00 (00000000)
> 0x1b = 0x00 (00000000)
> 0x1c = 0x00 (00000000)
> 0x1d = 0x00 (00000000)
> 0x1e = 0x40 (01000000)
> 0x1f = 0x00 (00000000)
> 0x7f = 0x71 (01110001)
> -------------------------------------------


This all looks OK


> 
> /proc/asound/M1010LT/ice1712
> -------------------------------------------
> M Audio Delta 1010LT at 0xd040, irq 20
> 
> EEPROM:
>   Subvendor        : 0x12143bd6
>   Size             : 29 bytes
>   Version          : 1
>   Codec            : 0x1f (00011111)
>   ACLink           : 0x80 (10000000)
>   I2S ID           : 0x72 (01110010)
>   S/PDIF           : 0x3 (00000011)
>   GPIO mask        : 0x4 (00000100)
>   GPIO state       : 0x7e (01111110)
>   GPIO direction   : 0xfb (11111011)
>   AC'97 main       : 0x0 (00000000)
>   AC'97 pcm        : 0x0 (00000000)
>   AC'97 record     : 0x0 (00000000)
>   AC'97 record src : 0x44 (01000100)
>   DAC ID #0        : 0x3 (00000011)
>   DAC ID #1        : 0x3 (00000011)
>   DAC ID #2        : 0x3 (00000011)
>   DAC ID #3        : 0x3 (00000011)
>   ADC ID #0        : 0x3 (00000011)
>   ADC ID #1        : 0x3 (00000011)
>   ADC ID #2        : 0x3 (00000011)
>   ADC ID #3        : 0x3 (00000011)
>   Extra #28        : 0x0 (00000000)
> 
> Registers:
>   PSDOUT03         : 0x0000
>   CAPTURE          : 0x00000000
>   SPDOUT           : 0x0000
>   RATE             : 0x10 (00010000)
>   GPIO_DATA        : 0x5a (01011010)
>   GPIO_WRITE_MASK  : 0x04 (00000100)
>   GPIO_DIRECTION   : 0xfb (11111011)

I do not see any problem here either. Perhaps it would be handy to add
all remaining envy registers, instead of just relying on their EEPROM
init values. Perhaps you could add the for loops in the proc listing in
1712.c the same way as in ice1724.c just to make sure the register values

The problem really looks like clock mismatch, as if envy was switched to
96kHz internal clock instead of accepting the 96kHz external clock. But
the RATE register is correctly set at SPDIF clock.

Just a try - are you sure your input signal is correct? :)

Thanks,

Pavel.