ich habe heute nachmittag kurzfristig eine latenzmessung am qu16 gemacht (analog in und out), um einen post auf meinem facebookprofil zu vervollständigen. ich bin auf sehr interessante ergebnisse gestoßen, die ich hier etwas näher erläutern möchte.
die ausgangssituation war folgende: qu16, ab168 (16/8 stagerack), macbook pro, waves superrack native, smaartv7 und ein älteres firewire audiointerface (edirol). der stimulus war pinknoise, der direkt in smaart generiert wurde. die in- und outs am edirol waren allesamt analog, um hier bereits laufzeitunterschiede ausschließen zu können. diese können entstehen, wenn gleichzeitig analoge und digitale ports für messungen verwendet werden und nur teilweise a/d-d/a-wandlungen in den pfaden vorhanden sind. normale fft-messung mit 48k abtastung und hardware-loopback.
meine routings sind immer so gestaltet, und das ist pultunabhängig, dass ich meine inputchannels auf subgroups schicke und von dort weiterroute bzw. direkt auf meine ausgangsbusse gehe. diese können der masterbus, weitere subgroups oder matrizen sein. da nun aber das qu16 keine subgroups hat, die man danach auf den masterbus routen kann, hab ich folgenden „subgroup-workaround“ gemacht (hardpatch), den ich nachfolgend als „quasi-subgroup“ nenne: ich gehe mit den inputs postfade in den mix5/6, dann raus analog (xlr 5/6) und direkt wieder in den input ST1 (2x symm. klinke) rein. so kann ich mir eine pseudo-subgroup machen, von der ich dann auf den master gehe. btw: manchmal habe ich auch hier ein ua apollo geinsertet für zusätzliches processing. natürlich mit einer weiteren a/d- und d/a-wandlung. soweit, so klar! wenn ich nun waves superrack (wsr) verwende, wird eben genau in diese „brücke“ digital per usb wsr geinsertet.
wie sieht es nun mit den gruppenlaufzeiten aus?
laut datenblatt hat die qu16 1,2ms latenz von local-in zu local-out und das dsnake-protokoll hat eine fixe latenz von 4 samples (= 83us) point-to-point, also one-way. verdoppelt man diese für hin und retour, ergibt das zusätzlich 8 samples (= 166us). insgesamt ergibt das rechnerisch rund 1,37ms. interessant erscheint mir nun, warum meine messung (bild 1B) aber 1,65ms ergibt, was wiederum eine erhebliche abweichung zum datenblatt zeigt! 0,45ms differenz klingt einerseits nicht besonders viel, ist im digitalen audiobereich aber doch relativ viel meiner ansicht nach, vorallem dann, wenn es sich um eine abweichung zu einer datenblattangabe handelt.
folgende messergebnisse sind entstanden und mit den screenshots dokumentiert: (anmerkung: der amplituden- und phasengang tut nichts zur sache ;))
bild 1A (local-in xlr / local-out xlr): channel direkt auf den master geroutet -> 1,65ms roundtrip
bild 1B (local-in xlr / ab168-out xlr): channel direkt auf den master geroutet -> 1,75ms roundtrip
bild 1C (ab168-in xlr / ab168-out xlr): channel direkt auf den master geroutet -> 2,08ms roundtrip
bild 2 (ab168-in xlr / ab168-out xlr): channel auf die „quasi-subgroup“ und dann auf den master geroutet -> 3,65ms roundtrip. d.h. alleine durch die zweite a/d-d/a-wandlung ergibt sich ein plus von 1,57ms! ergo: sollte nun ein pultsetting gemacht werden, wo neben dieser „quasi-subgroup“ auch einzelne channels direkt auf den masterbus geroutet werden, gäbe es phaseninkohärenz! dazu müsste man alle direkt auf den masterbus gerouteten channels mit 1,57ms am input delayen, damit man in-phase am output ist! btw: die dlive ist phasenkohärent in diesem fall, da alles intern geroutet wird!
bild 3 (ab168-in xlr / ab168-out xlr): channel auf die „quasi-subgroup“ und dann auf den master geroutet -> 12,15ms roundtrip. statt dem hardware-patch ist nun wsr geinsertet, jedoch ohne plugs, d.h. nur die app superrack im pfad. hier sieht man deutlich, wieviel laufzeit allein durch die app superrack native dazukommt, nämlich rund 10ms! diese entsteht einerseits durch den coreaudio treiber, der eben bei macs auf systemebene aufsetzt und andererseits durch die app-interne buffersize. oder? dazu weiter unten mehr 😉 den wsr audiobuffer habe ich mit 64 samples eingestellt, da mit 32 samples knackser o.ä. artefakte im audiosignal zu hören waren. mit 64 war davon nichts mehr zu hören und die cpu-last auch unter 8%.
bild 4 (ab168-in xlr / ab168-out xlr): channel auf die „quasi-subgroup“ und dann auf den master geroutet -> 13,56ms roundtrip. auch hier wsr im pfad aber mit 4 plugins, die insgesamt 68 samples ausmachen. in summe macht das für wsr digital 2×64 + 68 = 196 samples bei 48k aus, das wiederum 4,08ms roundtrip ergibt.
rein rechnerisch ergibt sich nun eine „rest“-gruppenlaufzeit von 13,56 – 4,08 – 2,08 = 7,4ms, die ich nicht genau zuordnen kann. meiner meinung nach, kann sie in diesem ausmaß vom apple-internen coreaudio treiber nicht herrühren, da dieser auf systemebene aufsetzt und optimiert für proaudio-anwendungen u.ä. programmiert wurde. demnach bleibt meine vermutung im pult-internen usb2-interface, das mit doch erheblichen zwischenspeichern, also puffern, designt und ausgeführt wurde. man muss aber auch fairerweise dazusagen bzw. -schreiben, dass die hauptanwendung dieser usb2-schnittstelle NICHT im nativen live-processing, sondern im multitrack-recording liegt. das wiederum erklärt die internen, relativ hohen buffersizes in den zwischenspeichern, um multitrackings sauber, sicher und ohne knackser zu bewerkstelligen!
und ja: sollte jemand meiner leser auch eine derartige messung durchführen, bitte um info zwecks datenabgleich! wäre interessant!
es bleibt spannend! … mit audioengineering eben immer 🙂
#knowledgebase #soundengineering #audioengineering #realengineering #soundengineer #andreas
Gefällt mir:
Like Wird geladen …