JUCE vs. FAUST
En jämförande studie i prestanda mellan plugins
Huvudområde: Datateknik
Författare: Henric Hiljanen & Jonathan Karlsson Handledare: Peter Larsson-Green
Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom [se huvudområde på föregående sida]. Författarna svarar själva för framförda åsikter, slutsatser och resultat.
Acknowledgements
We would like to thank our supervisor Peter Larsson-Green for great guidance and helpful feedback throughout the entire process of writing this bachelor thesis.
Abstract
Purpose – Examine if there is any difference in performance between the C++ framework JUCE and the domain-specific programming language FAUST to create a decision basis to facilitate choices between them when developing plugins.
Method – An experimental study where two delay-plugins with identical functionality were developed and compared in latency, CPU load and memory usage. The experiment consisted of three test cases and were performed on three different computers.
Findings – FAUST performed better than JUCE regarding latency and CPU load during the experiment. JUCE on the other hand performed better than FAUST regarding memory usage.
Implications – This study has made it easier to make a decision based on performance when choosing between JUCE and FAUST regarding development of plugins.
Limitations – Time restrictions has led to only comparing JUCE and FAUST, leaving other relevant alternatives aside. It has also led to only developing one type of plugin. The results of the study cannot be generalized or applied to other frameworks and programming languages whose purpose is to ease processing of digital signals.
Keywords – Plugins, music, sound, audio, latency, performance, JUCE, FAUST, digital signal processing, delay.
Sammanfattning
Syfte – Undersöka om det är någon skillnad i prestanda mellan C++-ramverket JUCE och det domänspecifika programmeringsspråket FAUST för att skapa ett beslutsunderlag för att underlätta val mellan dem vid utveckling av plugins.
Metod – En experimentell studie där två delay-plugins med identisk funktionalitet utvecklades och jämfördes i latency, CPU-belastning och minnesanvändning. Experimentet bestod av tre testfall och utfördes på tre olika datorer.
Resultat – FAUST presterade bättre än JUCE gällande latency och CPU-belastning under
experimentet. JUCE presterade däremot bättre gällande minnesanvändning.
Implikationer – Denna studie har gjort det lättare att fatta ett beslut baserat på prestanda vid val mellan JUCE och FAUST beträffande utveckling av plugins.
Begränsningar – Tidsbegränsningar har lett till att endast en jämförelse mellan JUCE och FAUST har genomförts. Andra relevanta alternativ har uteslutits på grund av detta. Det har också medfört att endast en typ av plugin har utvecklats. Studiens resultat kan inte tillämpas eller generaliseras till andra ramverk och domänspecifika programmeringsspråk vars syfte är att bearbeta digitala ljudsignaler.
Begreppsdefinitioner
AU: Audio Unit. Ett plugin-format utvecklat av Apple som endast går att använda på Mac OS X. DAW: Digital Audio Workstation är ett program som används för produktion och bearbetning av musik. Plugins används i DAWs för att addera ny funktionalitet för att bearbeta ljud.
Delay: En ljudeffekt som återupprepar ljudet likt ett eko.
Delay time: Inställningsparameter på en delay som styr hur ofta ekot ska repeteras.
Dry/Wet: Inställningsparameter på en delay där Dry är inputsignalen vilken inte är förändrad
medan Wet är delay-signalen efter bearbetning och representerar ekot. Parametern brukar ha ett värde mellan 0-100 %. 0 % spelar endast upp Dry signalen medans 100 % endast spelar upp delay-signalen. 50 % ger en blandning av båda.
DSP: Digital Signal Processing. Bearbetning av digitala signaler som representeras i form av samples. Feedback: Inställningsparameter på en delay som styr hur fort ekot ska tystas och försvinna. Parametern brukar ha ett värde mellan 0-100 %.
Ljudprogrammeringsspråk: Domänspecifikt högnivåspråk där domänen är ljud. Ett programmeringsspråk avsett för att utveckla applikationer som bearbetar ljud.
Musikproduktion: Skapandet av musik. Detta omfattar bland annat komposition, arrangering,
inspelning, mixning och mastering.
Plugin: En mjukvara som är till för att förändra eller förstärka digitala ljudsignaler och skapa olika ljudeffekter.
VST: Virtual Studio Technology. Ett plugin-format utvecklat av Steinberg som går att använda på
Innehållsförteckning
1 Introduktion 1
1.1 Bakgrund 1
1.2 Problembeskrivning 2
1.3 Syfte och Frågeställningar 3
1.4 Omfång och Avgränsningar 4
1.5 Disposition 4
2 Metod och genomförande 5
2.1 Koppling mellan frågeställning och metod 5
2.2 Arbetsprocessen 5 2.3 Experiment 5 2.4 Implementation 6 2.5 Enheter 7 2.6 Tester 8 2.7 Mätverktyg 9 2.7.1 PluginDoctor 9 2.7.2 Aktivitetskontroll 10 2.8 Mätmetoder 10 2.8.1 Latency 11 2.8.2 CPU-belastning 11 2.8.3 Minnesanvändning 11 2.9 Datainsamling 11 2.10 Dataanalys 11 2.11 Trovärdighet 12 3 Teoretiskt ramverk 13
3.1 Koppling mellan frågeställning och teori 13
3.2 Tidigare forskning 13 3.3 Digitalt ljud 14 3.4 Sample 15 3.5 Buffertstorlek 16 3.6 Delay 17 3.7 Latency 17 3.8 JUCE 18 3.9 FAUST 18 3.10 Standardavvikelse 19 3.11 Signifikansanalys 19 4 Empiri 21 4.1 Macbook Pro 2011 21
4.1.1 Macbook Pro 2011 - Latency 21
4.1.2 Macbook Pro 2011 - CPU-belastning 22 4.1.3 Macbook Pro 2011 - Minnesanvändning 23
4.2 iMac 2013 24
4.2.2 iMac 2013 - CPU-belastning 25
4.2.3 iMac 2013 - Minnesanvändning 26
4.3 Macbook Pro 2015 27
4.3.1 Macbook Pro 2015 - Latency 27
4.3.2 Macbook Pro 2015 - CPU-belastning 28 4.3.3 Macbook Pro 2015 - Minnesanvändning 29
5 Analys 30
5.1 Medelvärden från latencymätningar 30
5.2 Medelvärden från CPU-mätningar 32
5.3 Medelvärden från RAM-minnesmätningar 34
5.4 Hur stor skillnad är det i prestanda (latency, CPU-belastning och minnesanvändning) mellan en plugin utvecklad i JUCE och en utvecklad i FAUST? 36
5.4.1 Latency 36
5.4.2 CPU-belastning 37
5.4.3 Minnesanvändning 38
5.5 Sammanfattning 39
6 Diskussion och slutsatser 40
6.1 Resultat 40
6.2 Implikationer 40
6.3 Begränsningar 40
6.4 Slutsatser och rekommendationer 41
6.5 Vidare forskning 41
Referenser 43
Bilagor 45
Bilaga 1 - Ableton Live 10 46
Bilaga 2 - Logic Pro X 47
Bilaga 3 - Native Instruments plugin Massive 48
Bilaga 4 - Waves plugin H-Delay 49
Bilaga 5 - Native Instruments plugin Replika 50
Bilaga 6 - iZotopes plugin Neutron 3 51
Bilaga 7 - Mätningar från enheten Macbook Pro 2011 52 Bilaga 8 - Mätningar från enheten iMac 2013 54 Bilaga 9 - Mätningar från enheten Macbook Pro 2015 56
1 Introduktion
Kapitlet ger en bakgrund till studien och det problemområde som studien byggts upp kring. Vidare presenteras studiens syfte och dess frågeställning. Därtill beskrivs studiens omfång och avgränsningar. Kapitlet avslutas med rapportens disposition.
1.1 Bakgrund
Att göra musik med hjälp av datorer är inget nytt fenomen. Den första digitala synten utvecklades av Max Mathews och stod färdig redan 1957. Denna banade väg för vidareutveckling av musikapplikationer och har lett fram till dagens digitala musikproduktion (Lazzarini, 2013).
Utveckling av musikapplikationer med fokus på musikproduktion, mixning och mastering är idag en bransch med många aktörer. Figur 1 visar hur mycket branschen förutspås att växa. År 2017 omsatte branschen totalt runt 20 miljarder SEK världen över och förväntas växa rejält de kommande åren. År 2022 antas branschen omsätta över 60 miljarder SEK världen över vilket är en ökning på 300% jämfört med år 2017 (KCK Media Corp., 2018).
Figur 1. Global omsättning inom utveckling av musikprogramvara
Ray Williams som är ansvarig för marknadsföring på organisationen International Music Software Trade Association säger att det är svårt att göra musik idag utan att använda sig av mjukvara.1 Mjukvara spelar en nyckelroll i dagens musikproduktioner (NAMM, 2020a). Plugins är ett samlingsnamn för denna typ av mjukvara och kan vara allt från en komplex synt till en enkel ljudeffekt. Exempel på etablerade och välkända plugins är Massive (se bilaga 3), H-Delay (se bilaga 4), Replika (se bilaga 5) och Neutron 3 (se bilaga 6). Plugins används oftast i en Digital Audio Workstation (DAW) och är en applikation ämnad för att skapa och redigera hela musikproduktioner. Exempel på två etablerade och kända DAWs är Ableton Live 10 (se bilaga 1) och Logic Pro X (se bilaga 2). Enligt NAMM (2020b) är plugins den mjukvara som har haft och troligtvis också kommer att fortsätta ha, den största tillväxten inom branschen (Thompson, 2013; Walzer, 2016). Digital 1https://www.imsta.org/
musikproduktion kan idag leverera en ljudkvalitet som är jämförbar med dyra analoga instrument, men är mycket billigare. På grund av detta används mjukvara mer och mer i musikproduktioner. En vanlig plugin som återfinns hos de flesta företag som utvecklar och säljer plugins är en delay. Detta är en vanlig ljudeffekt som används i många musikproduktioner och har samma funktionalitet som ett eko.
Utveckling av plugins sker ofta i något ramverk eller ljudprogrammeringsspråk, men utveckling kan också göras direkt i lågnivåspråk som C/C++. Då plugins ofta är komplexa och innehåller avancerade algoritmer kan utvecklingen underlättas genom att använda ett ramverk eller ljudprogrammeringsspråk. Exempel på ett etablerat ramverk är JUCE och exempel på ett ljudprogrammeringsspråk är FAUST.
JUCE (Jules’ Utility Class Extensions) är ett C++-baserat ramverk som används vid utveckling av2 desktop-, plugin- och mobilapplikationer. JUCE används främst för att utveckla grafiska plugins som sen används i olika DAWs. Ramverket är crossplattform vilket innebär att källkoden som implementerats kan kompileras och köras identiskt på Mac OS X, Windows och Linux. Ramverket ägs av Roli Ltd. som också själva producerar musikrelaterade mjuk- och hårdvaror.
FAUST (Functional Audio Stream) är ett ljudprogrammeringsspråk som används vid utveckling av3 plugins och andra ljud-applikationer med hjälp av Digital Signal Processing-algoritmer (DSP-algoritmer). FAUST lanserades först år 2002 och går att använda i både Windows, Mac OS X och Linux. Via dess egna kompilator kan FAUST-kod översättas till många olika icke-domänspecifika programmeringsspråk, till exempel C, C++, Java, JavaScript, LLVM bit code, WebAssembly. FAUST är ett språk som medför både fördelarna med ljudprogrammeringsspråk och fördelarna med lågnivåspråk. Det kan därför ses som ett komplement till C++, men är lättare att lära sig ( Orlarey, Fober & Letz, 2009).
1.2 Problembeskrivning
Plugins bearbetar ljud, vilket kan vara svårt att hantera digitalt, och idag finns ett stort utbud av ramverk och ljudprogrammeringsspråk som underlättar detta. De tacklar däremot svårigheterna på olika vis och presterar också olika (Adams & Latulipe, 2013). Denna mångfald beror på det faktum att det finns flera olika sätt att tackla problem på, men bidrar också till oklarheter i vilket av alternativen som presterar bäst i kategorier som exempelvis latency, CPU-belastning och minnesanvändning. Ljudprogrammeringsspråkens gemensamma nämnare är att de vill underlätta utvecklingen och minska inlärningstiden som ofta kan vara lång med lågnivåspråk (Barkati & Jouvelot, 2013; Kollár, Pietriková & Chodarev, 2012). Ljudprogrammeringsspråk har däremot ett tidigare rykte om att vara långsamma och ineffektiva (Orlarey, Fober & Letz, 2009). Lågnivåbaserade ramverk vill istället dra nytta av snabbheten och effektiviteten som lågnivåspråk medför vid exekvering av kod (Ceccon, Thukral, & Eleuterio, 2016). Däremot kan syntaxen upplevas som mer svårtolkad då kodbasen blir större i lågnivåspråk gentemot ljudprogrammeringsspråk.
Latency, CPU-belastning och minnesanvändning är tre oerhört viktiga faktorer att titta på vid utveckling av plugins då de bearbetar ljud i realtid. Latency innebär den tid det tar för ett system att utföra vissa instruktioner och beräkningar. Latency är i denna studie tiden det tar för en plugin att ta emot en digital ljudsignal, bearbeta den och sedan skicka vidare den. Plugins med hög latency ger oftast en dålig användarupplevelse. Detta beror på att hög latency introducerar en tidsfördröjning mellan exempelvis anslag på ett instrument och uppspelning av det genererade ljudet. När
tidsfördröjning blir märkbar påverkar den användaren negativt (Riley, MacLeod, & Libera, 2016). Låg latency går att uppnå med hjälp av bra DSP-algoritmer ( Primavera, Cecchi, Romoli, Peretti, & Piazza, 2014). Latency förklaras mer utförligt i 3.7 Latency.
En stor mängd plugins används ofta samtidigt i en och samma musikproduktion. Detta på grund av att många ljudeffekter i olika kombinationer ofta krävs för att få ett bra resultat. Det här kan leda till hård belastning på datorns RAM och CPU. Det är därför av högsta vikt att varje plugin bidrar minimalt till den totala latencyn och använder datorns resurser effektivt. Detta för att undvika att ljudet blir märkbart fördröjt vid uppspelning eller att den DAW som används inte ska krascha på grund av överbelastning i RAM-minnet. På grund av detta kommer prestanda i denna studie att syfta till latency, CPU-belastning och minnesanvändning.
Eftersom att plugins bearbetar ljud i realtid är det önskvärt att använda det ramverk eller ljudprogrammeringsspråk som levererar bäst prestanda vid utveckling av plugins. Då plugins inte är ett välstuderat område och jämförelser mellan olika ljudprogrammeringsspråk och ramverk är sällsynta, är det svårt att göra ett val baserat på vilket av alternativen som levererar bäst prestanda. Eftersom JUCE är ett C++-ramverk som används av många företag i branschen , men 4 implementationer gjorda i FAUST påstås kunna prestera bättre än implementationer gjorda i C++ (Albouy & Letz, 2017; Orlarey, Fober & Letz, 2009; Orlarey, Fober & Letz, 2011) är det oklart varför företag inte också använder FAUST.FAUST skulle kunna bidra till kortare utvecklingstider då mindre kod behöver skrivas jämfört med i JUCE (Kollár, Pietriková & Chodarev, 2012). FAUST kan även integreras med JUCE om det önskas (Albouy & Letz, 2017). Eftersom prestanda är en avgörande faktor vid utveckling av plugins och oklarheter finns i om JUCE eller FAUST presterar bäst, är en jämförelsestudie mellan dessa högst relevant.
1.3 Syfte och Frågeställningar
I 1.2 Problembeskrivning framgår det att prestanda är en vital faktor när det gäller utveckling av plugins. Vidare framgår det även att det finns en hel del olika ramverk och ljudprogrammeringsspråk som är till för att underlätta utvecklingen på olika sätt, men att det inte är helt lätt att veta vilket som presterar bäst. Denna studie har därför haft i avsikt att titta närmare på JUCE och FAUST med följande syfte:
Att ta fram ett beslutsunderlag för att underlätta val mellan JUCE och FAUST vid utveckling av plugins.
För att kunna besvara syftet har en frågeställning formulerats. Då både JUCE och FAUST är ämnade för att underlätta utveckling av plugins men skiljer sig i hur implementationerna ser ut, kommer studien att undersöka hur de står sig mot varandra prestandamässigt. Därmed är studiens frågeställning följande:
● Hur stor skillnad är det i prestanda (latency, CPU-belastning och minnesanvändning) mellan en plugin utvecklad i JUCE och en utvecklad i FAUST?
För att besvara frågeställningen och därmed uppfylla syftet genomfördes en experimentell studie där två delay-plugins utvecklades och sedan jämfördes.
1.4 Omfång och Avgränsningar
Prestanda är inte den enda parametern som är avgörande vid utveckling av plugins. Underhållning, förbättring och optimering av kod är också aspekter som påverkar utvecklingen och resultatet. I denna studie togs valet att bortse från dessa och endast fokusera på prestanda på grund av studiens tidsbegränsning.
Valet att enbart implementera delays beror till viss del på studiens tidsbegränsning. Det är en simpel effekt som inte kräver en allt för komplex implementation men täcker samtidigt många grundläggande teoretiska byggstenar vid bearbetning av digitala ljudsignaler (Walton, 2014; Malinverno, 2019; Simionato, Liski, Välimäki, & Avanzini, 2018).
Då studien valt att endast beröra ramverket JUCE och ljudprogrammeringsspråket FAUST kan inte resultaten tillämpas eller generaliseras till andra ljudprogrammeringsspråk eller ramverk vars syfte är att bearbeta digitala ljudsignaler.
1.5 Disposition
Kapitel 2 Metod och genomförande beskriver den metod som använts för att besvara studiens frågeställning. Kapitlet visar också hur arbetsprocessen har sett ut.
Kapitel 3 Teoretiskt ramverk beskriver den teori som ligger till grund för denna studie. Detta kapitel går också igenom de fundamentala byggstenarna som krävs för att förstå studiens ämnesområde. Kapitel 4 Empiri ger en översiktlig beskrivning av den empiriska domän som ligger till grund för denna studie.
Kapitel 5 Analys ger svar på studiens frågeställningar genom att behandla insamlad empiri och teoretiskt ramverk.
Kapitel 6 Diskussion och slutsatser ger en sammanfattande beskrivning av studiens resultat. Vidare beskrivs studiens implikationer och begränsningar. Dessutom beskrivs studiens slutsatser och rekommendationer. Kapitlet avslutas med förslag på vidare forskning.
2 Metod och genomförande
Kapitlet ger en översiktlig beskrivning av studiens arbetsprocess och implementation. Vidare beskrivs studiens experiment och de enheter och mätverktyg som använts till detta. Därtill beskrivs studiens mätmetoder, datainsamling och dataanalys. Kapitlet avslutas med en diskussion kring studiens trovärdighet.
2.1 Koppling mellan frågeställning och metod
I denna studie har ett experiment genomförts för att besvara frågeställningen. Tanken med experiment, som involverar data, kod och någon typ av plattform, är att göra mätningar som kan användas som bevis. Experimentet bör testa beteenden som inte tidigare undersökts empiriskt (Zobel, 2014). En experimentell studie ansågs därför som passande då tidigare forskning inte besvarar denna studies frågeställning genom empirisk bevisning. Experimentet genererade i mätbar, kvantitativ, empirisk data som har legat till grund för att kunna besvara studiens frågeställning. En litteraturstudie gjordes för att få en god förståelse för den teori som är relevant för arbetsområdet, vilket också var nödvändig kunskap för att besvara frågeställningen.
2.2 Arbetsprocessen
Arbetet inleddes med att utföra en litteraturstudie där målet var att undersöka och få en översiktlig förståelse för den teori som var relevant för arbetet. Efter avslutad litteraturstudie valdes relevant teori ut som förklarar området studien handlar om. Detta beskrivs i kapitel 3 Teoretiskt ramverk. Efter litteraturstudie och utvald teori gick arbetet över till den praktiska fasen där två plugins utvecklades. Dessa plugins användes sedan i studiens experiment för att generera mätbara data. Denna data bearbetades därefter och jämfördes för att erhålla ett resultat. Resultatet analyserades slutligen och med hjälp av införskaffad teori drogs slutsatser. Arbetsprocessen illustreras i figur 2.
Figur 2. Studiens arbetsprocess
2.3 Experiment
Experimentet gick ut på implementera två plugins, en i JUCE och en i FAUST, och sedan mäta deras prestanda under tre olika testfall som beskrivs i 2.6 Tester. Detta gjordes på tre olika enheter och de valdes för att undersöka hur pluginsen presterar på olika hårdvaror där RAM-minne och typ av processor varierar.
Varje plugins latency mättes med hjälp av en tredjepartsmjukvara vid namn PluginDoctor , och5 beskrivs i 2.7.1 PluginDoctor. CPU-belastning och minnesanvändning mättes med hjälp av Apples egna mjukvara Aktivitetskontroll, och beskrivs i 2.7.2 Aktivitetskontroll. Hur mätningarna utfördes förklaras mer detaljerat i 2.7 Mätmetoder.
2.4 Implementation
Två implementationer har gjorts, en i JUCE och en i FAUST. Dessa har genererat i två delay-plugins med identisk funktionalitet i två olika format vardera - AU och desktop (även kallat standalone). Inställningar som går att ändra på pluginsen är Dry/Wet, Feedback och Delay Time, och beskrivs i
Begreppsdefinitioner. Anledningen till varför formatet AU och inte VST har använts beror på att
experimentet utfördes på tre mac-enheter som beskrivs i 2.5 Enheter. Figur 4 visar den implementation som gjorts i FAUST och genererar i en fullständig plugin med ett GUI. Figur 3 visar den del av implementationen som gjorts i JUCE som bearbetar inkommande ljud. Koden som genererar GUI:t ligger i en annan klass och finns tillgänglig för läsning på GitHub . 6
Figur 4. Hela implementationen av experimentets plugin utvecklad i FAUST
2.5 Enheter
Experimentet utfördes på tre enheter med specifikationer enligt Tabell 1-3 nedanför.
Hårdvara Macbook Pro (13 tum, tidigt 2015)
Operativsystem macOS Mojave version 10.14.6
Processor 2,7 GHz Dual-Core Intel Core i5
RAM 8 GB 1867 MHz DDR3
Grafik Intel Iris Graphics 6100 1536 MB
Hårddisk 250,79 GB Flash
Tabell 1. Beskrivning av den första datorenheten som använts i experimentet
Hårdvara iMac (27 tum, sent 2013)
Operativsystem macOS Catalina version 10.15.3
Processor 3,2 GHz Quad-Core Intel Core i5
RAM 16 GB 1600 MHz DDR3
Grafik NVIDIA GeForce GT 755M 1 GB
Hårddisk 1 TB SATA
Tabell 2. Beskrivning av den andra datorenheten som använts i experimentet
Hårdvara Macbook Pro (13 tum, tidigt 2011)
Operativsystem macOS Sierra version 10.12.6
Processor 2,3 GHz Dual-Core Intel Core i5
RAM 4 GB 1333 MHz DDR3
Grafik Intel HD graphics 3000 384 MB
Hårddisk 320 GB SATA
2.6 Tester
De olika testerna som har tagits fram är till för att simulera verkligheten och göra testerna mer trovärdiga. En svårighet med att definiera tester för en plugin är att musik är en oerhört bred och experimentell domän där både genre och personligt tycke spelar en stor roll (Dannenberg, 2018). Detta skulle kunna resultera i 100-tals olika testfall vilket är orealistiskt för en studie som denna med den tidsbegränsning som finns. Därav bygger parameterinställningarna på pluginen för varje test på en kombination av extremfall och realism för att få en omfattande jämförelse. Tabell 4-6 visar de parameterinställningar som valts för studiens experiment.
Test 1 är ett extremfall eftersom Dry/Wet-inställningen är 0. Detta innebär att ljudsignalen bearbetas men utan att något eko adderas till den. Test 2 är ett realistiskt fall eftersom ett eko adderas till den ingående ljudsignalen. Test 3 är ett extremfall eftersom att endast ekot skickas vidare och att det aldrig kommer att tystas ned.
Test 1 Dry / Wet (%) Feedback (%) Delay Time (ms)
JUCE 0 0 0
FAUST 0 0 0
Tabell 4. Parameterinställningar för test 1
Test 2 Dry / Wet (%) Feedback (%) Delay Time (ms)
JUCE 50 50 500
FAUST 50 50 500
Tabell 5. Parameterinställningar för test 2
Test 3 Dry / Wet (%) Feedback (%) Delay Time (ms)
JUCE 100 100 300
FAUST 100 100 300
2.7 Mätverktyg
Nedan beskrivs de verktyg som har använts vid mätningarna under experimentet.
2.7.1 PluginDoctor
PluginDoctor är en mjukvara som kan öppna plugins och vars syfte är att mäta och analysera dessa. En av PluginDoctors funktionaliteter är att mäta en plugins latency. PluginDoctor gör detta genom att skicka in en kontinuerlig sinussignal i pluginen och mäter hur lång tid det tar för den att bearbeta sinussignalen. Dessa tider är den rådande latencyn mätt i millisekunder och i förhållande till buffertstorlek. Buffertstorleken bestämmer mängden samples från den ingående bufferten som bearbetas åt gången innan de skickas vidare i kedjan. På grund av att denna cykliska bearbetning av den ingående bufferten ihop med hur andra aktiva processer använder datorns resurser kan göra att den rådande latencyn varierar lite mellan cyklerna. Via ett knapptryck i PluginDoctor kan detta skrivas ut till ett textdokument. Figur 5 visar hur PluginDoctor ser ut.
Figur 5. PluginDoctors vy som visar en plugins latency i relation till buffertstorlek
Latencyn som har observerats i textdokumentet är den i relation till buffertstorleken 2048 då detta är den största valbara buffertstorleken i de flesta DAWs. En stor buffertstorlek är önskvärt att ha vid mixning av musik då detta förhindrar oönskade klick och störningar i ljudet under uppspelning. Buffertstorlek förklaras mer ingående i 3.5 Buffertstorlek.
2.7.2 Aktivitetskontroll
Aktivitetskontroll är MacOS egna mjukvara vars syfte är att visa hur aktiva processer använder datorns resurser. Genom Aktivitetskontroll erhålls CPU-belastningen och minnesanvändningen för pluginsen. CPU-belastning visas i procent av enhetens totala processorkapacitet. Minnesanvändning visas i megabytes utav enhetens RAM-minne. Figur 6 visar hur Aktivitetskontroll ser ut.
Figur 6. MacOS inbyggda mjukvara Aktivitetskontroll
2.8 Mätmetoder
Testen utfördes 100 gånger per användningsfall, per plugin och per enhet för att eventuella extremvärden under mätningarna skulle ha en minimal påverkan på de beräkningar som senare gjordes under analysen.
Varje test började med att ladda upp enhetens batteri till 100% för att undvika oförutsedda och ojämna prestationer vid olika batterinivåer. Enhetens internetuppkoppling stängdes av för att undvika att bakgrundsprocesser, som är beroende av en internetuppkoppling, ska vara aktiva och påverka datorns prestationsförmåga, vilket kan leda till felaktiga mätningar. Strömadaptern var inkopplad och endast nödvändiga program var aktiva under alla tester på enheterna. Allt detta säkerställde att alla tester utfördes under bestämda förhållanden på alla enheter för alla testfall. Detta gjordes också för att undvika felmarginaler som kan bero på andra aktiva program och för att batteriet inte skulle påverka datorns prestanda.
2.8.1 Latency
Mätningarna av latency påbörjades genom att först starta upp PluginDoctor och ladda in testpluginen som AU. Sedan ställdes parametrarna på pluginen in utefter det testfall som skulle köras. Som nämnts tidigare så varierar en plugins rådande latency och därefter sparades latencyvärdet ner i ett textdokument via PluginDoctors inbyggda funktionalitet var tionde sekund. Första värdet registrerades tio sekunder efter uppladdning av testpluginen. När 100 värden har registrerats är testfallet färdigt och datan är erhållen.
2.8.2 CPU-belastning
Mätningarna av CPU-belastning påbörjades genom att först starta upp Aktivitetskontroll. Sedan startades testpluginen upp som standalone och parametrarna ställdes in utefter det testfall som skulle köras. Enhetens inbyggda mikrofon plockade upp ljud som bearbetades i testpluginen. Vilken typ av ljudkälla som plockas upp av mikrofonen är obetydlig då allt ljud bearbetas lika i testpluginen. Därefter registrerades CPU-belastningen var tionde sekund. Första värdet registrerades tio sekunder efter uppstart av testpluginen. När 100 värden har registrerats är testfallet färdigt och datan är erhållen.
2.8.3 Minnesanvändning
Mätningarna av minnesanvändning påbörjades genom att först starta upp Aktivitetskontroll. Sedan startades testpluginen upp som standalone och parametrarna ställdes in utefter det testfall som skulle köras. Enhetens inbyggda mikrofon plockade upp ljud som bearbetades i testpluginen. Vilken typ av ljudkälla som plockas upp av mikrofonen är obetydlig då allt ljud bearbetas lika i testpluginen. Därefter registrerades minnesanvändningen var tionde sekund. Första värdet registrerades tio sekunder efter uppstart av testpluginen. När 100 värden har registrerats är testfallet färdigt och datan är erhållen.
2.9 Datainsamling
Enligt de mätmetoder som presenterats i tidigare delkapitel 2.8 Mätmetoder erhölls studiens kvantitativa data och empiri i form av olika typer av mätvärden. Dessa beskrivs i tabell 7 nedan:
Latency CPU-belastning Minnesanvändning
Millisekunder (ms) Procent (%) Megabytes (MB)
Tabell 7. Typer av mätvärden som erhölls från experimentets mätningar
Sammanställning av alla mätvärden gjordes i Google Sheets enligt bilaga 7. Studiens kvalitativa data,
som också står till grund för det teoretiska ramverket, samlades in genom en litteraturstudie.
2.10 Dataanalys
Empirin analyserades med hjälp av beräkningar av medelvärde och standardavvikelse. Det var medelvärdet som användes vid själva jämförelsen och som sedan stod för resultatet. Därefter utfördes en signifikansanalys på den insamlade datan. Om skillnader mellan medelvärdena skulle vara systematiska och fri från slump, resulterar det i en signifikant skillnad. Dataanalysens alla beräkningar utfördes i Google Sheets.
Vid utförande av signifikanstester används två hypoteser, en nollhypotes och en mothypotes. Nollhypotesen är en negation till mothypotesen och står för att det inte är någon systematisk skillnad mellan populationerna som testas. Mothypotesen står för att det finns en systematisk skillnad mellan populationerna som testas. Eftersom denna studie undersökte skillnader mellan JUCE och FAUST innebar nollhypotesen att det inte är några signifikanta skillnader mellan dem. Mothypotesen skulle däremot visa på att signifikanta skillnader existerar mellan dem. Signifikansanalys förklaras mer utförligt i 3.11 Signifikansanalys.
2.11 Trovärdighet
En studies trovärdighet beror på om dess validitet och reliabilitet är höga. En hög validitet kräver att den data som insamlas är relevant och att det som mäts är korrekt. En hög reliabilitet fås genom att utforma en studie som lätt går att återskapa och att de mätningar som framställts är trovärdiga. Då denna studie avser att jämföra prestanda var genomförandet av ett experiment ett självklart val. Enligt Zobel (2014) är experiment rätt metodval i denna studie som nämnts tidigare i 2.1 Koppling
mellan frågeställning och metod. För att stärka validiteten i denna studie har implementationerna gjorts enligt den dokumentation som finns tillgänglig och programmeringen har utförts i par under hela utvecklingstiden för att undvika den mänskliga felfaktorn. Experimentets tester utfördes efter bestämda förhållanden för att undvika fel, vilket ytterligare stärker validiteten men även studiens reliabilitet. Reliabiliteten förstärks ytterligare genom att varje mätning har utförts ett stort antal gånger, att all kod är publik för vem som helst att läsa, att de mjukvaror som har använts som hjälpverktyg är kostnadsfria och att relevant matematisk teori har använts för att tolka resultatet. Det som däremot sänker studiens reliabilitet är att kodbasen inte reviderats av en tredje part.
3 Teoretiskt ramverk
Kapitlet ger en teoretisk grund och förklaringsansats till studien och det syfte och frågeställningar som formulerats.
3.1 Koppling mellan frågeställning och teori
För att ge en teoretisk grund till studiens frågeställning Hur stor skillnad är det i prestanda (latency, CPU-belastning och minnesanvändning) mellan en plugin utvecklad i JUCE och en utvecklad i FAUST? beskrivs följande områden i det teoretiska ramverket: Delay, Latency, JUCE, FAUST, Digitalt ljud, Sample, Buffertstorlek, Standardavvikelse och Signifikansanalys. Delay behandlas för att studien går ut på att utveckla två delay-plugins. Latency behandlas för att det är en viktig del inom ljuddomänen och är även en av tre faktorer som kommer att observeras i studien. JUCE och FAUST behandlas för att det är dessa som kommer att jämföras. Digitalt ljud, Sample och Buffertstorlek beskrivs främst för att ge en bättre förståelse för hur ljud och ljudapplikationer fungerar och vad som bör tänkas på vid utveckling av sådana. Standardavvikelse och Signifikansanalys behandlas eftersom att dessa används under analysen.
3.2 Tidigare forskning
Det finns flera studier där domänspecifika programmeringsspråk jämförs på olika sätt, men även studier som visar på att det kan vara svårt att välja vilka ramverk och språk som bör användas vid utveckling av olika applikationer. Dessa studier och deras resultat är relevanta för denna studie och nämns därför under denna sektion.
Dannenberg (2018) har gjort en jämförelse mellan domänspecifika programmeringsspråk inom musik och deras egenskaper ur ett syntaktiskt och semantiskt perspektiv. I studien är programmeringsspråkens relation till tid i fokus, då musik bygger på en stark relation till just tid. Takt, är exempelvis en tidsbaserad aspekt inom musik och måste tas i beaktning vid utveckling av musik applikationer. Musik och dess relation till tid är teoretiskt enkelt att förstå, men det kan vara svårt att implementera i ett programmeringsspråk. Denna studie visar detta, men frågan är om dessa programmeringsspråk har valt att tumma på prestanda för att få en bättre semantik och syntax i språket? Detta i jämförelse med konventionella och icke domänspecifika programmeringsspråk som C++. Ljudprogrammeringsspråk är begränsade, men FAUST är ett undantag.
Barkati och Jouvelot (2013) jämförde om generella synkrona programmeringsspråk är tillräckliga i jämförelse med mer domänspecifika programmeringsspråk. Denna studie står till grund för att underlätta val av programmeringsspråk vid utveckling av applikationer som hanterar ljud. I studien utvecklades en enkel ljudapplikation vid namn “osc” i olika språk, där FAUST var ett av dem. Barkati och Jouvelot (2013) menar på att en nyckelfaktor för framgång i ett visst mjukvaruprojekt är val av programmeringsspråk. Deras studie fokuserar på programmeringsspråkens likheter och skillnader ur ett designperspektiv. Att göra detta val enbart utefter ett programmeringsspråks design, utan att ta hänsyn till dess prestanda, är inte tillräckligt. Nedan citeras studien vilket visar på att de uppmanar till vidare studier där även prestanda mäts.
It would be interesting to see whether our findings regarding DSLs’ benefits can be leveraged to more complex use case applications. Future work needs also to address the implementation, performance, environment integration, and event management aspects of such a comparison, since these factors are also key in the decisions leading to the choice of a particular language or language paradigm in software projects. ( Barkati & Jouvelot, 2013, s. 31)
Studien uppmanar även till att implementera en delay istället för osc, för att kunna ge mer insikt eftersom det kräver en mer komplex algoritm.
Adams och Latulipe (2013) undersöker och jämför olika verktyg som används vid programmering av ljudapplikationer. Grunden till varför de valde att utföra denna studie beror på att dokumentation kring processen att programmera ljudapplikationer och vilka verktyg som behövs var för dålig. Studiens syfte är därför att till viss del täcka det gap som finns kring detta. Några av de ramverk som jämförs är JUCE, Csound, SuperCollider och ChucK. De element som tittas på vid jämförelserna är prestanda, användbarhet, stöd och support, dokumentation och stöd för utveckling av GUI.
Albouy och Letz (2017) berättar hur FAUST kan vara ett komplement till JUCE. FAUST kan ibland prestera bättre än implementationer gjorda i C++ av rutinerade programmerare. Syftet med deras studie är därför att visa hur FAUST enkelt kan integreras ihop med JUCE för att kunna dra fördelar av ljudprogrammeringsspråket. Det nämns däremot inte i vilka aspekter FAUST presterar bättre i, och därmed inte om latency var en faktor som togs i beaktning.
3.3 Digitalt ljud
Digitalt ljud är ljudsignaler som har kodats i digital form. Det kan också beskrivas som en sekvens av samples (se3.4 Samples) (Dannenberg, 2018). Figur 7 beskriver processen och kan förklaras som att ljud tas upp från en ljudkälla och omvandlas till en analog elektrisk signal. Denna analoga signal görs sedan om till en digital signal med hjälp av ett ljudkort, även kallat en “analog-till-digital-omvandlare”. När ljudet sedan ska spelas upp via högtalare igen görs en digital till analog omvandling istället.
Figur 8 visar den skillnad som är mellan digitalt och analogt ljud. Digitalt ljud är diskontinuerligt medan analogt ljud är kontinuerligt.
Figur 8. Två olika sätt att illustrera en sinusvåg i analogt jämfört med digitalt format
3.4 Sample
Omvandlingen från analog ljudsignal till digital ljudsignal görs med hjälp av sampling. Detta innebär en reducering av en kontinuerlig signal till en diskret signal genom att stycka upp den i en mängd samples. En sample är ett värde vid en viss tidpunkt taget från den kontinuerliga signalen, se figur 9. Med hjälp av alla samples går det sedan att återskapa den originella signalen igen.
Figur 9. Samples representeras som flyttal i en dator
Samplingen sker med hjälp av en A/D-konverterare som tar in den kontinuerliga analoga signalen och gör om den till en diskret digital motsvarighet. Samplingsfrekvensen avgör hur ofta ett sample ska tas och den analoga signalens momentana läge avgör vilket värde samplen får. En vanlig samplingsfrekvens för ljudapplikationer är 48 kHz, vilket innebär en uppstyckning av ljudet där varje sekund innehåller 48 000 samples.
3.5 Buffertstorlek
Buffertstorleken bestämmer hur många samples som ryms i en plugins ljudbuffert. Ljudbufferten är dataströmmen innehållandes de samples som ska bearbetas och/eller spelas upp åt gången av en plugin. En buffertstorlek på exempelvis 2048 samples menas att 2048 samples kontinuerligt bearbetas och spelas upp innan nästa 2048 samples i dataströmmen bearbetas och spelas upp. Störningar kan uppstå vid användning av antingen för stor eller för liten buffertstorlek. Används en för liten buffertstorlek kan det bildas luckor i ljudströmmen vilket resulterar i klick och störningar under uppspelningen. Det beror på att operativsystemet inte hinner fylla på bufferten innan den har tömts. En för stor buffertstorlek kan resultera i en större latency. Det beror på att alla nya manipuleringar av ljudsignalen kommer att läggas i nästa buffert. Används en stor buffert i dessa tillfällen kommer det att märkas tidsmässigt. Problemet med för stor buffertstorlek kan märkas vid ljudinspelning när det blir en markant latency mellan spel på instrument och uppspelning via högtalare.
Plugins får information om hur stor buffertstorleken är från sin “host”, vilket också är den DAW pluginen verkar inom. Figur 10 illustrerar buffertstorlekens betydelse i hur många samples en plugin bearbetar åt gången.
3.6 Delay
Delay är en tidsbaserad ljudeffekt som har en lång historia och har använts i många musikproduktioner. Den är nära besläktad med andra tidsbaserade ljudeffekter som chorus, flanger, phaser och reverb. Delay finns i många olika tappningar men framförallt är det en effekt som i princip alla företag som utvecklar och säljer plugins erbjuder i någon form. Valet av att implementera en delay i denna studie beror på den tidsbegränsning som finns. Det är en simpel ljudeffekt som inte kräver en allt för komplex implementation men täcker ändå många grundläggande teoretiska byggstenar vid bearbetning av digitala ljudsignaler (Walton, 2014; Malinverno, 2019; Simionato, Liski, Välimäki, & Avanzini, 2018). Figur 11 visar flödesschemat för en delay.
Figur 11. Flödesschema för en delay
3.7 Latency
Den latency som denna studie syftar till, är den tid det tar för en plugin att ta emot en signal, bearbeta den och sedan skicka vidare signalen. Figur 12 och 13 illustrerar detta.
Figur 13. Illustration av latency i plugins
3.8 JUCE
JUCE är ett open-source cross-platform ramverk som grundades 2004 och bygger på C++. Ramverket används för att utveckla både desktop och mobila applikationer av hög kvalité. Ofta utformar sig dessa applikationer i form av VST- och AU-plugins eftersom JUCE förser utvecklaren med både GUI och plugin bibliotek avsedda för detta. Många applikationer som utvecklas med hjälp av JUCE används sedan inom musikindustrin.
Som nämnt ovan, förser JUCE användaren med klasser och funktionalitet för GUI och ljud, men även klasser för grafik, XML och JSON-parsning, nätverksapplikationer, kryptografi och multi-threading. Många av dessa element är essentiella vid utveckling av ljud-plugins vilket gör att många använder sig av just JUCE vid utveckling av sådana applikationer. En annan viktig funktion som medförs i JUCE är att när en ljud-plugin byggs, skapas en binärfil som har stöd för de olika plugin-formaten (VST, AU, AAX). På grund av detta kan en utvecklare skapa både Mac och Windows-plugins från en och samma kodbas.
JUCE erbjuder även en mjukvara som kallas Projucer och är till för att underlätta att skapa och hantera JUCE-projekt. När specificeringar för både inställningar och filer gjorts för ett JUCE-projekt, genererar Projucer ett antal tredjepartsfiler för att göra projektet kompatibelt för olika plattformar. Dessa plattformar motsvarar Xcode, Visual Studio, Android Studio, Code::Blocks, CLion och Linux Makefiles. Utöver detta förser även Projucer användaren med en källkodsredigerare, en GUI-editor och en “live coding engine” som kan användas för att snabbt skapa GUI-designs och prototyper.
3.9 FAUST
lanserades år 2002 och går att använda i både Windows, OS X och Linux. FAUST-kod kan sammanställas till flera olika applikationer såsom ljud-plugins, standalone-applikationer och även smartphone- och webbapplikationer.
Den huvudsakliga komponenten i FAUST är dess kompilator. Den medför funktionalitet för att översätta en implementation i FAUST till flera olika icke-domänspecifika programmeringsspråk som C, C++, Java, JavaScript, WebAssembly och flera. FAUST kan ses som ett alternativ till C++ eftersom det kan vara mycket enklare att lära sig FAUST än C++. Detta eftersom kompilatorn översätter koden till C++ och även optimerar koden (Pakarinen, Välimäki, Fontana, Lazzarini & Abel, 2011; Albouy & Letz, 2017; Orlarey, Fober & Letz, 2009; Orlarey, Fober & Letz, 2011).
Kod i FAUST ser ut som en kombination av funktionell programmering och en blockdiagram-syntax. Programmet beskriver en signalprocessor. Ett FAUST-programs struktur är uppbyggt av flera olika definitioner där bland annat nyckelordet “process” kan jämföras med C:s nyckelord “main”.
3.10 Standardavvikelse
Standardavvikelse är ett mått på hur mycket olika värden i en population avviker från medelvärdet. Är det många värden samlade kring medelvärdet innebär det en låg standardavvikelse medan många spridda värden över och under medelvärdet innebär en hög standardavvikelse. Med hjälp av följande formel beräknas standardavvikelse:
σ =
√
1(x
μ)
N
∑
N
i=1 i
−
2Formelns olika variabler står för följande: ● N är antalet mätvärden.
● 𝝁 är medelvärdet av alla mätvärden. ● xi är ett enskilt mätvärde.
● 𝝈 är standardavvikelsen.
3.11 Signifikansanalys
Vid utförandet av en signifikansanalys görs ett test som kallas för T-test som även är en slags hypotesprövning. T-testet innebär att en jämförelse utförs mellan två normalfördelade populationers medelvärden för att se om det finns en signifikant skillnad mellan dem. Värdet som erhålls beskriver förhållandet mellan populationerna och beräknas enligt följande:
t =
x − x
j f√
sj+
2 Nj s f 2 Nf Formelns olika variabler står för följande:● j är JUCE ● f är FAUST ● x är medelvärdet ● s är standardavvikelsen
● t är skillnaden mellan populationerna ● N är storleken på populationen
Utförandet av ett T-test ger ett p-värde vilket ger mer information om analysresultatet. P-värdet visar sannolikheten att observera en skillnad som är minst lika stor som det som observerats. Detta förutsätter även att nollhypotesen är sann. Om p-värdet är mindre än signifikansnivån förkastas nollhypotesen. Är p-värdet 5% eller mindre brukar det kallas för signifikant och innebär att chansen att erhålla andra resultat än det som erhållits är mindre än 5% (Hubbard, Bayarri, Berk & Carlton, 2003). För att få ut p-värdet finns det olika program som automatiskt räknar ut det genom att skriva in information om t-värde, signifikansvärde och frihetsgrad i programmet.
4 Empiri
Kapitlet ger en översiktlig beskrivning av den empiriska domän som ligger till grund för denna studie. Vidare visas empirin som samlats in för att ge svar på studiens frågeställning.
Experimentet i denna studie genererade i en stor mängd data som presenteras i bilaga 7-9. Detta kapitel presenterar en grafisk representation av den insamlade empirin.
4.1 Macbook Pro 2011
Nedan presenteras den insamlade empirin från enheten Macbook Pro 2011. Först presenteras empirin för latency i figur 14-16, sedan empirin för CPU-belastning i figur 17-19 och sist presenteras empirin för minnesanvändning i figur 20-22.
4.1.1 Macbook Pro 2011 - Latency
Figur 14. Insamlad empiri för latency under test 1 utfört på Macbook Pro 2011
Figur 15. Insamlad empiri för latency under test 2 utfört på Macbook Pro 2011
4.1.2 Macbook Pro 2011 - CPU-belastning
Figur 17. Insamlad empiri för CPU-belastning under test 1 utfört på Macbook Pro 2011
Figur 18. Insamlad empiri för CPU-belastning under test 2 utfört på Macbook Pro 2011
4.1.3 Macbook Pro 2011 - Minnesanvändning
Figur 20. Insamlad empiri för minnesanvändning under test 1 utfört på Macbook Pro 2011
Figur 21. Insamlad empiri för minnesanvändning under test 2 utfört på Macbook Pro 2011
4.2 iMac 2013
Nedan presenteras den insamlade empirin från enheten iMac 2013. Först presenteras empirin för latency i figur 23-25, sedan empirin för CPU-belastning i figur 26-28 och sist presenteras empirin för minnesanvändning i figur 29-31.
4.2.1 iMac 2013 - Latency
Figur 23. Insamlad empiri för latency under test 1 utfört på iMac 2013
Figur 24. Insamlad empiri för latency under test 2 utfört på iMac 2013
4.2.2 iMac 2013 - CPU-belastning
Figur 26. Insamlad empiri för CPU-belastning under test 1 utfört på iMac 2013
Figur 27. Insamlad empiri för CPU-belastning under test 2 utfört på iMac 2013
4.2.3 iMac 2013 - Minnesanvändning
Figur 29. Insamlad empiri för minnesanvändning under test 1 utfört på iMac 2013
Figur 30. Insamlad empiri för minnesanvändning under test 2 utfört på iMac 2013
4.3 Macbook Pro 2015
Nedan presenteras den insamlade empirin för enheten Macbook Pro 2015. Först presenteras empirin för latency i figur 32-34, sedan empirin för CPU-belastning i figur 35-37 och sist presenteras empirin för minnesanvändning i figur 38-40.
4.3.1 Macbook Pro 2015 - Latency
Figur 32. Insamlad empiri för latency under test 1 utfört på Macbook Pro 2015
Figur 33. Insamlad empiri för latency under test 2 utfört på Macbook Pro 2015
4.3.2 Macbook Pro 2015 - CPU-belastning
Figur 35. Insamlad empiri för CPU-belastning under test 1 utfört på Macbook Pro 2015
Figur 36. Insamlad empiri för CPU-belastning under test 2 utfört på Macbook Pro 2015
4.3.3 Macbook Pro 2015 - Minnesanvändning
Figur 38. Insamlad empiri för minnesanvändning under test 1 utfört på Macbook Pro 2015
Figur 39. Insamlad empiri för minnesanvändning under test 2 utfört på Macbook Pro 2015
5 Analys
Kapitlet ger svar på studiens frågeställning genom att behandla insamlad empiri och teoretiskt ramverk.
5.1 Medelvärden från latencymätningar
Eftersom en plugins rådande latency varierar och varken den högsta eller lägsta latencymätningen från ett test beskriver hur en plugin presterar över tid, valdes medelvärdet av alla mätningar till det mest rättvisa måttet av en plugins latency.
Medelvärden på latencymätningarna som gjordes under studiens experiment visas i tabell 8-10. Förhållandet mellan JUCE och FAUST beskrivs på tabellernas sista rad. Figur 41-43 visar en grafisk representation av tabellernas medelvärden.
Macbook Pro 2011 Test 1 Test 2 Test 3
JUCE 0,44 0,44 0,45
FAUST 0,09 0,10 0,09
JUCE / FAUST 4,89 4,40 5,00
Tabell 8. Medelvärde i latency mätt i millisekunder på Macbook Pro 2011
Macbook Pro 2015 Test 1 Test 2 Test 3
JUCE 0,37 0,39 0,38
FAUST 0,07 0,07 0,08
JUCE / FAUST 5,29 5,57 4,75
Tabell 9. Medelvärde i latency mätt i millisekunder på Macbook Pro 2015
iMac 2013 Test 1 Test 2 Test 3
JUCE 0,35 0,32 0,34
FAUST 0,06 0,06 0,06
JUCE / FAUST 5,83 5,33 5,67
Figur 41. Medelvärde i latency mätt i millisekunder på Macbook Pro 2011
Figur 42. Medelvärde i latency mätt i millisekunder på Macbook Pro 2015
Figur 43. Medelvärde i latency mätt i millisekunder på iMac 2013
Diagrammen visar tydligt på att FAUST levererar lägre latency än vad JUCE gör på alla 3 enheter under experimentet.
5.2 Medelvärden från CPU-mätningar
Eftersom en plugins rådande CPU-belastning varierar och varken den högsta eller lägsta CPU-mätningen från ett test beskriver hur en plugin presterar över tid, valdes medelvärdet av alla mätningar till det mest rättvisa måttet av en plugins CPU-belastning.
Medelvärden på CPU-mätningarna som gjordes under studiens experiment visas i tabell 11-13. Förhållandet mellan JUCE och FAUST beskrivs på tabellernas sista rad. Figur 44-46 visar en grafisk representation av tabellernas medelvärden.
Macbook Pro 2011 Test 1 Test 2 Test 3
JUCE 3,50 3,52 3,62
FAUST 0,78 0,73 0,73
JUCE / FAUST 4,49 4,82 4,96
Tabell 11. Medelvärde i CPU-belastning mätt i procent på Macbook Pro 2011
Macbook Pro 2015 Test 1 Test 2 Test 3
JUCE 3,47 3,61 3,42
FAUST 0,71 0,70 1,02
JUCE / FAUST 4,89 5,16 3,35
Tabell 12. Medelvärde i CPU-belastning mätt i procent på Macbook Pro 2015
iMac 2013 Test 1 Test 2 Test 3
JUCE 2,68 2,37 2,38
FAUST 0,47 0,47 0,47
JUCE / FAUST 5,7 5,04 5,06
Figur 44. Medelvärde i CPU-belastning mätt i procent på Macbook Pro 2011
Figur 45. Medelvärde i CPU-belastning mätt i procent på Macbook Pro 2015
Figur 46. Medelvärde i CPU-belastning mätt i procent på iMac 2013
Diagrammen visar tydligt på att JUCE belastar CPUn mer än vad FAUST gör på alla 3 enheter under experimentet.
5.3 Medelvärden från RAM-minnesmätningar
Eftersom en plugins rådande minnesanvändning varierar och varken den högsta eller lägsta RAM-minnesmätningen från ett test beskriver hur en plugin presterar över tid, valdes medelvärdet av alla mätningar till det mest rättvisa måttet av en plugins minnesanvändning.
Medelvärden på minnesmätningarna som gjordes under studiens experiment visas i tabell 14-16. Förhållandet mellan JUCE och FAUST beskrivs på tabellernas sista rad. Figur 47-49 visar en grafisk representation av tabellernas medelvärden.
Macbook Pro 2011 Test 1 Test 2 Test 3
JUCE 11,2 11,3 11,3
FAUST 15,0 14,7 16,2
JUCE / FAUST 0,7 0,8 0,7
Tabell 14. Medelvärde i minnesanvändning mätt i megabytes på Macbook Pro 2011
Macbook Pro 2015 Test 1 Test 2 Test 3
JUCE 16,1 16,1 16,1
FAUST 20,2 20,2 20,2
JUCE / FAUST 0,8 0,8 0,8
Tabell 15. Medelvärde i minnesanvändning mätt i megabytes på Macbook Pro 2015
iMac 2013 Test 1 Test 2 Test 3
JUCE 20,3 19,8 17,7
FAUST 22,6 26,6 24,8
JUCE / FAUST 0,9 0,7 0,7
Figur 47. Medelvärde i minnesanvändning mätt i megabytes på Macbook Pro 2011
Figur 48. Medelvärde i minnesanvändning mätt i megabytes på Macbook Pro 2015
Figur 49. Medelvärde i minnesanvändning mätt i megabytes på iMac 2013
Diagrammen visar tydligt på att FAUST använder mer minne i genomsnitt än vad JUCE gör på alla 3 enheter under experimentet.
5.4 Hur stor skillnad är det i prestanda
(latency, CPU-belastning och
minnesanvändning) mellan en plugin utvecklad i JUCE och en utvecklad i
FAUST?
För att besvara studiens frågeställning gjordes jämförelser mellan JUCE och FAUST baserade på latency, CPU-belastning och minnesanvändning. Med hjälp av den insamlade empirin gjordes en signifikansanalys för att se om någon signifikant skillnad finns mellan JUCE och FAUST. Nollhypotesen, vilken är: JUCE = FAUST, kontrolleras med hjälp av p-värdet som genereras genom t-testet. Om nollhypotesen förkastas är mothypotesen sann vilken är: JUCE ≠ FAUST.
5.4.1 Latency
Tabell 17-19 visar resultatetet av de signifikansanalyser som gjorts på experimentets insamlade data från mätningar av latency. Det låga resulterande p-värdet för alla tester och på experimentets alla enheter visar på att nollhypotesen kan förkastas. Detta innebär att det är en skillnad i latency mellan JUCE och FAUST.
Macbook Pro 2011 Test 1 Test 2 Test 3
t-värde 35,8 33,4 33,6
p-värde 2,73×10^−63 9,94×10^−71 2,52×10^−58
Resultat p < 0.05 p < 0.05 p < 0.05
Tabell 17. Signifikansanalys av latency på Macbook Pro 2011
Macbook Pro 2015 Test 1 Test 2 Test 3
t-värde 37,8 30,9 31,1
p-värde 5,57×10^−66 1,20×10^−54 3,08×10^−65
Resultat p < 0.05 p < 0.05 p < 0.05
Tabell 18. Signifikansanalys av latency på Macbook Pro 2015
iMac 2013 Test 1 Test 2 Test 3
t-värde 48,7 39,8 30,3
5.4.2 CPU-belastning
Tabell 20-22 visar resultatetet av de signifikansanalyser som gjorts på experimentets insamlade data från mätningar av CPU-belastning. Det låga resulterande p-värdet för alla tester och på experimentets alla enheter visar på att nollhypotesen kan förkastas. Detta innebär att det är en skillnad i CPU-belastning mellan JUCE och FAUST.
Macbook Pro 2011 Test 1 Test 2 Test 3
t-värde 347,0 205,7 277,2
p-värde 4,06×10^−176 3,65×10^−138 2,12×10^−163
Resultat p < 0.05 p < 0.05 p < 0.05
Tabell 20. Signifikansanalys av CPU-belastning på Macbook Pro 2011
Macbook Pro 2015 Test 1 Test 2 Test 3
t-värde 316,2 297,3 262,9
p-värde 5,25×10^−260 2,55×10^−239 1,51×10^−254
Resultat p < 0.05 p < 0.05 p < 0.05
Tabell 21. Signifikansanalys av CPU-belastning på Macbook Pro 2015
iMac 2013 Test 1 Test 2 Test 3
t-värde 247,8 175,8 277,3
p-värde 8,00×10^−226 1,61×10^−182 3,16×10^−235
Resultat p < 0.05 p < 0.05 p < 0.05
5.4.3 Minnesanvändning
Tabell 23-25 visar resultatetet av de signifikansanalyser som gjorts på experimentets insamlade data från mätningar av minnesanvändning. Det låga resulterande p-värdet för alla tester och på experimentets alla enheter visar på att nollhypotesen kan förkastas. Detta innebär att det är en skillnad i minnesanvändning mellan JUCE och FAUST.
Macbook Pro 2011 Test 1 Test 2 Test 3
t-värde −1199,4 −1429,1 −494,1
p-värde 2,81×10^−247 3,55×10^−215 5,17×10^−219
Resultat p < 0.05 p < 0.05 p < 0.05
Tabell 23. Signifikansanalys av minnesanvändning på Macbook Pro 2011
Macbook Pro 2015 Test 1 Test 2 Test 3
t-värde −452,1 −472,5 −1302,7
p-värde 3,45×10^−215 6,99×10^−274 1,08×10^−260
Resultat p < 0.05 p < 0.05 p < 0.05
Tabell 24. Signifikansanalys av minnesanvändning på Macbook Pro 2015
iMac 2013 Test 1 Test 2 Test 3
t-värde −111,1 −428,2 −2256,2
p-värde 5,05 × 10^−254 7,32×10^−213 2,62×10^−284
Resultat p < 0.05 p < 0.05 p < 0.05
5.5 Sammanfattning
Studiens experiment visar på tydliga skillnader i resultatet och att signifikansanalysen därför inte varit nödvändig. Trots detta utfördes signifikansanalyserna som planerat och i kombination med den stora mängd utförda mätningar genererade det i stora t-värden och små p-värden. Då p-värdet är ett mått på hur extremt ett resultat är säger denna studies signifikansanalys att det är extremt tydligt att det är skillnader mellan FAUST och JUCE i frågan om latency, CPU-belastning och minnesanvändning (Hubbard, Bayarri, Berk & Carlton, 2003).
Med hjälp av förkastad nollhypotes från utförd signifikansanalys och resultat från experimentet kan studiens frågeställning besvaras. För att ge frågeställningen ett generellt svar har den valts att besvaras med förhållandet mellan JUCE och FAUSTs prestationer under experimentet. Enligt studiens resultat ger FAUST i genomsnitt minst 4,40 gånger mindre latency än JUCE. FAUST belastar även datorns CPU i genomsnitt minst 3,35 gånger mindre än JUCE. Däremot använder JUCE i genomsnitt minst o,7 gånger av vad FAUST använder i RAM-minne.
Testerna i det utformade experimentet visade sig inte ge några större skillnader i resultat. Parameterinställningarna på pluginsen påverkar inte prestandan olika mycket, vilket tyder på att de utvecklade pluginsens prestation är oberoende av parameterinställningarna.
6 Diskussion och slutsatser
Kapitlet ger en sammanfattande beskrivning av studiens resultat. Vidare beskrivs studiens implikationer och begränsningar. Dessutom beskrivs studiens slutsatser och rekommendationer. Kapitlet avslutas med förslag på vidare forskning.
6.1 Resultat
Insamlad empiri från experiment ihop med den analys som gjorts har visat på ett tydligt resultat. Resultatet visar att tidigare forskning, som säger att FAUST presterar bättre än JUCE i prestanda (Albouy & Letz, 2017), delvis stämmer. FAUST levererar lägre latency och belastar datorns CPU mindre men kräver mer RAM-minne än vad JUCE gör. Resultatet besvarar studiens frågeställning och uppfyller även dess syfte.
Utvecklingen av pluginsen har visat på en tydlig skillnad i storlek på kodbasen mellan JUCE och FAUST. Detta indikerar att det tar längre tid att implementera i JUCE, vilket har varit fallet i denna studie. Detta tyder även på att inlärningstiden är längre i lågnivåspråk jämfört med ljudprogrammeringsspråk, vilket stämmer överens med vad tidigare forskning säger (Kollár, Pietriková, & Chodarev, 2012).
Studiens resultatet går även att koppla till Adams och Latulipes (2013) tidigare forskning där de jämför olika språk och verktyg för utveckling av ljudapplikationer. De har dock inte tagit med FAUST i jämförelsen men många andra ljud-programmeringspråk istället. Deras resultat visar på att de flesta ljudprogrammeringsspråk presterar bättre än JUCE vilket även till viss del har bevisats i denna studies resultat.
6.2 Implikationer
Studiens syfte har uppfyllts då resultatet som presenterats kan användas som underlag för val mellan JUCE och FAUST vid utveckling av plugins. Även om JUCE underlättar GUI-utveckling, vilket FAUST är sämre på, har denna studie visat att FAUST är ett bra alternativ när ett snabbt resultat önskas då utvecklingstiden är kortare. Denna studie visar att tidigare forskning om att FAUST kan prestera bättre än implementationer gjorda i C++ stämmer. Tidigare forskning säger däremot inte på vilket sätt FAUST presterar bättre. Denna studie har därför bidragit med tydligare resultat kring frågan genom att ha jämfört latency, CPU-belastning och minnesanvändning.
6.3 Begränsningar
Den tidsbegränsning som har varit under studien har lett till att endast JUCE och FAUST har jämförts. Att ha med flera olika språk i jämförelsen hade varit intressant då det hade kunnat resultera i ett ännu bredare beslutsunderlag vid val av ramverk och programmeringsspråk för utveckling av plugins. Tidsbegränsningen har även lett till att endast en delay har utvecklats medans det hade varit intressant att utveckla och testa flera olika ljudeffekter med mer komplexitet som till exempel kompressorer, equalizers och reverbs.
En ytterligare begränsning är att koden inte reviderats av en tredje part. Detta hade kunnat resultera i en mer optimerad kod vilket hade kunnat ge ett annat resultat. Detta hade dock mest varit av intresse för utveckling av JUCE-pluginen eftersom FAUSTs kodbas redan är liten och det finns inte mycket att optimera.
6.4 Slutsatser och rekommendationer
Studien uppfyller sitt syfte och besvarar studiens frågeställning. Baserat på latency och CPU-belastning är FAUST ett bättre alternativ än JUCE. Baserat på minnesanvändning är däremot JUCE det bättre alternativet. FAUST har i både denna studie och tidigare forskning bevisat att ljudprogrammeringsspråk kan leverera hög prestanda. Företag borde vidga sina vyer och ta ljudprogrammeringsspråk som FAUST på allvar då de kan leverera effektiva algoritmer för att bearbeta ljud. En rekommendation till företag som bara använder JUCE är att testa FAUST för att ta fram prototyper. Eftersom utveckling i FAUST innebär en mindre kodbas kan nya koncept och idéer testas mycket snabbare (Dannenberg, 2018; Larkin, 2018). Vidare kan dsp-algoritmerna utvecklas i FAUST men finslipas i JUCE där också GUI-utveckling borde ske på grund av dess flexibilitet.
Rekommendationer för när JUCE respektive FAUST bör användas beskrivs i de två listorna nedan: Använd JUCE när:
● Full kontroll över koden önskas. ● Implementering av ett eget GUI önskas. ● Låg minnesanvändningen önskas. ● Förenklat underhåll av projekt önskas. Använd FAUST när:
● En kort inlärningskurva önskas.
● Ett snabbt resultat önskas på grund av kort utvecklingstid.
● Högpresterande plugins vad gäller latency och CPU-belastning önskas.
En slutsats som enkelt går att dra genom att titta på mängden utförda mätningar ihop med experimentets extremt tydliga resultat är att onödigt många mätningar utfördes i studiens experiment. Signifikansanalysens betydelse i analysstadiet förminskades på grund av detta. De olika testfallen som togs fram visade sig också inte bidra till resultatet. Förslagsvis kunde en bypass-funktionalitet ha utvecklats för att visa på skillnader när pluginen är aktiv och inaktiv istället för att ändra på parameterinställningarna.
Även om skillnaderna mellan FAUST och JUCE är signifikanta är de ändå väldigt små. I relation till varandra stämmer studiens resultat, men fler alternativ måste tas i beaktning för att ge en verklig bild.
6.5 Vidare forskning
Den mest självklara rekommendationen för vidare forskning inom studiens ämnesområdet är att utföra en liknande studie men med en mer komplex implementation. Förslag på implementationer är en synthesizer, kompressor eller modulering av ett fysiskt existerande instrument. Det hade också varit intressant att se om JUCE och FAUST presterar likadant på Windows-och Linux-baserade datorer. Då hade också ett annat plugin-format krävts (VST) vilket hade gett denna studie en motpart. Det finns en uppsjö av både ramverk och ljudprogrammeringsspråk som tidigare nämnts, vilket skapar goda grunder för fler jämförelsestudier av denna sort. En mer kvalitativ studie där utvecklingstider i olika ramverk och ljudprogrammeringsspråk mäts och sätts i relation till ljudkvalité hade däremot kunnat bygga vidare på det beslutsunderlag som denna studie har bidragit med. Ur ett mer musikproduktionsmässigt perspektiv hade tester på kommersiella plugins varit av hög relevans. Mätningar av latency, CPU-belastning och minnesanvändning hade även här kunnat göras för att se om olika företag levererar olika bra mätvärde på sina produkter. Detta är något som
potentiellt skulle kunna förändra synen på vissa företag på marknaden och till och med påverka försäljningssiffrorna på marknaden.
Vidare hade det även varit intressant att testa flera olika kombinationer av RAM-minne och processor för att se om vissa kombinationer presterar bättre än andra. Detta genom att testa flera plugins samtidigt för att undersöka om varje plugin kräver mer minne eller om det fortfarande kommer att hållas konstant. Samtidigt går det att kolla om en snabbare CPU överlag gör att det går snabbare eller om det är minnet som har den större begränsningen på prestandan. Vidare skulle detta kunna leda till ett förslag på den billigaste lämpliga datorn för musikproduktion. Detta skulle bidra till att musikproducenter inte köper onödigt dyr utrustning som inte går att utnyttja maximalt.
