[alsa-devel] M-Audio Delta 1010LT: S/PDIF clock source not working
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
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
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
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
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
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/ice... ?
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...
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;...
Thanks,
Pavel.
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/ice... ?
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...
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;...
I'm working on it...
- Jonas
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;...
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
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.
participants (4)
-
Alan Horstmann -
Gabriel M. Beddingfield -
Jonas Petersen -
Pavel Hofman