Demonstration af 3D lyd. Networks and Distributed System 3. semester af Mads Vejlø

Demonstration af 3D lyd Networks and Distributed System 3. semester af Mads Vejlø?

Institut for Elektroniske Systemer Fredrik Bajers Vej 7 DK-9220 Aalborg Ø http://es.aau.dk Titel: Demonstration af 3D lyd Tema: Projektorienteret forløb i en virksomhed Projektperiode: 3. semester Networks and Distributed Systems September December, 2013 Projektgruppe: 13gr925 Deltager(e): Mads Holdgaard Vejlø Vejleder(e): Jimmy Jessen Nielsen Oplagstal: 3 Sidetal: 55 Afleveringsdato: 10. Januar 2014 Abstract: Denne rapport beskriver undertegnedes praktikforløb hos virksomheden AM3D A/S. Formålet med praktik opholdet har været at udvikle et systmet beregnet til at demonstrere virksomhedens 3D engine som kan lave en almidelige stereo eller mono lydkilde om til en retningsbestemt lydkilde. Demonstrationen er blevet realiseret ved at udvikle en Android applikation der, ud fra et walkie-talkie princip, er i stand til at sende lyd trådløst fra én ad gangen til de andre enheder. Demonstrationen foregår på tre Nexus 7 Android tablets. Til hver enhed er der tilsluttet et headset samt et motion tracking board, som måler, hvilken retning brugeren af den enkelte enhed peger i. Når der trykkes på en Push-To- Talk knap på de enkelte enheder sender de det lyd de optager via headsets mikrofon sammen med en GPS position til de andre enheder. Hos modtageren bruges GPS positionen fra afsenderen samt modtagerens egen GPS position til at beregne en relativ retning til afsenderen i forhold til den retning modtager peger i, som udlæses via motion tracking boardet. Disse beregnede data bruges til at omdanne det modtagede lyd til en retningsbestemt lydkilde som afspilles i det tilsluttede headset. Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfattern.

Forord Denne rapport afspejler hovedparten af det arbejde der er blevet udført i forbindelse med praktikforløbet. Det vil dog være dele af arbejdet som ikke bliver beskrevet i rapporten. Rapporten forsøger derfor at give et overblik over hele systemet, men giver kun detaljeret information omkring specifikke emner af det udførte arbejde. I rapportens bilag findes den praktik aftale der har dannet grundlag for praktikopholdet, samt en udtalelse fra AM3D om praktikforløbet. Der gives en særlig tak til AM3D A/S som har stillet en praktikplads til rådighed, samt al det fornødne harware i forbindelse med projektet. Aalborg University, 10. Januar 2014 Mads Holdgaard Vejlø <mvejlo09@student.aau.dk> v

Indhold 1 Introduktion 1 1.1 AM3D....................................... 1 1.2 Arbejdsopgaver.................................. 2 1.3 Use case...................................... 2 1.4 Krav og ønsker til systemet fra virksomheden................. 3 1.4.1 System design overordnet........................ 5 2 Netværk 7 2.1 Analyse...................................... 7 2.1.1 Hvad er Wi-Fi-Direct?.......................... 8 2.2 Design og Implementering............................ 9 2.2.1 Netværksopsætning........................... 9 2.2.2 Routing.................................. 15 2.2.3 Push-To-Talk lås............................. 18 3 Lydprocessering 21 3.1 Analyse...................................... 21 3.1.1 Zirene 3D................................. 21 3.1.2 Lyd processerings forsinkelse i Android................. 22 3.2 Design og Implementering............................ 23 3.2.1 Optagelse................................. 24 3.2.2 Afsendelse................................. 26 3.2.3 Modtagelse................................ 27 3.2.4 Rendering................................. 28 3.2.5 Afspilning................................. 30 4 Test og Evaluering 33 4.1 Case 1 - Buffer kø til afspilnings kø....................... 33 4.2 Case 2 - TX tider for en og to klienter..................... 39 5 Konklusion 45 Litteratur 47 A Praktik aftale og udtalelse fra AM3D 49 vi

Kapitel 1 Introduktion 1.1 AM3D Praktikforløbet har foregået hos virksomheden AM3D A/S 1 under ledelse af Clemen Boje Larsen, som er chef udvikler i virksomheden og ansvarlig for forskning og udvikling i virksomheden. AM3D specialiserer sig i digital signal behandling inden for fire områder; Mobile devices, In-car entertainment systems, Home entertainment og Mission critical (militæret). Inden for disse fire områder har AM3D to produkter; Audio Enhancement og 3D Audio. 3D audio er virksomhedens primære produkt, men markedet for 3D lyd er lille og virksomheden har derfor været nødt til at udvikle Audio Enhancement løsninger for at kunne overleve. Virksomheden startede i 1997 med kommercielt at udvikle dets 3D engine og fik i 2000 sin første kontrakt med militæret. AM3D er ejet af Nordjyske Holding A/S 2 og hører under den afdeling der kaldes Nordjyske Kommunikation A/S. Hovedkvarteret for AM3D er her i Aalborg, hvor al produkt udvikling sker og hvor alle dets ingniørerer befinder sig. Virksomheden består af omkring 12 ingniørerer som står for udvikling og vedligeholdelse af firmates produkter. Der ud over har virksomheden et ukendt antal sælgere, fordelt på de forskellige afdelinger af virksomheden. Virksomheden har afdelinger til dets sælgere i Syd Korea, Japan og USA, samt sælgere spredt ud over det meste af Asien. Dette skyldes at virksomheden satser på at få solgt deres produkter til de større asiatiske elektronik giganter samt det amerikanske militær og amerikanske elektronik giganter. 1 http://www.am3d.dk/ 2 http://www.nordjyskeholding.dk/ 1

2 Kapitel 1. Introduktion 1.2 Arbejdsopgaver Den primære arbejdsopgave i forbindelse med praktikken bliver at designe og implementere det system der er beskrevet med use casen i afsnit 1.3 samt system beskrivelsen i afsnit 1.4. Dette er også hvad der er blevet indgået aftale om, forud for praktikken, se bilag A.1. Fokus for praktikforløbet er på at få designet og implementeret de tekniske dele af systemet, herunder netværks og lydprocesserings delene, samt de forskellige interfaces der måtte være til andre eksterne hardware enheder. Bruger interfacet til systemet udvikles i samarbejde med en ansat ved virksomheden som primært vil stå for at implementere bruger interfacet. Derudover vil projektet indeholde en performance analyse af det endelige system, med fokus på forsinkelser i systemet. Table 1.1 giver en oversigt over arbejdsfordelingen i forbindelse med projektet. To af punkterne i tabellen er opgaver som er delt imellem Mads (praktikanten) og virksomheden. Dette skyldes, for lyd renderings delen, at det er virksomhedens Zirene 3D produkt der skal anvendes i forbindelse med renderingen og der derfor arbejdes sammen med virksomheden i forhold til at få integreret denne del i systemet. Det andet delte punkt er udlæsning af retnings data, hvor virksomheden står at få hul igennem et bestemt board der er belvet indkøbt til projektet, mens praktikanten står for at integrere dette i systemet Det sidste punkt i tabellen står virksomheden primært for, da den har anstatte som er vant til at designe GUIs på Android platformen, samt har adgag til bestemte grafiske elementer som virksomheden gerne vil have til at ingå i GUI delen af systemet. Opgave Netværksløsning Lyd streaming Lyd processering Lyd rendering Udlæsning af retnings data GUI Ansvarlig Mads Mads Mads Mads og AM3D Mads og AM3D AM3D Tabel 1.1: Oversigt og arbejdsfordelingen i projektet. 1.3 Use case I dette afsnit vil den use case, som AM3D gerne vil have demonstreret, blive beskrevet. Når soldater er i by-kamp, dvs. i områder med tæt bebyggelse, kan de ikke nødvendigvis se hinanden, primært pga. bygninger og andre forhindringer. De er dog i kontakt med hinanden via radio, men radioen bidrager ikke til at give den enkelte soldat en fornemmelse af, hvor de andre soldater befinder sig, i forhold til ham selv. Det at en soldat ikke ved hvor en eller flere af hans med-soldater befinder sig kan skabe farlige situationer, hvor soldater

1.4. Krav og ønsker til systemet fra virksomheden 3 på samme side ender med at beskyde hinanden eller hvor ens egne soldater bliver fanget i krydsilden når en fjende beskydes. Figur 1.1 viser, hvordan der kan opstå situationer, hvor soldater ikke altid kan se hinanden i et bebygget område. Figur 1.1: Line-of-sight eksempel En måde at undgå dette problem på, er hvis soldaterne, ved hjælp af deres radioer, kan få en indikation af, hvorhenne på slagmarken deres med-soldater befinder sig, når soldaterne kommunikere med hinanden via radio. Det vil sige at når soldat B siger noget i sin radio, så vil det ved soldat A blive afspillet i hans hovedtelefoner, således at han kan høre i hvilken retning, i forhold til sig selv, at B befinder sig. 1.4 Krav og ønsker til systemet fra virksomheden Formålet med systemet er at demonstrere virksomhedens Zirene 3D produkt, som er et 3D renderings bibliotek som kan omdanne en standard mono eller stereo lydkilde til en retningsbestemt lydkilde. For at kunne rendere en lydkilde i 3D, skal Zirene 3D bruge en position for både sender og modtager, samt den retning modtager peger i. Disse data gives som input til Zirene 3D sammen med lyden fra senderen der skal renderes. Resultatet af renderingen er stereo lyd der kan afspilles i hovedtelefonerne på modtageren, således at han igennem den afspillede lyd kan høre, hvor senderen af lyden befinder sig, relativt til hans egen position og retning. Lige bortset fra 3D renderingen af lyden, skal det udviklede system udføre den samme opgave som walkie-talkier gør, da det er dette scenarie demonstrationen skal illustrere, jævnfør use casen. Når to eller flere enheder er på samme frekvens eller forbundet skal de kunne kommunikerer med hinanden. Det skal kun være muligt for én enhed at sende lyd til de andre enheder af gangen, hvilket vil blive betegnet som et Push-To-Talk koncept.

4 Kapitel 1. Introduktion Desuden skal det være et P2P basseret system, hvor enheder kan forbinde til hinanden uden noget central access point (AP) eller radio mast, ligesom med walkie-talkier. Virksomheden har oplyst at det i praksis ikke er muligt at komme til at udvikle systemet ved hjælp af den radio teknologi militæret anvender. Derfor er der forud for praktikken blevet truffet en række beslutninger angående det system der skal udvikles: Udviklings platformen skal være Android, da det er virksomhedens primære udviklings platform og den platform som deres eksisterende demonstrationer af andre produkter køre på. Udviklingen skal ske på en af de såkaldte Nexus enheder. Nexus serien består af både telefoner og tablets lavet af forskellige producenter på vejne af Google. Det er blevet valgt at udviklingen skal ske på Nexus 7 (2013) som er den nyeste tablet i Nexus serien. Som tidligere beskrevet kræver Zirene 3D både positioner og retninger. Virksomheden ønsker derfor at anvende GPS til positionerne, da alle Nexus enheder er udstyret med GPS. Hvad retning angår, så skal der anvendes en chip kaldet MPU-9150 fra firmaet Invensense 3. Chippen er hvad firmaet kalder en 9-axet MotionTracking enhed og består i sin enkelthed af et gyroskop, et accelerometer og et kompas. Chippen er monteret på et board med en MSP 430 microcontroller, et Bluetooth modul og en micro-usb port til udlæsning af sensor data. På MSP en køre der software udviklet af Invensense, som foretager kalibrering af sensorerne, samt laver sensor fusion for at opnå højere stabilitet og bedre præcision af sensor dataene. Dette board er blevet indkøbt af virksomheden forud for praktikken. Der skal anvendes headsets med mikrofoner i demonstrationen, da det ikke er muligt at opleve 3D renderingen på højtalere og for bedre at kunne optage brugernes tale. Desuden har virksomheden fremstillet det ønske til systemet, at det skal være nemt at transportere og opstille i forbindelse med demonstrationer, dvs. at systemet gerne skal være uafhængigt af APs og lignende, da det skal anvendes udendørs pga. GPS. Dog vil de gerne have muligheden for at kunne anvende APs på et senere tidspunkt. Demonstrationer af systemet kommer til at foregå udendørs, på hvad der formodentlig vil være en parkerings plads eller et lignende areal. I forhold til demonstrationen vil det være optimalt hvis den kan foregå således at deltagerne ikke kan høre hinanden andet end gennem deres headsets, for at give en bedre oplevelse af 3D renderingen af lyden. En rækkevidde på 30-50 meter for systemet er derfor påkrævet. Hvad systemets størrelse angår, så skal det designes til at understøtte 3 enheder som minimum, gerne med mulighed for at anvende flere enheder på sigt. En vigtig parameter, der kommer til at have stor indflydelse på systemet, er forsinkelse i forhold til lyden. Det er vigtigt at forsinkelsen fra at et stykke lyd er blevet optaget på en enhed til det bliver afspillet på en anden enhed holdes lav for at undgå den ekko effekt 3 www.invensense.com

Device 2 Device 1 1.4. Krav og ønsker til systemet fra virksomheden 5 der ellers vil være når ham der taler står tæt på ham der skal modtage og afspille lyden. Desuden er det også vigtigt at forsinkelsen fra et stykke lyd bliver renderet med Zirene 3D til det bliver afspillet holdes så lavt som muligt. Ellers vil brugeren opleve at lyden sejler for ørene af ham, når han drejer sit hoved, da lyden vil være renderet ud fra hans hoved i en bestemt retning, hvor efter han når at dreje hovedet inden lyden bliver afspillet. 1.4.1 System design overordnet Da forsinkelse komme til at spille en stor rolle i det system der skal designes er det tidligt i udviklingsforløbet blevet besluttet at den Android applikation der skal udvikles skal deles op i to dele. Den ene del bliver lavet i Java og kommer til at stå for alt det GUI relaterede i applikationen. Den anden del skal laves i C og skal håndtere alt hvad der relatere sig til lyd processeringen i systemet. Denne opdeling er valgt, da det programmerings teknisk er mere fordelagtigt at styre alt det GUI relaterede fra Java kode af. Der er heller ikke specielle krav til GUIen i forhold til forsinkelse, og afbrydelser af Javas garbage colleceter kommer ikke til at påvirker oplevelsen af 3D renderingen. Lyd processeringen derimod er meget følsom i forhold til forsinkelser, derfor laves den i C, udenfor den virtuelle maskine der afvikler Java kode, for at undgå uforudsete afbrydelser af garbage colleceteren. Desuden opnås der en større friheds grad i forhold til at designe optage og afspilnings processerne i C versus Java, da man har mulighed for at arbejde med betydeligt mindre buffer størrelser, altså hvor mange samples der skal optages og afspilles på en gang, i C frem for i Java. Lyd processeringen vil blive diskuteret yderligere i kapitel 3. Med udgangspunkt i use casen og de krav og ønsker virksomheden har stillet til systemet, kan systemet vist i figur 1.2 opstilles. User input Position data Push-To-Talk Record audio Prepare audio for transmission Transmit audio Receive audio Prepare audio for rendering Render audio Play audio Position and heading data Figur 1.2: Oversigt over de nødvendige dele af systemet.

6 Kapitel 1. Introduktion Som det ses på figuren er der to naturlige dele af systemet. Den ene del sker på enhed 1 og omhandler optagelse og afsendelse af data, mens den anden del sker på enhed 2 og omhandler modtagelse, rendering og afspilning af lyden. I de følgende kapitler vil disse dele af systemet blive analyseret og designet.

Kapitel 2 Netværk 2.1 Analyse Netværks delen af systemet skal først og fremmest stå for at forbinde de forskellige androidenheder i systemet, således at de kan kommunikere med hinanden. Dernæst skal netværket bruges til at transportere data mellem de forskellige androidenheder. Nedenfor ses en oversigt over, hvilke data der skal overføres: Lyd Meta-data Kontrol Det data der skal sendes består primært af optaget lyd, fra den tilsluttede mikrofon på en enhed. Meta-dataene der skal sendes, består af GPS data, som skal bruges til 3D renderingen på modtagerens side. Kontrol dataene vil primært dække over den Push-To-Talk lås der skal eksistere i systemet, for at der kun er en bruger der kan sige noget af gangen, ligesom med walkie-talkier. Designet af denne lås vil kort blive beskrevet under designet af netværksdelen i afsnit 2.2.3. Den valgte Android enhed (Nexus 7) er udstyret med Bluetooth 4.0, Wi-Fi og en forholdsvis ny standard kaldet Wi-Fi-Direct, som gør Wi-Fi basserede enheder i stand til at forbinde til hinanden uden et fysisk AP. Da virksomheden ønsker en løsning der er P2P basseret som udgangspunkt, men med mulighed for regulær Wi-Fi support senere, vil det være upraktisk at vælge at basere systemet på Bluetooth, da det vil kræve større ændringer i systemet når Wi-Fi skal understøttes, både i forhold til at forbinde enhederne, såvel som måden enhederne kommunikerer på med hinanden. Derfor vælges Wi-Fi-Direct som den anvendte netværksteknologi, på trods af at det adskiller sig fra Wi-Fi i måden der oprettes forbindelse på. Derimod er der ikke forskel 7

8 Kapitel 2. Netværk på Wi-Fi-Direct og Wi-Fi når først der er oprettet forbindelse, dvs. at begge teknologier giver mulighed for at anvende standard sockets til at kommunikere. 2.1.1 Hvad er Wi-Fi-Direct? Wi-Fi-Direct er en ny Wi-Fi standard fra Wi-Fi Alliance 1 som gør det muligt at forbinde enheder der understøtter standarden med hinanden uden et fysisk AP. I følge Wikipedia [2014] og Alliance [2014] kan Wi-Fi-Direct fungere på flere forskellige måder: Standard måden, hvor en række enheder, som alle understøtter Wi-Fi-Direct opretter en P2P gruppe og selv aftaler hvem der skal være Group Owner (GO). GO opretter et soft-ap, software defined access point, som de andre enheder, nu kaldet klienter forbinder til, for at blive en del at gruppen. Valget af GO sker på baggrund af en enheds ønske og evner til at udføre rollen. Wi-Fi Direct kan også fungere i en på en måde, hvor en bestemt enhed tildeler sig selv rollen som GO og derved starter en P2P gruppe uden andre medlemmer. Andre Wi-Fi- Direct enheder eller almindelige Wi-Fi enheder kan nu forbinde hertil, som var det et regulært AP. Denne metoder giver derved enheder som ikke understøtter Wi-Fi-Direct mulighed for at være med i en P2P gruppe. En GO enhed vil broadcaste sit SSID, som et regulært AP vil gøre det. GO enheden vil også have en DHCP-server kørende som står for at tildele IP adresser til nye enheder der forbinder til GO enheden. GO enheden ikke har mulighed for at tilgå DHCP-serveren og derved IP adresserne på dens tilsluttede klienter. Tilgengæld kender alle klienter IP adressen på GO enheden. Det betyder at der som udgangspunkt kun er mulighed for envejs kommunikation, fra klient til GO enheden. Wi-Fi-Direct er designet til at være et en-til-en netværk, eller et en-til-mange netværk, afhængigt af hvordan det sættes op, men det vil under alle omstændigheder altid anvende en centraliseret netværks topologi. En central topologi er ikke den mest oplagte topologi til systemet, da der skal sendes mange-til-mange, dvs. når der bliver talt i mikrofonen på en enhed skal den optagede lyd sendes til alle andre enheder i systemet, hvilket svare til hvad et ad-hoc netværk er designet til. Ved at anvende en centraliseret topologi skal det overvejes, hvordan trafikken routes for at undgå for stort et overhead i form af ekstra netværks hop. Yderligere kan det nævnes at Wi-Fi-Direct burde kunne opnå de samme overførsels hastigheder som almindelige Wi-Fi, dvs. hastigheder på optil 250[Mb/s] og at rækkevidden også burde være den samme på op til 200[m] [Alliance, 2014]. Det forventes dog langt fra at disse værdier kan opnås på Android enheder pga. deres antenner og begænsninger i forhold til batteri-levetid, men både overførselshastigheder og rækkevidde burde dog ikke blive noget problem. I det følgende afsnit vil designet af netværket blive beskrevet. 1 http://www.wi-fi.org/news-events/newsroom/wi-fi-alliance%c2%ae-announcesgroundbreaking-specification-to-support-peer-to-peer

2.2. Design og Implementering 9 2.2 Design og Implementering Netværksdelen af systemet står for at afsende data mellem de forskellige enheder, både kontrol data såvel som lyd og meta-data. Det betyder at det lyd data der optages i C skal sendes til de andre enheder. Derfor kunne man vælge at placere al håndtering af kommunikationen i C, men i Android udvikling er det således at hvis en tråd i C skal interface med en tråd i Java, skal C tråden være en del af den virtuelle maskine. C funktioner kan kaldes fra Java af uden problemer, da sådan et kald afvikles fra Java tråden, hvilket gør det muligt at skrive til og læse C variable, fra Java af, mens det omvendte ikke er muligt. Denne begrænsning skaber derfor et behov for at kommunikationen bliver delt op i to dele. En del der afvikles i C som udelukkende håndterer afsendelse og modtagelse af lyd og meta-data. En anden del der afvikles i Java som håndterer kontrol trafikken i systemet og det data der måtte relatere sig til GUIen. Det er nødvendigt at placere håndteringen af kontrol trafikken i Java, da denne i høj grad kommer til at være påvirket af brugerens input, i forbindelse med Push-To-Talk. Desuden skaber det også en klar afgrænsning imellem C og Java delene, da C delen udelukkende kommer til at fokusere på lyd håndtering, mens alt andet bliver håndteret i Java. 2.2.1 Netværksopsætning Som beskrevet i afsnit 2.1.1 er der flere forskellige måder at anvende Wi-Fi-Direct på. Da systemet skal kunne udvides til at anvende almindelige APer benyttes den metode, hvor en enhed opretter et netværk med sig selv som GO og de andre enheder forbinder hertil. Denne fremgangsmåde ligger ret tæt op af, hvordan et almindeligt AP fungere i og med der også her skal vælges et AP som der forbindes til. Ved at vælge denne metode kommer netværksopsætningen også til at kræve bruger input, da det skal bestemmes, hvilken enhed der skal agere GO. Klienterne skal også instrueres i, hvilken GO de skal forbinde til, da andre enheder udenfor systemet også kan oprette P2P grupper. Det er desuden ikke muligt selv at vælge navnet på det AP som GO opretter, derfor kan det ikke undgås at en bruger af systemet skal vælge hvem der forbindes til. Som nævnt i afsnit 2.1.1, så kender klienterne GOens IP adresse og kun den, mens GOen ikke kender nogen IP adresser, anden end sin egen, da der ikke er adgang til dens DHCPserver. Derfor er der behov for en mekanisme der gør det muligt for GOen at kommunikere med klienterne. Vigtigheden af dette fremgår af næste afsnit, hvor routingen i systemet beskrives. Som det også vil fremgå af det næste afsnit er der ikke behov for at klienterne kender hinandens IP adresser, derfor er det tilstrækkeligt at designe udvekslingen af IP adresser således at det kun er GOen der kommer til at kende alle i systemet. Da alle enheder i systemet skal kunne modtage kontrol beskeder, såsom information omkring Push-To-Talk låsen, er det derfor valgt at udvide den kontrol server der skal køre på alle enheder, således at den på en GO enhed også kan håndtere registrerings beskeder. Det betyder at når en ny enhed skal forbindes til systemet, skal den først forbindes via Wi-Fi- Direct og derefter skal den registrere sig ved GO enheden for at blive et aktivt medlem af systemet, således at der kan blive sendt lyd data til den nye enhed og så systemet er klar til at modtage data fra den nye enhed af.

10 Kapitel 2. Netværk Når der er indført et registrering koncept er der også behov for et af-registrerings koncept, således at enheder kan fjernes fra systemet. Princippet er det samme som ved registreringen, nu skal en klient blot sende en af-registrerings besked til GOen inden den afbryder forbindelsen fra Wi-Fi-Direct netværket. Hvis ikke en enhed af-registreres inden den forlaber systemt, vil GO enheden forsøge at forward lyd data til enheden, selvom om den ikke er tilstede. Det vil skabe situationer, hvor GOen kommer til at skulle vente på at der sker et time-out på en forbindelse før den opdager at klienten ikke kan nåes. Dette vil skabe forsinkelser og er unødvendigt, når det kan undgåes ved at af-registrere enheder inden de forlader systemet helt. Problemet kan dog stadigvæk opstå, hvis en klient bevæger sig for langt væk fra GO enheden, derfor skal forbindelses time-outs stadigvæk håndteres. For at undgår at brugere af systemet bevæger sig for langt væk fra hinanden anvendes GUIen. GUIen viser brugeren af systemet i centrum af en cirkel. I GUIen vil positionerne på de andre brugere af systemt også vlre plottet ind, da de sender deres GPS position sammen med deres lyd data. Radius på cirklen kan sættes alt efter behov, men kunne f.eks. være sat til 30 meter. På den måde kan brugerne af systemet blive instrueret i at de ikke skal bevæge sig længere væk fra hinanden, end at de alle holder sig inde for, hver deres cirkel på skærmen. For at opsummere, så består kontrol trafikken nu af; Push-To-Talk beskeder, registrerings beskeder og af-registrerings beskeder. Nedenfor ses en række screenshots, som viser hvordan netværksopsætningen forgår i implementationen. Figur 2.1 viser startskærmen for applikationen. Øverst til højre ses fire knapper Knapperne står for, fra venstre mod højre, at starte netværksopsætningen, at forbinde til USB enheden, at starte GPS modulet og for at åbe en menu op med adgang til applikations specifikke indstillinger.

2.2. Design og Implementering 11 Figur 2.1: Start skærm for applikationen. Figur 2.2 viser den menu brugeren præsenteres for når der er blevet trykket på netværksopsætnings knappen. I menuen er der tre muligheder; skanne for eksisterende netværk, oprette et nyt netværk (P2P gruppe) med enheden som GO eller forbinde til et almindeligt Wi-Fi netværk (denne del vil ikke blive diskuteret yderligere i rapporten, men er blevet implementeret i det endelige system).

12 Kapitel 2. Netværk Figur 2.2: Netværks menu, hvor det vælges hvordan der skal forbindes til andre enheder. Figur 2.3 viser hvad der sker efter der er blevet trykke på skan knappen. Her præsenteres brugeren med en liste af P2P grupper og Wi-Fi-Direct enheder der kan forbindes til. I eksemplet er der dog kun en valgmulighed, hvilket er en enhed som også er GO. Når der skal forbindes til en P2P gruppe skal der forbindes til GO enheden.

2.2. Design og Implementering 13 Figur 2.3: Netværks menu, efter det er valgt at der skal forbindes til en eksisterende P2P gruppe. Her vises en liste over alle P2P grupper, samt Wi-Fi-Direct enheder der kan oprettes forbindelse til. Listen vil være sorteret således at GO enheder visis øverst, mens P2P enheder vises nederst. I dette eksempel er der dog kun én enhed i nærheden og det er en GO enhed, som det fremgår af teksten på skærmen. Ved at trykke på feltet der beskriver GO enheden, vil systemet gå i gang med at forsøge at forbinde hertil, hvilket brugeren også informeres om, som det vises i figur 2.4. Denne besked vil forsvinde igen når der er blevet oprette forbindelse til P2P gruppen og enheden er blevet registreret hos GO enheden.

14 Kapitel 2. Netværk Figur 2.4: Status vindue der vises, mens der først oprettes forbindelse til P2P gruppen og derefter udføres system registrering. Dette leder videre til skærmen der vises i figur 2.5. Dette skræm billede er det samme som vises for både GO enheden når den har oprettet sin P2P gruppe med sig selv som GO, som for klienten når den har forbundet til en GO enhed.

2.2. Design og Implementering 15 Figur 2.5: Skærmen efter enheden selv har oprette en P2P gruppe med den selv som GO. Denne skærm er den samme som vises på en klient enhed når den er forbundet til en GO, bortset fra status teksten i højre side over PTT knappen. 2.2.2 Routing Som beskrevet i afsnit 2.1 anvendes der Wi-Fi-Direct som er en P2P basseret løsning, men med en centraliseret topologi. Denne topologi er ikke optimal for systemet i forhold til hvad der er beskrevet i afsnit 1.4, hvor der står at, hver enkel enhed skal kunne sende data til alle andre enheder i systemet, hvilket svare til en P2P topologi uden nogen form for centralt samlings punkt, hvilket svare til et ad-hoc netværk. Hvis der anvendes traditionel routing, svarende til et almindeligt Wi-Fi netværk, hvor alle enhederne forbinder til hinanden gennem et access point, vil der være et overhead på ét netværks hop pr. enhed der skal sendes data til, med undtagelse af GO enheden, da den kan forbinde direkte til alle klienter. Dette er illustreret til venstre i figur 2.6.

16 Kapitel 2. Netværk Standard routing Client Optimized routing Client Client Group Owner Client Client Group Owner Client Figur 2.6: Illustration af antals hops forbundet med afsendes af data ved en regulær tilgang til routing og ved en optimeret tilgang. Pilenes farver repræsentere de forbindelser der skal oprettes, mens hver enkelt pil repræsenterer ét netværks hop. Figuren viser at klienten har tre enheder den skal sende til. Der er et hop til GO enheden, hvilket ikke kan minimeres, men der to hop til hver af de andre klienter der skal sendes til. Det samlede antal netværks hop en pakke skal udføre for at nå ud til alle klienter vil derfor vokse med en faktor 2, for hver enhed der forbindes til systemet set fra klienterne af. Der ud over vil der formodentligt også være en store-and-forward forsinkelse ved GO enheden da den skal modtage en pakke helt, før den kan forwarde den til de en anden klient. Den forsinkelse der skabes ved at skulle vente på store-and-forward samt netværks hoppene kan mindskes ved at udnytte det faktum at GO enheden er et soft-ap. Der er ikke mulighed for at lave specielle routing protokoller på GO enheden, men ved at lade alle klienter sender deres data direkte til GO enheden, og derefter lade GO enheden route klienternes data vider til de andre klienter kan antallet af hops nedsættes til et hop pr. klient. Samtidigt eksistere der kun en store-and-forward forsinkelse i systemet og det er når GO enheden modtager dataene fra en klient inden den kan gå i gang med at route dataene videre til de resterende klienter. Dette er illustreret i højre side af figur 2.6. Denne optimerede løsning forudsætter dog at GO enheden kender IP adresserne på alle de tilsluttede klienter, hvilket blev varetaget i forbindelse med netværksopsætningen i forrige afsnit. Som beskrevet i indledningen anvendes der kommunikation både i Java laget såvel som i C laget. Ved at anvende den optimerede routing i begge lag, elimineres behovet for at de enkelte klienter skal kende til de andre klienter. Det at anvende en centraliseret topologi skaber også et single point of failure i systemet, i og med at det kun kan fungere så længe GO enheden køre og er inden for rækkevidde af alle de andre enheder. Der er dog ikke nogen vej uden om dette problem med den valgt netværksløsning. Man er derfor nødt til at være opmærksom på, hvor GO enheden befinder sig i forbindelse med en demonstration, evt. ved at lade en der kender systemet benytte GO enheden, således at den kan holdes centralt i forhold til de andre enheder. Routingen er implementeret som vist med flowchartsne i figur 2.7 og 2.8. Figur 2.7 viser en flowchart over, hvordan afsendelsen af data forgår på de enkelte enheder.

2.2. Design og Implementering 17 Yes Start Is empty? Is original sender? No Forward received data to client No Yes For each client Is GO? Yes Is it a forwarding packet? Yes Find client to send to in client IP list Yes More clients? No No No Send data to GO Send data to all known clients Figur 2.7: Flowchart over hvordan afsendelse af data forgår afhængig af en enheds system rolle. Afsendelsen af data sker i en dedikeret tråd som afventer pakker den skal sende. Dette er gjordt for at afsendelsen af data ikke skal blokere for andre dele af systemet. Når der er en pakke klar til afsendelse, kontrolleres enhedens rolle først. Hvis enheden er en almindelig klient sendes pakken til GO enheden. Hvis enheden er GO vil det blive tjekket om det er en pakke der skal forwardes. Er det ikke det, vil pakken blive sendt til alle klienter. Ellers vil pakken blive forwarded til alle klienter, med undtagelse af den klient som pakken oprindeligt er fra. Når pakken er afsendt startes TX tråden forfra, ved at se om der er flere pakker til afsendelse. Når køen er tom vil TX tråden sove og vente på det interrupt der bliver fyret når der bliver sat data i dens kø. Figur 2.8 viser en flowchart over, hvordan modtagelsen af pakker forgår på enhederne.

18 Kapitel 2. Netværk Start Received packet? Yes Is GO? No En data in audio processing thread No Yes En data in TX Client as forwarding packet Figur 2.8: Flowchart over hvordan modtagelse af data forgår afhængig af en enheds system rolle. Modtagelsen af pakker sker i en selvstændig tråd da det at vente på at modtage pakker er et blokerende kald. Når der bliver modtages en pakke, kontrolleres enhedens rolle først. Hvis enheden er klient, vil pakken blive afleveret til audio processerings tråden. Hvis enheden er GO, vil pakken først blive kopieret og sat i kø ved TX tråden som en forwarding pakke, således at den vil blive forwarded som beskrevet for TX tråden. Derefter vil pakken blive afleveret til audio processerings tråden. Yderligere bør det nævnes at al kommunikation i C laget forgår via UDP, for at spare overhead, da retransmission af tabte pakker ikke er nødvendigt da det er lyd der streames. Al kommunikation i Java forgår derimod via TCP da det er kontrol data der sendes, og et tab af en kontrol pakke kan skabe dead-locks i systemet, hvis f.eks. en Push-To-Talk pakke mistes, således at systemet er låst fast i en situation, hvor det tror at der er en bruger der har trykket på sin knap, fordi beskeden om at brugeren har sluppet knappen er gået tabt. 2.2.3 Push-To-Talk lås Som tidligere nævnt er der behov for en Push-To-Tak (PTT) lås i systemet, således at der kun er en bruger der kan tale til de andre af gangen. Det betyder at der skal eksistere en ressource i systemet som er delt mellem alle enhederne. Da systemet er basseret på en centraliseret topologi og i forvejen har en GO som kan anses for at være en master i systemet er det oplagt også at lade GO enheden styre denne delte ressource. Det betyder at GO enheden vil have ansvaret for at kontrollere tilstanden for den delte ressource og for at tildele ressourcen eller låsen til de enheder der måtte efterspørge den. Låsen kan være i to tilstande, optaget eller fri. Hvis låsen er fri kan den blive tildelt til en enhed, men hvis låsen er optaget skal alle forespørgsler på at få låsen afvises. Alle klienter skal spørge GO om lov til at få låsen. Når låsens tilstand ændre sig skal alle enheder informeres om dette, således at klienter kan opretholde en lokal kopi af låsens tilstand. Det gør at der på de enkelte enheder kan signaleres til brugeren, via GUIen, at der er en anden der har låsen i øjeblikket. Det kan også vises når låsen bliver fri igen. Det

2.2. Design og Implementering 19 at klienterne selv opretholder en kopi at låsens tilstand gør også at det, klienterne bliver sparet for at spøge GO om låsen, hvis den allerede er tildelt en anden. Når man har en delt ressource er det vigtigt at være opmærksom på at der kan opstå race conditions, hvis ikke den anvendes korrekt. Derfor forgår al håndtering af låsen i den samme tråd i implementeringen. Denne tråd læser forspøgsler på låsen fra en kø, og sørger også for at generere svar beskeder til de relevante enheder. Derved kan der ikke opstå race-conditions da der altid kun er en der kan tilgå låsen. Da der anvendes en simpel kø i forbindelse med denne tråd, forgår tildelingen af låsen efter et FIFO princip, hvor den der kommer først også får låsen, såfremt den er fri. Afsendelsen af svarene sker via en TX tråd, som kort blev nævnt i afsnit 2.2.2. Denne mekanisme er gangske simpel, da TX tråden også læser beskeder fra en kø og afsender dem hurtigst muligt.

20 Kapitel 2. Netværk

Kapitel 3 Lydprocessering 3.1 Analyse Som beskrevet i afsnit 1.4.1 skal lyd processeringen ske i C, for at undgår at den bliver afbrudt uventet af garbage collectoren i den virtuelle maskine. Derved er den første design beslutning i forhold til lyd processeringen blevet truffet. Beslutningen giver dog mere frihed i forhold til at bestemme størrelserne på de buffers der skal gemmes optaget lyd samples i eller læses lyd samples fra til afspilningen. Hvis lyd processeringen skulle ske i Java skulle der anvendes buffere med en størrelse på 2048 bytes som minimum, da APIet til lyd afspilning i Java kræver dette. En sample er 16 bit eller 2 bytes, dvs. at en buffer i Java svare til 1024 samples. I C er der i teorien ingen begrænsninger for hvor små eller store bufferne skal være, ud over arkitektur og hukommelses begrænsninger, men når størrelsen på en buffer vælges skal der dog tages højde for at jo mindre en buffer bliver desto oftere skal der skiftes til en ny buffer, da tiden det tager at afspille eller fylde en buffer afhænger af sample raten og buffernes størrelse. 3.1.1 Zirene 3D Formålet med lyd processeringen i systemet er at demonstrere Zirene 3D biblioteket. Derfor er det også naturligt at lade designet af lyd processeringen være baseret på de krav som biblioteket stiller. Følgende beskriver input og output for Zirene 3D biblioteket: Input sample raten kan være hvilken som helst imellem 8000-48000[Hz]. Output sample raten vil altid være 44100[Hz], uafhængigt af inputtet da der internt fortages sample rate konvertering, hvis input sample rate er forskellige fra 44100[Hz]. Biblioteket arbejder internt med en blok størrelse på 128 samples. Dvs. at hvis man forspørger en rendering af 10 samples, skal der som minimum ligge 128 samples klar til rendering, da de resterende samples vil blive præ-renderet, således at de er klar næste gang biblioteket bliver bedt om at rendere samples. 21

22 Kapitel 3. Lydprocessering Zirene 3D anvender Head Related Transfer Functions (HRTFs) til at bestemme, hvordan en standard lydkilde skal transformeres til en retningsbestemt lydkilde. Det er derfor HRTFerne der gør at biblioteket er afhængigt af positioner og retninger når der skal renderes. HRTFerne bliver opdateret for hver 1024 sample der bliver processeret. 3.1.2 Lyd processerings forsinkelse i Android Afspilning af lyd har længe været et problematisk emne i Android. På googles officielle android bug tracker blev der tilbage i 2009 åbnet et issue 1 som omhandler den høje forsinkelse der er i Android i forbindelse med afspilning af lyd. Der bliver opstillet en række krav til hvad brugeren, der har oprette issuet, mener er nødvendigt for at Android kan bruges som en lyd processerings platform. Over årene har mange bruger tilsluttet sig denne kravliste, og issuet er stadigvæk åbent. Med Android version 4.1 indførte Google det de kalder for en low-latency-audio-path, som et forsøg på at bringe lyd processerings forsinkelsen ned. Konceptet er at under visse forudsætninger kan visse led i den almindelige lyd processerings kæde springes over for at opnå en lavere forsinkelse. I følge Leubner [2013] er forsinkelsen fra der trykkes på et tilsluttet keyboard til lyden afspilles på 95[ms] når Androids low-latency-audio-path anvendes til afspilningen af lyden. Forsinkelsen fra tryk på touch skærm til afspilning af lyd er målt til 125 [ms]. Validiteten af disse målinger er ikke helt klare men virker troværdige, hvis der sammenlignes med måling foretaget af Lazzarini [2012] tilbage i 2012 af den gamle version af Nexus 7eren. Her er forsinkelsen fra tryk på touch skærmen til afspilning af lyd målt til 120 [ms] og ved brug af low-latency-audio-path. For at kunne anvende low-latency-audio-path på Nexus 7 enheden kræver dette at lyden der skal afspilles har en sample rate på 48000 Hz, og at der anvendes en buffer størrelse på 240 samples. Dette stemmer ikke overens med kravene for Zirene 3D som har et output med en sample rate på 44100 Hz. For at kunne anvende Androids low-latency-audio path er det derfor nødvendigt at up-sample outputtet af Zirene 3D. Dette vil dog ikke blive forsøgt i dette projekt, da det at up-sample et signal vil introducere endnu en forsinkelse i systemet. De berettede målinger ovenfor er for Androids low-latency-audio path, derfor må det forventes at forsinkelsen for afspilning af lyd gennem den normale audio path kommer til at være mindst lige så høje, hvis ikke højere. 1 https://code.google.com/p/android/issues/detail?id=3434

TX thread Recorder callback 3.2. Design og Implementering 23 3.2 Design og Implementering Lydprocesseringen kan deles op i fem skridt: 1. Optagelse. 2. Afsendelse. 3. Modtagelse. 4. Rendering. 5. Afspilning. Disse skridt indgår i den optegnelse der ses af systemet flowet i figur 3.1 og 3.2. Figur 3.1 viser den første del af program flowet som sker på en enhed, mens figur 3.2 viser det resulterende program flow på en anden enhed. Hver swimlane i figuren repræsentere arbejde der bliver udført i den samme tråd. Figurene er basseret på det system der blev præsenteret med figur 1.2 i afsnit 1.4.1 og inkludere de forskellgie udviddelser der er kommet til systemet i forbindelse med de forgående analyser. Program flow based on threads Phase 1 Recording and transmission PTT push User input Start processing recordings Encode recordings Store encoded recordins in TX Write TX Trigger TX thread Read data from TX Fetch GPS position Create packet and transmit Figur 3.1: Oversigt over system flowet i forbindelse med optagelse og afsendelse af data.

Player thread Audio processing thread RX tread 24 Kapitel 3. Lydprocessering Program flow based on threads Phase 2 Receiving, rendering and playing Receive network packet Unpack payload of packet Decode audio data from payload Store payload in streaming buffer Write Streaming buffer Read Read from streaming buffer Fetch GPS and heading data Render audio data read from streaming buffer En rendered audio data in player Write Player Read Playback Figur 3.2: Oversigt over system flowet i forbindelse med modtagelse, rendering og afspilning af data. Android anvender OpenSL ES 2 som dets lyd API i native kode, dvs. i C kode. OpenSL ES er et objekt orienteret API, hvor der skal oprettes objekter (structs) til at varetage forskellige opgaver. Det objekt orienterede koncept bag OpenSL ES er i princippet simpelt og let at gå til, men i praksis er OpenSL ES et yderst komplekst API at anvende, derfor er specifikationen GROUP [2009] på ikke mindre end 569 sider også blevet anvendt i høj grad for at kunne implementere optagelses og afspilnings funktionaliteten i systemet. Det er ikke muligt at antage at der vil være periodisk afsendelse og modtagelse af data i systemet. Dette skyldes to ting, for det første skal dataene streames over en trådløs forbindelse, imellem enheder som bevæger sig rundt. For det andet er Android ikke et realtids operativ system, hvilket betyder at selvom der oprettes en tråd som skal afvikle et job periodisk er det ikke garanteret at tråden får tildelt ressourcer når den forventer at skulle starte sit job næste gang, Android er gangske enkelt ikke deterministisk. Da lyden ved en modtager gerne skal opfattes som et kontinuert signal, er der derfor behov for en buffer mekanisme, kaldet streaming buffer, således at enhederne modtager og gemmer adskillige lyd pakker inden afspilningen af lyden begyndes. En buffer mekaniske garantere ikke at der ikke sker udfald i lyden, men den minimere sandsynligheden for at det sker. 3.2.1 Optagelse Figur 3.3 viser at dette afsnit beskriver opbyggelsen af optage callbacket. Grunden til at denne tråd betegnes sådan fremgår også af den følgende beskrivelse. 2 http://www.khronos.org/opensles/

TX thread Recorder callback 3.2. Design og Implementering 25 Program flow based on threads Phase 1 Recording and transmission PTT push User input Start processing recordings Encode recordings Store encoded recordins in TX Write TX Trigger TX thread Read data from TX Fetch GPS position Create packet and transmit Figur 3.3: Illustration af, hvilken del af systemet der beskrives i dette afsnit Optagelsesfunktionaliteten er opbygget ved hjælp af OpenSL ES. Strukturen for en standard optager i OpenSL ES er vist i figur 3.4. Figur 3.4: Figur over OpenSL ESs opbygning af en optager. Den eneste forskel imellem figuren og den egentlige implementering er at der ikke anvendes en URI datasink i Android, men det der kaldes en Android Simple Buffer Queue, som er en Android specifik udvidelse til OpenSL ES APIet. En datasink er det sted som OpenSL ES aflevere de optagede data. I dette tilfælde bliver optagede samples dumpet via en buffer kø. Det betyder at for at optageren kan startes skal der først allokeres en buffer, som sættes i kø ved OpenSL ES optageren. Når en bufferen er blevet fyldt med samples sker der et callback til en bruger defineret funktion, som skal opfylde et bestemt interface for kunne blive brugt. I denne callback funktion er der mulighed for at udlæse de samples der er blevet optaget. Når en optager skal oprettes er der en række parametre der skal specificeres, såsom hvor mange kanaler der skal være i den optagede lyd (mono eller stereo), hvilken sample rate der skal optages med, antallet af buffers der kommer i kø og hvor store disse buffere er.

TX thread Recorder callback 26 Kapitel 3. Lydprocessering Alle buffere må have samme størrelse. Og hvilken funktion der skal bruges som callback funktion. Da systemet anvender PTT konceptet skal der kun sendes lyd data til de andre enheder, når der er trykket på enhedens PTT knap og enheden har fået tildelt PTT låsen af GO enheden. Dette kan løses på to måde, ved enten at starte og stoppe OpenSL ES optageren efter behov, eller ved at lade optage callbacket polle en variable der styre, hvornår dataene skal sendes. Det er valgt at anvende variable polling metoden, da det formodes at der vil være et større overhead i at skulle starte og stoppe OpenSL ES optageren, hver gang der skal startes og stoppes for afsendelsen af data. Det betyder der er behov for en delt variabel som sættes fra Java af når en enhed får tildelt PTT låsen, således at optage callbacket ved at dataene skal afsendes. Ligeledes skal variablen også sættes når låsen gives fri igen, så afsendelsen af data stoppes. Når der ikke skal afsendes data skal den fyldte buffer blot sættes i kø igen, da indholdet ikke skal bruges. Hvad der helt nøjagtigt sker når der skal afsendes data kan læses i afsnit 3.2.2. I implementationen anvendes der en sample rate på 44100[Hz], derved kan der bruges den samme sample rate igennem hele systemet, da det også er output sample raten på Zirene 3D biblioteket. Der skal optages i mono, da der kun er en mikrofon i de anvendte headsets. Der bliver anvendt en kø med plads til to buffere, hvor hver buffer har en størrelse på 512 samples. Grunden til at buffer størrelsen er på 512 samples beskrives i afsnit 3.2.4. Der anvendes to buffere så der er en der bliver fyldt og en der kan bruges når callbacket sker, således at optageren altid har en buffer at fylde data i. Dette forudsætter dog at callbacket er hurtigere end den tid det tager at fylde en buffer. Hvis ikke callbacket er færdigt inden det næste kommer, vil det påvirker OpenSL ESs interne processering. Man frarådes derfor også, fra udviklerne af APIet, fra at lave blokerende kald og udføre store arbejds mængder i et callback. Callbacket afsluttes med at sætte den buffer der lige er blevet fyldt tilbage i kø så den kan blive fyldt igen, derved genbruges de bufferer der er blevet allokeret tidligere. 3.2.2 Afsendelse Figur 3.5 viser at dette afsnit vil fokusere på at beskrive opbygningen af TX tråden, men at anvendelsen af enkodning også vil blive beskrevet her. Program flow based on threads Phase 1 Recording and transmission PTT push User input Start processing recordings Encode recordings Store encoded recordins in TX Write TX Trigger TX thread Read data from TX Fetch GPS position Create packet and transmit Figur 3.5: Illustration af, hvilken del af systemet der beskrives i dette afsnit

3.2. Design og Implementering 27 Ved en sample rate på 44100 [Hz] og en buffer størrelse på 512 samples vil der være 1024 bytes klar til afsendelse med et interval på 11.61 [ms] (tiden det tager at fylde en buffer ved den givne sample rate). Det giver en data rate på 88.1 [kb/s]. Dette er ikke problematisk da der anvendes Wi-Fi. Der er dog mulighed for at formindske data raten betydeligt ved at anvende et codec til at enkode samlinger af lyd samples før afsendelse og dekode dem igen ved modtagelse. Til at løse denne opgave er open source codecet Opus 3 blevet valgt. Codecet er primært designet til sample rater på 8000, 16000, 24000, 32000 og 48000 [Hz], hvor der skal bruges buffer størrelser svarende varigheder på 2.5, 5, 10, 20 og 40 [ms]. Der er dog mulighed for at bruge codecet i en speciel tilstand, hvor der kan anvendes andre sample rater og buffer størrelser som passer til ens behov. Codecet bliver i impementationen anvendt med en sample rate på 44100 [Hz] og en buffer størrelse på 512 samples, svarende til de buffere der bliver leveret fra OpenSL ES optageren. Derved kan en fyldt optage buffer blive enkodet direkte, så den er klar til at blive sendt. Ved bruge af codecet formindskes det data der skal sendes fra 1024 bytes til omkring 100 bytes. Til at håndtere afsendelse af lyd data skal der oprettes en TX tråd, som kommunikerer via UDP protokollen. UDP er blevet valgt for at minimere overheadet i afsendelsen af lyd data, da der ikke er behov for den ekstra sikkerhed som TCP giver. En forsinket eller tabt lyd pakke kan ikke bruges, da lyden skal afspilles som et kontinuert signal, hvor man gerne vil undgå forsinkelser af lyden, såfremt der sker pakke tab. Det betyder at hvis en pakke går tabt, giver det ikke mening at vente på at den bliver retransmitteret, da det vil skabe en forsinkelse i systemet. Der i mod vil man hellere have at det kommer et hul i lyden, dvs. at der ikke bliver afspillet noget data, svarende til varigheden på den tabte pakke, og at systemet er klar til at afspille den næste lyd pakke der modtages. Afsendelsen af data styres fra optage-callbacket, men det er vigtigt at callbacket er færdig med at eksekvere inden den næste buffer er fyldt. Derfor bliver håndteringen af afsendelsen af data placeret i en separat tråd, således at det ikke blokere callbacket. For at callback funktionen kan kommunikere med TX tråden er der behov for en kø. Her anvendes der en simpel FIFO kø, som callbacket kan skrive til og som TX tråden vil læse fra. Når TX tråden ikke har nogen beskeder i sin kø kan den sove for at give mere processerings tid til andre dele af systemet. Når der skal afsendes data skal callback funktionen derfor blot enkode de data der skal sendes og sætte dem i TX trådens kø, hvorefter TX tråden vil sørge for afsendelsen af dataene jvf. afsnit 2.2.2 omkring routing i systemet. TX tråden vil udlæse de enkodede lyd data fra sin kø og lave en UDP pakke som indeholder disse. Desuden vil UDP pakken inkludere enhedens GPS position, som skal bruges til renderigen på modtagerens side. 3.2.3 Modtagelse Figur 3.6 viser hvilke dele af program flowet der indgår i modtagelsen af en pakke. 3 http://www.opus-codec.org/

Player thread Audio processing thread RX tread 28 Kapitel 3. Lydprocessering Program flow based on threads Phase 2 Receiving, rendering and playing Receive network packet Unpack payload of packet Decode audio data from payload Store payload in streaming buffer Write Streaming buffer Read Read from streaming buffer Fetch GPS and heading data Render audio data read from streaming buffer En rendered audio data in player Write Player Read Playback Figur 3.6: Illustration af, hvilken del af systemet der beskrives i dette afsnit Modtagelsen sker først som beskrevet i afsnit 2.2.2. Det at aflevere det modtagende lyd data til lydprocesserings tråden involvere dog flere ting. Først skal den modtagende pakke, pakkes ud, således at de enkodede lyd data kan blive skilt fra den tilhørende GPS position. Dernæst skal lyd dataene dekodes. Dekodningen forgår ved hjælp af det samme codec der blev beskrevet i afsnit 3.2.2, med de samme indstillinger. Til sidst skal det dekodede lyd data og den tilhørende GPS position sættes i streaming buffer køen der blev beskrevet i indledningen af dette kapitel. 3.2.4 Rendering Figur 3.7 viser, hvor i program flowet at renderingen befinder sig.

Player thread Audio processing thread RX tread 3.2. Design og Implementering 29 Program flow based on threads Phase 2 Receiving, rendering and playing Receive network packet Unpakc payload of packet Decode audio data from playload Store payload in streamin buffer Write Streaming buffer Read Read from streaming buffer Fetch GPS and heading data Render audio data read from streaming buffer En rendered audio data in player Write Player Read Playback Figur 3.7: Illustration af, hvilken del af systemet der beskrives i dette afsnit Zirene 3D biblioteket er objekt orienteret, hvilket betyder at der skal oprettes objekter som repræsenterer de forskellige dele af systemet. Der skal oprettes en listener, som beskriver lytterens position og retning. Der skal oprettes en source, med en dertilhørende buffer beskrivelse, for hver enhed der skal kunne afspilles lyd fra. Source objektet bruges til at beskrive positionen på den kilde eller enhed der skal afspilles for. En buffer beskrivelse beskriver hvilket format lyd dataene kommer i; antal kanaler, sample rate og bufferens størrelse, så Zirene 3D ved, hvordan dataene skal fortolkes. Når Zirene 3D skal rendere lyd, vil det rendere lyd for alle de source objekter der er blevet oprettet, da en del af formålet med biblioteket er at man skal kunne høre forskellige lydkilder klart, selvom om de bliver afspillet samtidigt, ved at gøre dem retningsbestemte. Derfor er det ikke nok bare at have puttet data i bufferen for det source objekt man modtager lyd fra, men der skal også fyldes stilhed i de andre source objekters buffere, så de ikke kommer til at støje, ved at bidrage med gamle lyd rester til det renderede lyd spor. Buffer størrelsen der anvendes til Zirene 3D biblioteket skal gerne passe til den interne processerings størrelse på 128 samples. Buffer størrelsen skal derfor være lig med 128 ganget med et heltal, for at undgå at samples bliver renderet inden de skal bruges. For at vælge en buffer størrelse tages opdaterings hastigheden af HRTFerne med i betragtningen, da de styrer, hvornår renderingen vil ændre karakteristik. HRTFerne opdateres for hver 1024 samples der bliver renderet. Det betyder at der ikke er behov for at opdatere positioner for source og listener objekterne, samt retning for listener objektet for mere end hver 1024. sample. Ud fra dette og tildeles også empiri er der blevet valgt en buffer størrelse på 512 samples, da den går rent op i 128 og sikre at når HRTFerne bliver opdateret så er der nye

Player thread Audio processing thread RX tread 30 Kapitel 3. Lydprocessering positions og retnings data klar. 3.2.5 Afspilning Figur 3.8 viser at dette afsnit både vil beskrive opbygningen af afspilnings tråden samt opbygningen af lyd processerings tråden. Først vil opbygningen af afspilnings tråden blive beskrevet og derefter vil det blive forklaret hvorfor der er behov for en lyd processerings tråd med en tilhørende beskrivelse af det arbejde der udføres i denne tråd. Program flow based on threads Phase 2 Receiving, rendering and playing Receive network packet Unpack payload of packet Decode audio data from payload Store payload in streaming buffer Write Streaming buffer Read Read from streaming buffer Fetch GPS and heading data Render audio data read from streaming buffer En rendered audio data in player Write Player Read Playback Figur 3.8: Illustration af, hvilken del af systemet der beskrives i dette afsnit Afspilningen forgår ved hjælp af OpenSL ES som vist på figur 3.9. Dog er der anvendt en Simple Buffer Queue som datasource frem for den URI datasource der er vist på figuren. Figur 3.9: Figur over OpenSL ESs opbygning af en afspiller

3.2. Design og Implementering 31 Konceptet er der nogenlunde det samme som ved optageren, her skal der blot sættes fyldte buffere i kø og så vil OpenSL ES lave et callback når en buffer er blevet læst. På samme måde som ved optageren skal der sættes en række parametre når afspilleren startes. Disse parametre inkluderer; antallet af kanaler i lyd sporet, sample raten, buffer størrelsen, antal buffere i kø osv. Til forskel fra optageren som optog i mono, skal afspilleren afspille i stereo, da outputtet af Zirene 3D er i stereo. Til forskel fra optageren skal der ved afspilleren aktivet sættes data i kø, når der skal afspilles lyd. Varetagelsen af denne opgave kan placeres to steder; i callbacket, når en buffer er blevet læst kan en ny blive sat i kø, eller i en separat tråd der holder øje med hvor mange buffere der er i kø ved afspilleren og sætter flere i kø når det er nødvendigt. At anvende callbacket har den fordel at der ikke skal oprettes en dedikeret tråd, da der arbejdes på en eksisterende tråd fra OpenSL ES. Anvendes callbacket til at sætte data i kø giver det også mulighed for at foretage renderingen lige inden en buffer skal sættes og afspilles. Ulempen er dog et callback altid skal være færdigt inden det næste callback sker, for at sikre at OpenSL ES ikke kommer bagefter i sin processering. Da afspilningen af lyd er følsom overfor forsinkelser vælges det at anvende en separat tråd til at styre, hvornår der skal sættes lyd i kø til afspilning. Denne tråd skal køre periodisk og kontrollere hvorvidt der er nok data i streaming buffer køen, til at afspilningen kan gå i gang. Når der er nok data skal tråden sørge for at få renderet den modtagne lyd ved hjælp af Zirene 3D biblioteket og til sidst sætte den renderede lyd i kø i afspilleren. Derved bliver lyden først renderet lige inden den skal i afspillerkøen, som også var tilfældet for callbacket. Desuden skal tråden sørge for at nulstille alt i forhold til afspilleren når der ikke længere modtages data fra en af de andre enheder, således at afspilleren er klar når der modtages data fra en ny enhed. I implantationen bliver afspilleren oprettet med en sample rate på 44100 [Hz], en buffer størrelse på 1024 samples, da de 512 samples der bliver optaget i mono bliver konverteret til et stereo signal. Der anvendes en kø med plads til fire buffere. I princippet brude det have været muligt kun at bruge to buffere til køen, men i praksis fungere dette ganske enkelt ikke. Den nøjagtige årsag til at det ikke virker er uvist, men det formodes at det hænger sammen med OpenSL ESs håndtering af køen og det faktum at det vil tage omkring 20 [ms] at få afspillet de to buffere. Efter 10 [ms], hvor callbacket sker, skal programmet nå at få fyldt en netop frigivende buffer op og have den sat i kø igen inden de næste 10 [ms] er gået. Derfor er kø længden sat til 4, da dette giver resten af systemet tid nok til at reagere når afspilningskøen er ved at være tom. En kø på 4 buffere, giver resten af systemet 46,5[ms] til at modtage og klargøre mere data til afspilleren, fra den er fuld til den er tom. Lyd processerings tråden sættes til at køre hvert 5. milisekund. Det betyder at den når at kontrollere status på afspilningskøen 1-2 gange imens afspilleren er ved at afspille en buffer, alt afhængigt af timingen. Den streaming buffering der skal ske, hver gang afspilningen fra en enhed skal startes, sættes til at være 5 lyd pakker. Dvs. at når afspilningen startes er der nok data til at fylde afspiller køen, samtidigt med at der er data klar til en buffer mere, hvis der skulle ske en

32 Kapitel 3. Lydprocessering forsinkelse inden det næste data modtages. En streaming buffer på 5 lyd pakker giver en indledende forsinkelse på 58[ms] fra det først data modtages til afspilningen startes. Denne forsinkelse er hørbar når ham der taler står ved siden af ham der får afspillet lyden, men da Andriods forsinkelse i afspilningen af lyden formodes at være over 100[ms] vil der alligevel blive oplevet et ekko i lyden uanset hvor lille en streaming buffer kø der anvendes.

Kapitel 4 Test og Evaluering I dette kapitel vil målinger af forsinkelsen i forskellige dele af systemet blive præsenteret og diskuteret. Der vil blive set på de følgende områder: Case 1 - Tiden der går fra at en lyd pakke bliver sat i streaming buffer køen til den bliver sat i afspilningskøen. Case 2 - Tiden det tager at sende til én klient i forhold til to klienter fra GO enheden. Alle tidsmælinger i det følgene er basseret på at tage et tidsstempel inde det der skal måles sker og efter det der skal måles er sket. Tidsstemplerne fåes ved at kalde C funktionen clock_gettime og specifiere at det skal være CLOCK_MONOTONIC tiden der udlæses. Det giver tiden siden et arbitrært start tidspunkt, men altid det samme tidspunkt, i hvert fald så længe enheden ikke genstartes, hvilket ikke sker i nogle af de udførte tests. Denne tid påvirkes ikke af Network Time Protocol (NTP), dvs. at der forkommer ikke spring i tiden, som følge af justeringer via NTP. I det følgende vil test casene blive præsenteret og deres resultater vil blive diskuteret. 4.1 Case 1 - Buffer kø til afspilnings kø Denne test er udført ved at starte en enhed som GO og lade en anden enhed forbinde hertil som klient. På klienten emuleres der et tryk på PTT knappen i kode, således at klienten går i gang med at sende data til GO enheden. Tiderne der bliver målt i denne case er fra en dekodet lyd pakke bliver sat i streaming buffer køen til den er blevet sat i afspilningskøen. Tiderne er målt på GO enheden da det er den der modtager lyd pakkerne. Testen har en varighed på 30 min. Derved sikres det at systemets tilstand og ydelse kan analyseres i hvad der kan anses for at være steady-state. Figur 4.1 illustrere, hvilken del af systemet, og hvor i systemet der bliver målt i forbindelse med denne test, markeret med rødt. Desuden viser figuren også at der vil blive set på de to køer, streaming buffering kø og player kø, markeret med grønt. 33

Player thread Audio processing thread RX tread 34 Kapitel 4. Test og Evaluering Program flow based on threads Phase 2 Receiving, rendering and playing Receive network packet Unpakc payload of packet Decode audio data from playload Store payload in streamin buffer Write Streaming buffer Read Read from streaming buffer Fetch GPS and heading data Render audio data read from streaming buffer En rendered audio data in player Write Player Read Playback Figur 4.1: Illustration af, hvor i systemet der måles i forbindelse med denne test. Figur 4.2 og tabel 4.1 viser resultaterne af den første udførsel af testen med en klient tilsluttet. Figur 4.2: Graf over tiden der går fra en lyd pakke sættes i streaming buffer køen til den er blevet renderet og sat i afspilningskøen. Figuren viser at systemet i de første 10 min. arbejder med tider på mellem 100[ms] og 150[ms] fra den ene kø til den anden, men omkring 10 minutter inde i testen ses det at

4.1. Case 1 - Buffer kø til afspilnings kø 35 Mean 253.76[ms] Std 141.85 Max 549.07[ms] Min 1.98[ms] Samples 154970 Tabel 4.1: Beregnede værdier basseret på måledataene for kø til kø tiderne. kurven begynder at stige, hvilket sker frem til omkring 22 minutter inde i testen, hvor tiderne først bliver meget små, hvorefter de bliver høje og tilmed højere end før faldet. Når tiderne vokser som det ses i grafen betyder at der bliver puttet mere data i streaming buffer køen end der bliver taget ud. Dette burde dog ikke ske da der arbejdes med den samme sample rate på 44100 [Hz] igennem hele systemet. Normalt i streaming applikationer løber man ind i problemer, hvor der opstår buffer underruns, dvs. at ens buffere bliver tømt hurtigere end de bliver fyldt op, hvilket som regel sker pga. pakketab og forsinkelser i systemet. For bedre at kunne forstå dette resultat er det nødvendig at se på afspilningskøens længde. Figur 4.3 viser længden på afspilningskøen under testen. Figur 4.3: Graf over afspilningskøens længde. Kø længden er målt efter der er blevet sat en buffer i kø, hvilket er grunden til at den aldrig når 0. Desuden er der også indbygget en mekanisme i systemet som sikre at køen aldrig løber tør, mens der skal afspilles lyd fra andre enheder. Dette opnås ved at sætte en buffer med nuller i kø når køen ellers ville være blevet tom. Dette er blevet indført da der er for stort et overhead i at lade afspilleren køre helt tør, hvilket vil pause den og derefter skulle starte den igen når der er nye data klar. At afspille tomme buffere betyder at, hvis

36 Kapitel 4. Test og Evaluering der modtages nyt data inden for de 11 [ms] det tager at afspille en buffer vil de nye data bliver forsinket, svarende til den tid der mangler for at få afspillet nul bufferen. Yderligere inspektion af dataene for afspilningskøen viser at kø længden når ned på én 47 gange i løbet af testen. Yderligere kan det bemærkes at der under hele testen kun skete 6 pakketab. Det betyder derfor at 41 af de 47 nul buffere, der er blevet afspillet, har udfyldt de tidsrum, hvor streaming bufferen er løbet tør på grund af forsinkelser i modtagelsen af lyd data. Regnes disse 41 buffere om til tid svare det til omkring 476 [ms]. Vender vi tilbage til grafen i figur 4.2 ses det at forsinkelsen går fra 100[ms] til 500[ms]. Nul bufferne kan derfor være en mulig forklaring på, hvorfor forsinkelsen stiger imellem 10 og 22 min. Nul bufferne kan dog ikke umiddelbart forklare, hvorfor der sker et spring omkring de 22 minutter, udover at der bliver afspillet adskillige af dem, mens streaming bufferne er løbet tør for data. For bedre at kunne forstå dette skal grafen i figur 4.4 inspiceres. Figur 4.4: Graf over streaming buffer køens længde samt tiden imellem at der bliver fyldt elementer i køen. De røde måle punkter vise kø længden for streaming buffer køen, mens de blå viser tiden imellem skrivninger til streaming buffer køen. Tabel 4.2 viser en række beregnede statistikker basseret på måledataene vist i figuren. Figuren viser med rødt kø længden for streaming buffer køen og med blåt tiden der går imellem to skrivninger til køen. Her ses den samme opførsel som kunne konstateres i målinger for kø til kø tiderne. Figur 4.5 viser et udsnit af grafen fra figur 4.4, hvor der er zoomet ind omkring de 22

4.1. Case 1 - Buffer kø til afspilnings kø 37 Mean () 22.37[ms] Mean (time) 11.61[ms] Std () 12.22 Std (time) 7.80 Max () 48.0[ms] Max (time) 385.50[ms] Min () 1.0[ms] Min (time) 0.0[ms] Samples 155009 Tabel 4.2: Beregnede værdier basseret på måledataene for streaming buffer køen, for første udførsel af denne test. minutter. Figur 4.5: Graf over streaming buffer køens længde samt tiden imellem at der bliver fyldt elementer i køen. De røde måle punkter vise kø længden for streaming buffer køen, mens de blå viser tiden imellem skrivninger til streaming buffer køen. Figuren viser at der går næsten 400[ms] imellem to skrivninger til køen. Inden for en periode på 10 sekunder er der målt flere tider imellem 100[ms] og op til 400[ms]. Dette resulterer i at køen bliver helt tom 2 gange. Inspicering af loggen viser at der ikke er sket nogen pakke tab i lige netop dette tidsrum. Det betyder at alle data når frem, de er blot blevet forsinket, hvilket skaber det hop der ses fra 250[ms] til 400[ms] i figur 4.2. For at få en bedre ide om, hvorvidt disse måledata er repræsentative for systemet er testen blevet gentaget. Resultatet af gentagelsen ses i figur 4.6.

38 Kapitel 4. Test og Evaluering Figur 4.6: Graf over streaming buffer køens længde samt tiden imellem at der bliver fyldt elementer i køen for anden udførsel af testen. De røde måle punkter vise kø længden for streaming buffer køen, mens de blå viser tiden imellem skrivninger til streaming buffer køen. Grafen viser at det der opleves omkring de 22 minutter ved første udførsel af testen sker allerede efter 5 minutter i anden udførsel af testen. Det ses også at det der sker, har betydeligt større indflydelse på systemet anden gang en det havde første gang. I denne graf ses det at tiden imellem to elementer bliver skrevet til streaming køen når helt op på 1 sekund 5 minutter inde i testen. Det resulterer i at for de sidste 25 min. af testen er streaming buffer kø længden på 40-50 lyd pakker. Ud fra grafen er der svært at se om der sker den samme stigning over tid som blev oplevet under første udførsel af testen. Der er ikke umiddelbart noget i loggen for testen der tyder på at der er gået noget galt på GOenheden som kan forsage de store forsinkelser. Det må derfor antages at forsinkelserne skyldes netværks forbindelsen eller at der er sket noget på klienten som ikke burde være sket. Loggen for klienten er dog ikke blevet gemt i forbindelse med disse tests og det er derfor ikke muligt at inspicere denne, for at kunne be- eller afkræfte dens rolle i forbindelse med de målte værdier. For at forbedre systemet er der flere forskellige ting der kan blive gjort. For det første kan mængden af data der skal buffers, inden afspilningen startes, sættes op, for at forsøge at undgå brugen af nul buffere når en enhed ikke har mere data at sætte i afspillerens kø. Størrelsen på de nul buffere der anvendes kan også justeres. I implementation anvendes der buffere med samme størrelse som lydpakkerne, dvs. 1024 samples i stereo. Et forsøg kan være at reducere denne størrelse til det halve eller det kvarte, for at se om det fjerner

TX thread Recorder callback 4.2. Case 2 - TX tider for en og to klienter 39 eller formindsker den stigning der opleves i måledataene. En anden ting der kan gøres er at skabe en overflow mekaniske, som genstarte en streaming session når streaming buffer køen bliver for lang. 4.2 Case 2 - TX tider for en og to klienter Et interessant aspekt af systemet er dets skalerbarhed i forhold til den routing der er blevet valgt, da det vides på forhånd at forwarding forsinkelsen vil stige lineært med antallet af enheder i systemet. Spørgsmålet er bare, hvor meget det vil stige pr. enhed. Denne test case består af to udførsler, en med to enheder og en med tre enheder. Der er desværre ikke mulighed for at teste med flere end tre enheder da der ikke er flere enheder til rådighed for dette projekt. Testen er udført ved først at lade en enhed blive GO, hvorefter klient(erne) forbinder hertil. Når klient(erne) er forbundet startes testen ved at emulere et tryk på PTT knappen på GO enheden, så den går i gang med at sende data. Testen har en varighed på 30 min. ligesom ved den forrige test. Figur 4.7 viser hvor i systemet tiderne er blevet målt. Program flow based on threads Phase 1 Recording and transmission PTT push User input Start processing recordings Encode recordings Store encoded recordins in TX Write TX Trigger TX thread Read data from TX Fetch GPS position Create packet and transmit Figur 4.7: Illustration af, hvor i systemet der måles i forbindelse med denne test. Resultaterne for den første udførsel af testen ses i tabel 4.3 og figur 4.8, hvor der er én klient forbundet. Den gennemsnitlige tid det tager at sende til en klient er på 0.4[ms]. Den maksimale værdi der er blevet målt er på 15[ms]. Inspektion af måledataene viser at ud af de ca. 155000 pakker der er blevet sendt, så har 0.05% taget over 1[ms] at få afsendt, mens 4 af målingerne har vist tider på over 10[ms]. For at kunne sige mere præcist hvad der forårsager de 4 målinger, på over 10[ms], er det nødvendigt at inspicere loggen fra modtageren, denne er desværre ikke blevet gemt under testen og der kan derfor kun gættes på hvad der skaber de høje målinger. En mulighed er at den tråd der står for at afsende data, på et tidspunkt

40 Kapitel 4. Test og Evaluering imellem start tiden og slut tiden er blevet afbrudt af Android operativsystemet, for at give ressourcer til en anden eller vigtigere opgave. En anden mulighed er at afsendelsen af dataene har taget længere tid en normalt, pga. forstyrrelser, som har skabt en dårlig forbindelse til modtageren. Mean: 0.40[ms] Std: 0.37 Max: 14.98[ms] Min: 0.00[ms] Samples: 155041 Tabel 4.3: Beregnede værdier baseret på måledataene TX tiderne med en klient tilsluttet. Det kan være svært at sige noget konkret ud fra figur 4.8. Derfor viser figur 4.9 et zoom af den samme graf omkring 14 minutter inde i testen. Figur 4.8: Graf over de målte forsinkelser med en klient forbundet. Figur 4.9 viser at der er en vis periodicitet i måledataene. Dette kan skyldes at måledataene er korreleret, pga. at netværksforstyrrelser ikke kun vil påvirker en enkelt måling, men flere målinger i træk. Der kan også fornemmes to niveauer i måledataene, hvilket er markeret med røde streger. De røde streger er indsat ved hjælp af inspektion af dataene. Det der er interessant at se på her er, hvor mange målinger og hvad gennemsnits værdierne er for de to niveauer. For at finde frem til disse værdier er målingerne blevet delt op i to grupper, hvilket den grønne linje indikerer. Den grønne linje er placeret midt imellem de to røde, ved en y-værdi på 0.28[ms]. Alle målinger mindre end den grønne linje høre til det nedre niveau, mens alle målinger større end eller lig med høre til det øvre niveau.

4.2. Case 2 - TX tider for en og to klienter 41 Behandling af måledataene viser at der er 67543 målinger i det nedre niveau, hvilket svare til 43.5% af måledataene. Gennemsnitsværdien for disse målinger er beregnet til at være 0.167[ms]. For det øvre niveau kommer der til at være 87498 målinger, hvilket svare til 56.4% af det samlede antal målinger. Gennemsnitsværdien for det øvre niveau er beregnet til at være 0.58[ms]. Dette er betragteligt højere end for det nedre niveau. Grunden til den højere gennemsnitsværdi skyldes de mange peaks der ses over den øverste røde streg. Som igen kan skyldes de faktorer der tidligere er blevet nævnt, såsom netværks forstyrrelser, eller afbrydelser fra Oset af. Figur 4.9: Graf over de målte forsinkelser med en klient forbundet, zoomet ind omkring halvvejs igennem testen. De to røde streger indikere de to niveauer der kan fornemmes i dataene. Den grønne streg er plottet midt imellem de to røde. Resultaterne for anden udførsel af testen ses i tabel 4.4 og er plottet i figur 4.10. Resultaterne viser at det er nogenlunde det samme billede som for første udførsel der gør sig gældende. Hvad der er værd at bemærke er at gennemsnits værdien er steget med 0.23[ms] ved at tilslutte to klienter frem for en klient. Inspicering af måledataene viser at med to klienter er det 0.17% af måledatene der er over 1[ms], mens 22 af måledataene er over 10[ms]. Dette kunne indikere at de høje måleværdier relatere sig mere til netværksforbindelsen end de gør til afbrydelser fra Android OSet.

42 Kapitel 4. Test og Evaluering Mean: 0.63[ms] Std: 0.51 Max: 18.55[ms] Min: 0.00[ms] Samples: 155036 Tabel 4.4: Beregnede værdier baseret på måledataene TX tiderne med to klienter tilsluttet. Figur 4.10: Graf over de målte forsinkelser med en klient forbundet. For bedre at kunne sammenligne resultaterne for 2 klienter med 1 klient, laves der den samme undersøgelse af de plottede data. Dette er vist i figur 4.11