Pro Tools erkennt I/O-Latenz von RME-Wandler nicht. Was tun?

@Karlo:

so wie ich es verstanden hat, berichtet das interface sowohl an PT als auch an cubase (also höchstwahrscheinlich an beliebige hosts) die wandlerlatenz seiner analogen i/os, das heisst, was du
da rausspielst und wieder reinholst, sollte - solange eventuell eingeschleifte geräte nicht selber noch
latenz produzieren - phasensauber direkt wieder im projekt landen.
dasselbe scheint bei adat nicht der fall zu sein, hier wird weder an PT noch an cubase die interface-eigene latenz von 75 samples über adat (die mich schon für sich sehr verwundert) berichtet.
klingt für mich bisschen nach nem firmware-hoppala, das wahrscheinlich einfach noch niemandem aufgefallen ist. ein fehlerchen isses trotzdem :)

dass avid in der vergangenheit absichtlich seine nativ-lösungen bisschen beschnitten hat,
um die kundschaft zu den DSP basierten lösungen zu treiben ist richtig. ich habe aber den eindruck,
dass sie diese praxis inzwischen aufgegeben haben. was angesichts der marktsituation und der stetig
wachsenden leistung von nativsystemen ja auch nur folgerichtig ist. die geschichte vom pferd, dass nativ sowieso nix leistet, die haben sie ihren kunden zahllose jahre zu lang erzählt, da müssen sie sich jetzt bisschen reinhängen. karma gibts quasi auch in der daw-branche ein kleines bisschen ;-)

ist doch aber nett. grosser nachteil für PT-user (ich mag PT ja durchaus ganz gern) war ja immer die mangelhafte portabilität, das thema ist z.b. inzwischen hinreichend vom tisch. und im nativ-markt isses mehr wettbewerb. also alles super für alle :)
 
ein grosses PT projekt, welches nur von der DSP variante gewuppt werden konnte, konnte man sich nicht mal so eben aufm laptop mitnehmen, ohne saftige zugeständnisse zu machen.

(mit portabilität war arbeit unterwegs am laptop gemeint, nicht projektmigration von einem studio zum nächsten, was mit dem begriff ja gerne auch mal gemeint wird)
 
Das hat die DSP Variante nun mal so an sich, das eben wesentlich mehr geht als nur nativ. ;)
Trotzdem kann die Session geoeffnet werden und es kann selbst bestimmt werden welches Plugin gebraucht wird und welches nicht.

Aber ich weiss schon: Native rulez! :headbang:
 
wie man in beliebig vielen benchmarks lesen kann, ist nativ seit jahren in manchen belangen in der tat deutlich überlegen, bei bereits recordeten projekten, wo es dann um mixing oder editing geht und die latenz höher sein darf manchmal sogar ein vielfaches je nach verwendetem plugin - ist aber auch wurscht und das fass will ich gar nicht aufmachen :) unabhängig davon wie man zu der frage steht wars ja nunmal so: mit PT musste man sich lange zeit mit nativ-versionen abfinden, die künstlich beschnitten waren um das native PT nicht zu gut im vergleich zum DSP PT aussehen zu lassen. es ist zwar üblich, kleine versionen künstlich zu beschneiden (macht jeder hersteller so), aber es gab halt schlicht keine "komplett entfesselte" nativ-variante, bei der man sich sicher sein konnte: das teil nutzt jetzt wenigstens wirklich vollumfänglich mein setup aus.

das kannste dir auch in beliebigen PT only foren nachlesen, wie gut das viele user fanden ;-)

aber ist ja jetzt alles schnee von gestern und insofern vollkommen wurscht, der punkt ist ja gerade der, dass es jetzt nicht mehr so ist.
 
wie man in beliebig vielen benchmarks lesen kann, ist nativ seit jahren in manchen belangen in der tat deutlich überlegen, bei bereits recordeten projekten, wo es dann um mixing oder editing geht und die latenz höher sein darf manchmal sogar ein vielfaches je nach verwendetem plugin
Und trotzdem kann kein natives System eine voll loaded DSP Session oeffnen und in den Latenzwerten beim Recording koennen native Systeme nur davon Traeumen da mal hinzukommen.
Kein Wunder, das in Pro Studios ein DSP System immer die erste Wahl ist.
 
@Karlo:
so wie ich es verstanden hat, berichtet das interface sowohl an PT als auch an cubase (also höchstwahrscheinlich an beliebige hosts) die wandlerlatenz seiner analogen i/os, das heisst, was du
da rausspielst und wieder reinholst, sollte - solange eventuell eingeschleifte geräte nicht selber noch
latenz produzieren - phasensauber direkt wieder im projekt landen.

Mich würde interessieren, wie du darauf kommst. Hast du denn mal Messungen gemacht, die das belegen? Oder steht das irgendwo geschrieben? Ehrlich gesagt habe ich die Sache zu Beginn auch so verstanden, als ich das PT Manual gelesen habe. Aber nach meinen Praxistests mit 2 DAWs bin ich anderer Meinung. Zumindest beim Adat-Wandler ist es doch klar, dass das nicht so funktionieren kann. Wie soll denn der ASIO-Treiber meines Fireface in der Lage sein, der DAW einen Latenzwert für jeden beliebigen Adat-Wandler mitzuteilen, der ans Interface angehängt ist?

Mein vorheriges Audio-Interface war ein RME Multiface 2, und bei dem war es auch so, dass es eine deutliche I/O-Latenz gab (um 1 ms), die ich ausgleichen musste. RME ist bekannt für die besten PC-Treiber. Ich kann mir also nicht vorstellen, dass die was falsch gemacht haben.

Meine Support-Anfrage bei RME ist seit einer Woche hängig. Das ging früher auch schon mal schneller. Aber immerhin kriegt man dort noch Support, ohne extra zu bezahlen ;)
 
Mich würde interessieren, wie du darauf kommst. Hast du denn mal Messungen gemacht, die das belegen? Oder steht das irgendwo geschrieben?

was meinst du, die 75 samples? ich zitiere da bloss die beobachtung von "muenze" zu beginn des threads. ich selber benutze kein fireface mehr (bzw ich hab noch eins im rack, das macht aber nur noch standalone-routingaufgaben)

Zumindest beim Adat-Wandler ist es doch klar, dass das nicht so funktionieren kann. Wie soll denn der ASIO-Treiber meines Fireface in der Lage sein, der DAW einen Latenzwert für jeden beliebigen Adat-Wandler mitzuteilen, der ans Interface angehängt ist?

darum gehts nicht. es geht nur darum, dass das interface die latenzwerte seines eigenen adat ports (den es ja wissen kann) der daw mitteilt.

Mein vorheriges Audio-Interface war ein RME Multiface 2, und bei dem war es auch so, dass es eine deutliche I/O-Latenz gab (um 1 ms), die ich ausgleichen musste. RME ist bekannt für die besten PC-Treiber. Ich kann mir also nicht vorstellen, dass die was falsch gemacht haben.

ich bin der erste, der RME im zweifel blank in den himmel lobt, aber auch die können ja mal nen fehler machen :)
 
Und trotzdem kann kein natives System eine voll loaded DSP Session oeffnen und in den Latenzwerten beim Recording koennen native Systeme nur davon Traeumen da mal hinzukommen.
Kein Wunder, das in Pro Studios ein DSP System immer die erste Wahl ist.

als nutzer beides systeme weiss ich, dass das schon seit langem nicht mehr zutreffend ist, aber weils son ding ist an dem besitzer, die viel geld in DSP systemen stecken haben, sich so dolle festkrallen, weiss ich auch wie sinnlos es ist, diese eigentlich nüchtern faktische diskussion zu führen :)

naja, nur soviel: viele algorithmen laufen heute nativ in ungleich mehr instanzen als auf DSP. schon vor vielen vielen jahren gabs da lustige tests mit waves plugins, die du auf damaligen PT systemen vielleicht 60 mal öffnen konntest, auf nativ bei etwas hochgeschraubter latenz hingegen plötzlich eher 300 mal.

da sagt der DSPler natürlich "aha! bei hoher latenz! eben!". nun ist es aber so, dass inzwischen nahezu alle nativhosts modular aufgebaut sind und gleichzeitig hohe und niedrige latenzen fahren können. heisst, du kannst sämtliche kanäle die nur abspielen mit CPU-freundlicher latenz fahren und dementsprechend absurde mengen an plugins verfrühstücken, während du auf den scharfgeschalteten kanälen mit 32 samples unterwegs bist. feine sache ist das. sequoia/samplitude waren glaube ich die ersten, die das angeboten haben, credit where credit is due. heute ist das nahezu überall standard.

somit bleibt als letzte domäne von DSP "liverecording inklusive mixing und echtzeitmonitoring von sehr sehr hohen trackcounts" (also mehr als ein nativsystem bei 32 samples mit üblichen mengen an processing gewuppt bekommen würde, das wäre am beispiel meines auch nicht mehr ganz neuen systems so oberhalb sagenwirmal 64 spuren). die sei PT neidlos zugestanden, und ja, somit sind studios, die regelmässig sehr grosse ensembles (big bands, orchester, solche dinge) aufnehmen, weiterhin gut beraten, protools zu nutzen. wurde hier im forum ja auch schon zur genüge durchdiskutiert.

ist aber halt ein sehr kleiner markt. avid hat ja auch ziemliche probleme, mit seiner neuen generation nochmal eine ähnliche marktdurchdringung zu erlangen, ob das noch was wird...sei mal dahingestellt. ich selber zumindest brauche so gut wie nie mehr als 64 spuren bei echtzeittracking, mir persönlich kanns also herzlichst egal sein.

und jetzt kannst du gerne ne rede darüber halten dass echte profis sowieso niemals ensembles unter 64 spuren recorden oder so :)
 
da sagt der DSPler natürlich "aha! bei hoher latenz! eben!". nun ist es aber so, dass inzwischen nahezu alle nativhosts modular aufgebaut sind und gleichzeitig hohe und niedrige latenzen fahren können. heisst, du kannst sämtliche kanäle die nur abspielen mit CPU-freundlicher latenz fahren und dementsprechend absurde mengen an plugins verfrühstücken, während du auf den scharfgeschalteten kanälen mit 32 samples unterwegs bist...

und jetzt kannst du gerne ne rede darüber halten dass echte profis sowieso niemals ensembles unter 64 spuren recorden oder so :)

Nein, aber sie haben gerne eine Latenz ueber alle Spuren in allen Lagen.
 
vollkommen irrelevant im mix.

ausserdem ist es wenig mehr als ein nettes gerücht, du hättest in protools in allen lagen auf jeder spur keine latenz. hängste ein linearphasiges plugin (oder eins der anderen drölfhundert plugins mit eigenlatenz) rein und tschüss. kann halt auch nicht zaubern.
 
vollkommen irrelevant im mix.
Und warum sollte man sich ein anderes System kaufen wenn man vom Recorden zum Mixen kommt? ;)
Ausserdem recordet man ohne Latenzausgleich und beim Mix schaltet man es ein.
Scheinst noch nicht viel mit HD/HDX gemacht zu haben?
 
nur diverse alben und DVDs.

das ist jetzt ne reine quatschdiskussion hier. es ist selbstverständlich vollkommen unerheblich, wenn man bei recording in ein bestehendes komplexes projekt 2 latenzen hat. der einzige unterschied wäre während dieser zeit der, dass plugins auf scharfgeschalteten kanälen reglerbewegungen mit z.b. 32 samples latenz statt mit 256 samples wiedergeben. ansonsten werden natürlich sämtliche latenzen vom host ausgeglichen.

wenn eine diskussion an den punkt kommt wo man sich an sowas aufhängt kann ich nur sagen "i rest my case" :)
 
das ist jetzt ne reine quatschdiskussion hier.
Vollkommen klar. :D
Aber wenn man sich bei dir auf was verlassen kann dann das, das du das letzte Wort haben willst.
Da wirst du nur noch von m_tree uebertroffen. Aber nicht viel. :D

So. Und jetzt wieder du.
 
Ah, du meinst du hättest es gerne gemocht dass ich deinen Spruch "hast wohl noch nicht viel mit PT gemacht" demütigst im Raum stehen lasse? Ja sorry, nee is nich :)

Ansonsten : du machst ad hominem, ich nehm das letzte Wort? Deal :)
 
Ah, du meinst du hättest es gerne gemocht dass ich deinen Spruch "hast wohl noch nicht viel mit PT gemacht" demütigst im Raum stehen lasse?
Nee, nicht mit PT im Allgemeinen sondern mit HD/HDX im Speziellen.

Und jetzt wieder du. :D
 
SAW Studio klingt doch viel geyler, äy!!
 
doch, tatsächlich hab ich eher mit den nativen versionen von PT sehr wenig erfahrungen (die haben ja auch jahrelang nix getaugt mit ihren lächerlichen spurlimits).

langweilt. nimm du das letzte wort, ich bin raus.
 
was meinst du, die 75 samples? ich zitiere da bloss die beobachtung von "muenze" zu beginn des threads. ich selber benutze kein fireface mehr (bzw ich hab noch eins im rack, das macht aber nur noch standalone-routingaufgaben)

Nein ich meine grundsätzlich: Wie kommst du darauf, dass Audio-Interfaces ihre Latenzwerte der DAW mitteilen? Anders gefragt: Hast du schon mal mit einer DAW (ausser Pro Tools mit Avid-Wandlern) gearbeitet, in der du einen Hardware-Insert einfügen konntest, ohne dass du die Latenz der Wandler ausgleichen musstest? Und falls ja: Hast dus wirklich gemessen oder nur "gefühlt". Eine Verzögerung von 3 Samples bemerkt man ja nicht, ausser man macht Parallel-Kompression oder sowas.

Ich habe noch einen Thread auf dem Avid-Forum gemacht und es scheint, dass ich nicht allein bin mit meinem Problem. Sieht nach Pro Tools Bug aus.
 

Ähnliche Themen

RECORDING-Redaktion
    • Danke
  • Artikel
Antworten
1
Aufrufe
1K
AudioPaw
AudioPaw
RECORDING-Redaktion
Antworten
1
Aufrufe
6K
Gast92251
G
Antworten
28
Aufrufe
34K
organix
organix
W
Antworten
3
Aufrufe
763
whocaresin20years
W

Oft gelesene Themen

Zurück
Oben