Am 31.01.2013 10:04, schrieb Pavel Hofman:
On 31.1.2013 02:19, Jonas Petersen wrote:
Am 29.01.2013 10:44, schrieb Pavel Hofman:
On 28.1.2013 22:25, Jonas Petersen wrote:
Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are connected to logical high? They should be :)
Physically they're both on ground. I don't know what active state that chip has though.
That would mean the chip is fed 11.2896MHz clock. I do not see any crystal on http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg . Is it the same card you have, with the crystal position empty? Are you really sure they are not on power supply?
I double-checked. There is zero ohms between these pins and ground (e.g. outer of the spdif connectors, or pin B3 of PCI). The adjacent pins are also on ground which are "VIN" (12), "P/SN" (9) and "IPS1/IIC" (8).
Yeah, pretty much excactly the same card. The crystal position is empty, like on the picture from nix.ru.
I did a quick test in Windows 7. This driver is able to
detect the sample rate. If I set the clock source to "spdif in" at the control pannel, then I can see the rate changing when I switch to another rate on the spdif source.
Did you test 192kHz and 176,4kHz? The receiver can work in two modes. Either it knows it is fed an independent clock and detects the sample rate precisely, or it simply reads the sample rate from SPDIF preamble of the incoming stream.
You mean probably this from the datasheet:
The AK4114 has two methods for detecting the sampling frequency as follows. 1. Clock comparison between recovered clock and X’tal oscillator 2. Sampling frequency information on channel status Those could be selected by XTL1, 0 bits. And the detected frequency is reported on FS3-0 bits.
It is indeed strange. There is an example system design in the datasheet that also has XTL0,1 on ground, but there is a 11 MHz Crystal on XTI and XTO.
The mode is select by the XTL0,1 pins. Often the streams do not contain correct information, especially for consumer mode which does not have room for the larger samplerates code. Could you please test both consumer and professional modes, all common samplerates?
I tested 32, 44.1, 48, 64, 88.2, and 92 kHz with both modes. All rates except 64 kHz are always reliably detected (64 kHz is not in the list of supported frequencies of the chip). They are detected no matter what mode I select (prof/consumer) on both sides, even if they do not match. I tried all combinations.
For these tests I was using an RME Multiface. I guess one can expect correct streams from this device...
Now I checked the spdif signal from a dbx 376 tube channel strip. 44.1, 48, 88.2 and 96 are detected properly.
Ok.. and now I just connected the ESI Juli(a) spdif out to the ap192 spdif in. I'm chaning the internal clock rate in alsamixer. Everything is detected, only 176.4 and 192 result in 88.2 and 96... But this might as well be the Juli failing, doesn't it? I wasn't able to play any sound at these rates neither.
By the way, the Windows 7 "M-Audio Delta Control Panel" has this "sync source" lamp. It is normally green an says "locked" if there is any detected signal. When I change the rate it will become red for a moment and say "rate missmatch", then it will display the detected rate and turn green again.
If I do nothing with a green "locked", it will periodically (about every 6 seconds) show a red "unlocked !" for maybe half a second. Only if I use the signal in a program (e.g. audacity) it will stay "locked" and green.
- Jonas