De timer is voor heel andere dingen bedoeld en heeft meestal een lage prioriteit: als het OS het eventjes heel druk heeft met andere dingen, wordt een Timer Tick doodleuk niet uitgevoerd. Dat is ook helemaal geen ramp, want de communicatie tussen applicaties en geluidskaart verloopt via call back functies...
Fout want het is net omgekeerd ! Geen enkel DAW zou alzo een loop kunnen herhalen zonder timing fouten. De timerfuncties die ik heb aangehaald zijn net bedoeld om wel met hoge prioriteit een callback functie aan te roepen. Die functie dien jezelf te maken en het adres ervan door te geven. Zo kan en zal het OS constant deze functie aanroepen, zonder verstoord te worden door andere acties (
maar zoals reeds vermeld met als kleinst haalbare resolutie 1 mseconde).
...dus de geluidskaart activeert via het OS de aangemelde interruptroutines van de applicatie waarmee data worden opgehaald en verzonden. In Windows bestaan aparte call back functies voor wav en voor Midi.
Inderdaad, maar enkel om een blok data te verzenden of ontvangen zonder dat er een softwarematige tijdsregistratie benodigd is, anders dient er gebruik gemaakt worden van die timerfunctie !
De communicatie tussen geluidskaart en applicatie via het OS verloopt niet via timerfuncties.
Mogelijk geen timerfuncties in het OS maar allicht zeker een aantal in de hardware. En, gezien die 1 mseconde latency heb ik nog steeds twijfels over 'verloopt niet via timerfuncties' van het OS'.
Yoozer schreef:
Ik weet niet of het opzettelijk is, maar als je latency elke keer werd aangepast op het moment dat je CPU er een track of plugin bij kreeg denk ik dat je daar niet veel gelukkiger van zou worden.
Ik zei stel dat die timings 100 sneller gaan en/of dat die latency dan 100 keer kleiner zou zijn => 1/100.000 seconde. Dat is nog steeds veel trager dan de processor zelf, maar best snel genoeg om alle audio en midi uiteraard realtime te kunnen doen. Om maar niet te spreken over de kostenbesparing aan geheugen voor elke audio-kaart.
Yoozer schreef:
Ik heb al eens voorgesteld om MIDI-berichten als audio te coderen - op dezelfde manier dat een modem dat doet, maar dan op hogere frequenties. Als een modem dat kan, moet een audio-interface dat zeker kunnen - en je kunt compressie toepassen en hebt veel meer bandbreedte dan op een reguliere telefoonlijn.
Midi is n.m.i. nog steeds een goed protocol maar mogelijk een zou 1000x hogere snelheid, 255 midi-kanalen i.p.v. 16 en aansluiting via één usbkabel voor zowel in als out, een goede verbetering zijn. Maar weerom, als het OS maar aan 1/1000 seconde resolutie registreerd waarom zouden fabrikanten die snelheid dan gaan verhogen.
Yoozer schreef:
In een ideaal universum hadden we geen MIDI meer maar gewoon OSC en een heel setje goedkope retrofit-doosjes die je op elke hardware-synth vastklampte en Minerva-stijl upgrades waarbij de interne processor ook gelijk een snelheidsboost kreeg. Een TX81z gaat over z'n nek als je 'm meer durft te sturen dan wat noot-informatie via MIDI.
In een normale wereld zouden mensen geen hypocriete houding moeten aannemen als hun meegedeeld wordt dat iets toch niet zo ideaal werkt als men door onkunde/luiheid of wat ook, veronderstelt.
Het is net door massaal gebrek aan deze kennis dat veel betere systemen het niet gehaald hebben van dit OS. En nu is er wss geen weg meer uit, tenzij een ticket naar jou 'ideaal universum'.
In de bijlage twee kleine testprogrammaatjes :
* één waarin Yoozer de nauwkeurigheid van zijn High Performance Counter kan bezien;
* één waarin WaveGuide7 het verschil kan bemerken tussen een lage en hoge prioriteit timer (venstertje verschuiven en terwijl beide timers eens bezien).
Stel dat je op exact elke (gemiste) Timer Tick een beat wil laten horen....geef mij dan maar die hoge prioriteit timer
