On Mon, Dec 19, 2011 at 05:00:31PM +0100, Johan Herland wrote:
Thanks for quantifying this for me. Between the crazy
audiophile
forums and my lack of experience in this field, it's not always easy
to keep track of how much is good enough, and what is just crazy
over-engineering. :)
Be very careful with what you read on 'audiophile' forums. 99% of the
high-end audio business is based on ignorance and hype these days.
Ok, I think I see now. Basically in order to prevent
sample rate
conversion or extensive buffering (to compensate for clock drift), you
must make sure that the input and output runs off the very same clock
(with a whole constant number of clock cycles worth of audio being
processed at any time in the audio PC).
Almost all audio cards use the *same* clock for input and output
anyway. Either one generated internally, or from a separate clock
input, or derived from one of the inputs. The latter is usually fixed,
for example the RME AES card can take its clock from AES input #1, but
not from the other AES inputs.
Ok, so I might be able to convert from AES/EBU to
SPDIF using a simple
(maybe even passive) circuit?
In the worst case it needs some resistors or a small transformer, but
in many cases (RME included) all you need is a correctly wired cable.
That is because the RME outputs are transformer balanced and can be
switched to a lower voltage.
The delicate point for AES->SPDIF is not the signal level or impedance
(as the AES signal is much stronger than needed anyway), but if the
SPDIF input accepts the AES format. The audio data is identical for
both, but there are also some subcode bits. One of these identifies
the signal as either 'professional' or 'consumer' - this affects the
meaning of some other subcode bits. Some SPDIF inputs will refuse the
stream if the 'pro' bit is set. The RME driver allows to select this
bit (at least in the Windows version, but I suspect also on Linux),
so you're probably safe in that case.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.