totalee
Ingeburgerd
weet iemand of cubase sx 3 enof cubase 4 goed draaien op de intel quad prosessors??
cubase en prosessorss
- Thread starter totalee
- Start date
compmuzikant
Nieuwkomer
Hallo,
We zijn hier toevallig juist wat testen aan het draaien voor nieuwe systemen met quadprocessoren. En het draait tot zoverre prima.
Je bent altijd welkom om te komen testen.
Groeten,
Renier
www.teachmusic.nl
We zijn hier toevallig juist wat testen aan het draaien voor nieuwe systemen met quadprocessoren. En het draait tot zoverre prima.
Je bent altijd welkom om te komen testen.
Groeten,
Renier
www.teachmusic.nl
neuromancer
Fire, walk with me
Ik heb zelf Cubase 4 op een Core 2 Quad Extreme draaien en ik moet zeggen dat ik het cpu gebruik nog niet boven de 25% heb zien uitkomen.
Waarbij er dan toch een aantal plugins en effecten draaiden.
Zelf vermoed ik dat het hebben van veel geheugen zinvol is bij gebruik van Cubase daar ik in het verleden heb gemerkt dat ie audio toch in memory gaat cachen.
Ook vreten plugins welke met samples werken veel geheugen.
Reden waarom er bij mij 4 Gig inzit (waarvan XP 'slechts' 3,5 Gig ziet)
Ook SX 3 kon al met multiprocessor systemen overweg trouwens.
Deze draaide ik op mij P4 met hyperthreading (soort van sloeber multi cpu effect)
Waarbij er dan toch een aantal plugins en effecten draaiden.
Zelf vermoed ik dat het hebben van veel geheugen zinvol is bij gebruik van Cubase daar ik in het verleden heb gemerkt dat ie audio toch in memory gaat cachen.
Ook vreten plugins welke met samples werken veel geheugen.
Reden waarom er bij mij 4 Gig inzit (waarvan XP 'slechts' 3,5 Gig ziet)
Ook SX 3 kon al met multiprocessor systemen overweg trouwens.
Deze draaide ik op mij P4 met hyperthreading (soort van sloeber multi cpu effect)
Zelf heb ik al bijna driekwart jaar een quadcore draaiend (zowel onder Vista als XP). Multiprocessor/multicore ondersteuning is onder Cubase 4 (en Nuendo 4 eveneens) volledig "corrupt". Ben zelf een van de eerste die dat opgemerkt heeft - zoek maar eens op het Nuendo en Cubase forum van Steinberg ( LINK naar steinberg forum ) en je komt de berichten meteen tegen: er is een onevenredige processorcore belasting waarbij de setting "multiprocessing on" van Cubase/Nuendo niet goed (meer) werkt: ASIO problemen en core 1 van je processor overbelast terwijl de andere drie relatief laag belast zijn en weinig staan te doen, is dan het probleem. In combinatie met bepaalde kaarten (UAD DSP kaarten) wordt dit probleem nogmaals erger.
Voor Nuendo is beterschap beloofd met de volgende update, voor Cubase 4.1 (eind oktober) zal dit probleem echter nog NIET zijn opgelost. Ook onder SX(3) is bij multicore/multiprocessor de belasting onevenredig per core. De problemen zijn minder erg bij multicore systemen maar erger bij de combinatie multi-CPU + multicore (bijv. een dubbele quadcore).
Onder Vista is dit probleem overigens nog erger door een ander prioriteitsmechanisme van het OS. Tot nu toe waren Cubase en Nuendo officieel Vista compatibel maar er niet specifiek voor geschreven - ook dat wordt met de komende 4.1 update aangepakt en opgelost.
Dat neemt niet weg dat je door veel andere technische redenen sowieso een berg meer performance haalt uit een quadcore processor. Maar de echte performance winst moet nog komen. Zelfs met de belabberde multicore/multiproc ondersteuning (of beter: gebrek aan) van Steinberg, de quadcore was bijna een verdrievoudiging in prestatie ten opzichte van mijn voormalige dual processor Opteron 250 systeem. Voor SX moet je je ervan bewust zijn dat daarvoor geen updates meer komen die de multicore ondersteuning zullen verbeteren.
Er is dus geen simpel antwoord op de vraag "quadcore of niet". Je krijgt niet de maximale prestatie uit je quadcore door fouten in de Steinberg software - wel geven de quadcores een enorme prestatiewinst. Een kwestie of je het geld er toch voor over hebt voor de prestatiewinst die je wél boekt. Gebruik je ook nog andere software naast SX (bijv. Reaper of Cakewalk), dan is het simpele antwoord "quadcore meteen doen".
Suc6 - Rick
Voor Nuendo is beterschap beloofd met de volgende update, voor Cubase 4.1 (eind oktober) zal dit probleem echter nog NIET zijn opgelost. Ook onder SX(3) is bij multicore/multiprocessor de belasting onevenredig per core. De problemen zijn minder erg bij multicore systemen maar erger bij de combinatie multi-CPU + multicore (bijv. een dubbele quadcore).
Onder Vista is dit probleem overigens nog erger door een ander prioriteitsmechanisme van het OS. Tot nu toe waren Cubase en Nuendo officieel Vista compatibel maar er niet specifiek voor geschreven - ook dat wordt met de komende 4.1 update aangepakt en opgelost.
Dat neemt niet weg dat je door veel andere technische redenen sowieso een berg meer performance haalt uit een quadcore processor. Maar de echte performance winst moet nog komen. Zelfs met de belabberde multicore/multiproc ondersteuning (of beter: gebrek aan) van Steinberg, de quadcore was bijna een verdrievoudiging in prestatie ten opzichte van mijn voormalige dual processor Opteron 250 systeem. Voor SX moet je je ervan bewust zijn dat daarvoor geen updates meer komen die de multicore ondersteuning zullen verbeteren.
Er is dus geen simpel antwoord op de vraag "quadcore of niet". Je krijgt niet de maximale prestatie uit je quadcore door fouten in de Steinberg software - wel geven de quadcores een enorme prestatiewinst. Een kwestie of je het geld er toch voor over hebt voor de prestatiewinst die je wél boekt. Gebruik je ook nog andere software naast SX (bijv. Reaper of Cakewalk), dan is het simpele antwoord "quadcore meteen doen".
Suc6 - Rick
ka2
Uitgekookt Lid
Dan heb je nog mazzel, bij mij ziet XP maar 2,87 staan in plaats van 4
Hoeveel geheugen je OS ziet, hangt af van een combinatie van factoren:
- je moederbord (en of dat wel of niet memory remapping ondersteunt in de bios)
- je hardware die je op het moederbord prikt: voor elke kaart (videokaart, UAD, Powercore, geluidskaart, etc.) wordt een deel "memory address space" gereserveerd door je os (en dat gaat dus af van de bovengrens). In PC termen heeft dit alles te maken met MMIO (Memory mapped I/O)
- je besturingssysteem (XP, XP64, Vista-32, Vista-64): XP heeft afgerond een theoretisch bovengrens van 3,7 GB, Vista van 3,25 GB: Vista reserveert dus iets meer geheugen voor z'n achtergrond processen ("services")
- hoe je applicatie (bijv. Cubase) is geschreven: wel of niet "large_address_aware": onder een 32-bit Windows besturingssysteem staat voor een applicatie maximaal 2 GB ter beschikking, tenzij deze "large_address_aware" is
- dan is er nog veel misverstand over de optionele boot-optie "/3G" onder XP: dit past de hoeveelheid virtueel geheugen aan voor een programma beschikbaar, zegt echter NIETS over je feitelijke RAM geheugen
- of DEP (Dynamic Execution Prevention) wel/niet door je moederbord wordt ondersteunt én of het is ingeschakeld onder je OS én wel/niet specifiek voor je programma actief is (vooropgesteld dat je programma er mee om kan gaan)
Geheugenmanagement op een PC is dus bijna een vakgebied geworden. Prik een paar UAD kaarten of Powercores erin en zie dat je opeens tot 1,2 GB "kwijt" bent aan het reserveren van geheugen voor adressering van deze kaarten. Prik (voor een echte muziek-PC totaal nutteloze) zware videokaarten als 8800 GT(X) Nvidia-based videokaarten in je syteem en het kost je nogmaals 600 tot 800 MB aan geheugenadressering.
Cubase is vanaf SX2 "large_address_aware": bij SX2 moet je dit handmatig zelf toevoegen (doorzoek Steinberg fora), SX3 en later ondersteunen dit direct. Maar of dit geheugen boven de 2 GB dan ook kan worden gebruikt, zelfs al heeft je systeem 2,8 GB of meer geheugen "vrij", hangt van een combinatie van factoren af. Bovendien: als je gebruik maakt van memory remapping via het BIOS van je PC, zal je PC door de extra vertaaltabel een fractie trager werken, aangezien elke geheugenaanroep eerst via de vertaaltabel moet worden herleid naar het echte adres in het geheugen waar de data staat. Zeker bij geheugen-intensieve programma's waar snelheid extreem belangrijk is (Cubase, sampler plug-ins, etc.), weegt het snelheidsverlies vaak niet op tegen het extra geheugen wat je "krijgt".
Dan is de combinatie van MMIO, memory remapping en DEP ook vaak nog reden voor crashen software en instabiele systemen (zeker bij geheugen-intensieve en snelheidsvretende software als muziek-DAWs) en zie hier: geheugen goed gebruiken is soms een complete ramp en lastig te traceren wat nu wel of niet werkt, etc.
Pas bij echte 64-bit programma's en een 64-bit besturingssysteem (XP64, Vista-64), kunnen we dit hele verhaal vergeten en tot minimaal 128 GB geheugen inprikken en vrolijk muziek gaan maken zonder technische poespas. Aangezien het nog jaren duurt voordat alle software 64-bit is, blijft het geheugen geneuzel iedereen voorlopig het leven zuur maken.
- je moederbord (en of dat wel of niet memory remapping ondersteunt in de bios)
- je hardware die je op het moederbord prikt: voor elke kaart (videokaart, UAD, Powercore, geluidskaart, etc.) wordt een deel "memory address space" gereserveerd door je os (en dat gaat dus af van de bovengrens). In PC termen heeft dit alles te maken met MMIO (Memory mapped I/O)
- je besturingssysteem (XP, XP64, Vista-32, Vista-64): XP heeft afgerond een theoretisch bovengrens van 3,7 GB, Vista van 3,25 GB: Vista reserveert dus iets meer geheugen voor z'n achtergrond processen ("services")
- hoe je applicatie (bijv. Cubase) is geschreven: wel of niet "large_address_aware": onder een 32-bit Windows besturingssysteem staat voor een applicatie maximaal 2 GB ter beschikking, tenzij deze "large_address_aware" is
- dan is er nog veel misverstand over de optionele boot-optie "/3G" onder XP: dit past de hoeveelheid virtueel geheugen aan voor een programma beschikbaar, zegt echter NIETS over je feitelijke RAM geheugen
- of DEP (Dynamic Execution Prevention) wel/niet door je moederbord wordt ondersteunt én of het is ingeschakeld onder je OS én wel/niet specifiek voor je programma actief is (vooropgesteld dat je programma er mee om kan gaan)
Geheugenmanagement op een PC is dus bijna een vakgebied geworden. Prik een paar UAD kaarten of Powercores erin en zie dat je opeens tot 1,2 GB "kwijt" bent aan het reserveren van geheugen voor adressering van deze kaarten. Prik (voor een echte muziek-PC totaal nutteloze) zware videokaarten als 8800 GT(X) Nvidia-based videokaarten in je syteem en het kost je nogmaals 600 tot 800 MB aan geheugenadressering.
Cubase is vanaf SX2 "large_address_aware": bij SX2 moet je dit handmatig zelf toevoegen (doorzoek Steinberg fora), SX3 en later ondersteunen dit direct. Maar of dit geheugen boven de 2 GB dan ook kan worden gebruikt, zelfs al heeft je systeem 2,8 GB of meer geheugen "vrij", hangt van een combinatie van factoren af. Bovendien: als je gebruik maakt van memory remapping via het BIOS van je PC, zal je PC door de extra vertaaltabel een fractie trager werken, aangezien elke geheugenaanroep eerst via de vertaaltabel moet worden herleid naar het echte adres in het geheugen waar de data staat. Zeker bij geheugen-intensieve programma's waar snelheid extreem belangrijk is (Cubase, sampler plug-ins, etc.), weegt het snelheidsverlies vaak niet op tegen het extra geheugen wat je "krijgt".
Dan is de combinatie van MMIO, memory remapping en DEP ook vaak nog reden voor crashen software en instabiele systemen (zeker bij geheugen-intensieve en snelheidsvretende software als muziek-DAWs) en zie hier: geheugen goed gebruiken is soms een complete ramp en lastig te traceren wat nu wel of niet werkt, etc.
Pas bij echte 64-bit programma's en een 64-bit besturingssysteem (XP64, Vista-64), kunnen we dit hele verhaal vergeten en tot minimaal 128 GB geheugen inprikken en vrolijk muziek gaan maken zonder technische poespas. Aangezien het nog jaren duurt voordat alle software 64-bit is, blijft het geheugen geneuzel iedereen voorlopig het leven zuur maken.
fuse
Gepokt en gemazeld
- Lid sinds
- 7 juli 2001
- Berichten
- 18.831
Leuk verhaal Rick.
Jammer dat Steiny er zoveel problemen mee heeft. Maar goed, multi cpu programmeren is nou ook bepaald makkelijk te noemen.
Poosje geleden had ik een fout moederbord en kon niet eens een multi-core kernel gebruik samen met een UAD en RME kaart want dan kreeg je een BSOD. Maar een mobo upgrade verder gaat dat dus wel. Dus denk ik ook niet dat Steiny alle schuld heeft maar dus ook microsoft en hardware boeren die de boel ook niet altijd voor elkaar hebben.
Jammer dat Steiny er zoveel problemen mee heeft. Maar goed, multi cpu programmeren is nou ook bepaald makkelijk te noemen.
Poosje geleden had ik een fout moederbord en kon niet eens een multi-core kernel gebruik samen met een UAD en RME kaart want dan kreeg je een BSOD. Maar een mobo upgrade verder gaat dat dus wel. Dus denk ik ook niet dat Steiny alle schuld heeft maar dus ook microsoft en hardware boeren die de boel ook niet altijd voor elkaar hebben.
BananaWorld
Addicted to Music
Als je nu een oude versie van cubase hebt (VST ofzo) dan heeft deze waarschijnlijk geen support voor multicore. Draait hij dan gewoon op 1 processor of werkt het niet?
Eigenlijk heb ik hier nooit over nagedacht, aangezien ik mijn laatste computer zo'n drie jaar geleden gekocht heb en teon alles gewoon kon overzetten. Weet iemand hier meer van?
Eigenlijk heb ik hier nooit over nagedacht, aangezien ik mijn laatste computer zo'n drie jaar geleden gekocht heb en teon alles gewoon kon overzetten. Weet iemand hier meer van?
@Fuse: je hebt helemaal gelijk Fuse: heb ook al eens mobo's moeten verwisselen omdat een bepaalde combinatie een ramp bleek of een bordje "gaar" was en Steiny krijgt al snel alle blame terwijl dit soort zaken vaak komt omdat je domme pech hebt met je hardware, Microsoft of anderen bepaalde SDK (system development kits) gewoon niet compleet hebben of niet op tijd klaar of drivers rampzalig uitpakken.
Dat neemt niet weg dat Steiny over het algemeen wel iets minder netjes programmeert, maar het zou me ook niet verbazen als Cakewalk als Amerikaans bedrijf gewoon betere support heeft vanuit Microsoft, maar hey.... wij arme gebruikers zijn overgeleverd en dus zeiken we af en toe dan maar (terecht of niet) tegen Steiny aan... Ach, alle pakketten Protools, Steiny whatever hebben zo hun eigen eigenaardigheden... ;-)
@BananaWorld: oudere software zal in principe dan inderdaad op 1 core draaien. Maar: het besturingssysteem (en dan met name Vista) kan zelf de belasting over de cores verdelen. Dus het kan heel goed zijn dat je toch meer prestatie uit je PC perst met een oude Cubase doordat je OS Windows achtergrondprocessen op een andere core en bijv. je VST-spullekes van elkaar gescheiden houdt. Of oudere software wel of niet draait hangt af van drivers die je nodig hebt en of de software netjes is geschreven. De meeste windows-progjes kun je blijven gebruiken op een nieuw systeem, het zijn meestal de drivers die voor problemen zorgen. Ik zou zeker oppassen met Vista, zeker bij oudere software, XP (Pro) is waarschijnlijk je beste keus voor een oudere VST-versie (tot de praktijk uitwijst dat het wel werkt). Eerst testen dus....
Dat neemt niet weg dat Steiny over het algemeen wel iets minder netjes programmeert, maar het zou me ook niet verbazen als Cakewalk als Amerikaans bedrijf gewoon betere support heeft vanuit Microsoft, maar hey.... wij arme gebruikers zijn overgeleverd en dus zeiken we af en toe dan maar (terecht of niet) tegen Steiny aan... Ach, alle pakketten Protools, Steiny whatever hebben zo hun eigen eigenaardigheden... ;-)
@BananaWorld: oudere software zal in principe dan inderdaad op 1 core draaien. Maar: het besturingssysteem (en dan met name Vista) kan zelf de belasting over de cores verdelen. Dus het kan heel goed zijn dat je toch meer prestatie uit je PC perst met een oude Cubase doordat je OS Windows achtergrondprocessen op een andere core en bijv. je VST-spullekes van elkaar gescheiden houdt. Of oudere software wel of niet draait hangt af van drivers die je nodig hebt en of de software netjes is geschreven. De meeste windows-progjes kun je blijven gebruiken op een nieuw systeem, het zijn meestal de drivers die voor problemen zorgen. Ik zou zeker oppassen met Vista, zeker bij oudere software, XP (Pro) is waarschijnlijk je beste keus voor een oudere VST-versie (tot de praktijk uitwijst dat het wel werkt). Eerst testen dus....
Laatst gewijzigd:
De laatste problemen rond multi-cpu/multi-core lezend op de Steiny forums (waar inmiddels te zien is dat men met de update na 4.1 - voorlopig als 4.1.1 aangeduid - het X-scale probleem zoals dat officieel heet, ook zal oplossen), wilde ik toch nog even een puur technische overweging toevoegen - voor wie het interesseert technisch:
Fuse stelde namelijk:
Hij bedoelt natuurlijk niet makkelijk. En in principe is dat helemaal waar. Behalve... als je het hele probleem vergeet en het als een logische uitdaging ziet.
Hoe gaat het nu/ging het tot aan nu met normale software?
De meeste software is "multi-threaded" tegenwoordig. Dit is op het PC-platform vooral in opkomst gekomen toen Intel de processoren met Hyperthreading ging uitrusten, zoals hier bovenal door een SF-lid gezegd, een sloeber multicore: geen echte extra processor, maar een quick'n dirty methode om de restcapaciteit van de CPU te gebruiken.
Belangrijk daarbij is te weten dat tot aan dat moment een PC helemaal niet in staat was om "realtime" gelijktijdig meerdere processen uit te voeren. Elk proces werd serieel (na elkaar) netjes berekend. Doordat dat steeds sneller kan verlopen, lijkt het dan alsof de PC realtime werkt en meerdere taken tegelijk uitvoert. In werkelijkheid krijgt elk proces een stuke processortijd en wordt alles in delen na elkaar berekent. Door een prioriteit aan een berekening toe te kennen verloopt het ene proces sneller, en minder belangrijke dus trager omdat deze minder rekentijd krijgen.
Dit principe is grofweg nog steeds de methode waarmee vrijwel alle huidige software werkt. Inmiddels hebben we multi-core en multi-cpu beschikbaar voor consumenten (in de prof industrie al decennialang achterhaald nieuws). Ook het besturingssysteem is veel beter geworden in de ondersteuning voor multi-threaded, multi-core besturing. Met name Vista heeft een arsenaal aan "class scheduling" mechanismen waar echte Vista software gebruik van kan maken. Omdat de software daar in de meeste gevallen nog niet voor is geschreven/geoptimaliseerd, zijn er met name met allerlei "realtime" software zoals DAWs nog enorme prestatiewinsten te behalen. De "ik-kan beter een wasmachine-testen"-consumentenbond ten spijt, Vista is wel degelijk een enorme stap voorwaarts MITS softwarefabrikanten de mogelijkheden van Vista ook gaan benutten. Kip-ei verhaal, niets nieuws onder de zon. Was in het begin met XP niet anders. Door je systeem te tweaken, waarbij allerlei voor jouw toepassing min of meer nutteloze services de nek worden omgedraaid, kun je de prestatie van je systeem nog verder opkrikken. Maar het feit blijft: zo lang het huwelijk van software, OS en hardware niet optimaal is, altijd een verspilling van resources, prestatie en problemen.
Van probleem naar toekomstgerichte uitdaging: MPP of SMP of een combinatie
Massive Parallel Processing (MPP) of Symmetrical Parallel Processing (SMP). twee begrippen die pas nu in de consumenten-PC wereld hun intrede doen. Bij MPP laat je veel brute rekenkracht los (lees: multi core + multi-CPU) op één specifieke taak. Bij SMP laat je veel rekenkracht los op een groot aantal taken tegelijk. Het principe van een PC onder XP en zeker Vista en OSX, is dat van SMP. Je hebt een multimedia computer waar je video's op kijkt, spellen mee speelt, mee mailt, chat, foto's bewerkt noem maar op. Veel applicaties staan tegelijkertijd open. De besturingssystemen zijn hier ook helemaal op ingericht.
Ga je een systeem tweaken, dan wil je ultiem je SMP ingericht OS zover optimaliseren dat hij als een MPP systeem gaat werken met maar één doel: de ultieme muziek DAW in onze toepassing.
De waarheid is echter dat complexe software als Cubase, ProTools (etc.) weliswaar één specifieke taak hebben en MPP lijken, maar in essentie SMP zijn én in een SMP omgeving draaien. Immers, voor een DAW moeten talloze berekeningen realtime worden gedaan: mixer, effecten, VSTs, time stretching, etc.
En juist daar zit een uitdaging als een software ontwikkelaar bereid is van de grond af aan zijn software te herzien.
Door namelijk een DAW op te delen naar een aantal specifieke achtergrondprocessen met een eigen prioriteits afhandeling, zou je een perfekt multi-core, multi-cpu programma kunnen ontwikkelen.
Je hebt zo even snel opgesomt en bedacht (en zeker niet compleet) nodig:
- Class scheduler: deze zit al in Windows, maar een, in dit voorbeeld, een eigen speciaal geschreven Steinberg Class Scheduler die de verschillende threads van het programma aan de hand van een classificatie (en dus prioriteit) opvangt, doorgeeft aan een berekenings-service, de resultaten afvangt en het programma informeert dat de berekening klaar is
- Algorithmic Services: diverse specifieke services (achtergrondprocessen), elke met een eigen taak te berekenen, die aan de hand van wat de Class Scheduler hen heeft toebedeeld, aan de slag gaat
- Exception Handler: een service die bekijkt waar de DAW zelf mee bezig is en uitzonderingen (bijv. stoppen/starten/punch-in opname, etc.) afvangt en doorgeeft aan de Class Scheduler (dit kan een integrale functie van de Scheduler zijn, beter is dit ook als aparte service uit te voeren voor multi-core/CPU systemen)
- Memory Buffer Scheduler: ondersteuning voor de Class Scheduler die in staat is nog niet compleet berekende resultaten toch al aan de DAW ter beschikking te stellen (zeker bij disk-streaming en sampling handig)
- User Thread Prediction Engine: een systeem dat "leert" hoe een gebruiker zijn DAW meestal gebruikt én wat de eerstvolgende logische berekening moet worden: dit voorspelt wat volgende taken zullen zijn en daarmee kan de Class Scheduler verder geoptimaliseert worden
- Plugin Monitoring Handler: door dit als achtergrondproces af te handelen crasht de DAW niet meer op een niet (goed) werkende plugin, maar schakelt deze uit en informeert de DAW dat deze onbeschikbaar is om welke reden dan ook
- ASIO/Stream Handler: een extreem low-level (betekent hoogste prioriteit) service die zorgt dat de audio (video) streams goed verlopen
- Stream Routing Service: een achtergrondproces wat zorgt dat alle data van en naar PCI-e/PCI-X/PCI optimaal verlopen en nooit meer voor bandbreedte problemen kunnen zorgen op de chipset: dit principe zou "realtime" audiokaarten mogelijk gaan maken met maar 1 sample buffer en zelfs minder dan één sample bit-buffers volgens DSD (Direct Stream Digital) principe: 1-bit serieel. Bovendien zou dit een enorme vooruitgang in de audiokaarten qua geluidskwaliteit teweeg brengen. De Stream Routing Service zou echter compatibel moeten zijn met alle huidige hardware, maar ook een complete nieuwe generatie kaarten mogelijk maken
- GUI Buffer & Handler: beeldscherm-afhandeling
De DAW applicatie zou vervolgens alleen nog maar een kernprogramma zijn wat de globale werking bestuurt en afhandelt naar wat het "krijgt" van de achtergrondprocessen. Zo'n opzet combineert dan MPP en SMP priincipes, is bij utistek voor moderne multi-core/multi-cpu systemen geschreven en kent in deze opzet geen concurrentie in de markt. Het grote nadeel voor een software fabrikant is dat ongeacht welke software nu op de markt, het moet compleet worden herschreven.
Als laatste optimalisatie voor PC's kun je een HAL (hardware abstraction layer)-enabled installatie uitvoeren (of simpelweg: OEM-installatie) en je zou een extra hardware profiel kunnen kiezen bij het opstarten van je PC waarbij vervolgens je hele machine automatisch optimaal is ingericht voor één toepassing: DAW gebruik. En wil je weer terug naar je normale PC-gebruik, start je de volgende keer op met je standaard hardware profiel waar alle dagelijkse dingen onder draaien.
Hoie kom ik bij deze "wijsheid" (zelfspot modus
): o.a. als adviseur/manager in o.a. de AV industrie die talloze bedrijven helpt bij de ontwikkeling van hardware/software. Hoe groot is de kans dat een dergelijke aanpak wordt toegepast? Niet bijster groot ben ik bang zolang de fabrikanten van dit soort software niet een PC durven te claimen voor één toepassing (wat in principe ook haaks staat op de gedachte van een PC). Maar voor high-end toepassingen, consumenten of niet, is een dergelijke ontwikkeling net zo vooruitstrevend als destijds de introductie van "ASIO" en "VST". Dus het kan wel degelijk. Als vervolgens Steinberg Marketing dan eens wakker wordt en een echt goede vent er neer zet die delen van deze techniek aan anderen als licenties gaat geven, is er veel meer te verdienen dan aan Nuendo, Cubase en wat VST-tjes alleen. Bovendien zet je als bedrijf dan een trend neer die je , mits goed gedaan, in 1-klap weer op het wereldpodium plaatst als trendsetter. En laten we eerlijk zijn: Steinberg mag ogenschijnlijk de laatste jaren voortborduren op eigen oude uitvindingen, het is wel degelijk een trendsetter vanuit het verleden die een revolutie hebben veroorzaakt met DAW toepassingen. Het wordt alleen tijd dat ze dit zelf weer eens in gaan zien en een echt plan trekken naar de toekomst. Want anderen kunnen dit in principe ook. Niet alleen andere DAW-fabrikanten. Maar inmiddels ook VST-fabrikanten. De concurrentie van een geheel nieuwe DAW kan op een zekere dag maar zo uit onverwachte hoek komen van een VST-fabrikant als Native Instruments: die hebben de kracht, het geld en de kennis. Op naar de volgende revolutie, en tot die tijd ploeteren wij als gebruikers voort met (veel) minder dan optimaal presterende systemen...
Fuse stelde namelijk:
Hij bedoelt natuurlijk niet makkelijk. En in principe is dat helemaal waar. Behalve... als je het hele probleem vergeet en het als een logische uitdaging ziet.
Hoe gaat het nu/ging het tot aan nu met normale software?
De meeste software is "multi-threaded" tegenwoordig. Dit is op het PC-platform vooral in opkomst gekomen toen Intel de processoren met Hyperthreading ging uitrusten, zoals hier bovenal door een SF-lid gezegd, een sloeber multicore: geen echte extra processor, maar een quick'n dirty methode om de restcapaciteit van de CPU te gebruiken.
Belangrijk daarbij is te weten dat tot aan dat moment een PC helemaal niet in staat was om "realtime" gelijktijdig meerdere processen uit te voeren. Elk proces werd serieel (na elkaar) netjes berekend. Doordat dat steeds sneller kan verlopen, lijkt het dan alsof de PC realtime werkt en meerdere taken tegelijk uitvoert. In werkelijkheid krijgt elk proces een stuke processortijd en wordt alles in delen na elkaar berekent. Door een prioriteit aan een berekening toe te kennen verloopt het ene proces sneller, en minder belangrijke dus trager omdat deze minder rekentijd krijgen.
Dit principe is grofweg nog steeds de methode waarmee vrijwel alle huidige software werkt. Inmiddels hebben we multi-core en multi-cpu beschikbaar voor consumenten (in de prof industrie al decennialang achterhaald nieuws). Ook het besturingssysteem is veel beter geworden in de ondersteuning voor multi-threaded, multi-core besturing. Met name Vista heeft een arsenaal aan "class scheduling" mechanismen waar echte Vista software gebruik van kan maken. Omdat de software daar in de meeste gevallen nog niet voor is geschreven/geoptimaliseerd, zijn er met name met allerlei "realtime" software zoals DAWs nog enorme prestatiewinsten te behalen. De "ik-kan beter een wasmachine-testen"-consumentenbond ten spijt, Vista is wel degelijk een enorme stap voorwaarts MITS softwarefabrikanten de mogelijkheden van Vista ook gaan benutten. Kip-ei verhaal, niets nieuws onder de zon. Was in het begin met XP niet anders. Door je systeem te tweaken, waarbij allerlei voor jouw toepassing min of meer nutteloze services de nek worden omgedraaid, kun je de prestatie van je systeem nog verder opkrikken. Maar het feit blijft: zo lang het huwelijk van software, OS en hardware niet optimaal is, altijd een verspilling van resources, prestatie en problemen.
Van probleem naar toekomstgerichte uitdaging: MPP of SMP of een combinatie
Massive Parallel Processing (MPP) of Symmetrical Parallel Processing (SMP). twee begrippen die pas nu in de consumenten-PC wereld hun intrede doen. Bij MPP laat je veel brute rekenkracht los (lees: multi core + multi-CPU) op één specifieke taak. Bij SMP laat je veel rekenkracht los op een groot aantal taken tegelijk. Het principe van een PC onder XP en zeker Vista en OSX, is dat van SMP. Je hebt een multimedia computer waar je video's op kijkt, spellen mee speelt, mee mailt, chat, foto's bewerkt noem maar op. Veel applicaties staan tegelijkertijd open. De besturingssystemen zijn hier ook helemaal op ingericht.
Ga je een systeem tweaken, dan wil je ultiem je SMP ingericht OS zover optimaliseren dat hij als een MPP systeem gaat werken met maar één doel: de ultieme muziek DAW in onze toepassing.
De waarheid is echter dat complexe software als Cubase, ProTools (etc.) weliswaar één specifieke taak hebben en MPP lijken, maar in essentie SMP zijn én in een SMP omgeving draaien. Immers, voor een DAW moeten talloze berekeningen realtime worden gedaan: mixer, effecten, VSTs, time stretching, etc.
En juist daar zit een uitdaging als een software ontwikkelaar bereid is van de grond af aan zijn software te herzien.
Door namelijk een DAW op te delen naar een aantal specifieke achtergrondprocessen met een eigen prioriteits afhandeling, zou je een perfekt multi-core, multi-cpu programma kunnen ontwikkelen.
Je hebt zo even snel opgesomt en bedacht (en zeker niet compleet) nodig:
- Class scheduler: deze zit al in Windows, maar een, in dit voorbeeld, een eigen speciaal geschreven Steinberg Class Scheduler die de verschillende threads van het programma aan de hand van een classificatie (en dus prioriteit) opvangt, doorgeeft aan een berekenings-service, de resultaten afvangt en het programma informeert dat de berekening klaar is
- Algorithmic Services: diverse specifieke services (achtergrondprocessen), elke met een eigen taak te berekenen, die aan de hand van wat de Class Scheduler hen heeft toebedeeld, aan de slag gaat
- Exception Handler: een service die bekijkt waar de DAW zelf mee bezig is en uitzonderingen (bijv. stoppen/starten/punch-in opname, etc.) afvangt en doorgeeft aan de Class Scheduler (dit kan een integrale functie van de Scheduler zijn, beter is dit ook als aparte service uit te voeren voor multi-core/CPU systemen)
- Memory Buffer Scheduler: ondersteuning voor de Class Scheduler die in staat is nog niet compleet berekende resultaten toch al aan de DAW ter beschikking te stellen (zeker bij disk-streaming en sampling handig)
- User Thread Prediction Engine: een systeem dat "leert" hoe een gebruiker zijn DAW meestal gebruikt én wat de eerstvolgende logische berekening moet worden: dit voorspelt wat volgende taken zullen zijn en daarmee kan de Class Scheduler verder geoptimaliseert worden
- Plugin Monitoring Handler: door dit als achtergrondproces af te handelen crasht de DAW niet meer op een niet (goed) werkende plugin, maar schakelt deze uit en informeert de DAW dat deze onbeschikbaar is om welke reden dan ook
- ASIO/Stream Handler: een extreem low-level (betekent hoogste prioriteit) service die zorgt dat de audio (video) streams goed verlopen
- Stream Routing Service: een achtergrondproces wat zorgt dat alle data van en naar PCI-e/PCI-X/PCI optimaal verlopen en nooit meer voor bandbreedte problemen kunnen zorgen op de chipset: dit principe zou "realtime" audiokaarten mogelijk gaan maken met maar 1 sample buffer en zelfs minder dan één sample bit-buffers volgens DSD (Direct Stream Digital) principe: 1-bit serieel. Bovendien zou dit een enorme vooruitgang in de audiokaarten qua geluidskwaliteit teweeg brengen. De Stream Routing Service zou echter compatibel moeten zijn met alle huidige hardware, maar ook een complete nieuwe generatie kaarten mogelijk maken
- GUI Buffer & Handler: beeldscherm-afhandeling
De DAW applicatie zou vervolgens alleen nog maar een kernprogramma zijn wat de globale werking bestuurt en afhandelt naar wat het "krijgt" van de achtergrondprocessen. Zo'n opzet combineert dan MPP en SMP priincipes, is bij utistek voor moderne multi-core/multi-cpu systemen geschreven en kent in deze opzet geen concurrentie in de markt. Het grote nadeel voor een software fabrikant is dat ongeacht welke software nu op de markt, het moet compleet worden herschreven.
Als laatste optimalisatie voor PC's kun je een HAL (hardware abstraction layer)-enabled installatie uitvoeren (of simpelweg: OEM-installatie) en je zou een extra hardware profiel kunnen kiezen bij het opstarten van je PC waarbij vervolgens je hele machine automatisch optimaal is ingericht voor één toepassing: DAW gebruik. En wil je weer terug naar je normale PC-gebruik, start je de volgende keer op met je standaard hardware profiel waar alle dagelijkse dingen onder draaien.
Hoie kom ik bij deze "wijsheid" (zelfspot modus
): o.a. als adviseur/manager in o.a. de AV industrie die talloze bedrijven helpt bij de ontwikkeling van hardware/software. Hoe groot is de kans dat een dergelijke aanpak wordt toegepast? Niet bijster groot ben ik bang zolang de fabrikanten van dit soort software niet een PC durven te claimen voor één toepassing (wat in principe ook haaks staat op de gedachte van een PC). Maar voor high-end toepassingen, consumenten of niet, is een dergelijke ontwikkeling net zo vooruitstrevend als destijds de introductie van "ASIO" en "VST". Dus het kan wel degelijk. Als vervolgens Steinberg Marketing dan eens wakker wordt en een echt goede vent er neer zet die delen van deze techniek aan anderen als licenties gaat geven, is er veel meer te verdienen dan aan Nuendo, Cubase en wat VST-tjes alleen. Bovendien zet je als bedrijf dan een trend neer die je , mits goed gedaan, in 1-klap weer op het wereldpodium plaatst als trendsetter. En laten we eerlijk zijn: Steinberg mag ogenschijnlijk de laatste jaren voortborduren op eigen oude uitvindingen, het is wel degelijk een trendsetter vanuit het verleden die een revolutie hebben veroorzaakt met DAW toepassingen. Het wordt alleen tijd dat ze dit zelf weer eens in gaan zien en een echt plan trekken naar de toekomst. Want anderen kunnen dit in principe ook. Niet alleen andere DAW-fabrikanten. Maar inmiddels ook VST-fabrikanten. De concurrentie van een geheel nieuwe DAW kan op een zekere dag maar zo uit onverwachte hoek komen van een VST-fabrikant als Native Instruments: die hebben de kracht, het geld en de kennis. Op naar de volgende revolutie, en tot die tijd ploeteren wij als gebruikers voort met (veel) minder dan optimaal presterende systemen...
Laatst gewijzigd:
anthonievos
Stamgast
- Lid sinds
- 12 januari 2004
- Berichten
- 189
Mensen een hoop technische info, maar kan iemand mij vertellen welke proccesor ik het best kan nemen
voor het draaien van SX3 in de toekomst Cubase 4.
Ik draai alleen Cubase, geen andere software er naast.
THnx
voor het draaien van SX3 in de toekomst Cubase 4.
Ik draai alleen Cubase, geen andere software er naast.
THnx
ka2
Uitgekookt Lid
Vergeet niet illigaal downloaden! He he he he he he.
Wat je pakt maakt geen jota uit; het is voornamelijk een kwestie van budget. Zowel Intel als AMD bieden dual-core oplossingen en 4 kan daar mee werken; pak wat je je kunt veroorloven.
Gewoon hier kijken: http://tweakers.net/reviews/727/tweakers-punt-net-best-buy-guide-editie-september-2007.html
en wegstrepen wat je al hebt.
