2011/12/18 Jörn Nettingsmeier <nettings@xxxxxxxxxxxxxxxxxxxxxx>: > 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. > > 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 <URL: http://www.meridian-audio.com/the-collection/accessories/hd621-hdmi-audio-processor.aspx > 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 > 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. > > 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 > 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 > 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) > > 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 >> 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, <jherland@xxxxxxxxx> www.herland.net _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
