DSP vs. FX-Teleport

  • Ersteller analographi
  • Erstellt am
analographi

analographi

Registriert
26.01.04
Beiträge
45
Reaktionen
0
Punkte
58
Vielleicht interessierts ja jemanden

Ich habe folgendes mail an Focusrite, TC Electronic, Waves und UAD geschrieben. Es geht darum, dass ihre DSPs eine relativ lange Latenzzeit haben, verglichen mit FX-Teleport und Aktuellen Soundkarten.

---------------------------------------------


Dear Sirs

Your [g=3]DSP[/g] solution has a fixed latency of 1024, respectivly 2048 samples for the roundtrip of the audio signal over your [g=3]DSP[/g].
This is exactly the same as it is with your competitive products.

But there is a software called "FX Teleport" (see http://www.fx-max.com/fxt/product.html#latency ) which uses a second windows computer over LAN to run plugins on it and it manages to send audio over LAN to the second computer and back into the sequenzer with a latency of 256 samples.

Experiencing this raises the question, why you product isn't able to have such a latency over Firewire, LAN, PCI or even PCIe?

Furthermore there are Firewire or PCI audio- interfaces from apogee or RME, which are able to send huge amounts of audio channels over an external analog or digital soundprocessor and back with latencies of 256 to 512 samples.

This again lets me ask the question: Why does your [g=3]DSP[/g] solution have such a high latency? And is the quality of the offered Plugins today the only reason to buy a [g=3]DSP[/g] Solution instead of a second computer and FX teleport?

This question has been raised in several forums and your answer is highly anticipated.

Thank you for your time and best wishes


THE ANSWERS:

---------TC - ELECTRONIC-----------------------
Thank you for your interest in our products.

The latency of PowerCore is not fixed, but dependend on the audio buffer size.
If the audio buffer size is set to 128 samples, the PowerCore buffer size can get as low as 128 samples.

We're constantly considering alternative ways to do processing, including streaming to other computers, but I can't say anything about specific future plans for TC.

Thanks for the input.

Best regards
Thomas Valter
Product Manager
TC Electronic
------------------------------------------------


---------Focusrite------------------------------
Hello Raphael,

Here is the info from our development team:

For the current release of the Liquid Mix, we chose a fixed latency of 2056 samples to support [g=17]DAW[/g] buffer sizes up to 1024. This decision minimises the overhead on the CPU and by guaranteeing a fixed delay makes delay compensation and sample accuracy between multiple channels easy to guarantee, as well as providing high data integrity for the avoidance of any audio glitches.

Latencies approaching 256 samples at 44.1kHz are now becoming possible with recent fast computers, although there is inevitably an increased overhead on the native CPU and an increased risk of other processes on the computer interfering with the audio. However we expect such latencies to be practical in the near future on well maintained host computers, and our policy of constant improvement means we will make these available as soon as we are confident that performance meets our stringent requirements for reliability and data integrity.

[We are working on 1.6 version of liquid mix at the moment which includes lower buffer size operation]

Solutions using LANs based on, for example, ethernet technology are intrinsically more susceptible to data corruption when used with short latencies because, unlike FireWire, ethernet was not designed originally with the concept of real time service, but for packet based communications of bulk data where arrival time cannot be guaranteed. Please see the note at the end about the example you cite.

Liquid Mix provides unique emulations of classic EQ and compression that are not available on any other processing platform. The hardware has been optimised for the task and is extremely cost effective. Choosing a second general purpose computer to run these emulations would have been a more expensive and less satisfactory solution.

The fact is that the quality of the emulations is an overriding factor and is the reason for choosing Liquid Mix over the solution you suggest.

Notes on reference cited http://www.fx-max.com/fxt/product.html#latency

The system cited makes it clear that you cannot guarantee latency with the solution proposed. For example it states "In case of network overload the red indicator will show up, meaning that some audio packets have been lost". It also makes an unlikely claim that "Our tests have shown a latency of 128 to 256 samples (or even less) with the audio card buffer set to 128 samples". However you have to ask how latencies smaller than the audio buffer sizes are achievable, as this packet of data has to filled in the [g=8]plugin[/g], transferred to the audio output, buffered to the D/A converter and fed to audio amplifiers. The actual example quoted is of playing synthesisers hosted on a remote machine. This is a situation where data integrity can easily be ignored as the play data to the remote processor is not audio but are small data packets which can be transferred quickly, and the return audio from the [g=70]sequencer[/g] is fairly tolerant of audio glitches as it has no audio reference to compare it with. While no doubt an excellent tool, we would suggest that in order to assess latency and audio integrity, an extended period of bidirectional audio processing is tested to estimate the true workable latency in real situations.


Let me know if you need more info,

Oliver


This message and any attachments are confidential to the user of the e-mail address to which it was addressed. The sender does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission. Any opinions contained in this message are those of the author and are not given or endorsed by Focusrite or office through which this message is sent unless otherwise clearly indicated in this message and the authority of the author to so bind the Focusrite entity referred to is duly verified.


-------------------------------------------------------



------------Waves--------------------------------------

Thank you for your mail.

We are aware of NetShell’s latency. NetShell was never meant for live usage and as a studio based system for mixing it is designed to work with a latency-compensating [g=17]DAW[/g] – as such, low latency wasn’t considered an issue. NetShell’s latency is even lower then some of Waves plug-ins, DeBreath for example. We indeed agree that a NetShell-type system that is aimed for live usage would be required to run in low latency. It’s an interesting direction.

As a solution NetShell prioritizes resource usage efficiency (CPU, LAN, memory, etc.), wide support base ([g=77]VST[/g], AU, RTAS, ...), scalability, and other aspects higher then low latency, although latency is an aspect we’re working to optimize as well. Be aware that some of the supported hosts put boundaries to the lowest latency you can set, boundaries NetShell cannot cross without violation of the host’s API.

Please let me know if you will need any further information or assistance. Please include a copy of our on going correspondence in your mail.


Thank you for your cooperation,


Best regards,


Barry Cohen
Inside Sales
Waves Audio Ltd.


later another mail:


I wanted to add to my previous mail.



Waves main concern when developing our Audio Processing Accelerators was a focus on audio integrity and quality. We found for our initial release that lower latency setting, like with other 3rd party Ethernet solutions, would drop and degradate audio. This was simply unacceptable to Waves standards and the decision was made to not include lower latency setting to assure the highest quality process. This does not mean however, that we do not have plans to release lower latency support in the future for our APA line.

--------------------------------------------------------------


----------------------Universal Audio-------------------------

they sent a message, telling me that only the developers know, so they will forward the message, and that I'm not allowed to quote their message...
I never received an answer

-----------------------------------------------------------
 
Diese Effekte setzt man doch hauptsächlich beim Mix ein.
Also frage ich mich, wo jetzt bitte das Problem sein soll ?
Die [g=5]Latenz[/g] kann Dir doch Wurst sein.
Wozu brauchst Du unbedingt eine geringe [g=5]Latenz[/g] ?

Weisst Du nicht wie man einen latenzfreien Monitormix
beim recorden macht, oder wofür brauchst Du bitte eine geringe
[g=5]Latenz[/g] ?

Geringe Latenzen sind lediglich nützlich, wenn man [g=89]VSTi[/g] in Echtzeit
per [g=32]Midi[/g]-Masterkeyboard spielen möchte.
 
Jeder arbeitet anders.

Ich mache z.B. elektronische Musik. Komponieren, mischen, einspielen, komponieren, mischen ist ein endloser Prozess der sich nicht so einfach in zwei Teile aufteilen lässt. Ich spiele meine Synthies ganz anders, wenn sie erstmal durch diverse Effekte so richtig durch die Mangel gedreht wurden.

Zudem siehst Du ja an der Reaktion der Firmen, dass auch sie darauf bedacht sind die Latenzen zu senken. Anscheinend geht es nicht nur mir so.

Geringe Latenzen sind IMMER nützlich, wenn man keine Einschränkungen will.

Schön, dass Deine Arbeitsweise so linear und konform ist, dass das für Dich immer aufgeht. Aber das geht halt nicht jedem so.
Sobald nur ein bischen experimentierfreude aufkommt geht nichts mehr mit direct monitroring.

Ich habe das mail übrigens nach Absprache mit jemandem verfasst, der Professionel ganz konventionel Bands aufnimmt und auch der wäre froh, wenn die Latenzen der DSPs geringer wären.

Direct Monitoring ist nur ein schlechter Kompromiss.
 
mal ganz abgesehen davon ist es technisch interessant, da es einfach keinen Sinn macht, dass die DSPs heute noch so lange latenzen haben.

Auf das die Welt stehen bleibe!
 

Oft gelesene Themen

Zurück
Oben