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.