2011/12/19 Jörn Nettingsmeier <nettings@xxxxxxxxxxxxxxxxxxxxxx>: > On 12/18/2011 03:28 PM, Johan Herland wrote: >>> 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. > > with these very simple and mostly linear operations, you will gain nothing > at all from upsampling. certainly nothing that would justify doubling the > cpu and throughput expense of your system. Yeah. After some thinking it's now obvious to me why I shouldn't upsample (as long as the rest of the pipeline can do the sampling rates I throw at it). However, I do want to use as many bits as possible in processing, to make sure that I don't loose detail by shifting bits into oblivion. > preventing the full fidelity of material produced at 96k is another issue, > but such material is rare outside of studio workflows. Actually, 24/96 and even 24/192 is becoming usual if you get your music from sites like hdtracks.com or gubemusic.com. >>> 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? > > all digital gear in the signal chain must run from the same clock, unless > you insert a sample-rate converter. > in a studio, there is a common wordclock which is distributed to all > players, processors, and output DACs. > consumer equipment will generally not be able to deal with external > clocking, so your source will have to be the clock master. the clock is then > distributed embedded in the signal - hdmi audio, spdif and aes/ebu are all > self-clocking. I don't see how the _entire_ pipeline can run off a single external clock. Say, I have a simple setup: A CD player connected to the audio PC doing a simple digital volume control, and then outputting the signal to a (Power)DAC. Obviously there will be some (small but still non-zero) delay between the audio PCs input signal and its output signal. How can both signals run from the same clock? Or does the audio PC sync the output to a _later_ pulse form the clock generator (i.e. all that matters is that the signal is synced with _a_ clock pulse, not necessarily _the_same_ clock pulse with which it was originally transmitted)? But if so, couldn't I have one clock between the CD player and audio PC, and a different clock between the PS and the DAC? And is self-clocking somehow inferior to an external clock? If an external clock is better, how come ethernet/USB/firewire and all other digital communication protocols run without external clocks? Sorry for being thick, but I haven't worked with these things before... > but this also means that if you switch from blue-ray player a to blue-ray > player b, your sound card must change its clocking source from input a to > input b. which might or might not cause an audible click or thump. Can't you "fix" this by quickly muting the signal, then switch sources, and unmute after you've "locked" onto the new signal? If the switch is software-controlled (via RS-232) wouldn't that be fairly simple to do? > as to "maximizing fidelity", this is digital pcm. it either works perfectly > or not at all. the only way to slightly degrade the signal is to have a > lossy codec in between (such as ac3 or dts), or when you're forced to insert > a SRC. but the latter should be pretty close to perfect if it's a good one. > no longer bit-transparent, obviously. Ok, so if I save money by not using external clocking, and using consumer-grade equipment (but stick to lossless PCM), I will either get a perfect signal, or get no signal at all. And if I get no signal at all, it's likely to be because my cheap devices don't agree on where the clock pulse is. Correct? >> 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). > > haven't done a proper survey, but i'd use RME gear for this job. which means > the combination of adat card plus external AES/EBU bridge will be more > expensive and less elegant than the hdsp/aes card. Yeah. I guess I'll have to wait and see what digital amps I end up with. The high-end scary expensive ones take both SPDIF coax/toslink and AES/EBU, but there's a growing breed of cheaper DIY-inspired digital amps (e.g. the miniDIGI/miniAMP combo <URL: http://www.minidsp.com/products/minidspkits/minidigi >, or the SUMOH amps <URL: http://www.sumoh.com/index-2.html >) that only take SPDIF coax/toslink input. I don't know whether it's cheaper/easier to convert AES/EBU or ADAT to SPDIF coax/toslink... Then again, there are some digital amps that take USB input (e.g. the miniSTREAMER/miniAMP combo <URL: http://www.minidsp.com/products/ministreamer >, or the HFX RipAMP 2.1/100 <URL: http://www.hfx.at/index.php?option=com_content&view=article&id=376&Itemid=185 >), which would bypass the entire audio interface altogether. However, I find it hard to believe that you could plug 4-8 of these into a single computer without maxing out the CPU or USB controller... Have fun! :) ...Johan -- Johan Herland, <jherland@xxxxxxxxx> www.herland.net _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
