Hi Leute, da mir das Thema etwas zu kompliziert ist, versuche ich es ertmal auf Deutsch. In diesem thread https://audiosex.pro/threads/my-brand-new-workstation-is-a-6000-piece-of-junk.34128/ wurde folgendes, für mich sehr aufschlußreiches Video gepostet Wenn ich das jetzt richtig verstanden habe, ist das Problem der Echtzeitperformance, daß die ganze Peripherie ständig irgendwelche Rückmeldungen an die CPU gibt (oder auch von ihr einfordert) und diese (die CPU) während dieser Belästigungsphase keine Berechnungen mehr von der DAW zur Soundkarte weiterleitet und es dadurch zu Tonaussetzern kommen kann. Daraus ergibt sich für mich folgende Frage: Warum kann man die Kommunikation zwischen Peripherie und CPU nicht auf ein, oder zwei Kerne samt zugehörigen threads beschränken und die restlichen Kerne und threads ausschließlich der DAW und Echzeitberechnung zuweisen? Liegt das am Betriebssystem (ist also, im Falle von Windows, Billyboy Gates mal wieder Schuld), an der Hardware (also der Art und Weise, wie die Peripherie mit der CPU kommuniziert), oder was? Und wenn das nicht geht, gibt es dann nicht zwangsläufig eine Performancegrenze, die sich nicht überschreiten läßt, egal wie gut die Prozessoren werden?
mit bill und gates hat das wenig zu tun...windows muss immer für den sin und zweck angepasst werden.es gibt nicht ohne grund ne server version!glaub mir windows ist zu allem zu gebrauchen,auch für echtzeit berechnungen.sehe ich das richtig das du dir ne server einheit zusammen geschustert hast...?!?sind da jetzt wirklich 2 cpu´s drinn?wenn du mit dem englischen etwas zu kämpfen hast...dan würd ich dir gern helfen!?!
@Recoil na, super, die erste Antwort ist gleich off topic , is aber nich so schlimm. Das Problem mit der buffer size kenn ich schon seit Jaaahren, das mit den Treibern seit Jahren und die dawbench.com Seite seit Monaten, oder Jahren. War also nix Neues, ist aber aufschlußreich - für den, der das nicht kennt.
@albert001 da liegt wohl ein kleines Mißverständnis vor. Der o.g. thread ist nicht von mir (und ich benutze auch keine "Xenon" Prozessoren), ich kannte nur das Problem bei der Echtzeitberechnung mit den An- und Abfragen der Peripherie noch nicht und wollte deshalb wissen, wieso sich das nicht umgehen läßt. Und was das Englische angeht, ich war heute einfach nur zu faul.
na jut...ich geh jetzt erst mal schlafen!sag dem server typen er sollte sich mal process lasso anschauen..dort kan er den multimediaklassen manager von windows einstellen..und er kann die i/o imperoperabilität die cpu affinität und das vordergrund boosting aktivieren!ich melde mich morgen wieder...gute nacht!!!
The thing is that windows and linux didn't start as realtime os'. Beos claimed to be a realtime os. Linux got realtime kernel extensions some years ago, i'm pretty sure windows got something similar. But 'realtime' is quite philosophical. In ancient times user input devices were interrupt handled. That was actually a real wire that told the system 'hey, that bloody bloke did something on the keyboard, we should handle that'. That was realtime, but as we had crt displays back then it took up to 20ms until the letter i typed was displayed, or better: drawn by the cathode ray. What I want so say: There is no real 'realtime' in this world as long as physics are involved. The sound traveling from your speaker to your ear takes 3 ms per meter... so... Now lets say your audio interface has an overall latency of 3-5 ms. Thats pretty realtime, or realtime enogh. What your system does or does not while you play your piano samples doesnt matter, as long as it is in time back to the task of shoveling samples to your soundcard.
@Plendix thanks for your answer, but I was refering to the "realtime" problem is the video, so, you might watch it to understand what I mean.
Dafür ist der Satz aber ganz gut. Du kannst mir auch auf englisch antworten, das werde ich schon verstehen, wie Du mittlerweile wissen dürftest. Ich war nur zu faul auf englisch zu schreiben...
