Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture

[Pavel Hofman <pavel.hofman@ivitera.com>]

On 2.2.2013 23:47, Jonas Petersen wrote:
> Am 02.02.2013 11:44, schrieb Pavel Hofman:
> 
> Yeah, I found the right combination, it's OCKS0=1,OCKS1=0. Now the spdif
> input works, thank you!

Congrats.
> 
> I wonder why there is no level controls for the analog input (e.g. in
> alsamixer). Is that because the "AK5385 ADC chip has no control"? The
> ESI Juli doesn't have an analog input level control as well.

Right, ak5385 offers no attenuation control.

> 
> 
> Ok, to make it clear, on the ap192 the FSx registers are always at their
> default (0001). So far I've never seen them on any other value. Only the
> corresponding Channel Status bits do change.

OK

> 
> Well, I guess by default snd_ak4114_rate_get should still interpret the
> FSx bits. Other cards might work as expected (see 'Observation C' below).
> In the case of the ap192 it might make sense to read the Channel Status.
> Maybe it needs a flag that gets set on card initializing indicating what
> should be used?
> 
> But, after all it seems there is still something obscure in the rate
> detection. Because while watching the ak4114 registers when switching
> sample rates I made the following observations:
> 
> Observation A:
> 
> RME Multiface spdif out goes to AP192 spdif in. In Linux the FSx bits
> are alwas "0001" and the Channel Status bis are set according to sample
> rate and mode (consumer/professional).

That means the RME driver configured the SPDIF-out preamble correctly.
In alsa e.g. using the iecset tool.

> 
> Observation B:
> 
> ESI Julia spdif out goes to AP192 spdif in. (Recall that in windows the
> AP192 _does_ detect sample rate changes!)
> In Linux the FSx bits are alwas "0001" and the Channel Status bis are
> (almost) always _all_ "0". It seems the ESI does not send Channel Status
> at all (could it be the misconfiguration of the ESI?). It looks like this:
> 
> 0x07 = 0x10 (00010000) [FS3,2,1,0 etc.]
> 0x08 = 0x00 (00000000) [CS0]
> 0x09 = 0x00 (00000000) [CS1]
> 0x0a = 0x00 (00000000) [CS2]
> 0x0b = 0x00 (00000000) [CS3]
> 0x0c = 0x00 (00000000) [CS4]
> 
> There is one strange exception. When I switch the output to spdif in the
> (I think it is) pulseaudio GUI. Then register 0x09 will be '00000010'
> for 5 second and switch back to '00000000'. When I play the test sound,
> then register 0x09 _and_ register 0x0b will be '00000010' for 5 second
> and switch back. Other than that the Channel Status does not change.

I do not know in windows, but in alsa the SPDIF bits can be set
explicitly by user space. See the AESx params in
/usr/share/alsa/pcm/iec958.conf , /usr/share/alsa/cards/ICE1724.conf
(setting the alsa control "IEC958 Playback Default"). ICE1724 datasheet
says the integrated SPDIF transmitter should set the corresponding SPDIF
bits (reg MT3C) automatically:

quote

These bits declare the S/PDIF transmitter clock rate (64*fs) in the
Channel Status Byte 3, low
nibble if Consumer mode (MT3C_0 = 0) and Byte 0 (bits 7-6) and Byte 4
(bits 6-3) if
Professional mode (MT3C_0 = 1). It will be set automatically by MT01 low
nibble if master. In
slave mode (MT01_4 = 1), to display the correct sampling rate, it must
be written to reflect the
external clock recovered.

endquote


> 
> Now, how is the windows driver detecting the rate if there is a) no
> crystal in there and b) no Channel Status available? Might it be the
> clock being on PLL (I'm not realy aware of what that means right now)?

I do not know, are you sure there is really no channel status available?

> 
> One thing might be of interest here: when switching the sample rates,
> register 0x06 does the following: Bit 0, bit 4 and flash to 1 for a
> short moment and back to zero (sometimes 2 times in a row).
> 
> 0x06 = 0x11 (00010001) [flash to 1]
> 0x06 = 0x00 (00000000) [and back to 0]
> 
> Bit 0 is "PAR: Parity Error or Biphase Error Status"
> Bit 4 is "PLL Lock Status" (1 being "Out of Lock")
> 
> Observation C (this is regarding ESI Juli):
> 
> dbx 376 tube channel strip spdif out goes to ESI Juli spdif in.
> The FSx bits in register 0x07 of ESI Juli's AK4114 _do_ change on
> different sample rates. They do not match those in the datasheet though:
> 
> 1000 - 44kHz (expected: 0000)
> 1010 - 48kHz (expected: 0010)
> 1100 - 88.2kHz (expected: 1000)
> 1110 - 96kHz (expected: 1010)
> 
> So maybe this is another symptom of the ESI's misconfiguration?


When I tested the driver of Juli the values worked correctly. Let's
figure out AP192 first and then attack Juli :)


> 
> 
>> Back to the light indicating "sync source" in the windows driver. I
>> think it is reading status of GPIO06 as you reported "INT0 (pin36) --
>> GPIO6 pin 58". It would be possible to add a new read-only control for
>> sync source to revo.c for ap192. It might be useful. Of course a generic
>> method for ak4114.c would be more suitable but we would have to abstract
>> the reading method.
> 
> Ok, why not adding a control for that. But first explain something to
> me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in
> ak4114.c. How are they accessed? Where can I read for example the
> "IEC958 External Rate" value? In the proc dir they do not show up.
> Neither at Juli nor at AP192. Are these only API functions?

see output of amixer contents. They are defined as PCM-type controls
(not MIXER type and do not apper e.g. in alsamixer.

Regards,

Pavel.