vink
atropos-krans-os
ik zal deze thread zo simpel mogelik beginnen, en men weet dat is een hele opdracht, voor mij.
wat je over latency vindt op internet, je ziet b.v. op gearspace heel statistieken, en overzichten van verschillende geluidskaarten, ik zal, wanneer nodig, nog eens de link opzoeken, RME eindigt vrijwel altijd bovenaan natuurlik.
goed.
je ziet vooral, ook in recensies, mensen stunten met een 32 sample buffer size, en de RTL latency, die dat oplevert, in wezen zijn de verschillen volgens mij vrij minimaal.
een 32 sample buffer, zelfs met server, hoe krijg je die zo snel vol, dat je geen buffer overrun krijgt?
ik zie dit gaat me niet lukken. simpel beginnen.
ik richt vooral op ITB gebruik, terwijl natuurlik een hybride setup hier ook welkom is, wanneer dit een interessante thread wordt...
RTL is bij ITB niet belangrijk, behalve voor vocals, maar daar heb je direct monitoring voor. de output latency wel.
to the point!
de lijst, een aantal nieuwe kaarten staan er niet;
wat RXC, CV, NCV betekent weet ik niet.
bovenaan staat de RME, maar wat opvalt de latency bij een 512 sample buffer (ik zie overigens de sample rate niet vermeld), dezelfde latency zo ongeveer heeft als mijn..... behringer UMC204HD.....
ik neem dat de meesten weten dat een hogere sample rate, lagere latencies geeft, maar natuurlik ook veel meer CPU kracht vereist.
sample rate en grootte van sample buffer hangen samen.
goed. ITB, zelfs met een flink proc, 512 sample buffer haal je snel, zeker wanneer een plugin (b.v. pigments 3), de cpu voor ontbijt eet, en pigments 3 lijkt dat ook te doen, ik heb zo'n gevoel door inefficiënte kode.
of ik kan dat geheel mis hebben, ook MPE veroorzaakt een groot cpu gebruik.
overigens CPU gebruik en hoe snel een sample buffer vol zit, zijn niet altijd 1 op 1. wat je in een DAW ziet, is hoe snel de buffer wordt gevuld, niet CPU gebruik, en soms zie je plugins die niet zo heel veel CPU trekken, en toch de buffer snel vol gooien.
het lijkt mij dat het hele latency verhaal niet het hele verhaal, maar ook de efficiëntie van de driver om de data goed te verwerken, dat lijkt onder latency te vallen. maar ik heb nooit daar iets over gelezen, het lijkt me dat dat onderscheiden kan zijn.
waarom vraag ik dit; ik heb een nieuwe studie desktop pc, en mijn oude Motu Ultralite Mk3 Hybrid, lijkt zich nu prima te gedragen op 512 sample buffer. wat niet de beste latency oplevert, die is hoger dan bovengenoemde behringer. dat is schijnbaar, dat wist ik niet, maar ik vermoedde al zoiets, dat ze dubbele buffering op de output, of zoiets (weer zoiets) toepassen.
ik zie ook dat cpu's luier worden, bij hogere sample buffers, zelfs met vast overklok, i.e. reële klokfrekwentie, dus geen stiekem slapen (wat mijn nieuwe studio desktop pc doet..).
het is moeilik to the point te zijn. wat ik eens wil weten, wat zijn nu echte praktijk ervaringen. b.v. een RME die met dezelfde latency toch beter presteert? als mijn behringer UMC204HD, die nu ook overigens in de studio staat.
het is heel leuk dat je een RTL van 3 ms, afgerond op 32 sample buffer kan krijgen. maar wanneer knalt dit het systeem dicht???
de meest praktische vraag is, ik vind de latency van mijn Motu aanvaardbaar op 512 samples, en nu ook weer veel beter op 256 sample buffer size werken. op 512 sample buffer size is de output latency ongeveer 23ms, wat tot groot geschreeuw leidt; dat is te veel, etc.
er zijn ook wat mythen over latency, sowieso, de afstand tot je monitoren; latency; zelfs een versterke heeft een latency; hardware synthesizers (analoog of digitaal) hebben latency, midi heeft latency.
ja dan wordt het een optelsom, en natuurlik waarvoor ben je gevoelig. ik heb een artikel gelezen, nooit bij stilgestaan, een kerkorgel, da is pas latency!! kun je toch goed bespelen.
dus het kan gewenning zijn, of je kunt er ekstreem gevoelig voor zijn, ik ga dat niet ontkennen.
maar heb nooit een duidelikke thread gezien over praktijk voorbeelden, je ziet wel in threads dat mensen zelfs met aardig 'spul', ITB snel naar 1024 gaan of zelfs hoger....
en je hebt show offs, met 64 sample buffer (zelfs op 96Khz), ja dat laatste met alleen audio tracks, kan bijna elke geluidskaart.... want of cpu...
dus wat is mythe? wat is de praktijk?
dus hoop dat dit een soort van algemene thread kan worden, met praktische inzichten. want de link die ik gaf, gaat met Dawbench, benchmarks voor een CPU, kunnen een overgeklokte CPU, of beter het systeem laten crashen, maar die benchmarks doen dingen, niet allemaal, er zijn er ook die wél praktische en hoge belasting 'emuleren', die normaal nooit voorkomen, alleen SSE/AVX routines (vooral die laatste) op volle kloksnelheid, sja... zo werkt bijna geen enkele code...
(en meer specifiek voor mij, inzicht natuurlik, en of een het vervangen van de oude Motu, door een Motu M4 b.v. me zoveel zal opleveren, ik kan het zelf niet uitproberen, geen M4 te vinden... en b.v. een RME, ik zou het eens weekje willen uitproberen, zag wel een RME babyface (geen pro of pro fs, maar de eerste) om marktplaats, maar om die te kopen voor een test (en wellicht dan te houden))
er wordt nogal gerommeld met cijfers.
ik heb een projekt op mijn nieuwe studio pc gemaakt, die op mijn oude systeem niet zou werken. toch zijn het maar 4 (!!!) soft synths, ja 2 met MPE, vooral Pigments 3 is de boosdoener, crusher- x met 1100 grains, maar die peutert dan nog uit zijn neus, kan ie ook op stuklopen, Vital, eigen preset met MPE, (allemaal eigen presets/samples), die toch meer trekt dan ik dacht, met morhping van de wavetable (bekend als CPU killer, b.v. serum... en alle anderen), music developments syne, sja die gaat naar 19.6K partials, oftewel 19600 sinus oscillatoren... maar vooral Pigments 3, MPE, 2 x granular engine, woops.
het systeem speelt het feilloos af, maar ik hoef de Pigments 3 track niet dupliceren, of dan....
TL;DR
ik hoop dat het toch duidelik is. en ik laat het gewoon staan, het is VINK, hee, sommige tradities mot je in ere houe...
wat je over latency vindt op internet, je ziet b.v. op gearspace heel statistieken, en overzichten van verschillende geluidskaarten, ik zal, wanneer nodig, nog eens de link opzoeken, RME eindigt vrijwel altijd bovenaan natuurlik.
goed.
je ziet vooral, ook in recensies, mensen stunten met een 32 sample buffer size, en de RTL latency, die dat oplevert, in wezen zijn de verschillen volgens mij vrij minimaal.
een 32 sample buffer, zelfs met server, hoe krijg je die zo snel vol, dat je geen buffer overrun krijgt?
ik zie dit gaat me niet lukken. simpel beginnen.
ik richt vooral op ITB gebruik, terwijl natuurlik een hybride setup hier ook welkom is, wanneer dit een interessante thread wordt...
RTL is bij ITB niet belangrijk, behalve voor vocals, maar daar heb je direct monitoring voor. de output latency wel.
to the point!
de lijst, een aantal nieuwe kaarten staan er niet;
Audio Interface - Low Latency Performance Data Base - Page 155 - Gearspace.com
Quote: Originally Posted by monkeyxx ➡️ Yeah I have a 'regular' Quantum, the first one. It's hard to go completely for a purchase based on online discussions, for many reasons including subjectivity, different levels of ability, computer knowledge, recording styles etc. The thing I love the most...
gearspace.com
wat RXC, CV, NCV betekent weet ik niet.
bovenaan staat de RME, maar wat opvalt de latency bij een 512 sample buffer (ik zie overigens de sample rate niet vermeld), dezelfde latency zo ongeveer heeft als mijn..... behringer UMC204HD.....
ik neem dat de meesten weten dat een hogere sample rate, lagere latencies geeft, maar natuurlik ook veel meer CPU kracht vereist.
sample rate en grootte van sample buffer hangen samen.
goed. ITB, zelfs met een flink proc, 512 sample buffer haal je snel, zeker wanneer een plugin (b.v. pigments 3), de cpu voor ontbijt eet, en pigments 3 lijkt dat ook te doen, ik heb zo'n gevoel door inefficiënte kode.
of ik kan dat geheel mis hebben, ook MPE veroorzaakt een groot cpu gebruik.
overigens CPU gebruik en hoe snel een sample buffer vol zit, zijn niet altijd 1 op 1. wat je in een DAW ziet, is hoe snel de buffer wordt gevuld, niet CPU gebruik, en soms zie je plugins die niet zo heel veel CPU trekken, en toch de buffer snel vol gooien.
het lijkt mij dat het hele latency verhaal niet het hele verhaal, maar ook de efficiëntie van de driver om de data goed te verwerken, dat lijkt onder latency te vallen. maar ik heb nooit daar iets over gelezen, het lijkt me dat dat onderscheiden kan zijn.
waarom vraag ik dit; ik heb een nieuwe studie desktop pc, en mijn oude Motu Ultralite Mk3 Hybrid, lijkt zich nu prima te gedragen op 512 sample buffer. wat niet de beste latency oplevert, die is hoger dan bovengenoemde behringer. dat is schijnbaar, dat wist ik niet, maar ik vermoedde al zoiets, dat ze dubbele buffering op de output, of zoiets (weer zoiets) toepassen.
ik zie ook dat cpu's luier worden, bij hogere sample buffers, zelfs met vast overklok, i.e. reële klokfrekwentie, dus geen stiekem slapen (wat mijn nieuwe studio desktop pc doet..).
het is moeilik to the point te zijn. wat ik eens wil weten, wat zijn nu echte praktijk ervaringen. b.v. een RME die met dezelfde latency toch beter presteert? als mijn behringer UMC204HD, die nu ook overigens in de studio staat.
het is heel leuk dat je een RTL van 3 ms, afgerond op 32 sample buffer kan krijgen. maar wanneer knalt dit het systeem dicht???
de meest praktische vraag is, ik vind de latency van mijn Motu aanvaardbaar op 512 samples, en nu ook weer veel beter op 256 sample buffer size werken. op 512 sample buffer size is de output latency ongeveer 23ms, wat tot groot geschreeuw leidt; dat is te veel, etc.
er zijn ook wat mythen over latency, sowieso, de afstand tot je monitoren; latency; zelfs een versterke heeft een latency; hardware synthesizers (analoog of digitaal) hebben latency, midi heeft latency.
ja dan wordt het een optelsom, en natuurlik waarvoor ben je gevoelig. ik heb een artikel gelezen, nooit bij stilgestaan, een kerkorgel, da is pas latency!! kun je toch goed bespelen.
dus het kan gewenning zijn, of je kunt er ekstreem gevoelig voor zijn, ik ga dat niet ontkennen.
maar heb nooit een duidelikke thread gezien over praktijk voorbeelden, je ziet wel in threads dat mensen zelfs met aardig 'spul', ITB snel naar 1024 gaan of zelfs hoger....
en je hebt show offs, met 64 sample buffer (zelfs op 96Khz), ja dat laatste met alleen audio tracks, kan bijna elke geluidskaart.... want of cpu...
dus wat is mythe? wat is de praktijk?
dus hoop dat dit een soort van algemene thread kan worden, met praktische inzichten. want de link die ik gaf, gaat met Dawbench, benchmarks voor een CPU, kunnen een overgeklokte CPU, of beter het systeem laten crashen, maar die benchmarks doen dingen, niet allemaal, er zijn er ook die wél praktische en hoge belasting 'emuleren', die normaal nooit voorkomen, alleen SSE/AVX routines (vooral die laatste) op volle kloksnelheid, sja... zo werkt bijna geen enkele code...
(en meer specifiek voor mij, inzicht natuurlik, en of een het vervangen van de oude Motu, door een Motu M4 b.v. me zoveel zal opleveren, ik kan het zelf niet uitproberen, geen M4 te vinden... en b.v. een RME, ik zou het eens weekje willen uitproberen, zag wel een RME babyface (geen pro of pro fs, maar de eerste) om marktplaats, maar om die te kopen voor een test (en wellicht dan te houden))
er wordt nogal gerommeld met cijfers.
ik heb een projekt op mijn nieuwe studio pc gemaakt, die op mijn oude systeem niet zou werken. toch zijn het maar 4 (!!!) soft synths, ja 2 met MPE, vooral Pigments 3 is de boosdoener, crusher- x met 1100 grains, maar die peutert dan nog uit zijn neus, kan ie ook op stuklopen, Vital, eigen preset met MPE, (allemaal eigen presets/samples), die toch meer trekt dan ik dacht, met morhping van de wavetable (bekend als CPU killer, b.v. serum... en alle anderen), music developments syne, sja die gaat naar 19.6K partials, oftewel 19600 sinus oscillatoren... maar vooral Pigments 3, MPE, 2 x granular engine, woops.
het systeem speelt het feilloos af, maar ik hoef de Pigments 3 track niet dupliceren, of dan....
TL;DR
ik hoop dat het toch duidelik is. en ik laat het gewoon staan, het is VINK, hee, sommige tradities mot je in ere houe...
Je 1e post heb ik gelezen, je 2e reaktie heb ik ff overgeslagen. Maar dit is op zich wel een nuttig en interessant onderwerp. Die super lage latencies op 32 of 64 zou ik idd maar ff terzijde schuiven, lijkt me niet dat mensen dat in de praktijk met “echte projecten” voor elkaar krijgen (dwz zeggen een redelijk aantal sporen vanaf 20 bv, ikzelf zit soms tegen de 50 of meer aan, waarbij eea dan niet alleen uit audio sporen bestaan, maar ook “live” vsts spelen, dus geen freezes). Als mensen dat wel voor elkaar krijgen hebben ze waarschijnlijk echt extreem dikke bakken.
, misschien kunnen we hier wat voorbeelden verzamelen, met screenshots van je instellingen (sample rate, buffer en latency) icm met je PC specs.
, ik zal morgen hier eens wat posten, maar vast ff uit mijn hoofd, ik denk dat ik op 256 zit bij 44.1kHz en dan iets van 13ms heb. Ik heb een RME UFXII met een core I7 6700 geloof ik.
