linuxaudio.org

2011/12/18 Jörn Nettingsmeier :

quoted text
> On 12/15/2011 02:59 AM, Johan Herland wrote:

>>  2. Decode and/or upsample the input (if necessary) into a suitable

>> format, typically 96kHz or 192kHz 24-bit PCM in 8 channels (for a 7.1

>> system).

>

> out of curiousity, what is the benefit of upsampling? is there something

> peculiar about power dacs that would make it useful or mandatory?

It's not really a requirement, but I thought it'd make sense for two reasons:
1. Making sure there's enough resolution to do room correction, volume

control, etc. without losing details.
2. Forcing everything into a common format to make thing

simpler/uniform for the remainder of the pipeline and the dacs/amps.
>>  - A HDMI switch with audio split (SPDIF) and RS-232 control.

quoted text
>

> hdmi to spdif means that you either get only two channels, or lossy

> encoding.

True. Ideally, I'd be able to run the HDMI directly into the PC, and

pick up the sound signal directly from the HDMI stream. However, I

don't know of _any_ consumer-available HDMI input card, and even if

they were available, I probably wouldn't be able to decode an

HDCP-encrypted stream (or maybe the audio signal isn't encrypted? I

don't really know HDMI...).
Meridian has an HDMI switch http://www.meridian-audio.com/the-collection/accessories/hd621-hdmi-audi...

quoted text
> that I believe is able split of the HDMI audio without signal loss,

but the audio is output using either MMHR (over RJ45) or SmartLink

(over 4xRCA), which are (AFAIK) both encrypted and can only be

connected to other Meridian gear. (Also, I don't have $3000 to spend

on an HDMI switch.) I don't know of any other commercially available

physical connection that can carry the full information of the HDMI

audio signal.

> plus you will need to think about the clocking structure. usually

quoted text
> this will mean that your audio card will have to slave itself to the

> incoming hdmi/spdif/whatever.

Hmm. I don't really know much about clocking. How would you organize

the system to minimize clocking issues, and maximize fidelity?
>>  - A suitable audio interface with at least 8 digital outputs.

quoted text
>

> tough one. there are a number of cheap options with ADAT, but you will need

> two at 96k due to s/muxing, and four at 192k. for the latter, the only

> option i know of is the rme raydat.

I've been doing some reading on 96kHz vs. 192kHz, and most people seem

to think that there is no audible difference, and that it's a lot of

marketing hype, so until I'm convinced otherwise, I'm not going to

spend extra money on 192kHz equipment. So what other equipment is

available with 2 ADAT outputs?
> iirc, rme also has a card with native aes/ebu outs, and it should be working

quoted text
> ootb with the normal driver, but you may well find yourself to be the only

> user ever of this card under linux. so be prepared to get in touch with adi

> and get your kernel compilation toolchain ready :-D

Yes, the RME HDSPe RayDAT and HDSPe AES are the two cards I've been

looking at the most. However, the AES seems to be ~60% more expensive

than the RayDAT, so I'm leaning towards the RayDAT. It really comes

down to how cheaply I can convert from ADAT to either AES/EBU or SPDIF

(either of which is what most digital amps will take as input).
When it comes to kernel compilation, I'm not too scared, as my

background is in Linux and software. I'm more afraid to screw up the

audio hardware part of this project... :-)
> the vendor is moderately linux-friendly, at least they are providing specs

quoted text
> and not actively making our lives harder than necessary. plus the gear tends

> to be reliable and flexible.

That's my impression of RME too. I'll gladly spend some extra bucks on

equipment that will cause less headache in the long run.
>>  - MOTU 828mk3 (capable, but seems to be poorly supported by Linux)

quoted text
>

> don't go for firewire. it's great for mobile use, but a) it's on the way

> out, b) it requires a very carefully tuned low-latency system, and c) it

> totally does not work with frequency scaling and you will burn a quarter of

> the available cpu cycles just to get the audio data in and out. pretty

> deadly for an embedded and possibly passively cooled system.

Thanks! That's exactly the kind of advice I was looking for. I had a

feeling that it'd be simpler with PCI(e) than with firewire, and now

I'm convinced. :-)
>>  - Focusrite Saffire PRO 40 (seems similar to RME Multiface II, but

quoted text
>> cheaper. Unsure how well it is supported by Linux)

>

> it is well supported, but see above.

>

>> What other audio interfaces should I check out? Are there other things

>> I should keep in mind when picking an audio interface?

>

> unfortunately, the only answer for truly professional audio hardware under

> linux is rme. not that their gear is bad, but it sure is expensive, and i

> wonder what we're going to do if they ever turn evil... time for those open

> hardware projects...

Indeed. I've seen some DIY projects that are interesting to hobbyists

[*]. Hopefully some of them will "grow up" to become interesting to

professionals as well.
Thanks a lot for your input! :)
...Johan
[*]: Some of the interesting DIY audio interfaces I've stumbled across:

http://www.minidsp.com/products/ministreamer

http://www.qnktc.com/ab_11/
--

Johan Herland,

www.herland.net

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-user