64 of 32 bit

[WaveGuide7]

64-bits: enabling technology

64-bits: enabling technology

Ik kom er toch nog even op terug:

En nu wordt er opeens gedaan alsof je zonder 64-bit OS en/of 24-bit recording niks fatsoenlijk klinkends meer zou kunnen maken

Arno herhaalt hier wat hij in #78 beweerde en ik heb daarop al gereageerd in #79 (https://www.synthforum.nl/forums/showpost.php?p=1649382&postcount=79), maar hij is daar niet op in gegaan.
Daarom nog een nieuw voorbeeld om duidelijk te maken dat die vergroting van de woordbreedte alleen maar betekent dat we in staat worden gesteld om geluidsbewerkingen te doen, die we altijd al graag hadden willen doen, maar die we niet konden realiseren doordat de apparatuur te weinig rekenkracht/snelheid heeft. De vraag is in deze draad al gesteld (https://www.synthforum.nl/forums/showpost.php?p=1649183&postcount=64): noem nou eens een voorbeeld van een audiotoepassing die niet mogelijk is met 32-bits interne woordbreedte, maar wel met 64-bits.

Wel, een fascinerend voorbeeld daarvan is de zeer realistische galm-simulatie van een bestaande concertzaal d.m.v. hetzij directe, hetzij fast convolutie met meervoudige stereo pulsresponsies. Dit voorbeeld heb ik in febr j.l. besproken en gedemonstreerd in mijn voordracht voor de Nationale Wiskunde Dagen 2013 (https://www.synthforum.nl/forums/showthread.php?t=163503)) en hieronder een paar afbeeldingen die ik toen liet zien.

Bij directe convolutie is elke sample van de galm-output de som van zo'n 70.000 producten, waarbij elk product bestaat uit:
(1) 16-bits pulsresponsie van de concertzaal;
(2) 16-bits droog inputsignaal.
Elk product beslaat dus 32-bits.
De som van 70.000 van zulke 32-bits producten is een 49-bits getal.
Als er twee pulsresponsies, corresponderend met twee verschillende plekken op het podium van de concertzaal worden gecombineerd (zoals in het voorbeeld dat ik gemaakt had), komt daar nog 1 bit bij en heb je dus minimaal 50-bits woordbreedte nodig voor de berekening van de directe convolutie.

Doe je datzelfde via de fast convolution waarbij je gebruik maakt van de FFT, dan krijg je een heel andere berekening die ik hier maar weglaat (en die betrekking heeft op de rekennauwkeurigheid van de FFT zelf) maar het komt erop neer dat die berekening onmogelijk is met 32-bits interne woordbreedte, maar wèl mogelijk is met 64-bits interne woordbreedte.

Let wel: dit zegt allemaal nog niets over de snelheid waarmee de berekening kan worden uitgevoerd. Die hangt immers uitsluitend af van je hardware: CPU-kloksnelheid, breedte van databus etc.

Hoeveel optellingen en vermenigvuldigingen moet je uitvoeren om 1 minuut stereo-galmgeluid te berekenen? Het plaatje hieronder laat zien dat dit er voor de directe convolutie 840 miljard zijn. Een moderne, 64-bits laptop doet daar maximaal 3 uur over. Dus 3 uur zwoegen op 1 minuut geluid...
Maar nu de fast convolution die werkt met de FFT... Die is, op dezelfde laptop al gauw 500 maal zo snel en doet er geen 3 uur over, maar 36 seconde! Daarmee ligt de rekentijd ruimschoots binnen realtime!
Dus op een wat oudere, 32-bits laptop kun je dus de galm wel uitrekenen, maar lang niet binnen realtime, zelfs niet als je de fast convolution gebruikt.

Meer over het geweldige klankrealisme van galm d.m.v. directe (en fast) convolution: zie Sander02's draad "Zomaar een galmidee" (https://www.synthforum.nl/forums/showthread.php?t=48349)

Dit voorbeeld laat zien dat de opschaling van 32-bits naar 64-bits heel interessante bewerkingsmogelijkheden toevoegt aan wat we al kunnen.

Nu nog eens in 't kort mijn slotconclusie: aangezien de trend in klanksynthese en sound design geen andere is dan die al honderden jaren in de muziek bestaat, nl. continue ontwikkeling naar meer expressiviteit, en aangezien muzikale expressiviteit zich technisch direct vertaalt in complexiteit van bewerkingsprocessen, ligt het voor de hand om te streven naar een zo groot mogelijke woordbreedte en zo snel mogelijke processen. Elke vergroting van de capaciteit opent nieuwe horizonnen voor sound processing en design. Dat is geen gebakken lucht, geen reclame-hoempa, maar een simpele observatie.

 

[ano040425-3]

Ik heb (alleen) deze info:
It is a full digital production and both the LP and CD releases was encoded using the two-channel Ambisonic UHJ format.
http://en.wikipedia.org/wiki/Stereotomy

Meestal is Wikipedia toch wel redelijk betrouwbaar. Misschien heb jij een betrouwbaardere bron?

Maar wat ik ermee wilde zeggen: toen was er zeker nog geen 24-bit/96kHz oid. Gewoon 16-bit/44,1kHz. Dat was nog heel lang zo trouwens. En nu wordt er opeens gedaan alsof je zonder 64-bit OS en/of 24-bit recording niks fatsoenlijk klinkends meer zou kunnen maken. Bullshit. Ik blijf erbij. Maar ik trek me maar terug uit de discussie want dit leidt toch nergens toe.

dat ambisonics systeem heeft niets te maken met het opname medium.

ik weet het niet ,mogelijk gebruikten ze die tijd de sony DASH digitale multitrack recorder.

maar let op het synclavier systeem was bvb 100khz (begin jaren 80...)!!

de TC 2290 delay sampling freq is 1Mhz dacht ik,de output klinkt fenomenaal van dat toestel

 

[Yoozer]

Maar wat ik ermee wilde zeggen: toen was er zeker nog geen 24-bit/96kHz oid. Gewoon 16-bit/44,1kHz. Dat was nog heel lang zo trouwens.

Ja, maar dat geldt voor opname - al het lastige werk doe je al in de stappen daarvoor.

Tegenwoordig is het opnemen het laatste wat je doet; alles wat daar aan vooraf gaat (het geluid genereren, effecten toepassen, mixen, EQ) ook nog eens allemaal digitaal. Dan stapelen afrondingen zich toch wel een heel stuk sneller op.

En nu wordt er opeens gedaan alsof je zonder 64-bit OS en/of 24-bit recording niks fatsoenlijk klinkends meer zou kunnen maken. Bullshit. Ik blijf erbij. Maar ik trek me maar terug uit de discussie want dit leidt toch nergens toe.

If the facts are on your side, pound on the facts. If the law is on your side, pound on the table. If neither the law nor the facts are on your side, pound on the table.

Kun je fatsoenlijke muziek maken met een elastiek, een sigarendoos en een Portastudio? Ja. (en zeker ja als je een Eventide H8000 toevoegt)

Wil je dat? Nee. Zoals de niet-roker die tegen de roker zegt - "als ik al dat geld wat jij in sigaretten stopt had gespaard had ik nu een villa!" "Oh ja", zegt de roker dan - "waarom woon je dan nog steeds in een rijtjeshuis?"

Dus, waar is dat fantastische album op 16-bits 44k met een ouwe Pentium III? Ergens in 1997, toen je een studio niet in kwam als je enige skill bestond uit 19 zijn en een Macbook Pro hebben of je als 35-jarige stikte van de vintage synths maar niet eens zonder horten Roodborstje Tik kon spelen op je Minimoog. De tijd dat die PIII al als vooruitstrevend werd beschouwd omdat je tenminste niet meer met scheermesjes en tape aan de gang moest om een remix te maken.

Das war einmaal. Mooie tijd, maar voorbij.

Ik word zelf ook een beetje moedeloos als ik mensen hoor ruziën over dure converters terwijl hun output bestaat uit copy-paste inspiratieloze deep-house-kak die 15 jaar geleden geheid in het cylindrisch archief belandde, maar goed, waar men het geld aan uitgeeft, dat mag men zelf weten.

Gaan we terug naar 32-bits (of help, zelfs 16-bits) OSen? Nee.
Gaan we van 24 terug naar 16 bits met opnemen? Nee.

Heeft het dan zin in 2013 nog voor een 32-bits OS en een 16-bits geluidskaart te kiezen? Nee.

 

[audiocollage]

...
Gaan we terug naar 32-bits (of help, zelfs 16-bits) OSen? Nee.
Gaan we van 24 terug naar 16 bits met opnemen? Nee.

Heeft het dan zin in 2013 nog voor een 32-bits OS en een 16-bits geluidskaart te kiezen? Nee.

MAAR WE BLIJVEN OP DIE HARDWARE WEL MET EEN MAXIMUM SNELHEID VAN 1kHZ WERKEN OMDAT HET BESTURINGSSYSTEEM NIET MEER TOELAAT !!!
Minimum latency 1 msec oftewel 3 a 4 miljoen keer trager dan hun processor zelf, omdat het besturingssysteem niet lager toelaat. Bespreek dit effectief gebruik van hardware maar eens. Vergelijk dat eens met DSP's uit een atari falcon van 1992.
Wat een vooruitgang zeg.

 

[Johndoe11]

dit is ook geen topic voor mensen die met hun draaiorgel in de jaren 70 zijn blijven hangen.
zoals de NS zegt: "ga mee!"

 

[audiocollage]

Ga mee...
Het zou een zinnig antwoord kunnen zijn, als je het over MS had, maar ja Oblivion... dat zal wel niet hé.
Het is eerder een topic voor mensen die hun kop in het zand hebben steken.

 

[WaveGuide7]

MAAR WE BLIJVEN OP DIE HARDWARE WEL MET EEN MAXIMUM SNELHEID VAN 1kHZ WERKEN OMDAT HET BESTURINGSSYSTEEM NIET MEER TOELAAT !!!
Minimum latency 1 msec oftewel 3 a 4 miljoen keer trager dan hun processor zelf, omdat het besturingssysteem niet lager toelaat. Bespreek dit effectief gebruik van hardware maar eens. Vergelijk dat eens met DSP's uit een atari falcon van 1992.
Wat een vooruitgang zeg.

Ik zie het probleem niet. De latency van het zenuwstelsel is in het meest gunstige geval al langer dan 1 msec. Het oor heeft minimaal 20 msec nodig om een toon van 100 Hz te kunnen detecteren; datzelfde geldt voor een pitch detector.
Een spectrum analyzer heeft minimaal 1 periode nodig voor de detectie van de grondtoon, dus het duurt 50 msec voordat de computer de laagst waarneembare toon, 20 Hz, kan detecteren, dus 50 keer zo lang als de kortste latency. (Een animatie van de "ontwikkeling" van het spectrum tijdens het voortklinken van een toon, waarin goed is te zien dat de spectrale schatting steeds beter wordt naarmate de eerste periode van de toon vordert, is te vinden in WaveWizard -> Generatoren -> animatie electrische gitaar.)

Kortom: het minimale tijdsinterval voor detectie van frequentiecomponenten is aanzienlijk langer dan die latency van 1 msec.

Vandaar mijn vraag: noem een paar voorbeelden van audio-interacties waarin een latency van 1 msec voor problemen zorgt.

 

[Lynxxx]

MAAR WE BLIJVEN OP DIE HARDWARE WEL MET EEN MAXIMUM SNELHEID VAN 1kHZ WERKEN OMDAT HET BESTURINGSSYSTEEM NIET MEER TOELAAT !!!
Minimum latency 1 msec oftewel 3 a 4 miljoen keer trager dan hun processor zelf, omdat het besturingssysteem niet lager toelaat. Bespreek dit effectief gebruik van hardware maar eens. Vergelijk dat eens met DSP's uit een atari falcon van 1992.
Wat een vooruitgang zeg.

Euh, dit is de eerste opmerking in deze thread waar ik echt geen moer van begrijp. Wat bedoel je nu precies?

 

[DRe]

MAAR WE BLIJVEN OP DIE HARDWARE WEL MET EEN MAXIMUM SNELHEID VAN 1kHZ WERKEN OMDAT HET BESTURINGSSYSTEEM NIET MEER TOELAAT !!!
Minimum latency 1 msec oftewel 3 a 4 miljoen keer trager dan hun processor zelf, omdat het besturingssysteem niet lager toelaat. Bespreek dit effectief gebruik van hardware maar eens. Vergelijk dat eens met DSP's uit een atari falcon van 1992.
Wat een vooruitgang zeg.

misschien hoort dit wel meer in de andere draad over hertz

 

[Yoozer]

edit: overduidelijk, ik moet niet meer rond middernacht posten, dan nemen Gremlins m'n toetsenbord over. Omdat posts al na zo'n korte tijd niet meer bewerkt mogen worden:

De quote moet natuurlijk zijn:

If the facts are on your side, pound on the facts. If the law is on your side, pound on the law. If neither the law nor the facts are on your side, pound on the table.

en in correct Duits is het natuurlijk "einmal".

MAAR WE BLIJVEN OP DIE HARDWARE WEL MET EEN MAXIMUM SNELHEID VAN 1kHZ WERKEN OMDAT HET BESTURINGSSYSTEEM NIET MEER TOELAAT !!!
Minimum latency 1 msec oftewel 3 a 4 miljoen keer trager dan hun processor zelf, omdat het besturingssysteem niet lager toelaat. Bespreek dit effectief gebruik van hardware maar eens. Vergelijk dat eens met DSP's uit een atari falcon van 1992.
Wat een vooruitgang zeg.

Zelfs een dedicated DSP in een leuke VA heeft zo'n getallen voor latency; volgens mij zaten enkele romplers ergens zelfs rond de 5-10 ms. Het vullen van de audiobuffer kan heel snel gebeuren, da's niet zozeer het punt.

De "snelheid" van envelopes, daar kun je al helemaal boeken over volschrijven; een Minimoog haalt heel trots 1 ms op de laagste attack-stand en wordt als "snel" beschouwd. Bekijk ook even hoe lang het duurt eerdat het geluid van de speaker je oren bereikt - en hoe dat in profi studios wordt gedaan als je een setje midfields of mainfields in de muur hebt.

 

[WaveGuide7]

misschien hoort dit wel meer in de andere draad over hertz

Dat zeker, maar ik ben wel erg nieuwsgierig naar de voorbeelden waar audiocollage ongetwijfeld mee zal komen. Ik hoop jij ook.

 

[Yoozer]

Ik heb het idee dat 't te doen heeft met de tick count functie zoals hier beschreven:

http://delphi.about.com/od/windowsshellapi/a/delphi-high-performance-timer-tstopwatch.htm

 

[audiocollage]

Beginnen jullie zelf eerst maar eens wat bij te lezen hé.

@Yoozer, en alle anderen lees de Remarks (danwel op de officiele MS website uiteraard en niet op nog één of ander bullshit forum) :
High Performance Counter
Zoek de resolutie eens op in deze, een zogenaamd verouderde (uit het draaiorgel tijdperk) :
http://msdn.microsoft.com/en-us/library/windows/desktop/dd757634(v=vs.85).aspx
Zoek dan de resolutie eens op in de vernieuwde door MS aangeraden timer :
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682485(v=vs.85).aspx

Waveguide dat zelfs jij niet kan beredeneren wat de nadelen zijn aan een systeem dat je maar per 1/1000 seconde toelaat om je data te versturen. Waar haal jij je bewering van betere latency dan vandaan ?
Als die 1kHz nu eens 100 keer groter was (na twintig jaar meegaan met de tijd ), wat zou je dan allemaal niet kunnen ?!
Zou je dan nog over lantency spreken, in MIDI huh, in audio huh.
Redeneren mogen jullie zelf verder doen en gaat dat niet, ja wacht dan op de 25666 bit computers hé.

 

[WaveGuide7]

Waveguide dat zelfs jij niet kan beredeneren wat de nadelen zijn aan een systeem dat je maar per 1/1000 seconde toelaat om je data te versturen.

"een systeem dat je maar per 1/1000 seconde toelaat om je data te versturen" is iets heel anders dan een latency van 1 msec.
(1) latency is de tijd die verstrijkt tussen een gebeurtenis aan de input en de reactie van het systeem aan de output.
(2) "per 1/1000 seconde" = 1000 Hz, is een frequentie.

Het is mij nu niet meer duidelijk wat je nou eigenlijk bedoelt met latency: (1) of (2).

Ik had uit je vorige post de indruk dat (1) bedoelde. Daar heb ik op gereageerd en een vraag gesteld (die je nog niet hebt beantwoord).
Als ik er nu van uitga dat je (2) bedoelt, dan heb ik eigenlijk dezelfde vraag, want als een systeem mij 1000 maal per seconde input en/of output toestaat, dan ben ik daar dik tevreden mee. Jij blijkbaar niet, prima, maar ik zou graag willen weten in welke situaties of interacties jij daardoor in de problemen komt.

 

[bikkel]

1 ms constant is goed, 5ms constant is goed, meestal 1ms maar soms ook 20ms of 5ms is totale kak.

Ik ken Roodborstje Tik niet, zou het daardoor komen dat ik het niet op mijn MiniMoog kan spelen, mede geholpen door het feit dat ik geen MiniMoog heb?

 

[audiocollage]

"...
(1) latency is de tijd die verstrijkt tussen een gebeurtenis aan de input en de reactie van het systeem aan de output.

En die gebeurtenis is eenmalig ???
T.o.v. van wat dan ???

 

[Furious5]

Poehee wat een in depth gebabbel..

Een 32 bit O.S. is okay, met 64 bit heb je gewoon meer geheugen.
Als je met 32 bit wil werken moet je gewoon oplossingen vinden mocht je vastlopen tegen te weinig geheugen. En ook met 64 bit kom je de beperkingen op een gegeven moment tegen.

Wees dus creatief, freeze sommige tracks.. versimpel je fx - heb je nu echt steeds de hoogste setting nodig?

Als je met 32 bit niks vets kan maken dan kan je dat met 64 bit ook niet. Als koop je de beste gear, snelste computer, beste outboard hardware. Het creatieve gedeelte komt van jezelf. Al heb de beste high end spullen.. als je gewoon geen dikke tracks kan bouwen.. tja.. dan hou je teleurstelling over en zit je in je studio'tje en op fora te blaten over the best of the best...

 

[WaveGuide7]

Als je met 32 bit niks vets kan maken dan kan je dat met 64 bit ook niet. (...)

Die stelling is niet noodzakelijk altijd waar en tegenvoorbeelden zijn al gegeven. Die heb je waarschijnlijk aangezien voor:

Poehee wat een in depth gebabbel..

 

[WaveGuide7]

En die gebeurtenis is eenmalig ???
T.o.v. van wat dan ???

latency is geen "gebeurtenis" of "event", zoals een Midi Note On een event is. Want een event vindt altijd plaats op een (uniek en onvoorspelbaar) tijdstip. Latency daarentegen is "inherent" aanwezig in het systeem; het is de (voorspelbare, berekenbare) delay - tijdvertraging - tussen de input en de output als gevolg van noodzakelijke verwerkingstijd door het systeem. Dus latency is, letterlijk, de "laatheid", het achterlopen van het systeem. De vertraging van een systeem is meetbaar, berekenbaar, constant, dus een pure systeemkarakteristiek. Een event is geen systeemkarakteristiek.

 

[Johndoe11]

i.d.d latency is gewoon een vertraging, kan een procesvertraging zijn of een signaal vertraging.
Waarom snap je dat niet Audiocollage?