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

Størrelse: px
Starte visningen fra side:

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

Transkript

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

2

3 Institut for Elektroniske Systemer Fredrik Bajers Vej 7 DK-9220 Aalborg Ø 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.

4

5 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ø v

6 Indhold 1 Introduktion AM3D Arbejdsopgaver Use case Krav og ønsker til systemet fra virksomheden System design overordnet Netværk Analyse Hvad er Wi-Fi-Direct? Design og Implementering Netværksopsætning Routing Push-To-Talk lås Lydprocessering Analyse Zirene 3D Lyd processerings forsinkelse i Android Design og Implementering Optagelse Afsendelse Modtagelse Rendering Afspilning Test og Evaluering Case 1 - Buffer kø til afspilnings kø Case 2 - TX tider for en og to klienter Konklusion 45 Litteratur 47 A Praktik aftale og udtalelse fra AM3D 49 vi

7 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

8 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

9 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.

10 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å 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

11 Device 2 Device 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 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.

12 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.

13 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 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

14 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 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

15 2.2. Design og Implementering 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 Netværksopsætning Som beskrevet i afsnit 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.

16 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.

17 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).

18 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.

19 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.

20 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.

21 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 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.

22 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.

23 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.

24 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 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

25 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 Denne mekanisme er gangske simpel, da TX tråden også læser beskeder fra en kø og afsender dem hurtigst muligt.

26 20 Kapitel 2. Netværk

27 Kapitel 3 Lydprocessering 3.1 Analyse Som beskrevet i afsnit 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 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 [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

28 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 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å 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å 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

29 TX thread Recorder callback 3.2. Design og Implementering 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 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.

30 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 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

31 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.

32 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 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 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 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

33 3.2. Design og Implementering 27 Ved en sample rate på [Hz] og en buffer størrelse på 512 samples vil der være 1024 bytes klar til afsendelse med et interval på [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, og [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å [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 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 Modtagelse Figur 3.6 viser hvilke dele af program flowet der indgår i modtagelsen af en pakke. 3

34 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 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 Rendering Figur 3.7 viser, hvor i program flowet at renderingen befinder sig.

35 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 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

36 Player thread Audio processing thread RX tread 30 Kapitel 3. Lydprocessering positions og retnings data klar 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

37 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å [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

38 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.

39 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

40 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

41 4.1. Case 1 - Buffer kø til afspilnings kø 35 Mean [ms] Std Max [ms] Min 1.98[ms] Samples 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å [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

42 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

43 4.1. Case 1 - Buffer kø til afspilnings kø 37 Mean () 22.37[ms] Mean (time) 11.61[ms] Std () Std (time) 7.80 Max () 48.0[ms] Max (time) [ms] Min () 1.0[ms] Min (time) 0.0[ms] Samples 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.

44 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å 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 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

45 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 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

46 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: 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.

47 4.2. Case 2 - TX tider for en og to klienter 41 Behandling af måledataene viser at der er 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 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 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.

48 42 Kapitel 4. Test og Evaluering Mean: 0.63[ms] Std: 0.51 Max: 18.55[ms] Min: 0.00[ms] Samples: 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

AVR MP3 29-05-08 05576 Ingeniørhøjskolen i Århus Michael Kaalund

AVR MP3 29-05-08 05576 Ingeniørhøjskolen i Århus Michael Kaalund AVR MP3 29-05-08 Indholdsfortegnelse 1 Introduktion...2 2 Udviklingsmiljø...2 3 Beskrivelse af systemet...3 3.1 VS1001k...3 3.2 MP3 file formatet...6 4 Konklusion...6 5 Litteratur liste...6 6 Illustrations

Læs mere

UNO vejledning. Indhold

UNO vejledning. Indhold UNO vejledning Indhold I denne vejledning finder du informationer omkring installering af de forskellige Uno produkter, derudover er der samlet de mest brugte funktioner til daglig brug af Uno UNO VEJLEDNING...

Læs mere

Indholdsfortegnelse for kapitel 2

Indholdsfortegnelse for kapitel 2 Indholdsfortegnelse for kapitel 2 Kapitel 2. Analyse.......................................................... 2 Analyse af 2.1...................................................... 2 Analysen af Database.................................................

Læs mere

EasyRun En løbers bedste ven

EasyRun En løbers bedste ven En løbers bedsteven Anders Arnfast 06525, Martin Søberg 0655, Ken Falk 06504 09 . INDHOLD. Indhold... 2 2. Introduktion... 3 Opsætning... 3 3. System arkitekturdesign... 4 4. Hardware Design... 5 Ethernet

Læs mere

QUICK MANUAL BRUGERNAVN: ADMIN PASSWORD: 00000 APP: SMARTEYES PRO PORT: 50100. SecVision - Quick Manual v1.0

QUICK MANUAL BRUGERNAVN: ADMIN PASSWORD: 00000 APP: SMARTEYES PRO PORT: 50100. SecVision - Quick Manual v1.0 QUICK MANUAL BRUGERNAVN: ADMIN PASSWORD: 00000 APP: SMARTEYES PRO PORT: 50100 SecVision - Quick Manual v1.0 1. System Login 1.1. Bruger Login ID: admin Password: 00000 1.2. Indstilling af dato/tid og harddisk

Læs mere

Kvik guide: GT-Command Mobile

Kvik guide: GT-Command Mobile GamesOnTrack A/S, Uhresoevej 35, DK 7500 Holstebro, Denmark, www.gamesontrack.com Tel: +45 3070 3777, email: nb@gamesontrack.com, CVR and VAT number: DK 3105 3013 Kvik guide: GT-Command Mobile I version

Læs mere

QR koder kræver dels en fysisk genstand at klistre koden på, og dels er operationen noget omfattende med print af kode og fysisk opsætning af denne.

QR koder kræver dels en fysisk genstand at klistre koden på, og dels er operationen noget omfattende med print af kode og fysisk opsætning af denne. Notat SEGES P/S Koncern Digital Stedfæstede instrukser ved brug af Recho Ansvarlig JPH Projekt: 7463, Kompetenceudvikling - når landmanden har tid og behov Oprettet 12-2015 Side 1 af 6 Stedfæstede instrukser

Læs mere

BRUGER GUIDE. Waoo Web TV på tablet ipad og Android FIBERBREDBÅND TV TELEFONI

BRUGER GUIDE. Waoo Web TV på tablet ipad og Android FIBERBREDBÅND TV TELEFONI BRUGER GUIDE Waoo Web TV på tablet ipad og Android FIBERBREDBÅND TV TELEFONI INDHOLD Velkommen til Waoo Web TV... 4 Sådan kommer du i gang... 5 TV-guide... 6 Bio... 11 Indstillinger... 12 AirPlay på ipad...

Læs mere

TCP/IP stakken. TCP/IP Protokollen består af 5 lag:

TCP/IP stakken. TCP/IP Protokollen består af 5 lag: Trådløse netværk TCP/IP stakken TCP/IP er nok den mest benyttede netværks protokol. Protokollen har fået sit navn efter de to vigtigste protokoller i den : Transmission Control Protocol (TCP) og Internet

Læs mere

Bluetooth højttaler BABHCK811_1

Bluetooth højttaler BABHCK811_1 Bluetooth højttaler BABHCK811_1 Tillykke Tillykke med dit nye Amitech produkt! Oplysningerne i denne brugervejledning kan ændres uden varsel. Amitech Danmark A/S er ikke erstatningspligtig i tilfælde

Læs mere

SIP. Session Initiation Protocol TDC IP telefoni Scale. SIP design mål

SIP. Session Initiation Protocol TDC IP telefoni Scale. SIP design mål Session Initiation Protocol TDC IP telefoni Scale design mål Give mulighed for at integrere nye faciliteter efterhånden som de opfindes er ikke en erstatning for det offentlige telefonnet - er helt sin

Læs mere

Optimering af dit trådløse net

Optimering af dit trådløse net Optimering af dit trådløse net Her er en lille guide til nogle forslag du selv kan gøre for at optimere dit trådløse net. Du skal dog være opmærksom på følgende: - Den hastighed du køber er garanteret

Læs mere

BRUGER GUIDE. Waoo Web TV på telefon iphone og Android. Waoo leveres af dit lokale energiselskab

BRUGER GUIDE. Waoo Web TV på telefon iphone og Android. Waoo leveres af dit lokale energiselskab BRUGER GUIDE Waoo Web TV på telefon iphone og Android Waoo leveres af dit lokale energiselskab INDHOLD Velkommen til Waoo Web TV... 4 Sådan kommer du i gang... 5 TV-guide... 6 Bio... 11 Indstillinger...

Læs mere

QoS Design overblik. Agenda. QoS på L3. Trafiktyper. QoS principper. Voice Best-Effort. Klassifikation og mærkning Policing Queing

QoS Design overblik. Agenda. QoS på L3. Trafiktyper. QoS principper. Voice Best-Effort. Klassifikation og mærkning Policing Queing QoS Design overblik QoS på L3 Trafiktyper Voice Best-Effort Agenda QoS principper Klassifikation og mærkning Policing Queing. 1 Lidt forkortelser BE Best Effort Efter bedste evne AF Assured Forwarding

Læs mere

XProtect-klienter Tilgå din overvågning

XProtect-klienter Tilgå din overvågning XProtect-klienter Tilgå din overvågning Tre måder at se videoovervågning på For at skabe nem adgang til videoovervågning tilbyder Milestone tre fleksible brugergrænseflader: XProtect Smart Client, XProtect

Læs mere

IPv6 sameksistens med IPv4. af Laurent Flindt Muller & Jakob Pedersen

IPv6 sameksistens med IPv4. af Laurent Flindt Muller & Jakob Pedersen IPv6 sameksistens med IPv4 af Laurent Flindt Muller & Jakob Pedersen Gennemgangsplan: Network Address Translation Protocol Translation (NAT-PT) - Motivation - IPv4 NAT - NAT-PT - Stateless IP/ICMP Translation

Læs mere

4. Semesterprojekt System Arkitektur. MyP3000 I4PRJ4 E2004

4. Semesterprojekt System Arkitektur. MyP3000 I4PRJ4 E2004 Ingeniørhøjskolen i Århus 20. december 2004 IKT Dalgas Avenue 2 8000 Århus C 4. Semesterprojekt System Arkitektur MyP3000 I4PRJ4 E2004 Gruppe 4: Benjamin Sørensen, 02284 Tomas Stæhr Berg, 03539 Nikki Ashton,

Læs mere

Internet Protokollen. - IP er arbejdshesten på næsten alle netværk! Netteknik 1

Internet Protokollen. - IP er arbejdshesten på næsten alle netværk! Netteknik 1 Internet Protokollen - IP er arbejdshesten på næsten alle netværk! Netteknik 1 Internet Protocol (IP) Om IP protokollen generelt: Er arbejdsprotokollen i moderne netværks-kommunikation; al kommunikation

Læs mere

Streame fra Winamp til Dreambox/pc på netværk.

Streame fra Winamp til Dreambox/pc på netværk. Streame fra Winamp til Dreambox/pc på netværk. 1. Formål 2. Forudsætninger og installationer 3. Opsætning 4. Start streaming 5. Aflyt streaming 6. Kontakt 1. Formål Mange benytter Winamp ( Nullsoft, Inc.)

Læs mere

Kvik guide Mitel MC Klient Android

Kvik guide Mitel MC Klient Android 1 Kvik guide Mitel MC Klient Android Indhold Installation af Klient software Side 2 Installation af ny konfiguration/funktioner/lcr filer Side 3-4 Beskrivelse af faste funktioner Side 5 Beskrivelse af

Læs mere

Indholdsfortegnelse. Installation

Indholdsfortegnelse. Installation Indholdsfortegnelse Generelt om installationen... 2 Installation af Sybase Sybase SQL Anywhere... 3 Installation af Sybase SQL Anywhere... 4 Licensbetingelser... 6 Registreringsnøgle... 7 Bruger information...

Læs mere

Programmering af CS7002 GSM/GPRS modul Version 5

Programmering af CS7002 GSM/GPRS modul Version 5 Comfort CSx75 Programmering af CS7002 GSM/GPRS modul Version 5 Introduktion CS7002 GSM/GPRS modulet er en fuldt integreret enhed som kan sende alarmer trådløst enten via GSM eller GPRS nettet. Der er desuden

Læs mere

Network. Netværks design. Region Syd Grundlæggende netværk

Network. Netværks design. Region Syd Grundlæggende netværk Network Netværks design Region Syd Grundlæggende netværk Emner Design Principper 3 lags modellen Core Distribution Access Netværks typer Egenskaber ved et netværk Design Principer Design Principer Hierarki

Læs mere

Internet Protocol (IP)

Internet Protocol (IP) Internet Protocol (IP) IP protokollen: er arbejdsprotokollen i moderne netværks-kommunikation; al kommunikation går gennem den. adresserer pakkerne på lag 3 (netværkslaget). arbejder med forbindelsesløs

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere

Fjerneksamen sa dan. Indholdsfortegnelse. Ansvar. Eksamensprocessen i overblik. Forår 2013 / v. 3.0. Kære studerende

Fjerneksamen sa dan. Indholdsfortegnelse. Ansvar. Eksamensprocessen i overblik. Forår 2013 / v. 3.0. Kære studerende Fjerneksamen sa dan Kære studerende Forår 2013 / v. 3.0 Når du skal til fjerneksamen, foregår eksamen på nettet. Det stiller nogle krav til både dig og teknikken, som du kan læse om i dette dokument. Det

Læs mere

QUICK GUIDE. Waoo Web TV på ipad FIBERBREDBÅND TV TELEFONI

QUICK GUIDE. Waoo Web TV på ipad FIBERBREDBÅND TV TELEFONI QUICK GUIDE Waoo Web TV på ipad FIBERBREDBÅND TV TELEFONI INDHOLD Velkommen til Waoo Web TV på ipad... 4 Det er nemt at komme i gang... 5 AirPlay... 16 FAQ... 18 Kontaktinformation... 20 VELKOMMEN TIL

Læs mere

Efficient Position Updating

Efficient Position Updating Efficient Position Updating Pervasive Positioning, Q3 2010 Lasse H. Rasmussen, 20097778 Christian Jensen, 20097781 12-03-2010 1 Introduktion Denne rapport har til formål at beskrive implementeringen og

Læs mere

Med Fokus på Fremtiden

Med Fokus på Fremtiden Med Fokus på Fremtiden Din guide til MJ Vision videoovervågning i HD Tlf.: +45 70 20 82 12 Email.: Info@mjvision.dk Web.: www.mjvision.dk Hvorfor vælge? Herunder en guide 1 2 3 4 5 6 7 8 Hvad er Økonomi

Læs mere

Hvordan afspilles/vises materialet i LARM.fm

Hvordan afspilles/vises materialet i LARM.fm Hvordan afspilles/vises materialet i LARM.fm Når du har lært de mange måder, hvorpå det er muligt at søge i LARM.fm s materiale, er det relevant at vide, hvilke muligheder du har for at afspille radio-

Læs mere

Nexus IP Quickguide. Til alle Nexus VP og F modeller

Nexus IP Quickguide. Til alle Nexus VP og F modeller Nexus IP Quickguide Til alle Nexus VP og F modeller Indhold 1.0 Første Opsætning... 3 1.1 FYSISK TILSLUTNING... 3 1.2 FIND KAMERAET... 3 1.3 LOG PÅ KAMERAET MED INTERNET EXPLORER 11... 4 1.4 MENUEN...

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

Procesbeskrivelse - Webprogrammering

Procesbeskrivelse - Webprogrammering Procesbeskrivelse - Webprogrammering Indholdsfortegnelse Forudsætninger... 1 Konceptet... 2 Hjemmesiden... 2 Server-side... 3 Filstrukturen... 3 Databasehåndtering og serverforbindelse... 4 Client-side...

Læs mere

Lokationsbestemmelse. Mikkel Baun Kjærgaard ISIS Software Katrinebjerg Department of Computer Science University of Aarhus

Lokationsbestemmelse. Mikkel Baun Kjærgaard ISIS Software Katrinebjerg Department of Computer Science University of Aarhus Lokationsbestemmelse Mikkel Baun Kjærgaard ISIS Software Katrinebjerg Department of Computer Science University of Aarhus Projekt Fokus på fremtiden arkitektur, applikationer og grænseflader til trådløs

Læs mere

Viditronic NDVR Quick Guide. Ver. 2.0

Viditronic NDVR Quick Guide. Ver. 2.0 Viditronic NDVR Quick Guide Ver. 2.0 1 Indholdsfortegnelse 1. HOVEDMENU 3 1.1 START 5 1.2 AKTIVITETSINDIKATOR: 7 1.3 INFORMATIONS VINDUE: 7 1.4 PTZ KAMERA KONTROL: 7 1.5 SKÆRMMENU 8 1.5.1 AKTIVER BEVÆGELSE:

Læs mere

Kommunikationsprotokoller Summit06 worksession. Lisa Wells Datalogisk Institut Aarhus Universitet

Kommunikationsprotokoller Summit06 worksession. Lisa Wells Datalogisk Institut Aarhus Universitet Kommunikationsprotokoller Summit06 worksession Datalogisk Institut Aarhus Universitet Plan Kort introduktion til protokoller Protokoller i ISIS Katrinebjerg projekter Internet-baseret trådløs telefoni

Læs mere

Sådan bruger du BK- 9 Performance List. Formatering af USB- Memory. "Performance List" er en liste over dine registreringer.

Sådan bruger du BK- 9 Performance List. Formatering af USB- Memory. Performance List er en liste over dine registreringer. Sådan bruger du BK- 9 Performance List "Performance List" er en liste over dine registreringer. Hver Performance hukommelse indeholder alle din opsætninger af keyboardet herunder også din rytmestillinger

Læs mere

Indholdsfortegnelse: Firewall Erhvervsakademi Midtjylland

Indholdsfortegnelse: Firewall Erhvervsakademi Midtjylland Indholdsfortegnelse: Indholdsfortegnelse:...1 Indledning:...3 Kort om Astaro Security Linux:...3 Hvad er en firewall?...4 Hvorfor skal man bruge en firewall?...4 Installation af Astaro Security Linux....5

Læs mere

AgroSoft A/S AgroSync

AgroSoft A/S AgroSync AgroSoft A/S AgroSync AgroSync er et AgroSoft A/S værktøj, der bliver brugt til filudveksling imellem WinSvin og PocketPigs. Fordele ved at bruge AgroSync: Brugeren bestemmer overførsels tidspunktet for

Læs mere

Manual til at arbejde med POI på Garmin GPS.

Manual til at arbejde med POI på Garmin GPS. Manual til at arbejde med POI på Garmin GPS. Michael Pedersen (mike42dk) mike42dk@gratispoi.dk Juli 2009 Version 2.1 Jeg fralægger mig alt ansvar for den skade du kan komme til at forsage ved din GPS,

Læs mere

SIP. Session Initiation Protocol. TDC IP telefoni Scale

SIP. Session Initiation Protocol. TDC IP telefoni Scale SIP Session Initiation Protocol TDC IP telefoni Scale SIP design mål Give mulighed for at integrere nye faciliteter efterhånden som de opfindes SIP er ikke en erstatning for det offentlige telefonnet -

Læs mere

MANUAL. Præsentation af Temperaturloggerdata. Version 2.0

MANUAL. Præsentation af Temperaturloggerdata. Version 2.0 MANUAL Præsentation af Temperaturloggerdata Version 2.0 Indholdsfortegnelse FORORD...3 INTRODUKTION...3 KRAV OG FORUDSÆTNINGER...3 INSTALLATION...4 OPSÆTNING...8 PROGRAMOVERBLIK...10 PROGRAMKØRSEL...11

Læs mere

Brugervejledning. Trådløs HD Sender & Modtager Sæt

Brugervejledning. Trådløs HD Sender & Modtager Sæt Brugervejledning Trådløs HD Sender & Modtager Sæt Indholdsfortegnelse Functions and features... Fejl! Bogmærke er ikke defineret. Package contents... Fejl! Bogmærke er ikke defineret. 1. Product overview...

Læs mere

1 Introduktion Funktioner 3. 2 Kom godt i gang Pakkens indhold Oversigt over kameraet 5. 3 Installation 6

1 Introduktion Funktioner 3. 2 Kom godt i gang Pakkens indhold Oversigt over kameraet 5. 3 Installation 6 Indhold 1 Introduktion 3 1.1 Funktioner 3 2 Kom godt i gang 4 2.1 Pakkens indhold 4 2.2 Oversigt over kameraet 5 3 Installation 6 3.1 Hardware Installation 6 3.2 Tilføj IP kameraet i app 6 3.3 Tilgå IP

Læs mere

Kvik guide Mitel MC Klient iphone

Kvik guide Mitel MC Klient iphone 1 Kvik guide Mitel MC Klient iphone Indhold Installation af Klient software Side 2 Installation af ny konfiguration/funktioner/lcr filer Side 3-4 Beskrivelse af faste funktioner Side 5 Beskrivelse af menuer

Læs mere

Design Systemkald. User-mode Linux, The Linux kernel/325-2004

Design Systemkald. User-mode Linux, The Linux kernel/325-2004 Tracing tråden afbryder systemkaldet via ptrace Systemkaldet til værten ændres til getpid Processens stak manipuleres til at kalde kernen Kernen returnerer til processen Design Systemkald Design Startup/shutdown

Læs mere

Quickguide. Dansk quickguide til Nexus IP opsætning

Quickguide. Dansk quickguide til Nexus IP opsætning Quickguide Dansk quickguide til Nexus IP opsætning Contents NVR guide... 3 1.0 Optageren:... 3 1.1 Tilslutning... 3 1.2 Installation af harddisk:... 3 2.0 Først gang din optager bliver startet:... 4 3.0

Læs mere

Velkommen til BEHRINGER PODCAST hurtigstart guiden

Velkommen til BEHRINGER PODCAST hurtigstart guiden Velkommen til BEHRINGER PODCAST hurtigstart guiden Tak for tilliden af valget af et af vore podcast kompatible produkter. Denne fremragende software og hardware pakke muliggør produktion af podcasts af

Læs mere

Kvik guide AMC Klient Android

Kvik guide AMC Klient Android 1 Kvik guide AMC Klient Android Indhold Installation af Klient software Side 2 Installation af ny konfiguration/funktioner/lcr filer Side 3-4 Beskrivelse af faste funktioner Side 5 Beskrivelse af menuer

Læs mere

The ADSL-optimizer: Korrekt trafikstyring på ADSL linier

The ADSL-optimizer: Korrekt trafikstyring på ADSL linier The ADSL-optimizer: Korrekt trafikstyring på ADSL linier Trafikstyring i bolignet d.8/6-2005 Foredrag: Baseret på mit datalogi speciale af Jesper Dangaard Brouer Cand. Scient Datalog Datalogisk

Læs mere

Brugermanual Model Raxtune Oxygen

Brugermanual Model Raxtune Oxygen VST DAB+yourCar v2 DAB bil-receiver og Kontrolsystem (DAB/DAB+) Brugermanual Model Raxtune Oxygen Professionel installation er påkrævet Indholdsfortegnelse 1. Introduktion 2. Hvordan systemet virker 3.

Læs mere

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Programmering C Eksamensprojekt Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Indledning Analyse Læring er en svær størrelse. Der er hele tiden fokus fra politikerne på, hvordan de danske skoleelever kan

Læs mere

Manual for VALTRONICS IP kamera Android APP

Manual for VALTRONICS IP kamera Android APP Manual for VALTRONICS IP kamera Android APP Herunder vises forskellige måder hvorpå man kan installere sin Android APP for Valtronics undendørs kamera. 1) Søg og installer din Android mobil APP via Play

Læs mere

QoS Design overblik. QoS på L3

QoS Design overblik. QoS på L3 QoS Design overblik QoS på L3 Trafiktyper Voice Best-Effort QoS principper Agenda Klassifikation og mærkning Policing Queing. Lidt forkortelser BE Best Effort Efter bedste evne AF Assured Forwarding Sikret

Læs mere

Applikationen Klip (dansk)

Applikationen Klip (dansk) Applikationen Klip (dansk) PMH Version 3.0-0315 Indhold 1 Manual 2 1.1 Vejledning................................. 2 1.1.1 Starten.............................. 8 1.1.2 Strækkene mellem posterne...................

Læs mere

WiFi Vejledning. Smart serien 2016

WiFi Vejledning. Smart serien 2016 WiFi Vejledning Smart serien 2016 Forudsætninger for opkobling: En smartphone (ios el. Android) med app en Smart Airconditioner af Samsung installereret. Husk at opdatere denne hvis installationen er af

Læs mere

Introduktion til Quality of Service

Introduktion til Quality of Service Introduktion til Quality of Service Henrik Thomsen/EUC MIDT 2005 IP standard service IP er designet til best-effort services Best-effort: Transport af data efter bedste-evne IP er fra starten designet

Læs mere

Installation og ibrugtagning af Geomagic Alibre Vault

Installation og ibrugtagning af Geomagic Alibre Vault Karl Lausten Bright Ideas Tlf.:+45 98 62 28 37 Mejsevej 8 Email: klausten@bright-ideas.dk DK-9600 Aars www.bright-ideas.dk CVR 26 85 59 69 12.02.2014 Installation og ibrugtagning af Geomagic Alibre Vault

Læs mere

AFN2208N+ Wi-Fi forstærker 300mBit op til 2500 meters rækkevidde vandtæt.

AFN2208N+ Wi-Fi forstærker 300mBit op til 2500 meters rækkevidde vandtæt. AFN2208N+ Wi-Fi forstærker 300mBit op til 2500 meters rækkevidde vandtæt. WiFi forstærker/router med op til 2500 meters rækkevidde og med DANSK quick guide/installationsvejledning. Denne WiFi forstærker

Læs mere

Synkron kommunikation

Synkron kommunikation Synkron kommunikation Synkron kommunikation betyder, at kommunikationen foregår her og nu, med ingen eller kun lidt forsinkelse. De to kommunikatorer er synkrone de "svinger i samme takt". Et eksempel

Læs mere

ereolen.dk -Sådan downlåner du -Sådan anvender du på ebogslæser, tablet og smartphone

ereolen.dk -Sådan downlåner du -Sådan anvender du på ebogslæser, tablet og smartphone Side 1 af 18 ereolen.dk -Sådan downlåner du -Sådan anvender du på ebogslæser, tablet og smartphone Side 2 af 18 Indholdsfortegnelse ereolen.dk... 1 1. Første gang du vil anvende ereolen.dk... 3 1.1 Opret

Læs mere

Installation af GPS med tilslutning til USB port

Installation af GPS med tilslutning til USB port Indholdsfortegnelse Opsætning af GPS-tilslutning... 1 1: Installation af driver... 2 2: Opsætning af COM-port... 2 3: Vælg COM-port i DLS NG... 3 4: Brug af GPSViewer testprogram... 5 5: Hvis COM-port

Læs mere

Call Recorder Apresa Brugermanual

Call Recorder Apresa Brugermanual Call Recorder Apresa Brugermanual Version. 1.100.11 Vidicode Pleje og vedligeholdelse: CR Apresa må ikke blive våd. Hvis den bliver våd, tør den omgående af med en blød, ren klud. Væsker kan indeholde

Læs mere

Rx: Treating bugs as allergies a safe method to survive software failures. DIKU, Datalogisk Institut, Københavns Universitet 04/01/2006

Rx: Treating bugs as allergies a safe method to survive software failures. DIKU, Datalogisk Institut, Københavns Universitet 04/01/2006 Rx: Treating bugs as allergies a safe method to survive software failures DIKU, Datalogisk Institut, Københavns Universitet 04/01/2006 Præsentation af Jacob Munk-Stander & Lauge Wulff Rx Grund-ide: Hvis

Læs mere

Betjeningsvejledning. til. Vandkiosk. system

Betjeningsvejledning. til. Vandkiosk. system Betjeningsvejledning til Vandkiosk system Programnummer 731043 Tegningsnummer 201013 / 201019 www.tarp.dk 2012-02-20 1 Kundebetjening :... 4 AFLÆSNING AF DATA: 4 INDLÆSNING AF SPÆRRINGER: 4 FEJLMEDDELELSER:

Læs mere

IP & GPRS IP (+ GPRS) transceivere

IP & GPRS IP (+ GPRS) transceivere IP & GPRS IP (+ GPRS) transceivere IP/GPRS serie IP ER FREMTIDEN FRA ANALOG TIL DIGITAL Den perfekte løsning i enhver situation Transmission af alarminformation via IP at slutbruger er nødt til at udskifte

Læs mere

CSX 75 Comfort serien

CSX 75 Comfort serien CSX 75 Comfort serien Kom godt igang CS7002 GSM/GPRS modulversion 4.4 CS7002 GSM/GPRS modulet kan sende alarmer trådløst enten via GSM eller GPRS, det kan også fungere som backup for centralens analoge

Læs mere

MyWay. ios & Android

MyWay. ios & Android MyWay ios & Android MyWay Brugervejledning a2i Systems ApS Blangstedgårdsvej 8 DK-5220 Odense SØ Denmark Telefon: +45 7020 3120 Mail: support@a2i.dk Web: www.a2i.dk Det er tilladt at tage kopier af dette

Læs mere

TRUST WIRELESS VIDEO & DVD VIEWER

TRUST WIRELESS VIDEO & DVD VIEWER TRUST WIRELESS VIDEO & DVD VIEWER Brugervejledning Version 1.0 1 1. Æskens indhold Kontroller venligst æskens indhold. Den skal indeholde følgende: 1. Transmitter (sender) 2. Modtager 3. Strømforsyning

Læs mere

IP routing. - flytter pakkerne effektivt på lag 3! Netteknik 1

IP routing. - flytter pakkerne effektivt på lag 3! Netteknik 1 IP routing - flytter pakkerne effektivt på lag 3! Netteknik Routingsteknik Routere er de enheder på netværket som kan flytte IP datapakker mellem forskellige logiske netværk (IP net) Router IP pakke protocol

Læs mere

Automatiser dine redigeringer med Sony Vegas Pro Produktion Assistant Software

Automatiser dine redigeringer med Sony Vegas Pro Produktion Assistant Software Automatiser dine redigeringer med Sony Vegas Pro Produktion Assistant Software Gary Rebholz Ved siden af din viden og færdigheder med Vegas Pro software, der intet tilbyder dig mere produktivitetsforbedringer

Læs mere

Det Nye Testamente lyd-app. v. Stefan Lykkehøj Lund

Det Nye Testamente lyd-app. v. Stefan Lykkehøj Lund Det Nye Testamente lyd-app v. Stefan Lykkehøj Lund Indledning For nogle år siden, fik jeg Det Nye Testamente som lydbog på USB. I starten lyttede jeg en del med tiden blev det dog til mindre og mindre.

Læs mere

Vejledning til Kilometer Registrering

Vejledning til Kilometer Registrering Vejledning til Kilometer Registrering iphone Appen som holder styr på dit firma og privat kørsel. Udviklet af Trisect Development 2011. www.trisect.dk For iphone version 4.2 og nyere. Med Kilometer Registrering

Læs mere

InterWalk brugermanual. Specifikt til iphone og ipod touch

InterWalk brugermanual. Specifikt til iphone og ipod touch InterWalk brugermanual Specifikt til iphone og ipod touch Indholdsfortegnelse 1. Sådan kommer du godt i gang med InterWalk... 3 1.1 Kort introduktion... 3 1.2 Sådan låser du din skærm op og åbner InterWalk

Læs mere

Radio R 4.0 IntelliLink FAQ

Radio R 4.0 IntelliLink FAQ Indholdsfortegnelse 1. Audio... 1 2. Telefon... 2 3. Apple CarPlay... 2 4. Android Auto... 5 5. Galleri... 7 6. Andet... 8 1. Audio Sp.: Hvordan kan jeg skifte mellem forskellige lydkilder (f.eks. FM-radio

Læs mere

Vidicode præsentation. Aldrig har kommunikation været så let, enkelt og effektivt.

Vidicode præsentation. Aldrig har kommunikation været så let, enkelt og effektivt. Vidicode præsentation Aldrig har kommunikation været så let, enkelt og effektivt. Produkter & løsninger Grey Line Single kanal Call Recordere Silver Line Multi kanal Call Recordere Ruby Line Multi kanal

Læs mere

BRUGERVEJLEDNING FLTA

BRUGERVEJLEDNING FLTA V2.2 (5.06.202) () FUNKTIONSPRINCIP fungerer som en basisstation for trådløse transmittere. Controller og målinger kan transmitteres via basestationen til de kontrolsystemer, der understøtter Modbus RTU-protokollen.

Læs mere

Brugsvejledning. ABAX Kørebog. www.abax.dk. The difference is ABAX

Brugsvejledning. ABAX Kørebog. www.abax.dk. The difference is ABAX Brugsvejledning ABAX Kørebog www.abax.dk The difference is ABAX 2 The difference is ABAX Indhold Til lykke med dit valg af ABAX kørebog 3 Brug af kørebogen 3 Menuer 3 Kørebog 4 Turdetaljer 5 Slå ture sammen

Læs mere

Modulationer i trådløs kommunikation

Modulationer i trådløs kommunikation Modulationer i trådløs kommunikation Valg af modulationstype er et af de vigtigste valg, når man vil lave trådløs kommunikation. Den rigtige modulationstype kan afgøre, om du kan fordoble din rækkevidde

Læs mere

15. Digital kode vælger (hvid DIP switch) 16. Kanal vælger (gul DIP switch) 17. Batteri hus

15. Digital kode vælger (hvid DIP switch) 16. Kanal vælger (gul DIP switch) 17. Batteri hus Babyalarm MBF 8020 DK 1.. INDHOLD 1 x sender med integreret oplader, 1 x modtager, 1x ladestation for oplader 2 x strømforsyninger, 2 x specielle opladte batteri pakker 1 x Bruger manual 2.. KOMPONENTER

Læs mere

Introduktion til CD ere og Arkivdeling Gammel Dok - September-oktober 2003. Jonas Christiansen Voss

Introduktion til CD ere og Arkivdeling Gammel Dok - September-oktober 2003. Jonas Christiansen Voss Introduktion til CD ere og Arkivdeling Gammel Dok - September-oktober 2003 Jonas Christiansen Voss 2. marts 2004 Indhold 1 CD ere 2 1.1 Brænde dokumenter til CD....................... 2 1.2 Disk Copy.................................

Læs mere

tube tube Brugermanual Internet Radio Digital Radio OXX Digital 2010 1 Follow OXX DIGITAL on twitter Follow OXX DIGITAL Scandinavian

tube tube Brugermanual Internet Radio Digital Radio OXX Digital 2010 1 Follow OXX DIGITAL on twitter Follow OXX DIGITAL Scandinavian N E X T G E N E R A T I O N R A D I O tube Brugermanual Internet Radio tube OXX Digital 2010 1 Follow OXX DIGITAL on twitter Follow OXX DIGITAL Scandinavian on facebook Design Indhold Oversigt...3 Front

Læs mere

Huset 2 overblik 4 Følgende kamera systemer kan linkes til DBM 6000 : Avermedia, Dallmeier, GeoVision, Milestone, Mirasys, Seetec, VisiMAX Kameraet kan tilgåes via installations vinduet, bygningstegningen

Læs mere

BRUGER GUIDE. Waoo Web TV på computer via waoo.tv. Waoo leveres af dit lokale energiselskab

BRUGER GUIDE. Waoo Web TV på computer via waoo.tv. Waoo leveres af dit lokale energiselskab BRUGER GUIDE Waoo Web TV på computer via waoo.tv Waoo leveres af dit lokale energiselskab INDHOLD Velkommen til Waoo Web TV... 4 Sådan kommer du i gang... 5 Betjeningsguide... 8 TV-guide... 10 Bio...

Læs mere

High-Performance Data Mining med SAS Enterprise Miner 14.1

High-Performance Data Mining med SAS Enterprise Miner 14.1 High-Performance Data Mining med SAS Enterprise Miner 14.1 nye procedurer til en mere effektiv modeludviklingsproces Kristina Birch, Advisory Analytical Consultant, SAS Institute Indhold Hvad er High-Performance

Læs mere

Netteknik 1. AMU kursus nr Netværk grundlæggende ( AMU Netteknik 1 ) - anvendelse af teknologier og begreber. Formålet med kursus

Netteknik 1. AMU kursus nr Netværk grundlæggende ( AMU Netteknik 1 ) - anvendelse af teknologier og begreber. Formålet med kursus Netteknik 1 - anvendelse af teknologier og begreber AMU kursus nr. 44947 Formålet med kursus Overblik over Internet teknologier Sammenhængen mellem TCP/IP net og Pc en Ethernet-teknologi Ethernet switches

Læs mere

Quickstart Guide. Dansk

Quickstart Guide. Dansk Quickstart Guide Dansk Support: For produktregistrering, besøg venligst ION hjemmeside: ionaudio.com For de seneste oplysninger om dette produkt, kan du besøge hjemmesiden ionaudio.com/blockpartylive.

Læs mere

BRUGERVEJLEDNING TÆND-SLUK ENHED

BRUGERVEJLEDNING TÆND-SLUK ENHED BRUGERVEJLEDNING TÆND-SLUK ENHED Side 1 til tænd-sluk enheden Introduktion Med tænd-sluk enheden fra LOCKON kan du styre strømmen i din bolig. Du kender princippet fra de traditionelle tænd-sluk ure, der

Læs mere

Hvad skal du vide for at bygge din egen computer?

Hvad skal du vide for at bygge din egen computer? Hvad skal du vide for at bygge din egen computer? Kender du alle de her dele og hvad de gør godt for? Er du mellem 11 og 16 år, og tænker på at sammensætte din egen computer? Så er denne her guide lige

Læs mere

Datalogi 1F rapportopgave K2 Anonym datakommunikation

Datalogi 1F rapportopgave K2 Anonym datakommunikation Datalogi 1F rapportopgave K2 Anonym datakommunikation 23. april 2004 1 Administrativ information Rapportopgave K2 stilles fredag den 23. april 2004 og skal afleveres senest fredag den 14. maj kl. 11:00

Læs mere

Fang Prikkerne. Introduktion. Scratch

Fang Prikkerne. Introduktion. Scratch Scratch 2 Fang Prikkerne All Code Clubs must be registered. Registered clubs appear on the map at codeclubworld.org - if your club is not on the map then visit jumpto.cc/ccwreg to register your club. Introduktion

Læs mere

Kvik start opsætning af kamera det første du skal gøre:

Kvik start opsætning af kamera det første du skal gøre: Kom godt i gang Tillykke med købet af Valtronics Trådløst IP kamera. Denne quickmanual kan bruges til alle Valtronics IP kameraer. Kameraet giver mulighed for at fjenovervåge steder via sin mobiltelefon

Læs mere

Forår 2012 - Firewalls

Forår 2012 - Firewalls Syddansk Universitet DM830 - Netværkssikkerhed Imada - Institut for matematik og datalogi Forår 2012 - Firewalls Forfatter: Daniel Fentz Johansen Alexei Mihalchuk Underviser: Prof. Joan Boyar Indhold 1

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Vocally 3 Infinity. In-Line, stemme aktiveret opkaldsenhed Brugsanvisning. Rev 1.01

Vocally 3 Infinity. In-Line, stemme aktiveret opkaldsenhed Brugsanvisning. Rev 1.01 Vocally 3 Infinity In-Line, stemme aktiveret opkaldsenhed Brugsanvisning Rev 1.01 Dette er en Dansk udgave af producentens officielle bruger manual. Der henvises til den officielle i tvivls tilfælde og

Læs mere

Program Dokumentation PC Software Skrevet af. Gruppen. Version 1.0

Program Dokumentation PC Software Skrevet af. Gruppen. Version 1.0 Program Dokumentation PC Software Skrevet af Gruppen. Version 1.0 Indholds fortegnelse 1. INDLEDNING...3 1.1. FORMÅL...3 1.2. REFERENCER...3 1.3. VERSIONSHISTORIE...3 1.4. DEFINITIONER...3 1.5. DOKUMENTATIONENS

Læs mere

Brugermanual til MOBI:DO Make på Android

Brugermanual til MOBI:DO Make på Android Brugermanual til MOBI:DO Make på Android Introduktion Med MOBI:DO Make kan du oprette guides, som kan ses i MOBI:DO. En guide virker som en guide der fører brugeren hele vejen igennem en arbejdsopgave.

Læs mere

Brugermanual SuperSail (DS Version) Performance System Release 1.0

Brugermanual SuperSail (DS Version) Performance System Release 1.0 Brugermanual SuperSail (DS Version) Performance System Release 1.0 Dokument: SuperSail DS Users Manual 1.0.docx Dato: 09. December - 2013 Revision: 1.0 Antal sider: 19 Side 1 af 19 Indholdsfortegnelse

Læs mere

MVT380 Vejledning. Forord. Website: www.smartgps.dk Kontakt: salg@smartgps.dk. Tillykke med din nye GPS tracker MVT380.

MVT380 Vejledning. Forord. Website: www.smartgps.dk Kontakt: salg@smartgps.dk. Tillykke med din nye GPS tracker MVT380. MVT380 Vejledning Forord Tillykke med din nye GPS tracker MVT380. Denne manual viser hvordan du installerer enheden korrekt. Sørg for at læse denne manual grundigt, før du bruger dette produkt. Brugermanualen

Læs mere