Analyzer & Equalizer

Afdeling for kommunikations teknologi 19. december 2002Aalborg Universitet

Gruppe 506

AALBORG UNIVERSITET

INSTITUT FOR ELEKTRONISKE SYSTEMER

AFDELING FOR KOMMUNIKATIONSTEKNOLOGI

Fredrik Bajersvej 7 DK-9220 Aalborg Øst Telefon 96 35 80 80

TITEL:Analyzer & Equalizer

TEMA:Apparat/system konstruktion

PROJEKTPERIODE:5. semesterseptember til december 2002

PROJEKTGRUPPE:506

GRUPPEMEDLEMMER:Dan Dejgård HermansenKristian KjærHans Johnny Nørgaard MadsenTorben Nørregaard MatzenMorten Højfeldt RasmussenSteven André SkaaningJesper Mølgaard Sommerset

VEJLEDER:Søren Krarup Olesen

OPLAGSTAL: 10

RAPPORT: 63

AFSLUTTET: 19. december 2002

SYNOPSIS

Formålet med dette projekt erSKAL SKRIVES.......

Projektgruppe 506, Aalborg Universitet

ForordDenne rapport er udarbejdet af gruppe 506, 5. semester på elektronik og elektroteknikved Institut for elektroniske systemer, Aalborg Universitet. Målgruppen for rapporten ermedstuderende.

Referencer til den benyttede litteratur er udført efter Harvard-metoden, med kilderneopstillet alafabetisk efter forfatteren, hvor denne kendes. En reference før et punktumhenviser til specifik information i den foregående sætning. En henvisning efter et punk-tum henviser til det foregående afsnit. Hvor en kilde danner grundlag for et helt kapiteler dette anført i starten af kapitlet.Vedlagt findes en CD, som indeholder datablade, rapporten i PDF- og DVI-format, samtkildekode til den under projektet udarbejdede software. En henvisning til en fil på denvedlagte CD er i rapportteksten udført som følger: (CD-ROM, , projektoplaeg.pdf).Filen "projektoplaeg.pdf"kan her findes i biblioteket "rapport/"på CD’en.Henvisning til et brudstykke af kildekoden er i rapportteksten udført som følger:/* Kode taget fra aegui.cpp */. Kildekodeudsnittet kan her findes under afsnittetaegui.cpp i appendiks. [*Note *] Muligvis skal der nævnes noget

om testrammernes placering, oghvorvidt de er i appendiks eller ej

Dokumentation for klassetest forefindes i de relaterende afsnit under softwaredesign,hvorimod integrationstestene for klasserne forefindes i appendiks. Apparaturliste, eldia-gram samt komponentliste er indsat sidst i rapporten.

Hvor tal i hexadecimal benyttes er disse anført med syntaksen: 0xA1, som representeretallet 161 i traditionel decimalnotation, hvor 0x-præfikset angiver hexadecimalnotation.

I forbindelse med forsøg i det lyddøde rum vil vi gerne rette tak til Claus Vestergaardfor en storstillet hjælp med apparaturvalg, opstilling og målinger.

Dan Dejgaard Hermansen Kristian Kjær

Hans Johnny Nørgaard Madsen Torben Nørregaard Matzen

Morten Højfeldt Rasmussen Steven André Skaaning

Jesper Mølgaard Sommerset

Aalborg Universitet, 19. december 2002

Indhold

1 Indledning 1

2 Problemanalyse 22.1 Softwareanalyse og -design med UML . . . . . . . . . . . . . . . . . . 22.2 Foranalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.5 Afslutning på problemanalysen . . . . . . . . . . . . . . . . . . . . . . 8

3 Designfase 93.1 Design af filtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Frekvensområde og opdeling i frekvensbånd . . . . . . . . . . 93.1.2 Udregning af knækfrekvenser . . . . . . . . . . . . . . . . . . 93.1.3 Program til udregning af knækfrekvenser . . . . . . . . . . . . 93.1.4 Båndpasfiltre til analyzer . . . . . . . . . . . . . . . . . . . . . 113.1.5 Digital filterdesign . . . . . . . . . . . . . . . . . . . . . . . . 133.1.6 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Design af software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Softwaredesign 214.1 Indledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Fejlhåndtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 CExternal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3.1 System V IPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.2 Tilfældet CExternal . . . . . . . . . . . . . . . . . . . . . . . . 244.3.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 CSound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.1 Behandling af data til CSoundCard . . . . . . . . . . . . . . . 264.4.2 Afspilning af pink noise . . . . . . . . . . . . . . . . . . . . . 264.4.3 Fejlhåndtering . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.4 Testramme for funktionerne . . . . . . . . . . . . . . . . . . . 27

4.5 Interface til lydkort . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5.1 Initialisering af lydkort . . . . . . . . . . . . . . . . . . . . . . 274.5.2 Afspilning og optagelse . . . . . . . . . . . . . . . . . . . . . 284.5.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.6 CAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6.1 Båndpasfiltrenes RMS-værdier . . . . . . . . . . . . . . . . . . 304.6.2 Returnering af RMS-værdier . . . . . . . . . . . . . . . . . . . 31

Indhold iii

4.6.3 Fejlhåndtering . . . . . . . . . . . . . . . . . . . . . . . . . . 314.6.4 Testramme for funktionaliterne . . . . . . . . . . . . . . . . . . 32

4.7 Implementering af filtre . . . . . . . . . . . . . . . . . . . . . . . . . . 324.7.1 Test af CFilter . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.8 Den grafiske brugerflade . . . . . . . . . . . . . . . . . . . . . . . . . 334.8.1 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.8.2 Projektets grafiske brugerflade . . . . . . . . . . . . . . . . . . 354.8.3 Aegui - GUI’s main window . . . . . . . . . . . . . . . . . . . 364.8.4 CButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.8.5 GraphWindow . . . . . . . . . . . . . . . . . . . . . . . . . . 404.8.6 Kodning af en speciel Qt widget . . . . . . . . . . . . . . . . . 414.8.7 CSliderWindow . . . . . . . . . . . . . . . . . . . . . . . . . . 424.8.8 CPlayWindow . . . . . . . . . . . . . . . . . . . . . . . . . . 444.8.9 Trådet styring af data, signaler og fejlhåndtering . . . . . . . . 46

4.9 Integrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 Konklusion 51

Litteratur 52

6 Nomenklaturliste 53

A Mikrofon 54A.1 Forsøg i lyddødt rum . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

B Apparaturliste 57

C Komponentliste 58

D UML 59

E Kildekode 60

Bilag 61

Figurer2.1 Deployment diagram for analyzeren. . . . . . . . . . . . . . . . . . . . 32.2 Deployment diagram for equalizeren. . . . . . . . . . . . . . . . . . . 42.3 Deployment diagram for kalibreringen. . . . . . . . . . . . . . . . . . 42.4 Use case diagram for GUI. . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Sekvensdiagram for adjust frequency characteristics. . . . . . . . . . . 7

3.1 Forhold mellem opdeling i 1N og 1

1 oktav båndbredde. . . . . . . . 10

3.2 Filtrenes overlapning. . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 a) 2. orden og b) 3. ordens polplacering i s-domænet . . . . . . . . . . 123.4 y n som respons på en puls x n 32000 filtreret gennem et 5. ordens

filter. Det bemærkes at filtreret er stabilt . . . . . . . . . . . . . . . . . 15

4.1 Dobbeltbuffer-systemet . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Således er data til lydkortet formateret . . . . . . . . . . . . . . . . . . 294.3 Illustration af placering af RMS-værdier i rmscoeff(). . . . . . . . . . . 314.4 Udkast til GUI, udarbejdet fra usecases. . . . . . . . . . . . . . . . . . 364.5 Illustration af vinduet med nogle af knapperne og radionbutton. . . . . . 384.6 Illustration af signalvejen ved knaptryk. . . . . . . . . . . . . . . . . . 394.7 Oversigt over integrationstestens første trin før overgangen til Main. . . 50

A.1 Placering af mikrofon og højttaleren i henhold til hinanden. . . . . . . . 54A.2 Forsøgopstilling for måling af frekvenskarakteristik. Cifrerne represen-

terer apparaturerne fra tabel B.1, og Mic representerer den konstrueredemikrofon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.3 Frekvenskarakteristik for reference mikrofonen. . . . . . . . . . . . . . 56A.4 Frekvenskarakteristik for den konstruerede mikrofonen. . . . . . . . . . 56A.5 Differencering af frekvenskarakteristik for den konstruerede og refer-

ence mikrofonen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

C.1 Diagram for konstruktionen af mikrofonen samt forstærker til produktet. 58

Tabeller3.1 Metodespecifikation for CExternal. . . . . . . . . . . . . . . . . . . . . 163.2 Metodespecifikation for CButton. . . . . . . . . . . . . . . . . . . . . . 173.3 Metodespecifikation for CSound. . . . . . . . . . . . . . . . . . . . . . 183.4 Metodespecifikation for CSoundCard. . . . . . . . . . . . . . . . . . . 183.5 Metodespecifikation for CAnalyzer. . . . . . . . . . . . . . . . . . . . 193.6 Metodespecifikation for CEqualizer. . . . . . . . . . . . . . . . . . . . 193.7 Metodespecifikation for CGraphWindow. . . . . . . . . . . . . . . . . 193.8 Metodespecifikation for CSliderWindow. . . . . . . . . . . . . . . . . . 203.9 Metodespecifikation for CSlider. . . . . . . . . . . . . . . . . . . . . . 203.10 Metodespecifikation for CFilter. . . . . . . . . . . . . . . . . . . . . . 20

4.1 Metodeoversigt for klassen CAnalyzer . . . . . . . . . . . . . . . . . . 304.2 Trykknapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3 Metodeoversigt for klassen GUIThread . . . . . . . . . . . . . . . . . 46

6.1 Nomenklaturliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

B.1 Apparatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

1Indledning

Projektoplægget (CD-ROM, , projektoplaeg.pdf) for dette projekt omtaler bl.a. målingaf fysiske systemer, såsom mikrofoner, filtre, m.m, i sand tid. Målingerne for systemerneskal være informationsgivende om frekvensgangen, samt afslørende for forvrængn-ingskomponenters størrelse og natur.

Gruppen har et personligt engaragement i produkt udover projketsmæssige aspekter, idetalle gruppens medlemmer er indehavere af pc’er, samt tilhørende multimediehøjttaler.I den forbindelse er det interessant, hvilken kvalitet og egenskaber højttaler og ikkemindst lyden har, der observeres af brugeren.

Et system, der kan måle og foretage en analyse af målinger i forbindelse med frekven-sanalyse, vil være informationsgivende, men vil ikke løse problemet. Til dette vil enequalizer med oplysningerne fra målingerne være problemløseren, idet den aktivt kom-penseres for højttalernes, samt tilnærmelsesvis omgivelsernes, manglende egenskaberog kvalitet. Brugen af systemet skal være fleksibelt, idet der ikke er to brugere, som erens angående lydopfattelse og lydindstilling. Det skal derfor være muligt med person-lige indstillinger, hvilket brugeren muligvis skal guides igennem, da systemet kræverlidt kendskab til funktionen af frekvensområder. Inden systemet kan anvendes skal dendesignes og konstrueres, hvilket leder til følgende initierende problem:

Initierende problem

Problemet som gennem projektet skal løses kan formuleres som følger:Hvordan opbygges et system, der kan kompensere for dårlig lyd i (multimedie-) højt-talere?

2Problemanalyse

[*Note *] Projektoplægget til dette projekt henvender sig bl.a. til computerentusiaster og -Denne indledning er ikke god -bør omskrives!

interesserede, der ønsker den bedst opnåelige lyd fra en PC. Dette mål kan nås vha. etsystem bestående af en analyzer og en equalizer, hvorigennem frekvensindholdet i lydenkorrigeres. Systemet vil være til gavn for såvel afspilning af musik og film som lyd fraspil, da systemet giver en bedre lydoplevelse for brugeren. Om systemet skal bestå afhardware og software eller være ren software er afhængigt af markedsefterspørgsel, menda PC’er efterhånden bliver kraftigere og har en større ydeevne, vil det være fordelagtigt,at det er et softwaresystem, idet systemintegration er mere enkelt end, hvis det er etsystem delvist af hardware og software. En ren softwareløsning kræver kun installationaf et program, hvorimod en ny hardwareenhed kræver installation af såvel et programsom tilslutning af en ekstern eller intern enhed.

Idet Gruppen og dens medstuderende, som computerbrugere, vil være en del af mål-gruppen for produktet, vil det være nærliggende at opsætte kriterier for kravene udfradenne mindre gruppes ønsker til system funktioner. Til opstilling af kravene benyttesdet objektorienterede designsprog, UML1.

2.1 Softwareanalyse og -design med UML

Processen ved udvikling af software kan modelleres på mange forskellige måder strækkendesig fra ustruktureret til struktureret. Der kan findes fordele og ulemper ved begge ek-stremer, men erfaringsmæssigt er objektorienteret (OO) softwareudvikling stort set etandet udtryk for den strukturerede tankegang. Da gruppen i løbet af semestret har gen-nemgået et kursus i objektorienteret analyse og design (OOAD) er det derfor oplagt, attage udgangspunkt heri og samtidig implementere dette i et OO programmeringssprog.

Valget af programmeringssprog er, trods kursets fokusering på Java, faldet på C++ afflere årsager. Fra forrige semester har gruppen erfaring med C og desuden har vejlederindgående kendskab til C++, hvilket i forbindelse med problemløsning har været enfordel.

Kurset i OOAD har taget udgangspunkt i konceptet kaldet Unified Modeling Language(UML), som mest af alt kan karakteriseres som værende en række standardiserede værk-tøjer, der kan benyttes sammen eller hver for sig, alt efter hvilke værktøjer og strategier,der ønskes benyttet til løsningen. Der er skrevet en stor mængde litteratur om UML,hvorfor denne rapport udelukkende omhandler gruppens valg af værktøjer og strategiertil problemløsningen.

1Unified Modeling Language

Foranalyse 3

Problemanalysen afspejler gruppens OOAD, der har ligget til grund for den efterføl-gende implementering. Den opdeles således i en foranalyse, analysen og slutteligt de-signet. Selve implementeringen beskrives i det efterfølgende kapitel.

2.2 Foranalyse

I en ikke undervisningsmæssig situation ville en foranalyse indebære samtaler med kun-den, for at både kunden og udviklerne af systemet kunne spore sig ind på indholdeti systemet og omfanget af den arbejdsmæssige byrde. På baggrund af disse samtalerudarbejdes skitser af delsystemernes fysiske arkitektur. Skitserne kaldes deploymentdiagrammer og konventionelt opbygget med bestemte symboler. De følgende tre de-ployment diagrammer på figur 2.1 til 2.3 på næste side benytter sig ikke fuldstændigt afde konventionelle symboler, men tjener stadig samme formål.

MicFilter

F29

F2

F1 RMS1

RMS2

RMS29

Figur 2.1: Deployment diagram for analyzeren.

På figur 2.1 vises systemets analyzerfunktion og det fremgår heraf, at et signal sendesigennem en mikrofon, hvorefter det opdeles i her 29 filtre (F1...F29). Herefter udregnesgennemsnitsværdien for energien for hvert filterfrekvensbånd (RMS1...RMS29),somendeligt udskrives på skærmen i form af et piktogram, altså et grafisk brugerinterface.

Figur 2.2 på næste side viser en lydfil afspillet igennem en player med efterfølgendefiltrering i de 29 filtre. Sammensætningen af filtrene afhænger af kalibreringen, der kanses på figur 2.3 på den følgende side. Kalibreringen foregår i hovedtræk ved at udsendeet på forhånd kendt signal, der her er et hvidt støjsignal med samme energimængde ihvert frekvensbånd. Efter at være blevet udsendt igennem højttaleren analyseres signaletog findes ændret indenfor en vis margen, hvoraf højttalerens frekvenskarakteristik kanudregnes. På baggrund af den målte afvigelse udregnes filtrene, så de kompenserer forændringerne i højttaleren. Herefter gentages processen indtil filtrene er tilpasset, og denafspillede lydfil matcher den analyserede.

2.3 Analyse

I foranalysen blev udarbejdet deployment diagrammer for de tre overordnede delsyste-mer analyzer, equalizer og kalibrering. På baggrund af disse opstilles en række use cases

4 Problemanalyse

F29

F2

F1

Player

Wav

+

Figur 2.2: Deployment diagram for equalizeren.

f

A

Equalizer

f Analyzerf

AA

+

Ja: StopNej:Nye filtre

ok?Margin

File

Figur 2.3: Deployment diagram for kalibreringen.

Design 5

der i sætninger beskriver hvilke krav brugeren stiller til systemet. Hver enkelt use caseformuleres i samarbejde med kunden som i dette tilfælde anses som værende bruger afsystemet, og som ikke besidder nogen forhåndsviden om den efterfølgende implemen-tation. I gruppens tilfælde er situationen ikke helt reel, men ud fra et objektivt synspunktfandtes følgende use cases: Brugeren trykker på en knap og det måltes frekvensgang reguleres efter den ønskede

frekvensgang. Brugeren skaber den frekvenskarakteristik han ønsker højttaleren og rummet skalhave i målepunktet. Brugeren trykker på en knap og får vist højttalerens og rummets frekvenskarak-teristik (ved mikrofonens placering. Brugeren trykker på en knap og får grafisk præsenteret det måltes frekvensindholdi realtid. Brugeren skal kunne afspille lyd, således at det behandles gennem equalizeren.

De fundne use cases tegnes ind i et use case diagram, som ses i figur 2.4 på næste side.Denne type diagram viser de enkelte use cases, indkapslet i det system de tilhører, samtderes forbindelse til eksterne aktører. Aktører er i denne sammenhæng alle brugere ellersystemer der kommunikerer med det analyserede system. To undersystemer, analyzerenog equalizeren, er ved udarbejdelse af use case diagrammet blevet defineret, og de femuse cases er blevet samlet i use case diagrammet for GUI2, da det er dette undersystembrugeren ser.

Use case diagrammet kan efterfølgende benyttes som baggrund for en uddybende diskus-sion med kunden, hvor udvikleren kan komme med opklarende spørgsmål og lignendefor at sikre, at projektet er godt begyndt. Generelt for OO tankegang er tilbagevendendemøder med kunden med efterfølgende iterationer i analysen, for jo oftere designet kon-trolleres sammen med kunden desto mindre ændringer skal gennemføres per iteration.

2.4 Design

Efter de overordnede krav er blevet opstillet igennem use cases, er for hver use caseklargjort til yderligere analyse. Hver use case gennemgås sekventielt med efterfølgendeudarbejdelse af dertil hørende sekvensdiagrammer. Et eksempel på et sekvensdiagramfor use case Adjust Frequency Characteristic findes på figur 2.5 på side 7. For hverfunktion der skal udføres vil der i sekvensdiagrammet være et nyt punkt og på dennemåde udarbejdes klasserne og deres indhold. De funktioner der skal udføres, svarer tilmetoderne i klasserne og der kan således udarbejdes en metodespecifikation for hverenkelt metode. Et eksempel på metodespecifikation ses herunder:

2Graphical User Interface

6 Problemanalyse

GUI

Show RT−frequencycharacteristic

Show speakerchar.

Correct measuredf−char.

Adjust wanted f−char.

Play song

Stop playing

Bruger

Analyzer

Equalizer

<<include>>

<<extend>>

<<extend>>

Brugeren trykker på en knap ogfår grafisk præsenteret detmåltes frekvensindhold i realtid

Brugeren trykker på en knap ogfår vist højtalerens (og rummets)frekvens−karakteristik (ved mic. placering)

Brugeren trykker på enknap og det måltesfrekvensgang reguleresefter den ønskedefrekvensgang.

Brugeren skaber den frekvens−karakteristik han ønskerhøjtaleren (og rummet) skal havei målepunktet.

Brugeren kan starte afspilningaf en sang, valgt blandt et antalsange, gennem equalizeren.

Brugeren kan stoppeafspilningen af den valgtesang

1.1, GUI

1.1, GUI

Figur 2.4: Use case diagram for GUI.

Design 7

Navn receiveSignal()Input Signal fra sendSignal().Beskrivelse Modtager startsignal fra andet subsystem (ana-

lyzer/equalizer eller GUI).Output Metodekald.

I princippet burde metodespecifikationerne været tilstrækkeligt til at kunne implementerede enkelte metoder. I praksis kræves undervejs en del uddybninger og interface metoderneog klasserne imellem skal stemme overens, hvilket som oftest vil foregå i forbindelsemed integrationstesten som omtales i afsnit.[*Note *] hvilket afsnit bliver det?

Receive signal

Play noise

Store sound instance

Filter sound

Find RMS

Get wanted frequencycharacteristic from file

Compare measured andwanted frequencycharacteristic

Adjust filter coefficients

1.1, Adjust frequency characteristic (equ)

1.1, Adjust frequency characteristic (equ)

Figur 2.5: Sekvensdiagram for adjust frequency characteristics.

8 Problemanalyse

2.5 Afslutning på problemanalysen

Igennem problemanalysen er gennemgået hvorledes gruppen har benyttet sig af OOADved brug af UML. De anvendte værktøjer og strategier fra UML er blevet eksempli-ficeret. Ved udarbejdelsen af use case- og sekvensdiagrammer er benyttet er programkaldet Together, som også har været anvendt i undervisningen. [*Note *] Yderligere infor-Er det her Together skal nævnes,

og er det nok?mation om Together findes ikke nævneværdigt i rapporten.

Den samlede UML dokumentation med diagrammer findes i appendiks D. Udover deher gennemgåede diagrammer findes også et klassediagram, der viser samtlige klasser;et antal kollaborationsdiagrammer som uddybes i afsnit ?? på side ?? omkring integra-tionstest og slutteligt samtlige metodespecifikationer ordnet under klasserne. På ved-lagte CD findes samme dokumentation i html-format, så det kan ses via enhver web-browser med java-understøttelse.

3Designfase

3.1 Design af filtre

For at analysere signalets frekvensindhold, sendes dette gennem et givet antal båndpas-filtre. Antallet af filtre, og båndpasbredden bestemmes af frekvensområdet der analy-seres i, og båndopdelings-metoden.

3.1.1 Frekvensområde og opdeling i frekvensbånd

Det hørbare område strækker sig fra 20Hz til 20kHz[*Note *], hvorfor dette frekvensom- litt. henvisning!!!

råde vælges, dog reduceres den øvre grænse til 16kHz pga. af den valgte mikrofon[*Note

*]. Opdeling i frekvensbånd foretages efter konstant procentopdelt båndbredde, hvilket henvisning!!!

vil sige, at båndbredden udgør en konstant procentdel af den enkelte centerfrekvens.Båndbredden opdeles efter oktav-princippet, dette medfører en logaritmisk frekvens-skala, hvilket er i overensstemmelse med den måde, hvorpå det menneskelige øre hører.Den procentdel af centerfrekvensen som båndbredden udgør, bestemmes efter følgendeformel:

21 N 1 100 (3.1)

, hvor 1N angiver båndbredden i oktav. Ofte benyttede båndbredder:1

1, 1

3, 1

12 og

124 oktav. (Frequency Spectrum, )

3.1.2 Udregning af knækfrekvenser

Ifølge afsnit XX[*Note *] skal der kunne vælges et vilkårlig antal bånd. Dette kan løses ved ref til noget krav/design

at angive 1N oktav båndbredde som input til et program, der opdeler frekvensområdet i

F antal Bånd. Desto højere værdi, der påtrykkes N desto højere F, hvormed opløsningeni frekvensområdet øges. Input kan også direkte være iform af F antal bånd, hvilket vilfremgå af efterfølgende udregninger. Output fra samme program returnerer samtligeknækfrekvenser i frekvensområdet.

3.1.3 Program til udregning af knækfrekvenser

Der tages i programmet udgangspunkt i en centerfrekvens på 1000Hz og 11 oktavs

båndbredde. Udfra disse og båndbredden 1N eller antallet af bånd F, findes de resterende

centerfrekvenser fC_x i frekvensområdet således (se figur 3.1):

10 Designfase

fC_D

Hz

fC_x

Hz

1/N oktavs centerfrekvenser

1/1 oktavs centerfrekvenser

16000

16000

15,63

15,63

D4−6 0

1000

F0 1 2 . .

x

..

Figur 3.1: Forhold mellem opdeling i 1 N og 1 1 oktav båndbredde.

fC_x fC_D 2 x 1N (3.2)

, hvorfC_D 1000 2D D 6 4

udgør den laveste og højeste 11 oktavs centerfrekvens på hhv. 15 63Hz og 16000kHz

, og x 0 1 2 F angiver opdeling i de nye 1N oktavs centerfrekvenser fC_x (se

figur 3.1).

Ved at benytte sig af laveste og højeste 11 oktav centerfrekvens indsat i (3.2):

fC_D D 4 fC_D D 6 2 x 1N (3.3)

, uddrages gennem x F et udtryk for1N, til at indsætte i formel (3.2), når fC_x skal

findes ved F antal bånd som input:

1N

log fC_D D 4 log fC_D D 6

log2F

! " log1024

log2F # 1 (3.4)

På samme måde uddrages et udtryk for antallet af bånd F ved 1N som input:

F log fC_D D 4

log fC_D D 6 log

21 N

" log1024

log21 N (3.5)

Der gives følgende tal-eksempel på at udregne fC_x for filter nummer 6 (x 6) ved 10filtre (F 10):

Design af filtre 11

fC_x 1000 2 # 6 $ 2 % 6 % log & 1024 '

log & 210 ')(*(,+ 1000Hz

Udfra de fundne centerfrekvenser fC_x beregnes de tilhørende knækfrekvenser efter enmodificeret version af udtrykket 3.1. Udtrykket, der er fremyndet gennem studier affigur 3.1, opdeles i to formler; fHP for nedre knækfrekvens og fLP for øvre.

fHP 2 # 1N - 2 fC_x (3.6)

fLP 21

N - 2 fC_x (3.7)

Fremgangsmåden bliver derfor, ved F antal bånd som input, at beregne 1N(formel 3.4),

og dernæst udregne fHP og fLP for samtlige 0 . x . F . For 1N som input beregnes F

(formel 3.5), og derefter fHP og fLP for samtlige 0 . x . F .

fHP fLPfC_x

fHP fLPfC_xfHP fLPfC_x

Hz

dB

0

−3

Figur 3.2: Filtrenes overlapning.

3.1.4 Båndpasfiltre til analyzer

Signalets frekvensindhold findes ved at anvende en række båndpasfiltre på signalet forat opdele dette i række frekvensbånd som omtalt i afsnit 3.1.1 og frem, hvorefter RMSniveauet svarende til energien findes for hvert bånd.

Båndpasforstærkningen skal være 0dB og ved øvre og nedre knækfrekvens skal forstærknin-gen være faldet til 3dB således at summen af båndpasfiltrenes overføringsfunktionerer 0dB. Filtersummen vil afvige fra 0dB idet nabofiltrene vil overlappe og derved giveet yderligere bidrag. Størrelsen af dette bidrag afhænger derfor af filterordnen og bånd-bredden. Således at en højere orden og større båndbredde giver en mindre afvigelse.

Filtreordenen kan bestemmes ud fra krav defineret i anderkendte standarder f.eks DIN.Idet analyseren skal køre i realtid kræves det at de implementerede digitale båndpasfiltre

12 Designfase

kan procesere en sample og beregne RMS hurtigere end 1fs

. Dette betyder at filterordenog antal filtre begrænses af maskinens regnekapacitet.

Idet båndpasfiltrene skal være symmetriske skal høj- og lavpas filtrene være af sammmeorden, dette medfører at båndpasfilterets orden altid vil være lige.

Der ønskes maksimal fladhed i pasbåndet, hvilket betyder at typen skal være af Butter-worth. Dette svarer til at filterets poler ligger på en cirkel med radius Ω0 og er fordeltlige i s-planets venstrehalvplan som skitseret på figur 3.3.

Det generelle Butterworth lavpasfilter af N’te orden hvor pasbåndsforstærkningen er0dB kan udtrykkes som formel 3.8.

Hl ps / N

∏n 0 1

Ω0

s Ω0e jΘ (3.8)

Θ π2n 1 2N 1 π

2

a b

Figur 3.3: a) 2. orden og b) 3. ordens polplacering i s-domænet

Af beregnings grunde opdeles det generelle Butterworth filter af N’te orden i en række 2.ordens filtre med komplexkonjugerede poler samt et 1. ordens filter ved ulige filterorden.En kaskadekobling af disse 1. og 2. ordens sektioner vil give det ønskede Butterworthfilter.

Generelt 2. ordens filter i frekvensdomænet med Laplace operatoren s.

P 2 Ω0e jΘ 2 a 3 jb

H1 4 s 5/2 Ω04 s 6 P 5 2 Ω0

s 3 Ω0

H2 4 s 5/2 Ω204 s 6 P 5 4 s 6 P 785 2 Ω2

0

s2 6 2as 3 a2 3 b22 Ω20

s2 6 2Ω0 cos 4 Θ 5 s 3 Ω20

Eksempel på et 5. ordens lavpas filter som skal indgå i et 10. ordens båndpasfilter.

Design af filtre 13

Hl ps / Ω2

0

s2 2Ω0 cosΘ1 s 1 Ω2

0

Ω20

s2 2Ω0 cosΘ2 s 1 Ω2

0

Ω0

s 1 Ω0

Θn π2n 1 2 5 1 π

2

Θ1 610

π 108 9Θ2 8

10π 144 9

TODO?: Bestemmelse af minimum filterorden for eks. 1 og 1/3 oktav bp-filtre.

3.1.5 Digital filterdesign

Udfra filtrets overføringsfunktion i det analoge s-domnæne skal dette z-transformeres.Dette kan gøres ved matched, impuls invariant eller bilineær z-transformation. I dennesituration anvendes bilineær z-transformation for at udgå aliasing. Aliasing er et prob-lem for de øvre båndpasfiltre som ikke er væsentligt dæmpet ved den halve samplings-frekvens. Dette vil medføre en amplitude karakteristik som afviger væsentligt fra detanaloge prototype filter.

Bilineær z-transform: Ved at anvende denne transformation undgås aliaserings fejl og erderfor den beste tilnærmelse til det prototype filtret. Ved denne transformation erstatess i teorien af formel 3.9 men da ln ikke er på lukket form laves en rimelig tilnærmelse,hvilket ses i formel 3.10.

s 1T lnz (3.9)

s 2T 1 z # 11 1 z # 1

(3.10)

Ved transformationen bliver venstre halvplan i s domænet kortlagt i z domænet indenfor enhedscirklen, således at ∞ : Ω : ∞ bliver til π : ω : π. Dette betyder atden analoge frekvens Ω bliver komprimeret og derfor er det nødvendigt at udføre enprewarp af knækfrekvenserne for at rette op på frekvenskarakteristikken af de digitalefiltre. Prewarpningskonstanten C erstatter 2

T i formel 3.10, og udregnes ved formel 3.11

C arctan ωT

2 (3.11)

De fundne 1. og 2. ordens sektioner i s-domænet z-transformeres individuelt idet z-koefficienterne umiddelbart kan beregnes udfra formler udledt fra det generelle frekvens-normerede 1. og 2. ordens filter i s-domænet. Et eksempel på udregning ses herunder,hvor formel 3.12 på den følgende side udregner en fællesnævner og z-koefficienternetil et 2. ordens lavpasfilter udregnes i formlerne 3.13 til 3.15 (Hüche, 1986, side 376).

14 Designfase

Disse betegnes a0 til a2 for tællerkoefficienterne og b0 til b2 for nævnerkoefficienterne.C er prewarpningskonstanten og n er den enkelte pol, der regnes på.

common_denum 1 2coscplx

n C 1 C2 (3.12)

a0 1common_denum

b0 1 (3.13)

a1 2a0 b1 21 C2

common_denum(3.14)

a2 a0 b2 1 1 2coscplx

n C 1 C2

common_denum(3.15)

Dette giver en 2. ordens sektion i z-domænet beskrevet ved formel 3.16, der på y n -form ser ud som i formel 3.18. Dette filter, og en kaskade af flere 1. ordens og 2. ordenssektioner, kan direkte implementeres i C++, som det ønskes gjort i denne rapport.

Hz / a0 1 a1z # 1 1 a2z # 2

b0 1 b1z # 1 1 b2z # 2 b0 1 (3.16);(3.17)

y n < a0x n 1 a1x n 1 1 a2x n 2 b1y n 1 b2y n 2 (3.18)

3.1.6 Test

Til test af de designede filtres stabilitet, undersøges om polerne i overføringsfunktionenHz ligger indenfor enhedscirkelen i z-planet. Er dette tilfældet for alle 1. og 2. ordens

sektioner, vurderes filtrene som stabile. Med matlab-funktionen pzmap undersøges deenkelte sektioner, og da der ikke fandtes poler med en amplitude større end 1, betragtesfiltrene som stabile.

Dette kan endvidere bekræftes ved, i tidsdomænet, at kaskadekoble 1. og 2. ordenssektioner af båndpasfiltre af en given orden og påtrykke filteret en puls x n af arbitrærstørrelse til tiden n 0. Til alle tider n = 0 gælder x n > 0. Det kan nu forventes aty n @? 0 for n ? ∞, hvilket blev påvist med med et 5. ordens filter, hvor det var tydeligtat y n gik mod 0, og systemet er derfor stabilt. Dette er illustreret på figur 3.4 på næsteside, og matlabfilen for denne test kan ses i ??? [*Note *]cite til filtertest!

Det kan her nævnes at det først blev forsøgt at multiplicere 1. og 2. ordens sektionerne,således at overføringsfunktionen i z-domænet blev til én overføringsfunktion. Ved dennemultiplicering blev der observeret en afvigelse i de endelige filterkoefficienter, og ved et6. ordens båndpasfilter blev systemet ustabilt. Det blev derfor vedtaget at filtrere gennemen sektion af gangen.

Gennem .m-filen bpf.m blev bodeplot af de designede filtre tegnet, og resultatet

Design af software 15

0 20 40 60 80 100 120 140 160 180 200−1500

−1000

−500

0

500

1000

1500Filtrering med 5.ordens filter

y[n]

n

Figur 3.4: y A n B som respons på en puls x A n BDC 32000 filtreret gennem et 5. ordens filter.Det bemærkes at filtreret er stabilt

3.2 Design af software

[*Note *] skal de private metoder med?(cleanUp)

16 Designfase

Navn sendSignal()Input Trigger fra knap eller objekt.Beskrivelse Benyttes til at starte forløb i et andet subsystem (ana-

lyzer/equalizer eller GUI).Output (er ikke sikker; flag, semaphore, messagequeue etc.).Navn receiveSignal()Input Signal fra sendSignal().Beskrivelse Modtager startsignal fra andet subsystem (ana-

lyzer/equalizer eller GUI).Output Metodekald.Navn sendData()Input data:short[], target:short.Beskrivelse Sender data fra et subsystem til et objekt (target:short) i et

andet.Output (Kald til subsystem) data:short[], target:shortNavn receiveData()Input data:short[], target:short.Beskrivelse Modtager data fra andet subsystem og foretager et

metodekald ud fra target.Output Metodekald samt data:short[]Navn getStatus()Input voidBeskrivelse Henter aktuel status for systemOutput currentstatus:shortNavn setStatus()Input short fra knaptryk eller receiveSignal() i CExternalBeskrivelse Opdaterer currentstatus:shortOutput void

Tabel 3.1: Metodespecifikation for CExternal.

Design af software 17

Navn quit()Input Tryk fra bruger på GUI-knapBeskrivelse Sender signal til analyser/equalizer om at lukke processerne

og lukker GUIOutput Kald af “sendSignal” i CExternal og “close”Navn showSpkChar()Input Tryk fra bruger på GUI-knapBeskrivelse Sender signal til analyser/equalizer om at vise højttalerens

frekvenskarakteristikOutput Kald af “sendSignal” og “setStatus” i CExternalNavn showRTFreq()Input Tryk fra bruger på GUI-knapBeskrivelse Sender signal til analyser/equalizer om at vise frekvensind-

holdet i realtidOutput Kald af “sendSignal” og “setStatus” i CExternalNavn correctSpeakers()Input Tryk fra bruger på GUI-knapBeskrivelse Sender signal til analyser/equalizer om at starte korrektio-

nen af højttalerneOutput Kald af “sendSignal” og “setStatus” i CExternalNavn playSong()Input Tryk fra bruger på GUI-knapBeskrivelse Sender signal til ??????Output Kald af “sendSignal” i CExternal og “setStatus”Navn stopPlaying()Input Tryk fra bruger på GUI-knapBeskrivelse Sender signal til ??????Output Kald af “sendSignal”i CExternal og “setStatus”Navn storeWanted()Input Tryk fra bruger på GUI-knapBeskrivelse Sender signal til ??????Output Kald af “sendSignal” i CExternal og “setStatus”Navn setDefaults()Input Tryk fra bruger på GUI-knapBeskrivelse Sender signal til ??????Output Kald af “sendSignal” i CExternal og “setStatus”Navn setStatus()Input ?????Beskrivelse Sender signal til ??????Output Kald af ??????Navn fetchStatus()Input ?????Beskrivelse Sender signal til ??????Output Kald af ?????

Tabel 3.2: Metodespecifikation for CButton.

18 Designfase

Navn playNoise()Input voidBeskrivelse Afspiller en fil med pink noiseOutput voidNavn outputSound()Input voidBeskrivelse Sender data fra sound:signed short[] til CSoundCardOutput void

Tabel 3.3: Metodespecifikation for CSound.

Navn getIPointer()Input voidBeskrivelse Henter pointer til inputbufferOutput signed short*Navn getOPointer()Input voidBeskrivelse Henter pointer til outputbufferOutput signed short*Navn getBufferLength()Input voidBeskrivelse Henter in- og outputbuffernes længdeOutput intNavn init()Input int bits, int sampling_frequencyBeskrivelse Initialiserer lydkortetOutput voidNavn start()Input voidBeskrivelse Sætter lydkortet i gang med at afspille og optageOutput voidNavn pause()Input voidBeskrivelse Pauser afspilning og optagelseOutput voidNavn stop()Input voidBeskrivelse Stopper afspilning og optagelseOutput voidNavn cleanUp()Input int errBeskrivelse Lukker lydkortet, unmapper mapped memmory og kaster en

fejlbeskedOutput void

Tabel 3.4: Metodespecifikation for CSoundCard.

Design af software 19

Navn findRMS()Input filteredseq:signed short[]Beskrivelse Bestemmer RMS værdien af en lydsekvensOutput rmscoeff:*charNavn returnRMS()Input voidBeskrivelse Returnerer rmscoeff[] til brug ved grafgeneration.Output rmscoeff:char[]

Tabel 3.5: Metodespecifikation for CAnalyzer.

Navn calcDiffKvot()Input correctedcoeff:double[]Beskrivelse Finder forholdet mellem målt energi og energi i pink-noise-

filen i de enkelte båndOutput diffkvot:double[]Navn fetchWanted()InputBeskrivelse Henter ønsket frekvenskarakteristik fra filen <slidervalues>Output wantedfreqchar:double[]Navn subWantedFromDiff()Input diffkvot:double[], wantedfreqchar:double[]Beskrivelse Beregner og gemmer forskellen mellem den ønskede

frekvenskar. og den faktiske i bandamp:short[] og filen<bandamp>.

Output voidNavn fetchBandamp()InputBeskrivelse Henter båndpasforstærkninger fra filen <bandamp> og

gemmer i bandamp:short[]Output void

Tabel 3.6: Metodespecifikation for CEqualizer.

Navn drawGraph()Input coeff:double[]Beskrivelse Tegner analyzer-graf ud fra modtagne værdier.Output voidNavn getCoeff()Input voidBeskrivelse Koefficienter fra CExternal gemmes i coeff:double[]Output void

Tabel 3.7: Metodespecifikation for CGraphWindow.

20 Designfase

Navn storeWanted()Input voidBeskrivelse Gemmer aktuelle sliderindstillinger i filen <slidervalues>Output voidNavn fetchWanted()Input voidBeskrivelse Henter ønsket frekvenskarakteristik fra filen <slidervalues>Output double[]

Tabel 3.8: Metodespecifikation for CSliderWindow.

Navn setSliders()Input voidBeskrivelse Indstiller sliders; hvis kaldt uden parameter nulstilles sliders

og værdierne i filen <slidervalues>Output voidNavn fetchSliders()Input voidBeskrivelse Returnerer aktuelle slider-værdier.Output double[]

Tabel 3.9: Metodespecifikation for CSlider.

Navn filterSamples()Input voidBeskrivelse Filtrerer en række samples, hentet med getSequence i

CSoundOutput voidNavn fetchSeq()Input sound:signed short[]Beskrivelse Returnerer de filtrerede sekvenserOutput signed short[]

Tabel 3.10: Metodespecifikation for CFilter.

4Softwaredesign

4.1 Indledning

4.2 Fejlhåndtering

I C++ findes en indbygget mekanisme til fejlhåndtering kaldet ’exception handling’.Via exceptions kan et objekt, der fejler, informere sig selv eller andre i stakken højereplacerede objekter om fejlen. Afhængigt af fejlens betydning for afviklingen af hov-edprogrammet i main, er exception handleren i simple tilfælde placeret i det fejlendeobjekt og i mere alvorlige tilfælde i main; typisk dog i main.

Exception handling er opbygget omkring brugen af try, throw og catch. I selve ob-jektet indsættes throw-kommandoen på de steder i metoderne, hvor der ønskes en fe-jlhåndtering. I hovedprogrammets main pakkes de dele af metodekaldene, der ønskeskontrolleret for exceptions, ind i try’s klammer. Og slutteligt forefindes catch i maintil at opfange de afsendte exceptions fra metodekaldene indkapslet i try.

For at sofistikere fejlhåndteringen kan de enkelte exceptions bestå af specifikke argu-menter såsom brug af metoder. Tilsvarende opfanges specifikt de enkelte fejlobjekter, ogpå denne måde kan en præcis fejlbeskrivelse inddelt i forskellige fejlområder håndteresog forevises brugeren.

Der findes mange forskellige måder at opbygge fejlhåndteringen på, og den i dette pro-jekt benyttede fejlhåndtering baserer sig på brugen af klasser. Der er således oprettetfølgende fire overordnede klasser: GUIErrors. AnalyzerErrors. EqualyzerErrors. MiscErrors.

GUIErrors omfatter exceptions fra GUI, og disse vil blive behandlet udelukkende i GUI-ens egen exception handler, da GUI kører som et selvstændigt program. De resterendeomfatter exceptions fra AnalyzerEqualizer-programmet, og indgår således i dette pro-grams fejlhåndtering.

Fælles for alle fire klasser er, at der udskrives fejlbeskeder både via GUI og via en kon-sol, da dette sikrer, at fejlbeskeden når frem. Om nødvendigt giver tekstboksen mulighed

22 Softwaredesign

for, at brugeren skal tage stilling til hvordan fejlen skal håndteres. Der vil være spe-cialtilfælde, hvor eksempelvis de to hovedprogrammer ikke kan kommunikere, hvilketgør at der ikke kan udskrives en fejlbesked via GUI.

Følgende eksempel viser et exception throw fra metoden makeError(), der program-mæssigt er placeret under Analyzer’en, hvorfor fejlbeskeder fra denne hører under klassenCAnalyzerErrors. Exception-objektet kommer med to argumenter, hhv. fejlnummeret 1og en specifik fejlbesked, der i dette tilfælde fortæller brugeren hvilken metode, derfejlede.

1 void CmakeError::makeError(void)2 3 ...4 if(error=1)5 throw CAnalyzerErrors(1,"makeError() has made en error!");6 7 ...8

Den praktiske opbygning er, at der til main i de to hovedprogrammer er knyttet en fe-jlhåndteringsfil kaldet CErrors.cpp med en tilsvarende h-fil. Denne indeholder alle fejl-håndteringer, og objekterne oprettes fra main når en exception er opfanget. Et eksempelpå et catch med efterfølgende kald af exception handling er:

1 CmakeError err;2

3 try /**:INFO: This is the method we want to4 * test for errors while running. */5 6 err.makeError();7 8

9 /**:INFO: Here we will catch the specific10 * errors coming from the CmakeError instances */11 catch(CAnalyzerErrors errorinstance)12 CErrors pass_to_handler;13 pass_to_handler.AnalyzerErrors -->14 (errorinstance.errornumber,errorinstance.errorstring);15

I dette eksempel er der tale om, at et objekt af klassen CmakeError fejler med en ex-ception af klassen CAnalyzerError. Dette objekt oprettes med udgangspunkt i følgendefejlhåndtering, som for eksemplets skyld er simpel og udelukkende håndterer fejlen ved,at udskrive fejlbeskeden til hhv. GUI og konsol:

1 void CErrors::AnalyzerErrors(int error,string s1) 2

3 CExternal outputGUI1(ANALYZERERROR);4 CExternal outputGUI2(ANALYZER);5

6 switch(error)7 8 case 1:9 /** :INFO: Writes output to console */

10 /** :INFO: Standard text for the specific error11 * number plus the number is written to cout.12 */

CExternal 23

13 cout << "GUI error number " << error << ":" << endl;14

15 /** :INFO: Specific text from the thrown16 * exception is written to cout.17 */18 cout << s1 << endl;19

20 /** :INFO: Writes output to GUI */21 outputGUI2.sendSignal(error);22 outputGUI2.sendData((char*)s1.c_str());23

24 break;25

26 default:27 break;28 29

Udskrivning til konsollen er simpel og ligefrem. Ved udskrivning til GUI oprettes der-imod et objekt af CExternal med en parameter ANALYZER for at angive, at det er enfejl fra Analyzeren. Derudover benyttes som tidligere fejlnummeret og den specifikkefejlbesked. Selve håndteringen af dette objekt tilhører ikke dette afsnit. For overskue-lighedens skyld, er der her ikke inkluderet al koden, og eksemplet er som nævnt eteksempel på opbygningen. Selve implementeringen kan ses i appendiks [*Note *] hvilket appendix indeholder ko-

den?

4.3 CExternal

Klassen CExternal varetager kommunikation mellem de to processer systemet gennemanalyse- og designfasen er blevet opdelt i. Denne kommunikation består af to ting: Sig-naler og data. Signalerne benyttes til at markere hvornår en af processerne skal starte ensekvens af metodekald, for at opfylde kravene fra en specifik usecase. Under behandlingaf samme usecase opstår behovet for at sende data imellem processerne. Den grafiskebrugerflade skal f.eks. have returneret værdier til brug for at tegne analyzer-grafen.For at muliggøre kommunikationen kan findes under Linux (og nogle Unix-systemer)benytte System V IPC1. System V IPC er en samling af en række systemkald, som stillerfølgende værktøjer til rådighed ved kommunikation mellem processer: Semaphores. Shared memory. Message queues.

4.3.1 System V IPC

Semaphores

Semaforer er en mekanisme der tillader styring af hvordan forskellige processer afvikles.En proces kan sættes i stå mens den venter på at en semafor får en bestemt værdi, og

1Inter Process Communication

24 Softwaredesign

bruger således ingen ressourcer inden dette sker. Andre processer (eller evt. andre trådei samme proces) kan derefter sætte semaforen, hvorefter afvikling af processen tagesop igen. Koordineringen af semaforerne, og de processer der afhænger af semaforerne,varetages af styresystemet, der opretter og vedligeholder en kø der indeholder de aktivesemaforer.

Delt hukommelse

Delt hukommelse (eng. shared memory) er som navnet antyder, et stykke hukommelsesom flere processer har adgang til. Ved brug af et eller flere sådanne områder, og medden rette koordinering, kan processer dele data i begge retninger. Koordineringen kanf.eks foregå ved at sætte flag direkte i den delte hukommelse, og polle på disse, ellerved brug af de førnævnte semaforer, hvorved man undgår at polle, og derfor sparersystemressourcer.

Message queues

Det tredje værktøj der stilles til rådighed via. System V IPC er message queues. Enmessage queue kombinerer egenskaber fra de to andre værktøjer, og kan således brugesbåde til styring af andre processers afvikling , og til udveksling af data. En beskedsendes som en struct i C++, og kan, ud over en obligatorisk beskedtype, indeholdeså mange forskellige datatyper som man har brug for, så længe den samlede mængdeikke overskrider 4kB[*Note *]. Beskedtypen kan i modtagerenden benyttes til at foretagekilde for de 4kB? Dave?

prioritering af beskederne, til at udvælge specifikke beskeder, eller den kan ignoreres,hvilket bevirker at den første besked i køen, uanset type, modtages. Det skal bemærkes aten beskedkø ikke virker efter FIFO2 princippet. Ved prioriteret modtagelse kan det altsålade sig gøre at tage den sidst ankomne besked ud af køen, hvis den matcher kriteriernebedst.

4.3.2 Tilfældet CExternal

[*Note *] For at løse de opgaver CExternal skal løfte, kan enten en kombination af de todårlig overskrift?

første værktøjer, semaforer og shared memory, eller det sidste værktøj, message queues,benyttes. Da message queues kan håndtere både den indbyrdes styring, der her kaldessignaler, og overførsel af data, vælges denne løsning.Der skal i CExternal-klassen findes tre sæt metoder: sendSignal og receiveSignal , derstår for den indbyrdes styring mellem processerne, sendData og receiveData, der somnavnene antyder, håndterer dataoverførsler, og sendErrorType og receiveErrorType, dertager sig af fejlhåndteringens kommunikation mellem GUI og AnalyzerEqualyzer. Føl-gende afsnit gennemgår implementationen af disse tre metodepar i forhold til brugen afbeskedkøen som værktøj.

2First In, First Out

CExternal 25

Styring

Signalerne der skal flyttes med sendSignal og dennes modpart benyttes til at startesekvenser af metodekald, der svarer til de usecases projektet fra starten er baseret på.Den eneste information der er nødvendig at sende med en besked i sendSignal er såledesen identifikation af den sekvens der skal startes. Denne gives i sendSignal som et num-mer, og den overførte datastruktur består derfor af en long mtype der angiver besked-typen, og en int signal der identificerer den ønskede sekvens.Afhængigt af om CEx-ternals constructor kaldes med parameteren GUI, parameteren ANALYZER, GUIERROR ellerANALYZERERROR sættes sendSignal til at sende beskeder af typen 1, 2, 3 eller 4. Modsvarendesættes receiveSignal til at modtage beskeder af typerne 4, 3, 2 eller 1. Alternativt kunnemetoderne være opbygget med prioriteret modtagelse, hvorved den anden del af datas-trukturen, int signal, kunne spares. Dette kunne dog bevirke at den ene af processerne,hvis denne foretog et receiveSignal kald efter et sendSignal, og før den anden proces,ville modtage sin egen besked. Den førstnævnte implementation blev derfor foretrukket.

Dataoverførsel

Metodeparret sendData og receiveData har som hovedfunktion at returnere de udreg-nede værdier der skal bruges til at tegne analyzergrafen på den grafiske brugerflade.Der er tale om en række talværdier, svarende i antal til de implementerede filtre. For atoverføre denne række af værdier benyttes et array af typen char. Dette giver mulighedfor en opløsning på grafens værdiakse på op til 256 punkter. Det skal bemærkes at vær-dien af en char kan ligge mellem 128 og 127, hvorfor det vil være nødvendigt at lademetoden findRMS i klassen CAnalyzer returnere værdier mellem disse to grænser.

Metoden receiveData skal returnere den data der modtages til en kaldende funktion.Hvis man i C++ returnerer et array fra en metode, får man reelt en pointer til adressenpå dette array. Da metoden afsluttes ved kaldet af return, frigives den benyttede mem-ory imidlertid, og den returnerede pointer er ikke længere brugbar. For at omgå detteproblem oprettes et privat array i klassen, og en pointer til dette returneres. Da de tooprettede CExternal objekter ikke lukkes ned før hele programmet afsluttes, vil dennepointer også være brugbar uden for objektet.Metodeparret sendErrorType og receiveErrorType fungerer i hovedtræk ligesom send-Data og receiveData, men har til formål at sende informationerne om fejltypen samten specifik fejlbesked mellem AnalyzerEqualyzer og GUI. Fejlhåndteringen omtalesyderligere i afsnittet Fejlhåndtering 4.2 på side 21.

Fælles for alle metoderne er, at de med funktionen msgget opretter en message queueførste gang de bliver kaldt. Køen får for Signal nøglen 0xCAFE, for Data nøglen FACEog for Error nøglen FEAC [*Note *]. Findes en kø med samme nøgle i forvejen, får msgget bør skrives til i fejlhåndteringsaf-

snittet i stedetingen betydning. De oprettede message queues skal nedlægges med funktionen msgctl,med kommandoen IPC_RMID ved programmets afslutning. Denne oprydning skal ligge ihhv. main-funktionen i den grafiske brugerflade, og main-funktionen i analyzer-/equalizer-programmet.

26 Softwaredesign

4.3.3 Test

For at teste de metoder CExternal indeholder, benyttes to små testprogrammer, “tes-tramme1” og “testramme2”. De to programmer opretter hver især et CExternal ob-jekt, i testramme1 med parameteren ANALYZER, og i testramme2 med parameteren GUI,hvorved de to seperate processer i projektet simuleres. I hvert testprogram oprettesherefter to message queues, med hhv. nøglerne 0xCAFE og 0xFACE. I testramme1kaldes sendSignal, og i testramme2 kaldes receiveSignal. Denne sekvens gentages i denmodsatte retning, og de modtagne signaler skrives til cout. Samme fremgangsmådegentages for sendData og receiveData, med et array af characters oprettet til formålet.Til slut nedlægges de oprettede message queues, og de to programmer afsluttes. Testenforløb tilfredsstillende, CExternal anses for afsluttet og tages i brug i de andre klasser.

4.4 CSound

Klassen CSound varetager fortolkning af instruktioner fra CPlayWindow og internt iklassen, til brug ved forsendelse af lyddata til CSoundCard. Funktionen består i mod-tagelse af instruktioner fra CPlayWindow og playNoise, der henholdvis er i GUI ogklassen selv. Instruktionerne fra CPlayWindow kalder outputSound med parameterenconst char, hvori stien til lydfilen er defineret, som skal håndteres og videresendes.Instruktionen for playNoise består i kaldet med en statisk sti til filen for pink noise.

4.4.1 Behandling af data til CSoundCard

4.4.2 Afspilning af pink noise

Ved korrektion af højttalerne skal der afspilles et kendt signal, der dækker hele frekven-sområdet for mikrofonen. Til dette formål anvendes pink noise, men white noise kanogså anvendes, hvor gengivelsen af pink noise sker ved afspilning af en wave-filer, somskal ligge i samme mappe som filerne for klassen. Af hensyn til kaldet af filen skaldet sikres, at filens placering er korrekt. Idet kaldet af playNoise vil fejle, hvis filensplacering ikke stemmer overens med stien angivet i koden.

1 /** :INFO: Play a pink noise file through outputSound */2 void CSound::playNoise()3

4 /** :NB: Make sure the file "pink.wav" is placed in5 * the same directory as the CSound.* files */6

7 CSound noise = CSound();8 noise.outputSound("pink.wav");9

[*Note *]skal opdateres med den nyestekode.....

Interface til lydkort 27

4.4.3 Fejlhåndtering

4.4.4 Testramme for funktionerne

4.5 Interface til lydkort

En instans af klassen CSoundCard ligner ikke et typisk objekt med en række instansvari-able og metoder til at manipulere disse - i stedet er objektets primære formål at styrelydkortets optagning og afspilning.

For at tilgå lydkortet anvendes en driver. Der er til linux/UNIX lavet et sæt drivere,der giver et ensartet API3 kaldet OSS4. Det er således muligt at tilgå et givent OSS-kompatibelt lydkort i en computer kørende linux med de samme kald; programmet derimplementerer disse er således portabelt. Ud over OSS findes ALSA5, der giver mu-lighed for flere avancerede funktioner, men da disse ikke er nødvendige i dette projekt,og da OSS er den standard der pt. er til linux, anvendes ALSA ikke.

Til at understøtte kodningen af CSoundCard anvendes de to internetsider (Audio Pro-gramming, 2002) og (Making Audio Complicated, 2002) samt et konkret kodeeksempelaf Søren K. Olesen. [*Note *] skal søren nævnes her?

For at være i stand til at optage og afspille skal man kunne: Initialisere lydkortet. Skrive til og læse fra lydkortet.

4.5.1 Initialisering af lydkort

Lydkortet sættes op med en række ioctl-kald; ioctl-funktionen manipulerer med etgivent device’s parametre - se manualsiderne for ioctl[*Note *]. I disse sider står ok?

int ioctl(int d, int request, ...);

hvor d er file descriptor6, og hvor request fortæller hvilke parametre, der skal ændres (deforskellige requests anvendt kan findes på internetsiderne (Audio Programming, 2002)og (Making Audio Complicated, 2002)). Det sidste felt kan bruges til at fortælle, hvor-dan parametrene skal ændres. Et eksempel på brugen af ioctl er ved opsætning afbitopløsningen:

1 int actual_value = bits;2 if(ioctl(audio_fd, SNDCTL_DSP_SAMPLESIZE, &actual_value) == -1) clean\3 Up(0x0030);4 if(actual_value != bits) cleanUp(0x0031);

3Application Programming Interface4Open Sound System5Advanced Linux Sound Architecture6Et systemspecifikt nummer der bruges til at identificere den åbne fil for systemet

28 Softwaredesign

Her forsøges bitopløsningen (eller sample-størrelsen) sat til actual_value. Hvis det ikkeer muligt at sætte en bitopløsning, returnerer ioctl -1. Efter bitopløsningen er sat, kon-troleres om det er den rigtige opløsning der er sat (da actual_value videregives som enreference, er ioctl i stand til at ændre dens værdi). Sker der en fejl under initialiserin-gen, lukkes lydkortet og der kastes en fejlbesked.

På lignende vis sættes andre parametre for optagelse og afspilning: Fuld duplex7 Bitopløsning: 16bitsample 2 kanaler (optagelse og afspilning) Samplingsfrekvens: 44 1kHz

4.5.2 Afspilning og optagelse

[*Note *] Efter lydkortet er sat op, er det muligt at begynde at optage og afspille lyd.hvad hedder det: optagelse, op-tagning...

CSoundCard er lavet således, at det er muligt at hente pointerne til optagebufferen og tilafspillebufferen samt længden af bufferne; længden er det halve af størrelsen, da hversample er to bytes stor. Der anvendes et såkaldt[*Note *] dobbeltbuffer-system (to buffereer dette nævnt før?

i indgangen og to i udgangen), hvor det er muligt for applikationen at læse/skrive tilden buffer, lydkortet ikke er i gang med at bruge. En illustration af dette ses på figur4.1 Hvis man anmoder CSoundCard-objektet om pointere til input- og output-bufferen,

in_ptr1 in_ptr2

out_ptr2out_ptr1

OUT

IN

B1

B1

B2

B2

lk_in_ptr

Figur 4.1: Dobbeltbuffer-systemet

kontrollerer objektet først, hvor lydkortet er i gang med at skrive og læse fra (lk_in_ptr).Derefter returneres pointere til starten af de ubenyttede buffere (in_ptr2 og out_ptr2).Anmodes om pointere til input- og output-bufferen hvor lk_in_ptr stadig er ved B1,venter objektet med at returnere pointerne in_ptr1 og out_ptr1, indtil lydkortet begyn-der på B2. Da lydkortet læser og skriver fra/til input- og output-bufferen med det sammeoffset fra begyndelsen af bufferne, og da bufferne har samme længde, er det nok bareat bestemme hvor lydkortet skriver i inputbufferrummet for at returnere en pointer tilinputbufferen og outputbufferen.

Dataene til lydkortet er formateret som vist på figur 4.2. Et standard konsumer-lydkort

7Mulighed for at optage og afspille på samme tid.

CAnalyzer 29

L R L R L R

16 bit

n = 0 n = 1

Figur 4.2: Således er data til lydkortet formateret

anvender little endian-formaterede 16bit samples. På en x86-maskine kan således an-vendes en signed short til at indeholde en enkelt sample. Til tiden n 0 er der i stereoto samples, en til højre og en til venstre kanal (venstre før højre). Da mikrofonen optageri mono, og applikationen i stereo, vil der således kun komme brugbare data i den ene afde to kanaler.

4.5.3 Test

Til test af CSoundCard er lavet en testramme. Hvad der sker i den opridses her:

1. Lydkortet initialiseres

2. Start optagelse og afspilning

3. Input- og output-pointer hentes

4. Inputbufferen kopirers over i outputbufferen

5. goto ’3’ 100 gange; (her anvendes en for-løkke)

6. Luk lydkortet

Med denne testramme er det altså muligt at fastslå, om CSoundCard virker. Da testpro-grammet blev kørt første gang, viste det sig, at der var hørbare klik i lyden. Det vistesig at denne sammenligning var forkert “info_in.ptr>input_buffer_length”, dainfo_in.ptr er af typen char og input_buffer_length af typen short (den rigtigesammenligning kan ses [*Note *]). Resultatet af det var, at dobbeltbuffer-systemets første hvor??

buffer (B1 figur 4.1) havde 14 af bufferrummet og den anden (B2 figur 4.1) 3

4. Efter

fejlen er rettet, er det muligt at høre, hvad der kommer ind i mikrofonen gennem højt-talerne med en bufferlængdes forsinkelse.

4.6 CAnalyzer

Klassen CAnalyzer varetager fortolkning af data fra CFilter, til videre brug i eksem-pelvis CGraphWindow. Funktionen består i at omforme de data, der modtages til ensamlet mængde data indeholdende informationer om RMS-værdierne på på de i af-snit ??[*Note *] beskrevne 1

N oktavs bånd. Dette udføres ved at modtage data fra et skal lige kontrolleres

30 Softwaredesign

Method Summaryvoid findRMS(signed short * filteredseq, int buffer_length)

:INFO: Calculates the RMS value of a sound-sequenceunsigned char*

returnRMS()

:INFO: When called it returns the RMS values for use in thegraph-generation

Tabel 4.1: Metodeoversigt for klassen CAnalyzer

forudbestemt antal båndpasfiltre og dernæst beregne RMS-værdien for hver af disse.Disse kan derefter returneres til CGrphWindow. En kort beskrivelse af metoderne i CAnalyzerkan ses i tabel 4.1.

4.6.1 Båndpasfiltrenes RMS-værdier

Til beregning af RMS-værdien for et bånd skal den lydsekvens, som modtages i et arrayaf typen signed short, gennemgå en procedure. Denne procedure består i at udførefølgende beregning

RMS 1T

T

∑n 0 0

y n 2For at udføre denne beregning er det nødvendigt at inkludere <math.h> der bla. omfatterfunktionerne sqrt() og pow(x,y), der henholdsvis uddrager kvadratroden og opløfterx i potens af y.

Værdierne tilhørende de enkelte elementer i omtalte array repræsenteres ved y n ogomtales i koden som filteredseq[i], et lokalt array, hvor int i går fra 0 til og medT, der i koden benævnes number og udgør antallet af array-elementer.number beregnesud fra bufferlængden bufferlength, som angiver antallet af samples.

Hver beregnet RMS-værdi lagres som et element i et lokalt array rmscoeff[rmsnr]afklassen, hvor rmsnr angiver i hvilket element der skal lagres. rmsnr er en lokal variabelaf klassen CAnalycer, og initialiseres til 0, når der oprettes et nyt objekt af klassen.Desuden tæller rmsnr een op hver gang metoden findRMS(filteredseq[]) kaldes.rmsnr re-initialiseres når antallet af forudbestemte bånd(nrofband) er nået, hvorved denæste RMS-værdier påny placeres fra første element i rmscoeff[rmsnr].

Dette ser på kode form således ud:

1 for (int i=0; i<number; i++) 2 sum = sum + pow(filteredseq[i], 2);3 4

5 rms = sqrt(sum) / number;

CAnalyzer 31

4.6.2 Returnering af RMS-værdier

Når de udregnede RMS-værdier, ønskes returneret, foregår det ved at kalde metodenreturnRMS(), der blot sender en pointer til startadressen på det lokale array rmscoeff[rmsnr],hvor RMS-værdierne ligger. Dette foregår gennem klassen CExternal, indebærer føl-gende kode, hvor external er et tidligere oprettet CEXternal(GUI)-objekt:

1 void CAnalyzer::returnRMS(void)2 external.sendData(rmscoeff);3

Figuren 4.3 illustrerer, hvorledes RMS-værdierne for de enkelte båndpasfiltre placeres ioutput-array’et rmscoeff og det kald, der foretages inden værdierne er beregnet.

CAnalyzer::findRMS()

CAnalyzer::findRMS()

CAnalyzer::findRMS()

CAnalyzer::findRMS()FN

F3

F

F1

2

i = (nr_og_bands − 1)

i = 0

N = nr_og_bands

CAnalyzerBåndpasfiltre rmscoeff[]

Figur 4.3: Illustration af placering af RMS-værdier i rmscoeff().

Metodekald af findRMS(filteredseq[]), foregår sekventielt fra main[*Note *]svarende navn eks ændres

til antallet af bånd, for til sidst at kalde returnRMS() for at få RMS-værdierne sendtvidere.

4.6.3 Fejlhåndtering

I denne klasse inddrages, under fejlhåndtering, en undersøgelse af bufferlength, derikke må være nul eller derunder. Dette kriterie er opstillet da denne indgår som nævneri en division, og da en negativ bufferstørrelse ikke giver mening.

32 Softwaredesign

Der kan udover ovennævnte fejl, opstå uhensigtsmæssigheder, iform af for tidlig kaldaf returnRMS(), dette resulterer i at de sendte RMS-værdier kan bestå af en blandingaf gamle og nye, tilhørende de respektive bånd. Dette vil ikke være synlig for brugeren,og undgåes ved kalde returnRMS() efter sidste bånd.[*Note *]skal måske slet ikke stå der!!!!!!

4.6.4 Testramme for funktionaliterne

Klassen testes ved at kode en testramme, der opretter et test-objekt af klassen CAnalyzerog kalder klassens Constructer med antallet af bånd som parameter. Herefter gener-eres et givet antal array’s indeholdende både positive og negative værdier. Hvert arraybenyttes derefter som parameter ved kald af metoden test.findRMS(short x-array[]).Dernæst oprettes et CExternal-objekt, hvorefter test.returnRMS() kaldes, der senderRMS-værdierne til CExternal. Til sidst kaldes CExternal-objekt.receiveData(),der modtager en pointer til RMS-værdierne, hvorefter værdierne skrives ud gennemen for-løkke. Denne test forløb uden konplikationer og minimal debugging. Der kan iappendiks XX[*Note *] findes en samlet integrationstest hvor CAnalyzer er inkluderet.husk ref

4.7 Implementering af filtre

Følgende afsnit er en beskrivelse af klassen CFilter’s implementering i C++ på bag-grund afsnit 3.1 på side 9 om teorien bag digitale filtre. Klassen har to hovedopgaver,henholdsvis i forbindelse med kalibrering og filtrering.

Alt efter antal bånd frekvensspektret opdeles i, samt filterordenen for de tilsvarendeantal filtre, udregnes forskellige overføringsfunktioner for hvert filter. Ved opstart afprogrammet vælges disse parametre, hvorefter et objekt indeholdende de udregnedeoverføringsfunktioner oprettes. Fra CAnalyzer ændres koefficienterne i overførings-funktionerne, ved multiplicering med en konstant, til de under kalibreringen fundnekorrigerede værdier.

Til beregning af koefficienterne til overføringsfunktionerne er udarbejdet en række metoder,der i C++ gengiver de i afsnit 3.1 på side 9 opstillede formler for udregning af polværdierne,samt første- og andenordenskoefficienterne for henholdsvis højpas- og lavpasfiltrene:

calcPoleValuescalc1FilterLowPasscalc1FilterHighPasscalc2FilterLowPasscalc2FilterHighPass

Som det fremgår af metoderne herover, er der udelukkende tale om første- og ande-nordens højpas- og lavpasfiltre, der under filtreringen kaskadekobles. Selve filtreringen

Den grafiske brugerflade 33

forestås af metoden filterSamples, der sekvensvis gennemløber et filter og lader out-putværdien blive inputværdi for det næste filter i kaskaden. Filtreringen foretages bådeved CAnalyzer’s analysering af signalet og ved CEqualyzer’s afspilning af lyd.

For at få størst mulig præcision i udregningerne foretages disse med variable af typendouble, som til sidst castes til typen signed short.

4.7.1 Test af CFilter

Klassen er opbygget omkring kravet til brugerens mulighed for at kunne forskelligeantal filtre og filterordener.

Testen opdeltes naturligt i to dele, henholdsvis udregning af filterkoefficienterne ogdernæst selve filtreringen.

Til udregning af filterkoefficienterne benyttedes filterordenen og filtrenes båndpasknæk-frekvenser som input til oprettelsen af objektet. Der er ingen krav til hastigheden fordisse udregninger, men testet med udregning af 30 tyvendeordens båndpasfiltre tog detkun en brøkdel af et sekund, hvilket må siges at være tilfredsstillende. De resulterendekoefficienter blev kontrolleret med Matlab og fundet valide.

Tilpasningen af filterantal og -orden er set i forhold til brugervenlighed en fordel, men iforhold til hastighed en ulempe, hvilket skyldes et større antal metodekald for at hentekoefficienterne i et array [*Note *] hver eneste gang et nyt filter skal processere signalet. VEKTORER?

Der er derfor gennemført test med dynamisk udregnede koefficienter og manuelt udreg-nede faste koefficienter for forskellige filterantal og filterordener. Beregningstiderne ermeget maskinafhængige, men forholdsmæssigt metoderne imellem blev resultatet, atfiltreringen med faste koefficienter er omtrent dobbelt så hurtig som dens modpart.

Til trods for dette har gruppen bibeholdt kravet om, at brugeren skal kunne tilpassefilterantal og -orden til sin egen maskine.

Et endnu mere slående resultat var dog, at med denne metode er det muligt på en stan-dard pentium III 1GHz pc, at kunne filtrere signalet med op til seks andenordens bånd-pasfiltre indenfor halvdelen af længden på samplebufferen.

Konkluderende kan det siges, at det umiddelbart ikke er muligt, at opfylde kravet tilAnalyzeren/Equalyzeren om at kunne filtrere i 1/3 oktav båndpasfiltre. Derfor benyttesi den endelige integrationstest som udgangspunkt seks andenordens båndpasfiltre.

4.8 Den grafiske brugerflade

Softwaren i projektet udvikles efter objektorienterede principper, og skrives i C++. Forat implementere en grafisk brugerflade8 til analyzer- og equalizerprogrammet var detderfor nødvendigt at vælge et grafikbibliotek til brug med C++. Valget faldt på Qt, etprofessionelt softwareudviklingsværktøj, som er gratis tilgængeligt for Unix/Linux sys-temer under GPL9. Qt tilbyder et omfattende bibliotek af funktioner og objekter (kaldetwidgets) til brug ved konstruktion af en GUI, og nyder derudover popularitet fordi en

8GUI: graphical user interface9Gnu Public License; se www.trolltech.no for yderligere licensinformation.

34 Softwaredesign

applikation udviklet i Qt kan benyttes på kryds af de tre store platforme, Unix/Linux,Windows og MacOS. Et godt eksempel på brugen af Qt kan findes i Linux desktoppenKDE. Det følgende afsnit gennemgår nogle koncepter og metoder i forbindelse med Qt,præsenterer et udkast til projektets GUI, og går derefter i dybden med implementationenaf de enkelte elementer i denne.

4.8.1 Qt

[*Note *] Qt er som nævnt et grafikbibliotek til C++. Brugen af de funktioner og klassermåske Qt - et kort overblik

der findes i Qt tillader at projektets GUI kan udvikles uden det bliver nødvendigt atsætte sig ind i de indre virkemåder af X11, Unix og Linux’ graphics-engine. To ting ercentrale for Qt: Widgets, og Qt’s signal/slot fremgangsmåde, til at kommunikere mellemforskellige elementer af en applikation.

Widgets

En widget er i Qt (og i andre sammenhænge) et element af en GUI, som giver brugereninformation, eller en mulighed for at kommunikere med systemet. Definitionen kan ud-vides til at omfatte elementer af GUI’en som har den funktion at indeholde andre wid-gets, og dermed tjener et layoutmæssigt formål. Som eksempler på widgets kan f.eks.nævnes en simpel trykknap, eller et vindue. Trykknappen tillader brugeren at kommu-nikere med systemet; når et tryk på knappen registreres kan forskellige forløb i systemetstartes eller stoppes. Vinduet er en såkaldt container-widget, som kun giver informa-tion eller mulighed for interaktion gennem de widgets den indeholder. Vinduet giveren ramme om en applikations GUI, og tillader evt. at applikationen minimeres, eller atstørrelsen ændres.I en Qt-applikation består alt synligt således af widgets. Selve vinduet, trykknapper,scrollbars og tekstvinduer er alle widgets, og kan i vid udstrækning findes som stan-dardelementer i Qt. De enkelte widgets er defineret som C++ klasser, og indgår i etnedarvningshierarki, der for de flestes vedkommende starter med klassen QWidget. FraQWidget nedarves en lang række af de mest almindeligt brugte egenskaber og metodertil at tegne et objekt på skærmen, og de enkelte underklasser specialiceres derefter nedgennem hierarkiet.

Signals and slots

For at give f.eks. en trykknap mening, skal den forbindes til noget. Hvis der intet sker nårder trykkes på knappen kan den lige så godt udelades. For at opnå forbindelse mellemde enkelte widgets der udgør en GUI, benytter Qt signals og slots.En widget kan indeholde et arbitrært antal signals og slots. Et signal kan udsendes(emittes) enten på baggrund af en event, som er en handling fra systemets bruger, eller eteksternt system, eller det kan udsendes som følge af en intern ændring i den pågældendewidget. Udefrakommende events håndteres internt af Qt, og det er som bruger af Qt kunnødvendigt at specificere hvilke events en widget skal reagere på, og implementere ko-den for de ønskede reaktioner. Når en widget har modtaget en event, og har udsendt

Den grafiske brugerflade 35

et signal, er dens rolle i forløbet reelt udspillet. En widget sikrer sig ikke at signaletmodtages af nogen, og det kan derfor lade sig gøre at implementere dele af et system,uden at der opstår fejl pga. manglende modtagere. Når modtageren til et signal tilføjestil systemet, forbindes det udsendte signal til et slot i modtagerwidget. I modtagerwid-get er det pågældende slot implementeret som et stykke kode, der køres hver gang detspecificerede signal modtages.

4.8.2 Projektets grafiske brugerflade

Designprocessen tager udgangspunkt i en række usescases, som også danner grundlagfor et udkast til GUI’en:

1. Brugeren trykker på en knap og det måltes frekvensgang reguleres efter den ønskedefrekvensgang.

2. Brugeren skaber den frekvenskarakteristik han ønsker højttaleren (og rummet)skal have i målepunktet.

3. Brugeren trykker på en knap og får vist højttalerens (og rummets) frekvenskarak-teristik (ved mic. placering).

4. Brugeren trykker på en knap og får grafisk præsenteret det måltes frekvensindholdi realtid.

5. Brugeren skal kunne afspille lyd, således at det behandles gennem equalizeren.

Usecase 1 kræver en knap til regulering af systemets frekvensgang. Ligeledes krævesfra usecases 3 og 4 knapper til start af hhv. måling af systemets frekvensgang, og visningaf frekvensindhold i realtid. For at kunne stoppe de enkelte processer igen kræves deru-dover en stopknap. Disse knapper tildeles et område på den grafiske brugerflade. Udover de fire nævnte trykknapper kommer to fra usecase 2, som bruges til hhv. at gemmeden indstillede frekvenskarakteristik, og til at gendanne default-værdierne for denne.Fra usecase 5 kommer en “play” og en “stop” knap til brug ved afspilning af lyd gen-nem equalizeren. Alle disse trykknapper samles i en klasse, CButton, og er beskrevet iafsnit 4.8.4. Usecase 2 lægger op til at brugeren skal kunne indstille en række værdiergennem GUI. Denne funktionalitet er oplagt at implementere med en række sliders ,som tildeles et område på GUI, sammen med de to knapper til at gemme, og nulstille.Implementation af sliders og knapper samles til en enhed i klassen CSliderWindow,med underklassen CSlider, og dokumenteres i afsnit 4.8.7. Fra usecase 3 og 4 kanudledes et krav om en grafisk præsentation af data fra analyzeren. Denne repræsenta-tion håndteres i klassen CGraphWindow, som beskrevet i afsnit 4.8.5. Usecase 5 læggerud over knapperne til “play” og “stop” op til at brugeren skal kunne vælge en fil fra enliste på displayet. Implementationen af denne funktion er lagt i klassen CPlayWindow,og dokumenteret i afsnit 4.8.8.

Ud fra de fundne elementer er udkastet i figur 4.4 udarbejdet.

36 Softwaredesign

EFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFEEFEFE

GFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFGGFGFG

HFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFHHFH

IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFI

JFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJJFJFJ

KFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFKKFK

LFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLLFLMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFMMFM

NFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNNFNFNOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFOOFOFO

PFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFPPFP

QFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQQFQ

RFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFRRFRFR

SFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFSSFS

TFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFTTFT

UFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFUUFU

VFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFVVFV

WFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFWWFW

XFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXXFXFXYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFYYFYFY

ZZZZ[[[[

\\\\]]]]

^^^^

____````

aaaabbbbLydfil1.wav

Lydfil2.wav

Lydfil3.wav

Lydfilx.wav

Figur 4.4: Udkast til GUI, udarbejdet fra usecases.

4.8.3 Aegui - GUI’s main window

For den praktiske implementation af GUI viste det sig at være mest fornuftigt at benytteen containerwidget der indeholder alle de andre widgets. Denne widget baseres påstandardklassen QMainWindow, og kaldes Aegui. Den bygges fra starten i TrollTech’sgrafiske værktøj, Qt-Designer. I Qt-Designer indsættes eksemplarer af alle de standard-widgets der umiddelbart skal bruges i de enkelte underklasser der er defineret gennemUML designprocessen. Layouts tilføjes til vinduet, så knapper , sliders mm. grupperessom vist i udkastet på figuer 4.4. Med værktøjet UIC omsættes den konstruerede widgettil en C++ kilde- og headerfil, hvor constructoren, og slots og signals implementeresfor at opnå den ønskede funktionalitet. Dette betyder at underklasserne CPlayWindow,CSliderWindow og CButton reelt ikke bliver oprettet som seperate klasser, men bliveren del af Aegui. De metoder der ligger i de enkelte klasser fra designfasen bliver dogstadig udført samlet i undergrupper, og dokumenteret i samme inddeling som der hidtiler lagt op til.

Aeguimain

For at få vist alle de widgets der bliver implementeret igennem kodningen af den grafiskebrugerflade, er det nødvendigt at have en main funktion, der opretter et QApplication ob-jekt, sætter et Aegui objekt til dettes mainWidget, og kører metoden QApplication::exec.QApplication::exec starter en løkke, der henter events fra X11, og omsætter disse tilQEvents der fanges af de enkelte objekter i applikationen. Denne main funktion ligger ifilen aeguimain.cpp.

Den grafiske brugerflade 37

4.8.4 CButton

Klassen CButton’s funtkion er formidling af information mellem brugeren og softwaren,idet brugeren via knapperne indgiver forskellige funktionskald, som på forhånd er de-fineret i de forskellige knapper på brugergrænsefladen. Med henblik på en brugervenligGUI, hvor brugeren har adgang til de fornødne funktioner. Derved er der via analyse-og designfasen fremkommet forskellige knapfunktionaliteter. Disse funktionaliteter forCButton kan ses i tabel 4.2 på den følgende side.

GUI skal danne rammen for de forskellige trykknapper, der hver varetager specifikkeopgave. Dette leder hen til den næste fælles funktion, der skal aktiveres efter et vilkårligtknaptryk, som er midlertidig deaktivering af alle knapper med undtagelse af quit, da pro-grammet til en hver tid skal kunne lukkes. Funktionens varighed er variabel, da denneafhænger af den opstartede proces’s varighed. Til varetagelse af opgaven er konstruereten Radiobutton, som illustativt skal give brugeren information om statusen for det funk-tionskald, der er aktiveret. Dette sker ved en ON/OFF stilling, hvor ON informerer omen igangværende proces, mens OFF for en afsluttet proces og dermed venter på nyaktivering. Foruden den illustative ændring af Radiobutton, sker der samtidig en “Low-light” af de enkelte knapper, der ikke kan tilgåes. Processen med “lowlight” er en funk-tion, der kommer med brugeren af QT.

Til varetagelse af denne funktion er der konstrueret et slot setStatus, som sender etsignal til en Radiobutton med kommandoen RadioButton1->setChecked( FALSE ).Med denne kommando sættes knappens status til OFF uafhængigt af tidligere status.Slottet setStatus aktiveres via signaler fra eksempelvis CgraphWindow, der sendersignal efter udføret funktionskald. Derved kan aktivering af knapperne før den igangvær-dende proces er fuldført ikke forekomme. Figuren 4.5 på næste side viser, hvorledesnogle af knapperne og radiobutton er grafisk illustreret, mens figuren 4.6 på side 39viser signalvejen ved knaptryk inden for CButton og til dens periferi.

[*Note *] skal ses igennem efter GUI erblevet ændret.

Tabel 4.2 på næste side viser en oversigt over sammenhængen mellem knappernes funk-tioner, knaptekster, slot og signaler, hvor funktionerne beskriver, det brugeren fore-spørger af programmet via brugergrænsefladen. Dernæst beskriver kolonnen med knaptekstkort, hvilke valg muligheder brugeren har tilrådighed, og hvilken funktion der kaldesved et knaptryk. Den næste kolonne er en mere programmeringsmæssigt indsigt i, hvilkeslot der er forbundet til de enkelte knapper, og hvori koden til skrevet, som klades vedaktivering af den eller de enkelte knapper. Den sidste kolonne giver en oversigt over,hvilke signaler der sendes videre til andre dele af systemet, som kald af andre funk-tioner. Beskivelsen af knapperne og deres tilhørende funktioner er i relattion til denopgave, der skal udføres. Imodsætning er signalerne, der sendes, valgt ud fra ide ombedre overskuelighed og en gruppering af de enkelte knapper i henhold til deres plad-sering på GUI. Det eneste signal, der påforhånd kan fastsættes til en værdi, er Quit, idetdefinitionen af int(1) er fastsat til at stoppe og lukke alle processer og underprogram-mer.

Beskivelsen af knapperne og deres tilhørende funktioner er i relattion til den opgave,der skal udføres. Imodsætning er signalerne, der sendes, valgt ud fra ide om bedre over-skuelighed og en gruppering af de enkelte knapper i henhold til deres pladsering på GUIog overordent funktionalitet. De to eneste knapper, der påforhånd kan fastsættes til en

38 Softwaredesign

ccccccccddddddddefeefeefeefeefeefeefeefegggggggghfhhfhhfhhfhhfhhfhhfhhfhifiifiifiifiifiifiifiifi

jjjjjjkkkkkk llllllmmmmmm nnnnnnnooooooopfppfppfppfppfppfppfppfpqqqqqqqq

rfrrfrrfrrfrrfrrfrrfrrfrsfssfssfssfssfssfssfssfsttttttttuuuuuuuuvfvvfvvfvvfvwfwwfwwfwwfw

xxyy

zz ||~~

Lydfil1.wav

Lydfil2.wav

Lydfil3.wav

Lydfilx.wav

Speaker Char

RT Freq

Correct Spk

Stop All

Quit

Processing...

Figur 4.5: Illustration af vinduet med nogle af knapperne og radionbutton.

værdi, er Quit og Stop All, idet definitionen af int(1) er fastsat til at stoppe og lukkealle processer og underprogrammer, mens int(9) er defineret til at stoppe samtligeprocesser.

Funktion knaptekst Slot Signal

Quit Quit quit 1Show Speaker Characteristic Speaker Char showSpkChar 2Show Real Time Frequency RT Freq showRTFreq 3Correct Speaker Correct Spk correctSpeakers 4Play Song Play playSong 5Stop Playing Stop stopPlaying 6Store Wanted Store storeWanted 7Set Default Default setDefaults 8Stop All Processes Stop All stopAll 9

Tabel 4.2: Trykknapper

Eksempler fra CButton.cpp

I det efterfølgende eksempel vil der ses bort fra den kode, der genereres af QT, idetkoden til den grafisk brugergrænseflade automatisk genereres ved to kompeleringer afoutput filen fra programmet. Det interessante i perpektivet er den kode, der tilskrives deenklte trykknapper og deres kald af funktioner fra andre filer. Til dette eksempel er valgt

Den grafiske brugerflade 39

Brugeren

Start

Knaptryk

Andre processer

Ja

Nej

: Low

light

RadioButton

showSpkChar

Speaker Char

setStatus OFF: Enabled

Signal: int(9)

Signal: int(8)

Signal: int(7)

Signal: int(6)

Signal: int(5)

Signal: int(4)

Signal: int(3)

Signal: int(2)

ON: Disabled

showRTfreq

RT Freq

ON: Disabled

correctSpeaker

Correct Spk

ON: Disabled

playSong

Play

ON: Disabled

stopPlaying

ON: Disabled

Stop

Store

storeWanted

ON: Disabled

setDefault

Default

Stop All

stopAll

ON: Disabled

ON: Disabled

CExternal

Knapstatus

Signal: int(1)quitQuit

Figur 4.6: Illustration af signalvejen ved knaptryk.

40 Softwaredesign

knappen Quit, som foruden kald fra anden fil også lukker programmet i henhold til dentidligere nævnt definition.

Det første, der skal tage stilling til, er de enkelte filer, der skal kaldes funktioner fra. Idette tilfælde skal der kaldes funktioner i filen CExternal.h og gøres på følgende mådeved at inkludere:#include "CExternal.h" ,derved bliver samtlige funktioner i CExternal tilgængelig for CButton. Dernæst skal derdefineres den eller de funktioner, som skal kaldes, hvilket gøres på følgende måde:CExternal external1 = CExternal(GUI); ,hvor der kaldes funktionen external1, som sættes lig med CExternal(GUI), der påforhånd er defineret i CExternal.Det sidste skridt, inden knappen er fuldt funktionsdygtig, er definering af funktionernei knappens slot, der tidligere nævnt forbinder knappen til de kald, der skal ske vedaktivering.

1 /*Is used to quit all active system and subsystem*/2 void Buttons::quit()/*The slot which represent the pushbutton Quit*/3 4 external1.sendSignal(1); /*Sending signal to CExternal*/5 close(); /*Closing the program and subprograms*/6

Test af funktionerne

Ved test af CButton sker dette sekvetiel med fuldførelsen af de restende dele af GUI,hvor knapperne skal varetage opgaver for eksempelvis CGraphWindow med opdaterin-gen af grafen for henholdvis “Show Speaker Characteristic” og “Show Real Time Fre-quency” eller CPlayWindow med “Play Song” og “Stop Playing” osv. Foruden de enkeltetest i GUI, er der lavet en test med kommunikation til CExternal. Testen går grundlæggendeud på kontrol af de signaler, der sendes til CExternal, er korrekte med dem, der fremgåraf tabel 4.2 på side 38. Dette udføres ved hjælp af nogle allerede eksisterende tes-trammer, der er anvendt til test af kommunikationen i CExternal. Efter testen kan detkonkluderes, at signalerne, der modtages i CExternal, er identiske med fastsatte ud fratablen.

4.8.5 GraphWindow

Klassen CGraphWindow skal ligesom de andre elementer i den grafiske brugerflade lavesi Qt. I modsætning til CCommandWindow og CSliderWindow er der imidlertid ikke enstandard widget der kan håndtere de opgaver der skal løses i CGraphWindow. Disse op-gaver består ifølge UML-processen i at modtage data fra metoden findRMS i klassenCAnalyzer, og omsætte dette til en løbende opdateret graf der vises på brugerfladen.Data fra findRMS overføres som et array af typen double[*Note *]. For at løse de nævntenej det gør ej - char!!

opgaver er det nødvendigt at udvikle en custom widget til Qt. En custom widget kanenten sættes sammen af Qt’s standardelementer, eller skrives i kode og bruges som alleandre widgets. En custom widget udmærker sig i øvrigt ved at kunne medtages i værk-tøjet Qt-Designer, som benyttes til andre dele af brugerfladen. Dette tillader at imple-mentationen af CGraphWindow kan tages med fra starten, selvom der ikke er mulighed

Den grafiske brugerflade 41

for at udføre reverse engineering af den C++ fil der genereres fra Qt-Designer. Fandteskoden ikke som en widget ville det være nødvendigt manuelt at indsætte den ved alleændringer af brugerfladen, da den så ville gå tabt i C++ filen.

4.8.6 Kodning af en speciel Qt widget

Ønskes en special funktionalitet eller et grafisk udseende på brugerfladen som ikke kandesignes udfra QT’s standard widgets som knapper, tekstvinduer eller menupunkter erdet nødvendigt at fremstille en speciel widget.

En speciel widget består af en klasse som nedarver fra Qwidget, i denne klasse reim-plementeres de ønskede metoder for at tilpasse udseende og interaktivitet. Desuden kander defineres signaler og slots for at kommunikere med andre widgets.

For at få QT’s signal/slot mekanisme til at fungere efter hensigten er det nødvendigt atindsætte en Q_OBJECTmakro og generere en Meta Object Code (moc) fil udfra klassedef-initionen. Den genererede fil er en c++ fil, som indeholder Qts implementation af bl.a.deres signal/slot metode, og som skal kompileres og linkes sammen med den applika-tion hvor den pågældende widget indgår. Hvordan denne mekanisme konkret er imple-menteret ligger bag QT’s API der anvendes i projektet.

Den færdige widget kan indsættes i QT-designers værktøjslinie, ved at tilføje og manueltindtaste signals, slots og offentlige variable. Herefter er muligt at anvende den i nyedesigns på samme måde som QT’s standard widgets.

graphwidget

Det analyserede signals frekvenskarakteristik skal vises på brugerfladen. Der findes ikkenogen QT widgets som umiddelbart kan lave en koordinatsystem og plotte værdier ind.Derfor er der lavet en speciel widget til dette formål kaldet graphwidget som nedarverfra klassen QWidget.

Det er valgt at opdele den grafiskefront i en statisk og dynamisk grafikområde. Detstatiske område indholder koordinatsystemets akser, inddeling og akseværdier, mens detdynamiske område indholder en række rektangler afhængig af antallet af filtre. Højdenaf det enkelte rektangel bestemmes udfra rækken af værdier der bliver sent med signalettil widget. Ved denne opdeling er det muligt kun at opdatere det dynamiske område forhver gang det næste sæt RMS værdier skal vises.

Den statiske del består af et objekt af klassen QPixmap som bliver oprettet med wid-get størrelsen i pixels. Herefter bliver de statiske dele tegnet med et objekt af klassenQPainter på Qpixmap objektet. Til sidst anvendes en bit blit teknik på QPixmap objektetså det bliver synligt for brugeren. Denne teknik kopierer indholdet af Qpixmap objektetud på én gang og derved opnås en mere flimmerfri grafik.

QPixmap objektet i den dynamiske del fylder kun selve koordinatområdet. Efter sammeprincip tegnes en række rektangler med et objekt af klassen QPainter på QPixmap ob-jektet, og til sidst bruges bit blit teknikken til at kopiere dette ud på brugerens grafiskefront.

42 Softwaredesign

PaintEvent og resizeEvent bliver sendt til graphwidget når henholdvis dens grafikom-råde bliver udefineret eller når widget størrelsen ændres. Disse events er reimplementeretså den statiske og dynamiske del bliver vist korrekt.

Der er implementeret et slot kaldet setRMSvalues i graphwidget. Dette slot modtager etsæt RMS værider som argument og udfra disse bliver det dynamiske område opdateret

test af graphwidget: Først blev det testet at graphwidget kunne vise et koordinatsystemmed et sæt RMS værdier korrekt samt at widget området var skal é rbart. Derefter blevder programmeret en tråd som sendte signaler med et tilfældigt sæt RMS værdier tilgraphwidget med en frekvens på 10 Hz. [*Note *]to come.. debugs endeligt resultat

og konklusion

4.8.7 CSliderWindow

CSliderWindow er den del af GUI, der tillader brugeren at definere den frekevenskarak-teristik der ønskes af systemet. Da analyzeren og equalizeren deler frekvensområdetmellem 20Hz og 16kHz op med en række båndpasfiltre, skal CSliderWindow give mu-lighed for at stille på samme antal bånd.

Til at indstille de enkelte bånd vælges en række QSlider-widgets, som er standard iQt, og derfor simple at benytte sig af. Til at gemme værdierne, og nulstille samme,benyttes to trykknapper, hvis implementation er beskrevet nærmere i 4.8.4[*Note *]. Tocheck this reference!

slots, <verbAegui::storeWanted og Aegui::setDefaults til at håndtere knaptrykkeneoprettes i klassen Aegui, som er den hovedwidget der indeholder alle andre dele af GUI.

Oprettelse og initialisering af sliders

Da det først ved runtime angives hvor mange filtre der skal oprettes, er det nødvendigtat tilpasse antallet af QSliders hver gang programmet køres. Denne opgave løses vedat tilføje en parameter, filtre [*Note *], til Aegui-klassens constructor. Denne parameterbør omdøbes til filters

gemmes ved oprettelse af Aegui-objektet i den private instans-variabel numberOfFilters,til senere brug, i forbindelse med lagring af værdier fra de oprettede QSliders. Der udover benyttes den direkte i constructoren, i en for-løkke, der opretter de ønskede sliders:

1 /* Kode taget fra Aegui.cpp */2

3

4 /* Create a configuration file it one doesn’t exist */5 QFile file(datafile);6 if(!file.exists())7 8 file.open(IO_WriteOnly);9 QTextStream stream( &file );

10

11 for ( int i=0; i<LENGTHOFCONF; i+=3 )12 stream << CONFLINE;13 file.close();14 15

16 /* calculate position in file according to numberOfFilters */17 int filePos = 0;18 for(int i = 1; i < numberOfFilters; i++)19 filePos += 3*i;20

21 /* Create sliders and initialize from file: slider.dat */

Den grafiske brugerflade 43

22 file.open( IO_ReadOnly );23 QTextStream stream( &file );24 file.at(filePos);25

26 for ( int i=0; i<filtre; i++ )27 28 Slider[i] = new QSlider( privateLayoutWidget_2 );29 Slider[i]->setOrientation( QSlider::Vertical );30 Slider[i]->setTickmarks( QSlider::Left);31 Slider[i]->setValue(stream.readLine().toInt()); // Value from file32 Layout5->addWidget(Slider[i]);33 34

35 file.close();36

Med QFile.exists() undersøges om en konfigurationsfil, “slidervalues.dat”, som gem-mer de sidst kendte værdier af rækken af sliders, eksisterer. Er dette ikke tilfældetoprettes en fil, hvor værdien “49 n”, defineret som CONFLINE, indskrives et antalgange, der svarer til summen af alle de mulige værdier af numberOfFilters, 1 til 30.Værdien “49 n” svarer til at hver enkelt slider sættes i midterpositionen, og med end-of-line karakteren “ n” kommer hver enkelt slider til at fylde 3 bytes i konfigurationsfilen.

Pladskravet på 3 bytes pr. slider udnyttes til at finde adressen hvor værdierne for detaktuelle antal filtre er gemt. I den anden for-løkke i ovenstående kode summeres dennødvendige plads til i sliders fra i=1, til numberOfFilters. Resultatet gemmes i vari-ablen filePos, som bruges ved indlæsning af gamle værdier, og initialisering af deoprettede sliders, med metoden QSlider::setValue.

Slider er oprettet som et array af pointere til QSlider objekter, QSlider **, og findessom en public instans-variabel i klassen. Ud over at de ønskede sliders i ovenståendekod oprettes, og får tilskrevet en værdi som beskrevet herover, orienteres de vertikalt,og afmærkninger i venstre side specificeres.

Lagring af værdier fra sliders

For at kunne bruge de valgte indstillinger i equalizeren, og for at kunne genbruge demved næste opstart af programmet, blev det i UML-designet besluttet at disse værdierskulle gemmes i en fil[*Note *]. Værdien af en QSlider kan hentes med metoden QSlider::value,check UML - hedder den slider-

values der?og i slot Aegui::storeWanted hentes samtlige, og gemmes til filen “slidervalues.dat”,defineret i koden som datafile.

1 /* Kode taget fra Aegui.cpp */2

3 /*Is used to store the user slider option */4 void Aegui::storeWanted()5 6

7 QFile file(datafile);8 if ( file.open( IO_ReadWrite ) ) 9 file.at(filePos);

10 QTextStream stream( &file );11

12 for ( int i=0; i<numberOfFilters; i++ )13 stream << Slider[i]->value() << "\n";14 file.close();15

44 Softwaredesign

16

17

Variablen filePos som bliver sat i constructoren (se 4.8.7), benyttes ved lagringen tilat sørge for at de nye værdier bliver skrevet ind på det rigtige sted i filen. Program-met starter på denne måde med de sidst kendte indstillinger for det valgte antal fil-tre. Ønskes de hentede værdier ikke benyttet, kan sliderne nulstilles med et tryk på“default”, som kalder metoden QSlider::setValue med værdien “49 n”, og derefterkalder Aegui::storeWanted.

Trykket på “default” nulstiller således også værdierne i filen. Ønskes disse værdier gemt,skal man som systemet fungerer nu, omdøbe filen “slidervalues.dat” før man trykker“store” eller “default”.

Test

De metoder der hører til CSliderWindow er efter implementationen testet i korthed, vedat starte GUI op med en række forskellige antal filtre, gemme en række forskelligeslider-indstillinger, notere disse, og undersøge om de samme indstillinger var valgt vednæste opstart. Yderligere slettedes konfigurationsfilen et antal gange, og den efter næsteopstart af GUI undersøgtes den nyoprettede fil. Det konkluderes ud fra disse simple testsat CSliderWindow fungerer efter hensigten.

4.8.8 CPlayWindow

Det område af den grafiske brugerflade der dækkes af CPlayWindow indeholder detre trykknapper “File”, “Play” og “Stop”. Disse tre knapper er forbundet gennem deresClicked signal til slots i Aegui-klassen, der er grundlaget for hele GUI. Det følgende af-snit gennemgår implementeringen af disse tre slots: Aegui::getFile, Aegui::playSongog Aegui::playSong.

File

Knappen “File” har til formål at lade brugeren vælge en wav-fil til afspilning gennemequalizeren. Qt stiller en standardwidget, QFileDialog, til rådighed til valg af filer. Somnavnet antyder, nedarver denne widget fra QDialog, og tilhører den gruppe af wid-gets der tænkes anvendt som popup-vinduer. Således skrives slot getFile så et tryk påknappen får en QFileDialog til at vise sig på skærmen. Brugeren kan fra denne grafiskmanøvrere rundt i filsystemet, og vælge den fil der skal afspilles. Ved et tryk på “OK”knappen i QFileDialog, lukkes popup-vinduet, og det valgte filnavn returneres som enQString. Siden QFileDialog findes som en standardwidget i Qt, kan det meste af dennefunktionalitet klares med én linie kode:

fileinfo = new QFileInfo(QFileDialog::getOpenFileName(‘‘/’’, ‘‘*.wav’’));

Hvor fileinfo på forhånd er erklæret som en privat instans-variabel af typen QFileInfo,i klassen Aegui. De to parametre til QFileDialog angiver hvor man starter med at lede,og hvilket filter QFileDialog skal bruge når den viser filerne på den aktuelle lokation.

Den grafiske brugerflade 45

Når en fil er valgt skrives navnet ind i et QTextLabel over knappen, så den er synlig forbrugeren. Når QFileInfo klassen benyttes, i stedet for QString, som QFileDialog::getOpenFileName()

returnerer, skyldes det at der i QFileInfo stilles en række metoder til rådighed, der gørdet muligt at hente specifikke informationer om en enkelt fil ud. F.eks. kan metodenQFileInfo::absFilePath() returnere filens fulde lokation, i forhold til roden, mensQFileInfo::fileName() kun returnerer filnavnet, uden sti. Disse metoder er praktiskenår filnavnet hhv. skal skrives ud på GUI, og sendes til den anden proces, til brug vedafspilning.

Play

Knappen “Play” skal sende et signal til den anden proces, analyzer- og equalizerpro-grammet, og overføre navnet og stien på den valgte fil. Disse funktioner er imple-menteret i slot Aegui::playSong(). Signalet sendes med CExternal::sendSignal,og starter en tråd i den anden proces. Se ?? på side ??[*Note *] for detaljer om denne tråd. check this reference!

Filnavnet skal sendes med CExternal::sendData. Da denne metode sender et array afcharacters, kræver det lidt forarbejde:

1 /*Kode taget fra aegui.cpp*/2

3 int i = 0;4 while(fileinfo->absFilePath().latin1()[i] != ’\0’)5 6 filename[i] = fileinfo->absFilePath().latin1()[i];7 i++;8 9 filename[i] = 0;

10

11 analyzerinterface->sendData(filename);12

Metoden QFileInfo::absFilePath() returnerer en QString, fra hvilken metoden QString::latin1()kaldes, for at konvertere til en klassisk nul-termineret streng i C-stil. Denne streng eren const char*, og kan derfor ikke sendes med CExternal::sendData(), som ac-cepterer en char*. For at omgå dette, kopieres den returnerede streng element for ele-ment ind i variablen char * filename, som er oprettet til formålet, i metoden. Fordielementet ’\0’ bliver fjernet fra strengen i while-løkken, nul-termineres filename igenfør den sendes gennem CExternal. Efter filnavnet er overført, og således ligger klar påen message queue, sendes et signal gennem CExternal::sendSignal, og afslpilningaf den valgte fil påbegyndes.

Stop

“Stop” skal, som navnet siger, stoppe afspilningen af en lydfil. Dette gøres ved , gen-nem CExternal::sendSignal, at sætte et flag i analyzer-/equalizerprocessen. Detteflag stopper den tråd der sørger for afspilningen af lydfilen.

46 Softwaredesign

Test

De to af knapperne i CPlayWindow skal starte kommunikation med den anden proces,og den tredje, “File”, skal hente et filnavn. For at teste kommunikationen skrives ettestprogram10 der benytter CExternal, og i en switch-case-struktur simulerer analyzer-equalizer processen, men udskriver de modtagne signaler og data, frem for at behandledem. GUI startes op, og “File” testes ved at vælge en fil, og undersøge om denne ind-skrives i det QTextLabel der i GUI er placeret lige over denne knap. Når dette kriterieer opfyldt, trykkes “Play”, og signalet til analyzeren, og det overførte filnavn checkesi tesprogrammet ved at de udskrives til cout. Signalet fra “Stop”-knappen testes påsamme måde.

4.8.9 Trådet styring af data, signaler og fejlhåndtering

Method Summaryvirtual void run()

:INFO: Virtual method which MUST be reimplemented for aQThread to perform any actions

void setApp (QApplication * ptr):INFO: Supplies pointer to the QApplication to a GUIThread- must be called before run() when GUIThread is in mode 2

void setForm (Aegui * ptr):INFO: Supplies pointer to the main window to a GUITThread- must always be called before run()

void setMode (int modeIn):INFO: Sets mode i GUIThread to decide whether the stringawaits data or signals - accepts parameters 1 and 2,anything else kills thread immediately

Tabel 4.3: Metodeoversigt for klassen GUIThread

Når QApplication::exec afvikles, startes en løkke der afventer events fra X11. Nårdenne løkke er startet, kan det ikke umiddelbart lade sig gøre at afvikle anden kodei programmet. For at modtage signaler og data fra den anden proces benyttes derforQThread, Qt’s implementation af tråde, som på Linux virker ved at bruge pthread.Aeguimain deles reelt op i tre tråde, der adskiller sig fra hinanden på den type datade modtager. Hovedprogrammet modtager events fra X11, og de to andre tråde mod-tager hhv. data til grafen, og styresignaler til GUI. I klassen GUIThread, som sættes tilat nedarve fra QThread, skal den virtuelle metode QThread::run (se tabel 4.3) reim-plementeres til at håndtere hhv. data til GraphWidget, signaler og fejlbeskeder. I runimplementeres en indlejret switch-case-struktur, der deler metoden op i to modes, derhåndterer signaler og fejlbeskeder under ét, og data til GraphWidget for sig selv. Hvilkenmode GUIThread::run opererer i, bestemmes gennem metoden GUIThread::setMode.Når et GUIThread::run kaldes, og et af de to modes er valgt, sættes programmet ind i enuendelig while-løkke, og sættes i stå med et kald til hhv. CExternal::receiveSignal

10aeguitest.cpp

Den grafiske brugerflade 47

og CExternal::receiveSignal. Ved lukning af programmet, som er en QApplicationlukker Qt automatisk igangværende tråde.

I mode 1, der modtager data, er der ud over kaldet til CExternal et kald til Aegui::signalGraph,som sender signalet Aegui::callToGraph, der er forbundet til GraphWidget::setRMSvalues.

I mode 2 findes endnu en switch-case-struktur, der switcher på returværdien fra CExternal::receiveSignal.Modtages signalet 1, tolkes det som en klar-melding fra den anden proces, og alle dis-ablede knapper reaktiveres. Signalerne 2 til 5 styrer fejlhåndtering for hhv. analyzer,equalizer, udefinerede og CSoundCard. Fra fejlhåndteringen i den anden proces med-sendes, ud over signalet der identificerer det fejlende modul, en tekststreng der nærmereforklarer hvilken fejl der er tale om. Denne fejl udskrives i en QMessageBox, og erimplementeret som i følgende kodeeksempel, fejlhåndteringen for analyzeren:

1

2 /* Kode taget fra guithread.cpp */3

4 case 2: // errormessage from analyzer5

6 7 QMessageBox *mb = new QMessageBox( "Error",8 "What happened?",9 QMessageBox::Warning,

10 QMessageBox::Ok | QMessageBox::Default,11 QMessageBox::NoButton,12 QMessageBox::NoButton );13 errortext = guiexternal.receiveString();14 mb->setCaption("Analyzer error");15 mb->setText(errortext);16 if(mb->exec()==QMessageBox::Ok)17 delete mb;18

19 20 break;21

QMessageBox skaber et popup-vindue, som i ovenstående kodeeksempel har ikonetfor typen warning (en trekant med et udråbstegn), én knap med teksten “OK”, og enbeskedtekst der sættes til noget tilfældigt, da den alligevel skal overskrives ved brug.Efter modtagelse af tekstrengen der hører til en given fejl, kaldes QMessageBox::setText,og den modtagne streng skrives ind. QMessageBox objektet vises, og slettes når dertrykkes på “OK”.

Hvis et ukendt mode sættes, falder den første switch-case igennem til default, en fe-jlbesked udskrives til cout, og tråden dræbes med det samme. Sendes en ukendt fejlkodefalder den anden switch-case igennem til default, og beskeden “GUI: Unknown signalfrom analyzer” udskrives i terminalen.

Test

Testprogrammet fra CPlayWindow udvides til at inkludere den trådede styring, og rea-gere på knaptryk i GUI ved at sende en data og fejlbeskeder tilbage, samt reaktivereknapperne. Dataoverførslen til GraphWidget fungerer i testen efter hensigten. Når test-programmet sender en fejlmeddelelse tilbage oprettes den øsnkede popup-dialog ko-rrekt, men GUI fastlåses nogle gange ved et tryk på “OK” knappen, eller ved selve

48 Softwaredesign

oprettelsen. I de tilfælde hvor GUI fastlåses sender systemet fejlbeskeden “Xlib: un-expected async reply”. Research i TrollTech’s “Qt Interest Archive”[*Note *] pegede på atBibTeX?

fejlen opstod fordi programmet forsøgte at oprette nye widgets fra en anden tråd endden der kører Qt’s “main event loop” - løkken der håndterer X11 events. For at rettedenne fejl er der to muligheder: Enten kan syntetiske events sendes fra tråden, og tilhovedprogrammet, så håndteringen stadig udelukkende ligger i hovedprogrammet, ellermetoden QApplication::lock kan bruges til midlertidigt at stoppe “main event loop”mens fejlbeskederne er fremme på skærmen. Den første måde er den mest korrekte, menogså mest tidskrævende, da den kræver at der implementeres en QCustomEvent, og enmetode til at håndtere denne event i Aegui-klassen. Den anden metode, som benyttes her,kan klares med to linier kode, der kalder QApplication::lock i starten af den switch-case-struktur der styrer fejlhåndteringen, lige efter CExternal::receiveSignal, og etkald til QApplication::unlock efter switch-case-strukturen er blevet gennemløbet. Pådenne måde overgives kontrollen af events helt til de enkelte QMessageBox-objekter sålænge de eksisterer, og der opstår ingen konflikter længere.

-indledning om hvad aemain tager sig af

Softwaren består af to processer den ene indholder de digitale filtre, interface til lyd-kortsdriver og musikfiler, analysator og højttaler optimerings reguleringen. Den andenproces er er den grafiske brugerflade hvor brugeren af systemet har mulighed for at seog styre systemet. De to processer kommunikerer indbyrdes via et fælles interface derer implementeret via CExternal klassen som begge processer derfor benytter.

Klassen CAEmain samler de enkelte klasser og modtager signaler og data fra dengrafiske brugerflade for derefter at starte en tråd op hvor klassernes objekter udførerden ønskede opgave for brugeren.

Der anvendes tråde idet det giver brugeren mulighed for at afbryde en opgave ellertilstand hvis dette ønskes. Dette sker f.eks iforbindelse med der startes en RT frekvens-analyse i en tråd som analyserer signalet fra mikrofonen, denne tråd vil fortsætte indtilbrugeren vælger at stoppe frekvensanalysen via den grafiskefront eller terminerer pro-cessen.

De tråde der anvendes i CAEmain der QThreads som ligeledes anvendes i den grafiskebrugerflade. QThreads er en del af QT’s API og kan derfor umiddelbart anvendes i ob-jektorienterede software designs. QThreads er implementeret for forskelligvis afhængighvilket operativsystem der anvendes, i denne situration hvor der anvendes linux erQThreads impelmenteret via pthreads (Posix threads).

Klassen QThread indholder en virtuel metode run som er selve tråden. Denne run metodeimplementeres i en ny klasse som nedarver fra QThread. Et eksempel på dette er klassenCShowRTThread.

For at en tråd har mulighed for at anvende de objekter der bliver allokeret i konstruk-toren for CAEmain er det nødvendigt at gøre eksemplevis CShowRTThread klassentil en ’friend’ i CAEmain klassens definition, derved gør scopereglerne det muligt fortråden at tilgå CAEmains private instansvariable som konkret er en række objekter somudgør følgende: Interface til lydkortsdriveren, båndpasfiltrene, RMS analysatoren, kom-munikationsinterface til den grafiske brugerflade samt et overordnet interface til lydkortog musikfiler. Desunden er der også tilgang til et struct bestående af antalfiltre samtderes knækfrekvenser.

Den grafiske brugerflade 49

Generelt anvendes pointere til objekter fremfor direkte reference, dette er nødvendigtda en række objekter skal konstrueres med variable parametre. Filtre objekterne er etspecielt eksempel på dette hvor der i klasse definitionen for CAEmain er defineret enpointer til en pointer af typen CFilter. I konstruktoren bliver der først allokeret et array afpointere til CFilter objekter, dernæst bliver CFilter objekterne oprettet med de tidligereudregnede knækfrekvenser og andre relavante parametre.

Grunden til der er fremstillet en dedikeret klasse til processen frem for at indlejre ko-den i aemain.cpp hvor den egentlige main er indeholdt skyldes inspiration fra Java. IJava er en applikation blot en klasse hvor der er implementeret en main metode. I dettetilfælde er aemain.cpp derfor blot et skelet der opretter et objekt af CAEmain klassenmed argumenterne båndpasfilterbredde i n’te dele oktaver samt filterorden. Efter objek-tets konstruktion startes exec metoden som afvikles indtil den afbrydes, normalt via etsignal fra den grafiske brugerflade, og der returneres til operativsystemet.

Mere konkret omkring de forskellige tråde. CShowRTThread.. CShowSpkrchar.. ...etc.

-evt noget om det smarte obejktorienteret der gøres brug med konstant brug af metoderosv.

-hvilke specielle ting der er taget i brug i aemain; såsom: -gthread -pointer-pointer-pointer termelogien -.... og andre hvis der er nogen!!

-hvordan alle objekter initialiseres from the beginning of eamain!!

-måden hvorpå aemain er delt op i tråde i henhold til switch/case og trykknapper

-evt om problemer under integrering/opbygning af aemain

Lav Figurer, der viser hvrdan: - der deles op i tråde ud fra aemain - pointer hurlumhejet..foregår

God Weekend ;0Q

50 Softwaredesign

4.9 Integrationstest

[*Note *]kolaborationdiagrammer skalformegenligt indsættes her: pgaDAN....... Integrationstesten har ved projektstarten været defineret som en sekventiel integration

af klasserne med deres tilgrænsende klasser efter færdiggørelse, men dette er med tidenblevet omstrukturet til en Main for hver af hovedgrupperne GUI og Analyzer & Equal-izer, som indeholder strukturen for sammenkædning af klasserne. Inden ideen med in-tegrationstest gik fra integration mellem klasserne og til strukturen med Main, er derblevet udført to test. Dokumentationen af disse to test identisk med den for resterendeklasseintegrationer.

Figur 4.7 illustrerer fremgangsmåden for integrationstesten for de to udførte trin mellemCExternal & GUI og CAnalyzer & CExternal, som er representeret af flowdiagram-merne A) og B), samt ideerne for de restende trin i flowet fra “Støj/Lyde” til GUI.Foruden dette har der også været planlagt test for flowet fra GUI til højttalerne, somhenholdsvis går via og uden om equalzeren. Det er integrationstestene med undtagelseaf trin A) og B), der er overgået til Main. Dokumentation for kommunikationen mellemklasserne og deres driver og stube forefindes i sidst de respektive afsnit. Derimod forfindesdokumentationen for Main i to dele, der henholdsvis representerer GUI og Analyzer &Equalizer, som forefindes i ?? på side ?? og 4.8.3 på side 36.

CExternal

CExternal

CExternal

Canalyzer

CanalyzerCFilter

Driver

Driver

DriverA)

B)

C)

GUI

GUI

GUI

CExternalCCorrectMic CFilter Canalyzer GUI

CExternalCCorrectMic CFilter CanalyzerDriverD) GUI

E) MikrofonStøj/Lyde

Figur 4.7: Oversigt over integrationstestens første trin før overgangen til Main.

5Konklusion

LitteraturAudio Programming (01-12-2002).http://www.opensound.com/pguide/audio.html.

CD-ROM. Vedlagt cd-rom.

Frequency Spectrum.http://zone.ni.com/devzone/nidzgloss.nsf/webmain/...

Hüche, E. (1986). Digital Signal Behandling. Teknisk Forlag A/S, - edition.

Making Audio Complicated (01-12-2002).http://www.opensound.com/pguide/audio2.html.

6Nomenklaturliste

Symbol Definition EnhedΩ Analog frekvens radianer pr. sekω Digital frekvens radianer pr. sek

Tabel 6.1: Nomenklaturliste

AMikrofonVed konstruktion af funktionen CCorretMic er der foretaget underbyggende forsøg, derskal fastsætte omfanget af korrektionerne for mikrofonens frekvenskarakteristik. I denanledning er der udført forskellige forsøg i lyddødt rum, som forebyggelse mod ude-frakommende forstyrrelser. Det lyddøde rum er fuldt funktionelt indenfor frekvensom-rådet ca. 250-20000Hz, hvor målinger af frekvenser op til 250Hz vil afhænge af om-givelsesstøj. Dette viste sig at være tilfældet, da der jævnfør med forsøgene blev udførtundersøgelser af omkring liggende lokaler i frekvensområdet.

A.1 Forsøg i lyddødt rum

Forsøgsopstillingen er opstillet, som vist på figur A.1. Under opstillingen af udstyret erder taget hensyn til reflektioner fra den konstruerede mikrofonen med forstærkerkred-sløb og reference mikrofonen, som er forsøg reduceret mest muligt, hvilket er sket vedat placere mikrofonernes mindste overflader mod højttaleren. Mikrofonerne er samtidigplaceret så tæt som muligt på hinanden, idet forskelligt placeret mikrofoner ikke er sam-linglige, da de ikke udsættes for samme signaler.

1m

Figur A.1: Placering af mikrofon og højttaleren i henhold til hinanden.

Idet alle reflektioner vil give ukorrekte målinger, er alt unødvendigt materiale og udstyrplaceret i andet lokale, hvor samtlige målinger er foretaget og dokumenteret til viderebehandling.

Inden de egentlige forsøgsresultater kan måles, skal alle apparater kaliberes, hvor kaliberin-gen af de enkelte instrumenter sker ved indstilling af forudprogrammerede funtkioner,

Forsøg i lyddødt rum 55

mens til reference mikrofonen anvendes en kalibrator, der forefindes i tablen B.1 undernr. 4.

Af hensyn til opløsningen og frekvensområdet, der afgrænses af henholdsvis 20Hz og20kHz, måles mikrofonernes frekvenskarakteristik hver for sig, hvor reference mikro-noen første udsættes for lydtrykket fra pink noise og gemmes til videre brug ved dif-ferencering mellem reference mikrofonen og den konstruerede. Efter der er foretageten række målinger, og observationerne af dem viser en minimal variation mellem deenkelte målinger, skiftes der mikrofon til den konstruerede, hvor der foretages en rækketilsvarende målinger, til observationerne heraf tyder på målinger med minimale varia-tioner. Efter måling af den første mikrofon udskiftes den og processen gentages for toyderligere mikrofoner med samme forstærkerkredsløb. Efter lagering af måleresultaterfor de to mikrofoner indstilles apparatur nr. 1 fra tabel B.1 til differencering, hvor dettydeligt fremgår, hvilke frenkvensområde der skal dæmpes eller forstærkes.

Lyddødt rum

Lokale til måleopsamling

2+3+7

Mic

6+7

1 5

Figur A.2: Forsøgopstilling for måling af frekvenskarakteristik. Cifrerne representererapparaturerne fra tabel B.1, og Mic representerer den konstruerede mikro-fon.

Graferne A.3, A.4 og A.5 viser måleresultaterne, hvor skaleringen af de forskelligegrafer er foretaget af appartur nr. 1 fra tabel B.1. Ved denne proces er der en skaler-ingsfaktor på 6dB mellem graferne A.3 og A.4, mens grafen A.5 viser differenceringforetaget af apparaturet.

56 Mikrofon

25

30

35

40

45

50

55

60

65

100 1000 10000

Am

plitu

de [d

B]

Frekvens [Hz]

"bk4165a.data"

Figur A.3: Frekvenskarakteristik for reference mikrofonen.

5

10

15

20

25

30

35

40

45

100 1000 10000

Am

plitu

de [d

B]

Frekvens [Hz]

"mica.data"

Figur A.4: Frekvenskarakteristik for den konstruerede mikrofonen.

-34

-32

-30

-28

-26

-24

-22

-20

-18

-16

100 1000 10000

Am

plitu

de [d

B]

Frekvens [Hz]

"mic-bk.data"

Figur A.5: Differencering af frekvenskarakteristik for den konstruerede og referencemikrofonen.

BApparaturliste

I det følgende skema findes det udstyr, der er anvendt ved test af den konstrueredemikrofon med forstærker. Hvert anvendt apparat er anført ved navn, fabrikant, type ogAAU løbenummer. I rapporten henvises til de benyttede apparater ved hjælp af num-mereringen i skemaet. I tablen B.1 forkortes Brüel & Kjær med B&K.

ApparaturlisteNr. Navn Fabrikant, Type AAU Nr.1 Dual Channel Real-Time Frequency Analyzer B&K, 2133 085962 G.R.A.S. (Mikrofon) B&K, 26 AK 328103 Calibration Chart for Condenser Microphone Cartridge B&K, 4165 081334 Sound Level Calibrator 081555 Rotel Six Channel Power Amplifier RB-976MK I I 339816 Højttaler B&K, DM601S27 Stativer

Tabel B.1: Apparatur

CKomponentliste

Mikrofon

Navn Type Specifikation Navn Type SpecifikationC1 Kondensator 2 2µF R1 Modstand 2,2kC2 Kondensator 10µF R2 Modstand 100kC3 Kondensator 10µF R3 Modstand 5kJ1 Microfon R4 Modstand 50kJ2 BNC-stik R5 Modstand 2kJ3 Minijack WM-034DB R6 Modstand 1,5kJ4 Batteriholder inkl.

3 AA-batteriQ1 Transistor BC547B

Output

BNC-stik

Minijack

Batteriholder

J4

Vcc

0

0

0

Vcc

C1

2.2u

R35k C2

10u

R52k

R61.5k

R2100k

J312

R450k

J212

C3

10u

Q1BC547A

R12.2k

J1

Microfon

12

Figur C.1: Diagram for konstruktionen af mikrofonen samt forstærker til produktet.

DUML

EKildekode

Bilag

De nedenstående bilag findes i mappen “datablade” på vedlagte CD. Bilagene i mappen"datablade"forefindes alle i pdf-format samt i hardcopy-form på de efterfølgende sider.

Sti Titel Beskrivelsedatablade

Mic1 Mikrofon WM-034DB, side 1Mic2 Mikrofon WM-034DB, side 2

62 Kildekode

¡¢£ ¡ ¤¦¥8§¨ © ª¡ « ¬ ¡ª­ ¤®¯¡°¬ª ©) ¨ ±¦¡ ²« ±* ±±¬ « © ª¡ «« ¤

Microphone Cartridges³µ·¶¹º»¼¾½À¿ÂÁû¶ÅÄÀÆÈÇÉƽÀ¿ÂÁ¬¼Ê½ ÁËÌû¶Åº»½À¶ÅͽÀ¼ÉÎÏ¿>¼ÊûлÑÅÃҶŽÓËÌÄÀ¼ Á¼º»ÔÒ½ÕÖ × Ø Ö ÙÚÊÛ ÎÏÜÞÝàßá$âäã¾Ýàßá$åæâèç é Ø ê¦ë ì é Ö íÛ ÎÏÜÞÝàßá$ËîãÊÝÒß$áån Features

n ï£ð!ñóòô õô ö8ô õø÷n ïDùóðÊúô ûô ú¾üÊõô ýñ¨òþÿ þÿ ÿÿ ÿ ! #"$ % ÿ &ÿ 'ªÿ ( )!* )

Ω + ,* - Ω./ 0ÿ& 1 % 0ÿ& 2 34 0ÿ56ÿ& )78 ! 9 *:2ÿ0; 223 ÿ þ 0;2ÿ0; 223 ÿ <!* - + ,* - .=60;0ÿ>&26 % 2 9 *:,* ? % + ,* @ % .þÿ A0ÿ6& 2 BC ( D7@ @

+ 9 * E* "F#BG ( 7@ > .+ H* I,* JK* "F#BC ( D7) .þ LM0; 2 9 20ÿ ( 8n NÞ÷¬ù8ô úÊüEOQPSR ð,TVU¨ðñóú¾÷XW8ðÊòùÞýñ¨ò ðZY[USR öÞð

n \¦ô ]Èðñ¨òô ýñóò ô ñ^]_]a` bc,dSdec[fgQhAi jQklnm^o pq!rtsSuvpKqtr!ws lxmyozq!rt|uvpq!rtw

;~:eC >#

;~:eC

~#;G >z

~#;G>

z ¡¢£¤ ¥¦§¥¨©;ªK« ¬t­ ®

¯ °± ²³´ µ°¯ °¶·¸¹¶°º »¼½

¾¿À

ÁÂà ±ÄÅÆÁÂÇ ±ÄÅÆÁ ÄÈ ±ÄÅÆÉ ÙËÊ ÂÍÌ Î ÉÏAÐ Ê Ç|Ì ÇÑ Ω

ÒyÓMÔ#Õ Ä Â ÆQÖ Õ Ä Â× Ó ØÙÏÚ

Á ±Ç ÅKÆÁÂÇ ±Ç ÅKÆÁÂ Õ ±Ç ÅKÆÁ ÄÈ ±Ç ÅKÆÁ Ä Ã ±Ç ÅKÆ

É ÙÛÊËÜ Ì Î ÉÏAÐ ÊÛÜ Ì ÎÑ Ω

ÒZÓËÔ:Õ Ä Â|Ý ÆQÖ Õ Ä Â|Ý

l Useful for almost any type telephone and otherapplications

l Low operation voltage of 1.0V to 10V (2M-034D type)l Microphone with pins for PCB (WM-034B/034DB type)

63

Þßzàá âã>äã å|æQçeßè>á é á èäzê;á ë>ã àtäzì ßSàîíï ð ßèêzê ëSèñ äã âßSòÍá ê ñ ë>í ê>ã ëzê;á èzßóEôàîõîé äèzê ëzì öté ëìê ßzèñzãá èä>÷ àîçvßzèá é á èäê á ëã àïeßé ëì ßDçí ì èñ äzà:ß,äã åø ëzìQí à:ß>óùúñ ß>ã ßzû:ßzìäSåëíïeêä>ïvë>í êzà:äzé ßzê öAá àüàîí ßàQäìvá à:ßzàté ì ëýEê ñá àçeì ëåí èê þzç÷ ßäzà:ßDá ã é ëzì:ýGí àá ýSý>ßzåQá äê ß>÷ öQé ëzìê ßè>ñãzá èzä÷ èë>ã àîí÷ ê äê á ëãzó

Microphone Cartridgesÿ

! "$#%#'&(" )* + , +.-0/1 "' ,

243 5 6#%!%78

#8!4 !8#4, & +$9+ ;:

$9+ ;< ->= 1 , 1 ,

?@ 7A + & 1 "B

C4D

-'!4 !8#4, !9" #8-FEG%GHIJE< KL' '* ! " #%#%&("$) + , +M-(/1 " ,

293 5 0#%!%78$9+ ;:

$9+ ;< - = 1 ,$ 1 ,

?@ 7A + & 1 "%

C4D

NOP0QRSP6T*RUVSW6T8P6OX QYZF[SQRSX OX [SQ\L] ^_\a`cb(d e0^gfShc`cb0d b(i

Ωj [SRSW6kLlm[Sd npoaq*r4s tvu.w9x y w9unpoaq*r4s zcu.w9x y w9unpoaq*r4s _tvu.w9x y w9unpoaq*r4s _zu|w4x y w9unpoaq*r4s 0tvu.w9x y w9unpoaq*r4s 0zu|w4x y w9unpoaq*r4s ~tu.w9x y w9unpoaq*r4s ~zu.w9x y w9unpoaq*r4 0tvu.w9x y w9unpoaq*r4 0zu|w4x y w9unpoaq*r4 ~tu.w9x y w9unpoaq*r4 ~zu.w9x y w9unpoaq*r4 ttu.w9x y w9unpoaq*r4 zcu.w9x y w9unpoaq*r4r t4 npoaq*s4 t 4

NOP6QRSP0T*RUVSW0TBP0OX QYZm[HQRSX OX [HQ\ ] ^H\a`b(d e(^gfHhc`cb(d b0i

Ωj [HRSW0kLlF[Sd npoaqr s4cu|w4x y w9unpoaqr 4cu|w4x y w9unpoaqr 4tu|w4x y w9unpoaqr 4u.w9x y w9unpoaqr 4cu|w4x y w9unpoaqr 4u.w9x y w9unpoaqr 4cu|w4x y w9unpoaqr r44 npoaqr 44 npoaqr 4S4 npoaqr 4S4 npoaqs 4S4

NOP6QRSP0T*RUVSW0TBP0OX QYZm[HQRSX OX [HQ\ ] ^H\a`(d (^gfHhc`c((e

Ωj [HRSW0kLlF[Sd npoaq 44 npoaq 4S4 npoaq r4S4

NOP6QRSP0T*RUVSW0TBP0OX QYZm[HQRSX OX [HQ\ ] ^H\a`(d (^gfHhc`c(d e0i

Ωj [HRSW0kLlF[Sd npoaq 4u.w9x y w9u

NOP6QRSP0T*RUVSW0TBP0OX QYZm[HQRSX OX [HQ\ ] ^H\a`b(d (^gfHhc`cb(d b0i

Ωj [HRSW0kLlF[Sd npoaq s4u.w9x y w9u

NOP6QRSP0T*RUVSW0TBP0OX QYZm[HQRSX OX [HQ\ ] ^H\a`(d (^gfHhc`cb(d b0i

Ωj [HRSW0kLlF[Sd npoaq 4s u|w4x y w9unpoaq 4s tvu.w9x y w9unpoaq 4s ou.w9x y w9u

NOP6QRSP0T*RUVSW0TBP0OX QYZm[HQRSX OX [HQ\ ] ^H\a`(d (^gfHhc`c(d 0i

Ωj [HRSW0kLlF[Sd npoaq 4s u.w9x y w4unpoaq 4s u.w9x y w9unpoaq 4s vu.w9x y w9u