[alsa-devel] 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.