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

Discussion:

Jonas Petersen

2013-04-05 15:34:40 UTC

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

Jonas Petersen

2013-04-07 00:52:42 UTC

Permalink

Post by 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

Gabriel M. Beddingfield

2013-04-07 17:03:15 UTC

Permalink

Post by Jonas Petersen
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

Alan Horstmann

2013-04-07 20:35:45 UTC

Permalink

Post by Gabriel M. Beddingfield

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

Jonas Petersen

2013-04-08 22:56:23 UTC

Permalink

Post by Gabriel M. Beddingfield

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

Pavel Hofman

2013-04-09 14:21:36 UTC

Permalink

Post by Jonas Petersen

Post by Gabriel M. Beddingfield

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.

Jonas Petersen

2013-04-11 07:23:54 UTC

Permalink

Post by Pavel Hofman

Post by Jonas Petersen

Post by Gabriel M. Beddingfield

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.

Post by Pavel Hofman
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).

Post by Pavel Hofman
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..

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

Post by Pavel Hofman
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

Jonas Petersen

2013-04-12 14:53:01 UTC

Permalink

Post by 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

Pavel Hofman

2013-04-15 07:35:19 UTC

Permalink

Post by Jonas Petersen
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.

Post by Jonas Petersen
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.
01 - 256 * Fsi, where Fsi is derived from the AES3 input frame rate

That should be correct.

Post by Jonas Petersen
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

Post by Jonas Petersen
Here's the full contents of the proc files (the binary representations
-------------------------------------------
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

Post by Jonas Petersen
/proc/asound/M1010LT/ice1712
-------------------------------------------
M Audio Delta 1010LT at 0xd040, irq 20
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)
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.