<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Now i am proceeding with project that we talked some time ago:<br/>
<br/>
Now I am planning to use several RME Madi HDSPe cards and Madi/Adat converters. <br/>
Running one at 96k (for audio) as master and two at 48k (for control voltages and some basic audio) resampled with zita.</div>

<div><br/>
3 Madi cards = 32 i/o @ 96k + 128 i/o @ 48k<br/>
<br/>
Can this amount of audio streams be handled by modern multicore systems?<br/>
Plus DAW, plugins, ect ?<br/>
With a pleasant latency?</div>

<div> </div>

<div>I guess yes, as there exists the RME MadiFX, too - which provides ~196 i/o @ 48k.</div>

<div> </div>

<div><br/>
<span style="color:#000080;">>> So low latency is important but sample accuracy not so much. </span></div>

<div> 
<div>
<div>The time-shift of sample-streams would be different on each start up, right?<br/>
Even if a jack-client is "hanging" or x-runs occure, after re-syncing the time-shift changes, right?<br/>
How much of a time-shift is about to be expected?<br/>
<br/>
<span style="color:#000080;"> >> there is no need for sample accuracy or other sonic artifacts introduced<br/>
 >> by SRC </span><br/>
<br/>
What kind of sonic artefacts in the resampled audio are expected?</div>

<div><br/>
Would it be a good idea to apply an aliasing-filter before feeding the zita-resampler?</div>

<div> </div>

<div> </div>

<div> </div>

<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Donnerstag, 14. November 2019 um 07:34 Uhr<br/>
<b>Von:</b> "Len Ovens" <len@ovenwerks.net><br/>
<b>An:</b> linux-audio-dev@lists.linuxaudio.org<br/>
<b>Betreff:</b> Re: [LAD] 9 soundcards ?</div>

<div name="quoted-content">On Wed, 13 Nov 2019, Manuel Haible wrote:<br/>
<br/>
> - The Expert Sleepers converters will interface with an Eurorack<br/>
> modular-synthesizer.<br/>
>  They are the only ones who have DC-coupled i/o with 20 Vpp,<br/>
> for control-voltages and audio. <br/>
<br/>
So low latency is important but sample accuracy not so much.<br/>
<br/>
> And I guess there is no mastering-studio running 48k in 2020, no offence<br/>
> intended.<br/>
<br/>
None taken. I am also pretty sure that the 96k is an advertizing feature<br/>
rather than technical. More to do with not having customers walk down the<br/>
street to someone who charges the same but uses 96k. If you are doing<br/>
mastering as a living, using 96k is fine. Doesn't sound any better, has<br/>
more losses than gains but it does keep the dollars rolling in so it is<br/>
worth while.<br/>
<br/>
> but if I would use more than one USB 3.2 - PCIe slots in a desktop-computer,<br/>
> the bandwith would be more than sufficient!??? <br/>
<br/>
My experience with USB 3 plugs on my desktop is that no matter where I<br/>
plug in the motherboard silently routes any of them through the same USB<br/>
bus anyway. Remember that they are USB 2.0 interfaces even if plugged into<br/>
a USB 3.0 plug. (even if the interface says USB 3 compatable it is likely<br/>
USB2.0 audio via USB 3) So adding dedicated USB PCIe cards may help, using<br/>
a USB 3 hub may (or not) help.<br/>
<br/>
> - 96k for the Madi-Chain and 48k for the ADAT Expert Sleepers chain.<br/>
><br/>
>  Maybe this could be achieved<br/>
>  - with zita-ajbridge by re-sampling?<br/>
<br/>
Yes this would work. As you are usng the USB devices for voltage control<br/>
there is no need for sample accuracy or other sonic artifacts introduced<br/>
by SRC.<br/>
<br/>
>  - Or with zita-njbridge in a network with one Rasperry-Pi for each<br/>
> USB-connection and re-sampling?<br/>
>  With this I might get rid of USB-conflicts, too. Running into more possible<br/>
> failures?<br/>
<br/>
R-pi 4 would be ok, R-pi 1-3 (so far as I know use USB internally for the<br/>
network IF as well and there is only one. Rpi4 fixes this. However,<br/>
network style bridging normally adds latency, so test first with one unit<br/>
to see how much this is (normally one or two buffer sizes of latency).<br/>
<br/>
Just a quick note on 96k vs 48k for reduction of latency. While this seems<br/>
like a possibility as 1024 buffer size goes through twice as fast at 96k<br/>
for example. The determining factor in latency is normally not the sound<br/>
card but rather USB itself (1 ms access cycle) or the amount of CPU power<br/>
available for DSP. So running at 64 buffer size at 48k generally means<br/>
needing to run at 128 buffer size to get the same reliability (maybe<br/>
higher)<br/>
<br/>
> Is running different samplerates a good idea?<br/>
<br/>
Once you are using SRC anyway, it makes very little difference. Running<br/>
them all from the same clock would be ideal.<br/>
<br/>
<br/>
--<br/>
Len Ovens<br/>
<a href="http://www.ovenwerks.net" target="_blank">www.ovenwerks.net</a><br/>
_______________________________________________<br/>
Linux-audio-dev mailing list<br/>
Linux-audio-dev@lists.linuxaudio.org<br/>
<a href="https://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">https://lists.linuxaudio.org/listinfo/linux-audio-dev</a></div>
</div>
</div>
</div></div></body></html>