DSP comparison request

[Warp69]

Latencies are not inherent to the processors. The latency comes from the software, and how the data is moved from the hardware IO to application that is using the data.

You are 100% right, but allow me to completely disagree
not about cpu, but about the relation to a hardware, ie an ensemble of i/os, connections, cpu, ram etc....

Well, you're both right, but normally we're talking about the latency introduced by the software (OS and the actual plugins).

I just measured the roundtrips for Pulsar 2 (from the DSP environment - no latency introduced by the OS or buffer size).

44.1KHz roundtrip (in one direction) for SP-DIF = 4 samples = 0.09ms
44.1KHz total roundtrip (both direction) for SP-DIF = 8 samples = 0.18ms

The total roundtrip for the analogue connection is 66 samples - normally its 1/3 for the output and 2/3 for the input, so that will give us :

44.1KHz roundtrip for analogue output = 22 samples = 0.50ms
44.1KHz roundtrip for analogue input = 44 samples = 1.00ms
44.1KHz total roundtrip for analogue = 66 samples = 1.50ms

Let us do the same for the best audio interfaces - Apogee Symphony and Lynx Studio AES16e. They run without any problems at 32 sample buffers on my Mac Pro.

44.1KHz roundtrip (in one direction) for AES/Apogee = 32 + 2 samples = 0.77ms
44.1KHz total roundtrip (both direction) for AES/Apogee = 32 + 32 + 4 samples = 1.54ms

My AD/DA converter have 15 sample latency for the input and 8 sample latency for output - this give us :

44.1KHz roundtrip for analogue output (AES/Apogee -> D/A) = 32 + 2 + 8 samples = 0.95ms
44.1KHz roundtrip for analogue input (A/D -> AES/Apogee) = 32 + 2 + 15 samples = 1.11ms
44.1KHz total roundtrip for analogue (AES/Apogee -> D/A -> A/D -> AES/Apogee) = 32 + 2 + 8 + 32 + 2 + 15 samples = 2.06ms

The performance of my Logic setup is very close to the performance of the DSP environment of the Pulsar 2 - the next step for audio interfaces is 16 sample buffers in OSX.

[astroman]

44.1KHz total roundtrip for analogue = 66 samples = 1.50ms ...

interesting - that's precisely the value I get with my A16 (non-ultra) when I send something out and back in again.

cheers, Tom
ps: thanks for being the first to tell me

[spacef]

Thanks for those measures Martin
Some of your numbers are close to what i had or suspected (myself, I was talking only of latency when playing synths and the delay between midi-Note-On and hearing the sound - which is problematic as it also depends on how fast is the envelope/trigger method (driver+plugin latency) - but as that's the only thing i measured....).

Personally i'd be happy if Xite allows 3ms "ULLI" without problems (that would be around 1 / 1.5 ms output asio latency), and would be even happier if it goes down to 44 samples or less (may be we don't talk exactly of the same things - my interest being for using xite "live" in cunjunction with asio instruments without the need to "add delays" in xite to compensate for the asio latency). (makes me think i have a device to finish, for scope....) . 44/60 samples output asio latency seems ok to me for playing vstis and scope synths without the need to compensate for asio latency by adding delays in xite....

[winger]

"So i think latency, eventhough not bound to cpu/dsp themselves, is hardware dependant, and in this field, the superiority of scope is certain when it comes to synths and effects, mixing and all things that are nice to do on a real time basis, and that's been so for a long time (more than 10 years)...."

Ok, my trun to agree 100% but completely dissagree

You are right that hardware changes have improved latencies. But the hardware improvements are to make the software more efficient. You said that the asio drivers get down to 1 ms. If you think about that, that is huge. How many instructions can be executed in 1ms?

The latency is mostly the os and how it interacts with the drivers. You could toss out the os, and write software that would access the hardware directly, process the data and output the data and you could have microsecond latency. But you would not have a very flexible system then. When processing multiple things like an os does, you need to buffer the data so you can work ahead to avoid dropout. Most of the latency comes due to buffering and keep buffer sizes small keeps the latency down to a reasonable amount.

Scopes hardware is designed to make it very quick and easy to read handle io and i'm sure there is dedicated hardware to make it easier (translated to reduced latency). This is your point made correctly. However, when you move the data from scope to windows via asio driver you introduce latency and this is due mostely to buffers. It is a simple data transfer. The data is written to memory in a block, and read by the os when it gets around to it. Latency introduced by the buffer size, and how long the os waits to read the buffer. If the cpu could be waiting for every sample and you made the buffer size 1 sample, you would have 1 sample latency introduced by the transfer.

Conclusion, windows is an evil latency generator!

[spacef]

Ok.. i understand
i think we have an agreement

[netguyjoel]

I'll second that.......(Scope for Linux?) Dare I even think it out loud..

Joel

[siriusbliss]

Personally i'd be happy if Xite allows 3ms "ULLI" without problems (that would be around 1 / 1.5 ms output asio latency), and would be even happier if it goes down to 44 samples or less (may be we don't talk exactly of the same things - my interest being for using xite "live" in cunjunction with asio instruments without the need to "add delays" in xite to compensate for the asio latency). (makes me think i have a device to finish, for scope....) . 44/60 samples output asio latency seems ok to me for playing vstis and scope synths without the need to compensate for asio latency by adding delays in xite....

Makes me reconsider investigating the 'external' hardware routing in Samplitude (with 'delay compensation') to reduce ASIO latency and see how low I can go on big projects....hmmmmmmm.....

Greg

[greenbluegold]

This is just for contemplation, and I'm sure is misleading in some ways, but for a 20 year old relative perspective consider the original ensoniq eps sampler and the original apple macintosh. Both used a motorola 680000 processor. The eps had a custom OS made for processing digital audio, while the macintosh had a general purpose OS.
The eps had ~ 20 note polyphony, with real time digital filters, 3x envelopes, LFO, sequencer with very very low latency. The macintosh could go boing a little bit after when you clicked on a button.
Exact same processor very different results when it came to what it could do with audio, and it pretty much comes down to the OS.
Ok so in 20 years there have been great advances in CPU power to the point where !despite! having a general purpose OS running underneath, you can still do an amazing amount of audio manipulation, but the OS, and especially the code for writing audio apps, is what holds back the power today, as it was 20 years ago.
I suspect the complexities of modern processors are beyond the point where a person could to sit down and design an audio specific operating system / integrated application to run on the chip in a couple of weeks (which is how the eps was developed). However, it would unleash tremendous power if they could do so.

[astroman]

...Both used a motorola 680000 processor. The eps had a custom OS made for processing digital audio, while the macintosh had a general purpose OS.
The eps had ~ 20 note polyphony, with real time digital filters, 3x envelopes, LFO, sequencer with very very low latency. The macintosh could go boing a little bit after when you clicked on a button.
Exact same processor very different results when it came to what it could do with audio, and it pretty much comes down to the OS...

welly, welly, well... you couldn't be (much) farther off
let's do a timewarp into the mid 80s and see what this 8 MHZ shoebox could do for a musician
you'll see composition software, sound librarians, sample editors with waterfall spectra ...
the original Macintosh even had crude 4 bit sampling right from the beginning and it was used as the editing frontend for early Ensoniqs via SCSI.
The (home) Apple IIgs had the exact Mirage soundchip on board - Ensoniq probably wasn't keen at all to license that for the (pro) Mac
here's another clip that shows how fast the machine is booted from a floppy (early speech synthesis)

cheers, Tom
big thanks greenbluegold - without your remark I'd have never found those clips

[ScofieldKid]

After looking at the original question of this (very interesting) thread, I think you may have meant to ask a different question. Rather than comparing DSP to CPU... I would ask what your friend's interest is. My own interest in Scope was in the Synthesis environment and the quality of the synth emulations. In that arena, it succeeds tremendously. Having incredible sounding versions of the Minimoog, Odyssey, Prophet5/Pro-One/Prophet-VS... is a big deal to me. And the work environment that the tool presents is a very intuitive one for expanding on that foundation.

I would add, this is probably not an either/or question for your friend... depending on his situation. Depends on how he wants to work, what he wants to accomplish, and his own preferences. What I can say about the Scope stuff is that it works really well, and sounds incredible. If he wants a work environment like that, there it is. Whether he wants a particular external piece of dedicated hardware, or wants to work with VST's, or wants to write music, or likes a particular virtual studio environment... might be more important questions for your friend in the long run, than how many cycles get burned by one process or another in general. Lots of choices, and his own priorities probably will likely best decide the issue.

[siriusbliss]

Well, the original question was meant to fuel discussions on relative horsepower of Scope/Xite vs. other current paradigms so that I can eventually do some mag. articles - so that stands (and it's been a successful inquiry so far).

Nevertheless one friend is a synth-heavy kinda dude with tons of VST synths and other moosh such as Reaktor that he uses with Live, but he keeps hitting the ceiling and therefore desires to get back to his roots of performing with more 'hardware'.

The main reason for me is the studio environment, and the infamous routing schemes. Believe it or not I've hardly touched the synths in over a year, but am looking forward to doing more guitar-synth stuff when Xite lands.

In the interim, it's what Scope provides in the studio such as routing in/out/around Samplitude for tracking, and then mixing and mastering all within one main project containing THREE mixers, some plugs, effects and reverb, etc. My film-scoring friend and collaborator is REALLY interested in Xite for this reason alone.

Believe me these guys get it, and can't wait to see what I'm able to do down here.

It's gonna be a fun Summer

Greg

[ScofieldKid]

Ah, ok.

Well, I guess the obvious point to make here is... again, it's not either/or. If they're doing it all now in software, there is no law that stops them from adding scope. The beauty of the DSP hardware is how lightly it loads on your system.

So I guess another factor in all this is workflow when you are doing both. I liked the latency discussion above. But it was the case of not going in and out of a software sequencer/multi-track. Probably issues to pay attention to on that front.

The other end of the spectrum is living entirely within Scope. I don't think anyone mentioned VDAT yet, but if you can live entirely in Scope, that's kind of cool.

[Sounddesigner]

The XITE system have 12 X ADSP-21369 at 333MHz - each DSP is capable of 1998 MFLOPS. The XITE have 6 additional ADSP-21065L at 66MHz which is capable of 198 MFLOPS each.

The total processing power is therefor around 25 GFLOPS.

A Core i7-920 can reach 42+ GFLOPS.

The new 8-core MAC Pros has ALOT of power - 100+ GFLOPS (depending on the model). Most people are waiting for something like Larrabee which is capable of 2000+ GFLOPS with 32 x86 cores.

The above is peak performance and not sustained performance.

DSP's is not better than a CPU in anything - but DSPs are quite cheap compared to the performance that they deliver and the circuit boards are more simple and therefor cheaper.

But there's more to it than raw power - to achieve those numbers above you'll have to use SIMD 128bit/512bit vector units and the current compilers doesn't optimize automatically for the SSE/AVX etc. so that has do be done manually - some VST/AU developers have started (but most haven't started yet), but there's a long way before they master parallelism.

The 8-Core Mac pro is a Expanded computer ( 2 processors and 8 cores) and represents total available power for the intel platform. If XITE-1 is cascadable and you can combine 2 or 3 together then you have to consider the total platform power for SCOPE that forms one system. Likewise with UAD, 4 UAD-2 Quads can form one system. Likewise with current SCOPE Cards, 42 dsp's is total platform power.

I do have a question regarding Receptors, the Receptor uses a dual core E8400, what is the GFLOPS for that? It's worth noteing that 10 Receptors can be combined but i don't know how seamless it's expansion is tho, may not be worth combining.



@ siriusbliss, the Total available power for the platform and software performance and utilization of power are the focus points. We don't know if several XITE's can be combined or not yet.

[ScofieldKid]

Yeah, things look pretty good at the IOH level. On the X58 they say they can support 32-lanes of PCIE 2.0. (I'll assume Xite is 1.0, but anyway). So 2.5Gbps for a PCIE lane, and we just say back of the envelope that a QPI path can handle at least 20 of those...

Seems like we will want to be using the graphics cards slots, trying to stay on the north side of things. Or at least I would say that I have had much better performance in the past when I have paid attention to keeping things north.

[oldspeak]

x-cite would be 1.1

[garyb]

a 1x slot carries plenty of data atm....

[greenbluegold]

To go off an another tangent, it seems like it would be a good idea (or at least very cool) to abstract audio/synthesis into a 3d vector language and do sound with a GPU.

[Mr Arkadin]

To go off an another tangent, it seems like it would be a good idea (or at least very cool) to abstract audio/synthesis into a 3d vector language and do sound with a GPU.

i literally have no idea what you just said .

[astroman]

say CUDA and start thinking...
AcousticAudio already did... to a degree...
btw, it's pretty pointless for 'stream-like' DSP data processing, think twice

cheers, Tom

[greenbluegold]

[quote="astroman"]
btw, it's pretty pointless for 'stream-like' DSP data processing, think twice

cheers, Tom[/quote]

Ok way off topic now...

I don't think the real-time aspect would be necessary. I'd be quite happy with a 3-D space translated into spacialized sound that you could render offline and play back as an audio/visual movie. Some high end reverbs use ray tracing, but why not have vectorized sound objects bouncing off walls. There are similar things in 2D, but 3D x time would be a lot of fun. A synesthesia machine. Wouldn't it be fun to sequence though architecture? We could finally have those conversations about dancing to buildings etc.