Word Clock!?

Ist zwar unkonventionell, aber vielleicht dann doch einmal älteren Treiber ausprobieren?
 
ok. ich habe auch bisher den 1.0 und den 1.7 treiber ausprobiert.
es gibt noch einen dawzischen zum downloaden, werde es ausprobieren.


edit: was zum teufel...argh...
http://www.focusrite.com/support/software/saffire_pro_40/

wenn ich versuche den älteren treiber herunter zu laden (Saffire Mix Control 1.5), kommt:
"You do not have permission to download this file"
 
Herrjeh, es tut richtig weh zuzuschaun, wie Wolfgang und HvO aneinander vorbei reden!

Wenn ich das alles richtig verstehe, dreht HvO nicht an der Buffergröße (=[g=5]Latenz[/g]) sonden an einem zweiten Regler, der irgendwie mit "Platzierungsversatz der Aufnahme" beschriftet ist und den Wolfgang nicht kennt, weil sein Equipment sowas nicht braucht. Der ist wohl extra dafür da, bei fehlerhaften Treibern von Hand den Versatz zu korrigieren. Mit der [g=5]Latenz[/g]/Puffergröße hat der Regler nix zu tun und dieser Regler kann auch auf negative Werte gestellt werden. Was bei der Puffergröße/[g=5]Latenz[/g] wohl schlecht geht -)

Außerdem entnehme ich HvOs Posts, dass der vom Treiber verursachte Fehler auch von der eingestellten [g=5]Latenz[/g]/Puffergröße abhängt und HvO dann jedesmal den Aufnahmeversatz-Regler nachstellen müsste, wenn er die Puffergröße ändert, was nervig wäre.

Andererseits könnte HvO den Aufnahmeversatz dafür verwenden, den durch die [g=131]ADAT[/g]-Übertragung und die externen [g=60]Wandler[/g] in der ADAT-Kiste verursachte zusätzliche [g=5]Latenz[/g] zu kompensieren.

Sehe ich das so richtig, HvO?

Jetzt noch was anderes: HvO schreibt in Post #54 dieser unendlichen Saga: "(in [g=539]Cubase[/g] ist der Latenzauslgeich deaktiviert, daran liegts also auch nicht)". Bist Du sicher, dass es nicht genau daran liegt? Wenn Du [g=539]Cubase[/g] sagst, dass es die [g=5]Latenz[/g] nicht ausgleichen soll, wäre es kein Wunder, dass Du dann von Hand rumfrickeln musst. Hmmm....


Gerhard

P.S. Im Übrigen kompensiert der Treiber nicht die [g=5]Latenz[/g] (wie sollte er), sondern er meldet sie (anscheinend nicht immer korrekt) an die DAW, die dann die [g=5]Latenz[/g] korrigiert.
 
Was ich gemeint habe ist wirklich der "Aufnahme-Versatz" Regler, den es in vielen DAWS gibt. Dieser Regler SOLLTE bei guten Treibern einfach auf Null stehen, da dann die Latenzkompensation die [g=5]Latenz[/g] ausgleicht.

Falls die Treiber aber Müll sind (wie hier) kann man da manuell den Versatz einstellen, um den der Treiber falsch liegt.

Das hat natürlich nichts mit negativem Sample-Buffer zu tun, das sind zwei Paar Schuhe.

Jetzt ist hoffentlich klar was ich meinte, und nein Schwachsinn ist das nicht.

Gruss
match
 
PerfectMatch schrieb:
... den es in vielen DAWS gibt.

Dann zaehl doch mal die Vielen auf?

Ich kenn kein Einziges...

So einen "Regler" kenn ich nur fuer [g=32]Midi[/g] um die Eingangslatenz anzugleichen aber fuer Audio?
 
PerfectMatch schrieb:
Was ich gemeint habe ist wirklich der "Aufnahme-Versatz" Regler, den es in vielen DAWS gibt.
Bei Ableton heißt der tatsächlich "Treiberfehler-Kompensation",...

Falls die Treiber aber Müll sind (wie hier) kann man da manuell den Versatz einstellen, um den der Treiber falsch liegt.
...und es ist ein Live-Set (als Tutorial verpackt) dabei, das Schritt für Schritt durch den Loopback-Test führt, den HvO gemacht hat.



TopTension:
Andererseits könnte HvO den Aufnahmeversatz dafür verwenden, den durch die [g=131]ADAT[/g]-Übertragung und die externen [g=60]Wandler[/g] in der ADAT-Kiste verursachte zusätzliche [g=5]Latenz[/g] zu kompensieren.
Er hat den Treiberfehler mit dem Loopback-Test ja schon im Interface identifiziert, da stelle ich es mir heikel vor, auch noch eine Korrektur für [g=131]ADAT[/g] drauf zu packen.
 
Ihr versteht mich. :)

Der manuelle Aufnahmeversatz ist echt eine Notlösung wenns zum Beispiel ums reampen geht, aber sonst ist das natürlich Käse, weil die Verschiebung latenzabhängig ist.

Die [g=131]ADAT[/g] Verzögerung nutzen um die [g=5]LAtenz[/g] auszugleichen geht nicht, da die VErzögerung über [g=131]ADAT[/g] nur 1ms beträgt und der Versatz ins negative etwa 5ms beträgt.

Was den Latenzausgleich in [g=539]Cubase[/g] angeht, ergibt dies keine Veränderung wenn ich den Latenzausgleich aktiviere oder deaktiviere, leider.


So wie es aussieht liegt es zu 100% an dem Treiber, was mich echt ärgert.


Jetzt überlege ich halt ob ich es zurückschicken soll oder einfach mit dem Problem leben/arbeiten muss. Ich tendiere dazu es zu behalten, da mir das Interface absolut gefällt und ich ansonten begeistert bin.
Meine Hoffnung besteht wirklich darin, dass es irgendwann noch ein Treiberupdate geben wird, wo dieses Problem behoben wird. Ich habe aber die Befürchtung, dass die meisten Leute es gar nicht merken und es vielleicht deshalb gar nicht behoben wird. Hätte ich das nicht getestet, wäre es mir wahscheinlich auch nicht aufgefallen.... jedoch spätestens beim ersten Reamping.


Nochmal danke für euer Bemühen!

Gruß HvO
 
Wolfgang schrieb:
PerfectMatch schrieb:
... den es in vielen DAWS gibt.

Dann zaehl doch mal die Vielen auf?

Ich kenn kein Einziges...

So einen "Regler" kenn ich nur fuer [g=32]Midi[/g] um die Eingangslatenz anzugleichen aber fuer Audio?

[g=539]Cubase[/g] kann das, [g=540]Logic[/g] wenn ich mich recht erinnere auch. Bin davon ausgegangen das es alle können.

In PT LE kann man nur [g=32]Midi[/g] manuell ausgleichen lassen ([g=32]Midi[/g] offset glaube ich).

match
 

Ähnliche Themen

RECORDING-Redaktion
  • Artikel
Antworten
0
Aufrufe
790
RECORDING-Redaktion
RECORDING-Redaktion
moonbooter
    • Danke
  • Artikel
Testberichte Test: Eventide H9 Max
Antworten
2
Aufrufe
2K
BassExplorer
B
L
Antworten
31
Aufrufe
2K
Lightyear
L
moonbooter
    • Danke
  • Artikel
Testberichte Test: Strymon Nightsky
Antworten
1
Aufrufe
3K
tim_heinrich
tim_heinrich
moonbooter
    • Danke
  • Artikel
Antworten
4
Aufrufe
4K
ollo123
ollo123

Oft gelesene Themen

Zurück
Oben