Apple wirklich sinnvoll?

[Nachtschicht]

(nebenbei, wenn der kleine OT-ausflug erlaubt sei, freu ich mich sehr von rainer hier zu lesen. good times!)

 

[synthpark]

core audio hat also keinen pufferjitter? interessant. ich dachte bisher, das wäre technisch gar nicht möglich.

quelle? interessiert mich (wenn auch nur theoretisch, in der praxis halte ich pufferjitter für irrelevant bzw eine phantomdiskussion, da er bei kleinen puffern deutlich unter der ungenauigkeit von midi selbst liegt). aber quelle möchte ich trotzdem gerne haben, weil mich technisch interessieren würde wie das gemacht wurde.

ich hab keine Quelle. Ich habs einfach gemessen und andere Leute im Internet auch.

Ich seh auch nicht, warum dies technisch nicht moeglich sein soll. Es ist eine Frage, wie oft das System zum Beispiel den USB Bus abfragt. Es gibt an sich keinen Zusammenhang zwischen Midi und Audiopuffer, ausser dass sie sich quasi den gleichen Bus teilen, USB oder PCIe. Wenn da ein Zusammenhang besteht, dann wurde dieser quasi kuenstlich durch den ASIO Standard erschaffen, aber er muss gar nicht sein. Und der Bus hat ne Riesenbandbreite.

Klar kann man denken, nach 256 Samples duerfen dann erst Mididaten folgen etc. Also abwechselnder Datenverkehr. In dem Fall waere so ein Jitter dann die Folge, da die Mididaten in dieses Zeitschlitzverfahren gezwungen werden. Aber es gibt sich andere Moeglichkeiten, das zu vermeiden. Zum Beispiel, indem die Samplepakete bei der Uebertragnug kleiner gewaehlt werden, auf Kosten eines etwas groesseren Overheads.

Quelle muesste man erstmal suchen. Mal sehen, ob ich was finde.

 

[Nachtschicht]

leuchtet mir nicht ein. bin aber auch kein experte, weil ich wie gesagt das thema für in der praxis mehr oder weniger irrelevant halte, da man, wenn tatsächlich echtzeit-reaktion auf midiinput eine rolle spielt, natürlich mit niedrigen latenzen arbeitet und dann der jitter geringer ist als die ungenauigkeit von midi selbst (wie gesagt: klassischer john lennon chord gegriffen wird ja bereits über 5ms verteilt, eventuelle systemlatenzen des senders und empfängers nicht mit eingerechnet, nur der nackte midistandard).

deine beschreibung ist auf jeden fall nicht das, was ich unter pufferjitter verstehe, da hast du was falsch verstanden. hier nochmal in a nutshell:

- ein system spuckt daten in form von paketen zu je (z.b.) 256 samples aus
- das system empfängt ausserdem mididaten
- nun kann das system zwar wie du schreibst, die mididaten in höherer präzision als 256 samples empfangen. selbstverständlich reden wir da nicht von einem abwechselndem datenverkehr, ist ja albern.
- ABER: das ist nicht zuende gedacht. zum musizieren gehören hier ja zwei teile. erstens, der empfang der mididaten (sagen wir zum rechnen pauschal mit präzision 1ms). aber zweitens: die wiedergabe des durch diese mididaten ausgelösten audio-events. das, was du in deinem test mit aufgezeichnet hast. und DIESES kann selbstverständlich bei einer puffergrösse von 256 samples nur entweder in einem oder dem nächsten puffer ausgelöst werden, das liegt ja in der natur des pufferprinzips. sonst müsstest du den puffer kleiner machen.

wenn du nun also das pech hast, dass dein miditrigger minimal nach versenden des letzten 256-sample-päckchens eintrifft, dann muss dieser trigger fast 256 samples lang auf das entsprechende audiosignal warten, denn natürlich kann dieses audiosignal erst mit dem nächsten pufferpäckchen verschickt werden. wenn du hingegen glück hast, traf dein signal minimal vor versenden des nächsten pufferpakets ein und wird noch mit versendet, in dem fall beträgt die wartezeit nur wenige samples.

-> führt also insgesamt zu einem jitter von knapp 256 samples, also 5-6 millisekunden.

aus meiner sicht liegt das in der natur eines verfahrens, das audio in pufferpäckchen ausgibt, und dazu gehört coreaudio m.w. auch.

dann bleibt also nur noch die frage: ist es magie? oder hast du vielleicht einen fehler im testaufbau gehabt? sei mir nicht böse wenn ich dir sage, dass ich in dem fall letzteres für wahrscheinlicher halte. ich behaupte jetzt einfach mal ganz frech (im vollen bewusstsein dass du das unabhängig des wahrheitsgehalts vehement abstreiten wirst), dass du vielleicht einfach die tests in unkenntnis der problematik nicht mit absolut identischen puffergrössen gemacht hast. wahrscheinlich stand dein damaliger pc, der natürlich weniger leistung hatte als der später gekaufte mac, auf einer typischen pragmaten-latenzeinstellung, also wahrscheinlich 256 oder 512. haben ja jahrelang alle gemacht.

modernere systeme hingegen sind da deutlich potenter und da kann man locker von werk an mit deutlich kleineren puffern fahren. erst recht wenn man wie du offensichtlich "20-100 spuren" als hohe audiolast empfindet, da schlafen CPUs schon lange bei ein. rumms machst du denselben miditest, und dank der niedrigeren latenz wird der jitter exponential kleiner, und schon ist logic und coreaudio "grooviger" als deine damalige asio-erfahrung.

siehs mir nach wenn ich sage: finde ich naheliegender als die vermutung, apple hätte magische kräfte und könnte grundsätzliche gesetze der pufferbasierten audioübertragung aushebeln.

aber vielleicht haben sie ja auch ein system mit mehreren parallel laufenden pufferausgaben um das problem zu minimieren, kann ja schon sein (ich meine mal gelesen zu haben dass z.b. gigasampler sowas machte). das würde dann ja unter anderem auch die im schnitt sehr viel schlechtere low latency performance unter OSX erklären, das wäre dann ebene eine andere prioritätensetzung in der programmierung. deswegen hab ich nach einer quelle gefragt.

ich würde in dem fall aber trotzdem ganz klar die prioritätensetzung von asio bevorzugen. am ende des tages zählt die leistungsfähigkeit, und wenn dann ein system bei minimallatenzen (im livebandsetting spiel ich mein laptop inzwischen mit der minimallatenz von 48 samples) ordentlich performt, dann ist das thema pufferjitter aus meiner sicht am effektivsten aus dem weg geräumt.
aber von mir aus ist das geschmackssache.

aber wir wissen ja gar nicht, ob coreaudio mit solchen parallellayern arbeitet, das ist jetzt ja nur ne vermutung zu deinen gunsten sozusagen eigentlich würds mich überraschen. aber wie gesagt, bin kein experte.

 

[Gast92251]

Das mag ja alles sein...

Was interessiert es mich, ob da ein paar Milli-Latenzen mehr oder weniger sind, oder ob eine DAW ein paar mehr Plugins abspielen kann!
Heutzutage sind wir in CPU-Bereiche gestoßen, wo selbst kleine Rechner komplette Produktionen rein virtuell ermöglichen.
Mir ist es wichtiger, dass mir mein Hauptarbeitswerkzeug zusagt, nämlich die DAW ansich - und nicht irgendwelche Messwerte.... *gähn*

Jeder Sequenzer gleicht alle Latenzen beim Abspielen aus, für´s Einspielen mit niedrigen Latenzen usw. gibt es genug Massnahmen, welche man als ernsthafter User sowieso kennen und anwenden sollte.

Aber viel Spannender finde ich die Frage, ob Apple überhaupt noch eine MacPro-Serie herausbringen wird. Die Vermutungen gehen leider ins Negative.
Für sinnvolle und größere Studioanwendungen sind Desktop-Modelle immer noch bevorzugt eingesetzt und einzusetzen. Leistung, Steckplätze, Ausbaufähigkeiten, Schnittstellen uvam. sind da nur einige wichtige Punkte. Viele Filmschaffende z.B. vernetzen nämlich ihre G5-mehrCore-Rechner, um Libraries usw. abfeuern zu können. Mit NoteBooks & Co. undenkbar...

Apple tendiert in Richtung Consumer-Befriedigung, wie wir anhand der Entwicklungen von iPhone/Pads und auch deren Notebooks längst wissen. Das ist der Markt, wo Kohle zu holen ist - nicht im Musik oder Pro-Bereich.
So denke ich weiterhin leider, Logic X wird sehr sehr schwierig, wenn es denn überhaupt noch kommt (?) Viele ehemalige User sind abgewandert zu anderen DAWs, oder nutzen sie zumindest schon als Zweitwerkzeug.
Auch gibt es mehr und mehr Studios und viele Postpro/Broadcastfirmen, welche sich vom Mac los sagen und speziell auf ihre Bedürfnisse hochgerüstete Win-Rechner in ihre Räumlichkeiten stellen.
Diese Tendenz ist nun mal nicht von der Hand zu weisen, auch wenn es traurig ist, was Apple aus Logic und ihrer Desktop-Pflege gemacht hat. So wird mein 12Core wohl auch der letzte DesktopMac im Studio sein.

Ich glaube nicht mehr an eine Umkehr dieser misslichen Lage.
Meine Meinung hierzu.

 

[synthpark]

deine beschreibung ist auf jeden fall nicht das, was ich unter pufferjitter verstehe, da hast du was falsch verstanden. hier nochmal in a nutshell:

- ein system spuckt daten in form von paketen zu je (z.b.) 256 samples aus
- das system empfängt ausserdem mididaten
- nun kann das system zwar wie du schreibst, die mididaten in höherer präzision als 256 samples empfangen. selbstverständlich reden wir da nicht von einem abwechselndem datenverkehr, ist ja albern.
- ABER: das ist nicht zuende gedacht. zum musizieren gehören hier ja zwei teile. erstens, der empfang der mididaten (sagen wir zum rechnen pauschal mit präzision 1ms). aber zweitens: die wiedergabe des durch diese mididaten ausgelösten audio-events. das, was du in deinem test mit aufgezeichnet hast. und DIESES kann selbstverständlich bei einer puffergrösse von 256 samples nur entweder in einem oder dem nächsten puffer ausgelöst werden, das liegt ja in der natur des pufferprinzips. sonst müsstest du den puffer kleiner machen.

wenn du nun also das pech hast, dass dein miditrigger minimal nach versenden des letzten 256-sample-päckchens eintrifft, dann muss dieser trigger fast 256 samples lang auf das entsprechende audiosignal warten, denn natürlich kann dieses audiosignal erst mit dem nächsten pufferpäckchen verschickt werden. wenn du hingegen glück hast, traf dein signal minimal vor versenden des nächsten pufferpakets ein und wird noch mit versendet, ...

Hi Derek,

der Punkt ist, nicht ich, du hast da was falsch verstanden .

Wie du richtig schreibst (so sieht's laut Standard zumindest aus), ist die Buffergröße die Anzahl der Samples bei der Übertragung.

Wenn es jetzt so wäre wie du schreibst, nämlich das ein Audioevent es mal noch in diesen Puffer der jenen Puffer geschafft hat, und dementsprechend mal früher oder später geplaybacked wird, also zum Beispiel das Antriggern von VSTs oder AUs, dann wäre es ein Desaster und außerdem technisch nicht machbar. Denn das würde heissen, dass sehr lange Buffergrößen zu extremen Schwankungen führen würden, tun sie aber nicht. Da ist nur ne große LATENZ. Denn mit Latenz kann man die Schwankungen vermeiden.

Warum technisch nicht machbar? Weil die alten Noten auch ausklingen müssen, also es gibt Eventüberschneidungen, die Art, wie mehrere Events, also mehrere Audiovoices zusammen klingen.
Das VST sendet bei langen Releasephasen ja die ganze Zeit einen Audiostream und nicht getriggert mal Samples oder keine.

Was stattdessen passiert ist folgendes: es wird sichergestellt, dass zwischen Eintreffen des Events, also Midinote, und Reaktion in Form von neuer Voice eine konstante Zeitdauer vergeht. Da der Buffer mit sagen wir mal 256 Samples irgendwann abgeholt wird, und das kann in Bezug auf den Zeitpunkt des Events beliebig sein, wird eine Latenz vom System eingeplant, und die muss logischerweise mindestens 256 Samples betragen, damit jeder Fall abgedeckt wird, plus eine zusätzliche Bufferzeit, den sich der Sequencer gönnt, um alles abzuarbeiten. So läufit die Sache ab.

Mach doch mal den Test: stell die Buffergröße auf den größten Wert. Spiel den Akkord, ein Arpeggio, und höre, wie das Arpeggio wie ein Echo zeitverzögert abgespielt wird, jedoch mit dem richtigen Timing der Noten zueinander.

 

[John_Lennon]

Wenn ein Midi-Ereignis eintrifft, kann der Sequencer pauschal die 1 ms abziehen, und eine weitere Verzoegerung, die ihm der Treiber mitteilt.

Wir sprechen aber von Realtime, richtig? Wenn der Sequenzer von einem eintreffenden Ereignis 1ms abziehen soll, dann muss er das Ereignis abspielen, bevor es überhaupt eingetroffen ist. Charlie Steinberg hat dazu mal den unsterblichen Satz gesagt: "Einstein hat etwas dagegen."

Wenn ich ueber MIdi was einspiele, dann arbeitet die Latenzkompensation sehr gut, solange keine Plugins waherend der Aufnahme im Spiel sind (Logic).

Das ist genau der Punkt, den Du nicht verstehst. Beim Einspielen selbst arbeitet die Latenzkorrektur GAR NICHT. Wie zum Teufel soll das auch gehen, wenn Du im Raum-Zeit-Kontinuum bleiben willst?

Bei Deinem Mac-Versuchsaufbau hast Du einfach nur einen kleineren Puffer, sprich kleinere Latenz. Und da dann automatisch der Pufferjitter auch kleiner wird, kommt eben das dabei heraus, was Du gemessen hast.

Ja, genau. ASIO, eine Windowsgeschichte. Schoen, dass du endlich selbst drauf kommst .

Charlie hat ASIO für den Mac entwickelt und ein Jahr später dann das Konzept auf den PC portiert, weil beide Welten bezgl. Audio damals die gleichen Probleme hatten. Coreaudio ist nichts anderes, als ASIO auf Betriebssystemebene. Microsoft hat mit WDM ähnliches zur ziemlich genau gleichen Zeit am Start gehabt.

Mac = CoreAudio/CoreMidi = kein ASIO = kein Windows = kein Jitter.

[...]

Ich kann den Asiotest nicht mehr machen, weil ich jetzt nur mit Macs arbeite und der PC ist woanders. Bei Mac ist dieser Jitter nicht abhaengig von der Audiolatenz, frag mich nicht, warum.

Weil sie dann asynchrone Puffer haben und den Playback-Puffer konstant auf einer niedrigen Größe halten, anders geht es nicht. Kostet aber - wie auf dem PC auch - einiges an Rechenleistung, was aber bei aktueller Hardware keine große Rolle mehr spielt. Das ist bei ASIO auf einem i7 aktuell aber exakt genauso. Da kann ich auch dickste Projekt mit minimaler Puffergröße fahren.

Aber pufferbedingter Jitter existiert auf JEDEM System, das nicht real-time fähig im engeren Sinne ist. Und das sind weder OSX noch Windows, da müsstest Du schon ein Embedded-System auffahren.

 

[John_Lennon]

Ich seh auch nicht, warum dies technisch nicht moeglich sein soll. Es ist eine Frage, wie oft das System zum Beispiel den USB Bus abfragt. Es gibt an sich keinen Zusammenhang zwischen Midi und Audiopuffer, ausser dass sie sich quasi den gleichen Bus teilen, USB oder PCIe. Wenn da ein Zusammenhang besteht, dann wurde dieser quasi kuenstlich durch den ASIO Standard erschaffen, aber er muss gar nicht sein. Und der Bus hat ne Riesenbandbreite.

Klar kann man denken, nach 256 Samples duerfen dann erst Mididaten folgen etc. Also abwechselnder Datenverkehr. In dem Fall waere so ein Jitter dann die Folge, da die Mididaten in dieses Zeitschlitzverfahren gezwungen werden. Aber es gibt sich andere Moeglichkeiten, das zu vermeiden. Zum Beispiel, indem die Samplepakete bei der Uebertragnug kleiner gewaehlt werden, auf Kosten eines etwas groesseren Overheads.

Ich frage mich gerade ernsthaft, welche Vorstellung Du von MIDI und VSTis hast. Wie soll das denn Deiner Meinung nach anders funktionieren, als dass ein MIDI-Event eine Berechnung im Plugin anstößt und danach eine Audio-Ausgabe VOM PLUGIN und zwar als AUDIOPUFFER erzeugt wird?

Da hast Du doch schon Deinen Zusammenhang.

Und selbst wenn es ein Brain-to-VST-Interface gäbe, das Plugin bräuchte auch dann eine gewisse Zeit, um nach eintreffen deines Hirnstromes den Ton zu berechnen und im nächsten Schritt auszugeben. Und weil auf jedem Nicht-Real-Time-System die Dauer dieser Berechnung schwankt, gibt es Puffer und zwar überall, auch auf Deinem Mac.

 

[synthpark]

Reiner,

davon hab ich doch gar nicht gesprochen.

Ich meinte, der Audiosequencer speichert die Midinoten korrekt ab, indem die 1 ms abgezogen wird.
Da die Latenzzeiten bekannt sind, kann der Sequencer also beim Playback korrekt wiedergeben. Ausserdem wird berücksichtigt, dass der Hörer den Tick ja verspätet gehört hat, das muß auch ausgeglcihen werden.

Anstatt mir dauernd vorzuwerfen, was ich alles nicht verstehe, einfach sich mal in Ruhe Gedanken machen und alle Fälle aufrollen.

Mach den Buffertest, 1024 Samples. Ist der Jitter größer als vorher, ja oder nein.

Ich hab alles hingeschrieben. Die vom System Latenzzeit wird dazu genutzt, daß der neue Audiostreambuffer korrekt aufgebaut wird, inklusive dem korrekten Einfügen eines Audioeregnisses, nur halt mit verspäteter, aber KONSTANTER Reaktionszeit.

Sorry, wenn ich das so direkt sage, aber wenn man nicht ein bisschen in der Lage bzw gewillt ist, wie ein Techniker zu denken, dann ist es sinnlos zu diskutieren.

 

[John_Lennon]

Ich meinte, der Audiosequencer speichert die Midinoten korrekt ab, indem die 1 ms abgezogen wird.

Cubase tut das z.B. nur, wenn Du ihm das in den Einstellungen sagst. Ich habe jetzt nicht mehr auf dem Schirm, was die Default-Einstellung ist, aber es kann sein, dass die gar nicht gesetzt ist. Dann speichert der Sequenzer alles exakt so, wie es eingeht. In dem Fall wäre Rendering und Live-Ausgabe von der MIDI-Seite her gleich. Das ist übrigens auch der Unsinn, den ich gestern Abend geschrieben und mittlerweile gelöscht habe. Da habe ich behauptet, dass das Rendering immer MIDI-latenzkorrigiert ausgegeben wird und das Playback nicht. Das ist aber nicht automatisch der Fall. War halt spät gestern Abend

ABER:
Wenn Cubase die 1 ms des MIDI-Protokolls abzieht, dann kann es das ja nur nachträglich bei den aufgenommenen MIDI-Daten machen. Bei den live gespielten Daten geht das natürlich nicht, da geht es exakt so raus, wie MIDI es geschickt hat. Und in dem Fall sind Rendering und Live-Aufnahme automatisch unterschiedlich. Das geht aber prinzipbedingt nicht anders und würde auf dem Mac ebenfalls so aussehen.

Da die Latenzzeiten bekannt sind, kann der Sequencer also beim Playback korrekt wiedergeben. Ausserdem wird berücksichtigt, dass der Hörer den Tick ja verspätet gehört hat, das muß auch ausgeglcihen werden.

Du sagst ganz richtig "beim Playback". Da kann er das, da hat er die MIDI-Events aber auch schon alle beisammen und gibt sie halt früher aus. Beim live spielen - und das vergleichst Du ja mit dem nachträglichen Playback - kann der Sequenzer das aber nicht. Daher wird das immer auseinanderlaufen.

Der Sequenzer berücksichtigt auch Deine menschliche "Spiellatenz" oder deren Kompensation keineswegs. Wie soll er das denn auch machen? Soll er spekulieren, wie gut jemand mit Latenzen umgehen kann? Curt Cress war z.B. vor 15 Jahren berühmt dafür, dass er selbst mit den allerersten MIDI-Drums, die Latenzen von um die 15 ms hatten, absolut tight zum Playback spielen konnte, weil er die Latenz beim einspielen bereits kompensierte. Der Drummer, mit dem ich zur gleichen Zeit in einer Band gespielt habe, konnte dagegen mit solchen Latenzen gleich gar nicht spielen, aber so richtig "gar nicht". Was soll nun der Sequenzer machen? Raten?

Anstatt mir dauernd vorzuwerfen, was ich alles nicht verstehe, einfach sich mal in Ruhe Gedanken machen und alle Fälle aufrollen.

Weißt Du, ich beschäftige mich seit über 20 Jahren mit Computern und MIDI, die Hälfte davon beruflich. In der Zeit hatte ich wahrlich genug Ruhe, um mir Gedanken zu machen und die Fälle aufzurollen. Und ich habe mir auch nicht aus den Fingern gezogen, wie die Sache funktioniert. Ich habe die Entwickler gefragt.

Mach den Buffertest, 1024 Samples. Ist der Jitter größer als vorher, ja oder nein.

Den hat Mathias Carstens, wie gesag,t schon vor knapp 10 Jahren gemacht. Wenn ich nicht ausgerechnet in den nächsten drei Tagen Vater werden würde, hätte ich das für Dich aber noch mal aufgebaut. Aber so muss Du schon entschuldigen, dass ich nicht mehr mache, als auf Abruf am Bürorechner zu sitzen

 

[DocNo]

Und die werden beide um genau die Audiolatenz auseinanderfallen. Die Audioausgabe des Plugins kommt erst nach 5ms. Wenn Du die dann aufnimmst (hoffentlich nicht auch noch einmal eine Runde über das Audiointerface), dann ist sie IMMER um die Audiopuffergröße hinter der MIDI-Aufnahme und damit auch hinter dem, was das Rendering aus selbiger macht.

Es wird dabei auch Jitter geben, aber auch das ist Audiojitter. Matthias Carstens von RME hat dazu vor zig Jahren mal einen Artikel für KEYBOARDS geschrieben. Je nachdem an welchem Punkt der Zeitscheibe das Event eintrifft, schwankt auch die effektive Ausgabe-Latenz. Glaub' mir, Du misst den Audio-Jitter und -Latenz, nicht MIDI.

http://www.rme-audio.de/techinfo/lola_latec.htm

 

[tomric]

Bleibt die Frage, inwieweit eine solche (sicher fuer einige interessante) Detaildiskussion dem Threadersteller weiterhilft...

 

[synthpark]

Du sagst ganz richtig "beim Playback". Da kann er das, da hat er die MIDI-Events aber auch schon alle beisammen und gibt sie halt früher aus. Beim live spielen - und das vergleichst Du ja mit dem nachträglichen Playback - kann der Sequenzer das aber nicht. Daher wird das immer auseinanderlaufen.

wieso auseinanderlaufen?

Ist dir der Unterschied klar von Latenz und Jitter? Bandmaschine als Tape Delay: Latenz = die Zeit zwischen Aufnahme aufs Band und Widergabe vom Band. Jitter = Fluttereffekt.

Weißt Du, ich beschäftige mich seit über 20 Jahren mit Computern und MIDI, die Hälfte davon beruflich. In der Zeit hatte ich wahrlich genug Ruhe, um mir Gedanken zu machen und die Fälle aufzurollen. Und ich habe mir auch nicht aus den Fingern gezogen, wie die Sache funktioniert. Ich habe die Entwickler gefragt.

Ok, und wenn jemand 20 Jahre Taxi fährt, dann wird er nicht zum technischen Motorexperten. Und Entwickler gefragt: da gibts drei verschiedene Versionen: das was jemand dir sagt, dann das was tatsächlich der Fall ist, und das was du daraus ziehst, nicht immer dasselbe.

Hier hilft nur ein Test, Zitate von Charly Steinberg von 15 Jahren etc. helfen hier nicht weiter.

 

[synthpark]

Bleibt die Frage, inwieweit eine solche (sicher fuer einige interessante) Detaildiskussion dem Threadersteller weiterhilft...

und was hilft denn dem Threadsteller weiter?

Ist es sinnvoll, BMW zu fahren? Ja.
Ist es sinnvoll, Open zu fahren? Ja.
Ist es sinnvoll, VW zu fahren? Ja.

 

[the_Emre]

Ich habe zur zeit nen win 7 64bit laptop mit dem ich aufnehme aber langsam schmiert er weg und möchte mir was neues holen.

Und... was soll uns das jetzt sagen? Welcher Prozessor, wieviel RAM und so? Win 7 ist doch nur ein OS und keine Hardware, kann Windows ja nix für wenn du es auf nem Single Core installierst ^^

 

[Nachtschicht]

der Punkt ist, nicht ich, du hast da was falsch verstanden .

ich gebe offen zu, dass ich gewisse probleme damit habe, DICH zu verstehen, da du nicht sauber zu unterscheiden scheinst zwischen den verschiedenen fällen (echtzeitreaktion auf midiinput, wiedergabe vom sequencer usw).

Wenn es jetzt so wäre wie du schreibst, nämlich das ein Audioevent es mal noch in diesen Puffer der jenen Puffer geschafft hat, und dementsprechend mal früher oder später geplaybacked wird, also zum Beispiel das Antriggern von VSTs oder AUs, dann wäre es ein Desaster und außerdem technisch nicht machbar. Denn das würde heissen, dass sehr lange Buffergrößen zu extremen Schwankungen führen würden

das hier z.b. verstehe ich überhaupt nicht - einerseits beschwerst du dich über genau jenes verhalten, welches wir dir hier gerade erklärt haben, und entschuldigung, deine ersten posts klangen nicht gerade so als wärst du da schon up to speed gewesen und hättest differenziert, da stand nur ein blankes "XY groovt besser". das wurde dir kurz mal widerlegt (eine zurkenntnisname wäre übrigens nett), jetzt reden wir also nur noch über timingjitter bei echtzeitmidiinput bei hohen latenzen. ein nicht gerade praxisgerechtes beispiel wie ich finde, aber bitte.

und die erklärung für das verhalten, welches du SELBST beobachtet hast und jetzt in mehrfacher ausführung von rainer, mathias carstens (man sagt ja der kenne sich mit sowas n bisschen aus) und mir bekommst - die ist "technisch unmöglich"? ...ah, ja...ich verstehe tatsächlich nicht.

den ansatz, dass der sequencer die latenz dann einfach künstlich hoch hält, ist ja ganz interessant - aber aus meiner sicht trotzdem ein irrweg. ob wir es nun damit zu tun haben, oder mit parallelpuffersystemen wie in der vorigen post beschrieben (wir wissen es ja leider weiterhin nicht, weil du nur mutmassungen ohne jegliche quelle anstellst): mir ist lieber, wenn das audiosystem sich nicht mit so nem tinnef beschäftigt sondern stattdessen einfach die maximale leistung bei minimaler latenz liefert. kurz: mir ist ein system, dass ordentlich leistung bei 48 samples latenz liefert und dafür einen jitter von schlimmtenfalls 48 samples in kauf nimmt (wir erinnern uns: midi selbst hat bereits bei einem john lennon-banalklavier als alleinigem signal ob seiner seriellen natur einen quasi-jitter der um das ca. zehnfache höher ist) lieber als ein system, dass mir zwar sinnvolles spielen ab sagen wir 96-128 samples erlaubt (bestenfalls, meine erfahrung mit OSX ist da eigentlich einiges düsterer), dann aber mein spiel noch bisschen nachkorrigiert indem es künstlich latenzen noch hinzufügt - wohlgemerkt, für microtimingüberlegungen, die UNTER der genauigkeit von midi selbst liegen.

also wie mans dreht und wendet, wird ein schuh raus und interessanterweise scheinst du das ja selber auch so zu sehen, hab einen satz deiner vorigen post übersehen auf den ich gerne noch antworten möchte:

Aber es gibt sich andere Moeglichkeiten, das zu vermeiden. Zum Beispiel, indem die Samplepakete bei der Uebertragnug kleiner gewaehlt werden, auf Kosten eines etwas groesseren Overheads.

richtig! man nennt das auch "kleinerer puffer". auch bekannt als "geringere latenz". das ist in der tat DAS mittel der wahl, um echtzeit miditiming fit zu machen. man macht die puffer einfach so klein, bis sie feiner auflösen als midi selbst, schon ist der flaschenhals wieder midi und nicht das audiosystem. so wirds gemacht, nicht indem man selber noch künstlich latenzen hinzufügt, is ja voll von hinten durch die brust durchs auge und genau so verhält es sich natürlich auch bei asio.

ich bleibe bei meinem bild, muss ich ehrlich gestehen. du hast wahrscheinlich damals einen test bei der pragmatenlatenz 5ms gemacht, hast eventuell auch niemals einen blick auf die timestamp-einstellungen geworfen, und dann das ganze erstmal global als "VSTIs haben schlechtes miditiming!" verallgemeinert, ohne zu differenzieren in echtzeit oder wiedergabe von sequencer. nur so ist deine seltsame auffassung, VSTIs hätten eine generelle timingungenauigkeit von 5ms zu erklären.
relevant fürs timing bei produktionen ist aber die wiedergabe vom sequencer, und die ist samplegenau. und relevant fürs timing bei *live-midi-spielen* auf das du jetzt ausgewichen bist, ist vor allem eins: die leistungsfähigkeit bei der kleinstmöglichen latenz. und da macht OSX mit verlaub gegen asio auf windows keinen besonders guten schnitt. konsultieren sie hierzu bitte die benchmarkseite ihres vertrauens

 

[akl]

Midi und Audio Treiber sind 2 verschiedene Stücke Treibersoftware.

Nur weil Du im ASIO Treiber eine Buffersize von 256 (was sind das eigentlich, Audio Samples ?) einträgst, heißt das noch lange nicht, dass der ASIO Treiber tatsächlich erst mal alles in einem Rutsch übertragen darf ehe die CPU irgendwas anderes wieder anpacken darf.

Ich würde erwarten, dass in einem Multiprocessor System sowieso die CPUs ständig Kontext switches machen zwischen Treiber und Applikationsbearbeitung.

Selbst wenn Du im ASIO Treiber eine Buffersize von XXX einträgst, dann kann das auf CPU/Treiber/Bus Ebene alles auch schon wieder ganz anders aussehen.

Erinnert Euch an den PCI Latency Time im BIOS ... das ist die Konfiguration der max. Anzahl von PCI Taktzyklen, für die eine PC Karte den PCI Bus für sich beanspruchen darf, wenn eine andere Karte auch auf den Bus zugeifen möchte. Bei 32 MHz PCI Bussen ca "32", bei 66 MHz Bussen kann der Wert erhöht werden. Zu kleine Werte killen die Bandbreite / den Durchsatz einer Karte.

Das heisst 32 PCI Bus Cyclen darf die CPU für den Treiber A arbeiten und dann wieder 32 Cyclen für den Treiber B und wenn nix anderes am Bus los ist auch mehr und länger.

Ich will darauf hinaus, dass es zwischen ASIO Buffer Einstellungen und dem Tatsächlichen Handling der Daten auf Bus ebene dann auch noch ein paar Welten klaffen ...

Grüße

 

[synthpark]

ich gebe offen zu, dass ich gewisse probleme damit habe, DICH zu verstehen, da du nicht sauber zu unterscheiden scheinst zwischen den verschiedenen fällen (echtzeitreaktion auf midiinput, wiedergabe vom sequencer usw).

Ok, an dem Punkt hab ich schon kein Bock mehr weiterzulesen, sorry. Ich hab die Erklaerung oben abgegeben. Du hast dich anscheinend nicht damit auseinandergesetzt. Dann machts auch keinen Sinn.

Ich hab hier tolle Kollegen um mich herum. Die sind alle ziemlich intelligent, wir verstehen uns quasi fast ohne Worte hier. Und die wuerden mir nie untstellen, ich sei minderbemittelt und wuerde so ein triviales Zeugs hier ewig ausdiskutieren. Dinge, die eigentlich klar sein sollten.

Und die wuerden darueber lachen, wenn es technisch nicht moeglich waere, ueber einen USB Bus mit gigantischer Datenrate gleichzeitig Midi und Daten zu uebertragen, so dass die Midiereigniesse verjittert werden, nur weil der Audiobuffer hoeher gewaehlt wird. Das ist der letzte Mumpitz. Wie lange dauert es, ueber einen sehr schnellen Bus 256 Samples zu uebertragen? Genau, es geht ganz ganz schnell. Und schon ist wieder Zeit, um Midinoten zu uebertragen.

Aber Musiker wissen immer alles besser. Na dann ...
Ich entwickle jetzt weiter mein Digital Radio ...

PS

Wenn du das Konzept verstanden hast, dass der Sequencer eine kostante Latenz aufrechterhaelt, damit eben keine Ereignisse verjittert werden, dann hast du es verstanden. Das hat nix mit der Uebertragungsgeschwindigkeit zu tun! Denn die naechsten 256 Samples werden quasi "gebacken", waehrend die vorherigen abgespielt werden. Und wenn dann Ereignisse eintreffen, werden diese an die richtige Stelle im Buffer gesetzt. Das ist der Punkt. Aber dafuer braucht es eine konstante Verzoegerung. Dabei wird gar nix verjittert, aber das Plugin spielt das Ereignis mit einer konstanten Verzoegerung ab.Und wenn das Ereignis noch spaeter kommt, dann wird es in den naechsten Bufferabschnitt gesetzt, so wie es sein soll. Dabei bleibt die Verzoegerung weiterhin gleich und variiert nicht. Das muss man verstehen.

 

[Gast92251]

Na endlich.
Kann mir nicht vorstellen, dass das Anfänger, welche hier ja auch mitlesen, bis ins letzte technische Detail, interessiert. Schreibt euch doch zukünftig ne PM, wo ihr dann ausführlichst streiten und besserwissen könnt. Oder telefoniert gleich miteinander, das ist dann schneller geklärt und artet nicht so monologhaft und beleidigend aus.
(Manche habe echt zu viel Zeit hier, vermute ich?)
Wie war noch mal der Threadtitel? ach ja:
"Apple wirklich sinnvoll?" Antwort: nein. Nicht wirklich...

Was interessiert es mich, ob da ein paar Milli-Latenzen mehr oder weniger sind, oder ob eine DAW ein paar mehr Plugins abspielen kann.
Heutzutage sind wir in CPU-Bereiche gestoßen, wo selbst kleine Rechner komplette Produktionen rein virtuell ermöglichen.
Mir ist es wichtiger, dass mir mein Hauptarbeitswerkzeug zusagt, nämlich die DAW ansich - und nicht irgendwelche Messwerte....

Jeder Sequenzer gleicht alle Latenzen beim Abspielen aus, für´s Einspielen mit niedrigen Latenzen usw. gibt es genug Massnahmen, welche man als ernsthafter User sowieso kennen und anwenden sollte.

+ 1


Liebe Grüße u. Schö WE.

 

[Gast92251]

Mac finden im Producing-Bereich - also Design, Programmierung, Audio&Video etc. - sehr hohen Einsatz. Für normale privat User ist es nicht verkehrt.

Ja, aber das ist schon seit Längerem längst im Umbruch: die Adobe-Pakete gibt´s für beide Plattformen, Audio-DAWs mittlerweile ja auch. Viele Designer/Fotografen (der Printbereich erst recht) und sowieso verstärkt der Broadcast/Radio-Bereich uvam. nutzen mittlerweile hochgerüstete PC-Systeme. Wobei die Serveranbindungen dort auch viel besser sind.
Nun, Abschreibungsgeschichten, Aufrüst-Problematiken und die Abkehr vom Prosumer-Markt lassen Apple in keinem guten Licht stehen. Das Desaster mit FinalCut wie auch mit Logic kennt man.
Dass die Hardware wie auch OSX top sind, ist allen klar. Man fragt sich: Quo fadis Apple?

Aber halt ein hoher Kostenfaktor. Pc mit gleicher Leistung kriegt man schon halb sogünstig..

Das ist ein sehr triftiger Grund vieler Nutzer, auch und gerade im Pro-Bereich.

 

[synthpark]

Kann mir nicht vorstellen, dass das Anfänger, welche hier ja auch mitlesen, bis ins letzte technische Detail, interessiert.

Ohne Details sind alle Systeme "gleichgut".

So, ich hab jetzt fuer Rainer und Derek ne Skizze erstellt. Da sieht man, wie ich das meine. Insbesondere, dass es moeglich ist, bei konstanter Verzoegerung T0 eintreffende realzeit-Midiereignisse jitterfrei abzuspielen.

Man sieht zwei Faelle. Einmal landet das getriggerte Audioevent im "gleichen" Packet, welches gerade bearbeitet wird, einmal im naechsten Packet. In beiden Faellen ist die Verzoegerung gleich.