20 Dec
2011
20 Dec
'11
1:29 a.m.
On Mon, Dec 19, 2011 at 17:57, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
This looks promising. It seems I'm closing in on a system looking
something like this:
- Various HDMI sources connected to an RS-232 controlled HDMI switch
with SPDIF output (e.g.
http://www.marmitek.com/en/product-details/audio-video-at-home/connect/conn…
). Ideally, I wanted a better method of extracting audio from the HDMI
switch, but it seems none are available.
- I also have a networked media drive that will be available to the
audio PC for direct playback.
- An audio PC with the RME HDSPe AES interface, doing surround
decoding, volume control, room correction, and crossover in software,
and outputting 2-channels-per-speaker mixed PCM data on the available
AES/EBU outputs.
- Running one AES XLR cable to each speaker position, where each
(2-way) speaker has a dedicated 2-channel digi-amp/powerDAC that does
the final conversion to the analog speaker inputs.
- I'm currently looking at digi-amps from SUMOH (
http://sumoh.com/index-2.html ), which seem to offer a nice tradeoff
between price and performance, although my search is far from over.
I currently have a 5.1 speaker system, so I'll need 5 amps (running
the subwoofer through its own analog amp for now). Given that I
already have the audio PC (minus audio interface), and the HDMI switch
is on its way, a quick calculation puts me somewhere near €2500, which
is in line with what I'd originally estimated for this project.
That should give me a good starting point for playing around with the
software, especially the room correction and crossover configurations.
I'll also be quite flexible hardware-wise:
- Expanding to 7.1 (requires a total of 7x2 (+ 1) channels, which the
RME card will handle; then simply add 2 speakers and 2 amps).
- Upgrading one amp at a time, and experimenting with different amps
for different speakers (e.g. putting some more money in the front
speaker amps, since those are more "important" than the surround
speakers).
Thanks again for all your help. Have fun! :)
...Johan
--
Johan Herland, <jherland(a)gmail.com>
www.herland.net
On Mon, Dec 19, 2011 at 05:00:31PM +0100, Johan
Herland wrote:
Thanks. Useful advice. I like to think that I only spend money on
stuff for which I have a clear and scientific rationale for why it's
worth the money, but it does require a lot of time researching
available options and understanding the underlying technologies (don't
get me wrong, the learning process is fun as well). However, when you
get into the specific implementations and "secret sauce" of chip
technologies, it's sometimes impossible to make 100% informed
decisions. For example, I'm currently comparing digital amplifier
technologies, especially TI Equibit/PurePath HD vs. Diodes/Zetex DDFA
(they seem to be the main commercially available contenders in the
all-digital HiFi-amp space), but so far there are so many stats and
other variables that muddy the waters. At some point I'll just have to
listen to the available options, and simply let my ear decide.
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, 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.