[alsa-devel] M-Audio Audiophile 192 (ice1724)'s broken spdif capture
jnsptrsn1 at gmail.com
Thu Jan 31 21:56:04 CET 2013
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
> . 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
> 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.
More information about the Alsa-devel