Re: [LAU] What audio interface to use for a Linux-powered surround preamp?

2011/12/19 Jörn Nettingsmeier <nettings@folkwang-hochschule.de>:
> 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@gmail.com>
www.herland.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user