Diplomová práce Vývoj a implementace simulátoru telekomunikační sítě

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra měření

Diplomová práce

Vývoj a implementace simulátoru telekomunikační sítě

Bc. Radek Veřmiřovský, 2010 Vedoucí práce: Doc. Ing. Jan Holub, Ph.D.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací.

V Praze dne.................................

................................. Podpis autora práce

1

Poděkování Mé poděkování za všestrannou pomoc patří vedoucímu práce Doc. Ing. Janu Holubovi Ph.D., a také mé rodině za podporu během studia.

2

Akademický rok 2009 - 2010

ZADÁNÍ DIPLOMOVÉ PRÁCE Student:

Bc. Radek Veřmiřovský

Obor:

Kybernetika a měření – blok Měřící a přístrojové systémy

Název tématu česky:

Vývoj a implementace simulátoru telekomunikační sítě

Název tématu anglicky: Telecommunication Network Simulator Design and

Implementation Zásady pro vypracování: Navrhněte a implementujte simulátor telekomunikační sítě pomocí signálového procesoru ADSP. Vývojový modul bude umožňovat zpracování analogových signálů v reálném čase přivedených na vstupy modulu (filtrace, sčítání, zpoždění, implementace kodeků). Zpracované signály budou následně převedeny zpět do analogové formy na výstupy modulu. Seznam odborné literatury: [1]

ITU - T P.800, 1996

[2]

ITU - T P.48, 1988

[3]

ITU - T P.79, 2007

Vedoucí diplomové práce:

Doc. Ing. Jan Holub, Ph.D.

Datum zadání diplomové práce:

1. června 2009

1

Platnost zadání do :

30. června 2010

L.S.

Prof. Ing. Pavel Ripka, CSc.

Doc. Ing. Boris Šimák, CSc.

vedoucí katedry

děkan V Praze dne 1. 6. 2009

1

Platnost zadání je omezena na dobu tří následujících semestrů

3

Abstrakt Práce se zabývá postupem při návrhu a realizaci prototypu simulátoru telekomunikační sítě. Ke vstupu přistupuje jako k analogovému signálu nesoucímu zvukovou informaci hlasu a umožňuje nastavovat parametry, které ovlivňují jeho kvalitu. Výsledek úpravy zprostředkuje na svém výstupu opět v analogové formě. Práce uvádí použité hardwarové a softwarové řešení a zároveň slouží jako zdroj informací pro obsluhu, modifikaci, nebo připadnou opravu.

Abstract This paper describes the procedure of designing and construction of a telecommunication network simulator, which takes input as analog signal carrying sound information of voice and enables setting of parameters which has influence of its quality. Results of signal modifications are available on simulator output in analog format. Author introduces used hardware and software solution and also provides a source of information for handling, modification and eventual repairs.

4

Obsah Obsah ......................................................................................................................... 5 Seznam obrázků ......................................................................................................... 9 Seznam tabulek ........................................................................................................ 10 Seznam rovnic .......................................................................................................... 10 1

2

Úvod .................................................................................................................. 11 1.1

Důvody vzniku simulátoru telekomunikační sítě .......................................... 11

1.2

Kvalita přenosu hlasu .................................................................................. 11

1.3

Hodnocení kvality přenosu hlasu ................................................................. 12

1.3.1

Objektivní hodnocení ............................................................................ 12

1.3.2

Subjektivní hodnocení ........................................................................... 13

1.3.3

Vyhodnocení kvality přenosu hlasu ....................................................... 14

Oblast použití simulátoru, jeho principy a parametry ......................................... 16 2.1

Oblast použití simulátoru ............................................................................. 16

2.2

Princip funkce STS ...................................................................................... 16

2.3

Vlivy snižující kvalitu hovoru ........................................................................ 17

2.3.1

Šum ...................................................................................................... 17

2.3.2

Zkreslení terminálem ............................................................................ 17

2.3.3

Sidetone ................................................................................................ 17

2.3.4

Zpoždění ............................................................................................... 18

2.3.5

Kodek .................................................................................................... 18

2.3.6

Echo ...................................................................................................... 18

2.4 3

Cíl práce ...................................................................................................... 18

Prostředky pro realizaci ..................................................................................... 19 3.1

Popis hardwaru............................................................................................ 19

3.1.1

ADSP - BF533 ...................................................................................... 19

5

3.1.2

EZ - KIT Lite pro ADSP - BF533 ........................................................... 20

3.1.3

Ovládání a komunikace ........................................................................ 21

3.2

4

3.2.1

IDDE visualDSP++ ................................................................................ 22

3.2.2

VisualAudio ........................................................................................... 23

3.2.3

Prostředky pro vývoj obslužného programu na PC ............................... 29

Zpracování zvuku .............................................................................................. 31 4.1

Návrhové principy STS vyplývající z využití VA ........................................... 31

4.2

Zkreslení terminálem ................................................................................... 33

4.2.1

Širokopásmové filtry .............................................................................. 33

4.2.2

Filtry Intermediate Reference System ................................................... 36

4.2.3

VA blok zkreslení terminálem................................................................ 41

4.3

Šum ............................................................................................................. 42

4.3.1

Bílý šum ................................................................................................ 42

4.3.2

Hothův šum ........................................................................................... 42

4.3.3

VA blok pro generování šumu ............................................................... 43

4.4

Kodeky ........................................................................................................ 43

4.4.1

G.711 .................................................................................................... 44

4.4.2

G.729 .................................................................................................... 46

4.4.3

Kodeky ve VA ....................................................................................... 47

4.5

Sidetone ...................................................................................................... 48

4.6

Zpoždění ..................................................................................................... 48

4.7

Echo ............................................................................................................ 48

4.8

Ostatní operace se signálem ....................................................................... 49

4.9

Nároky na výpočetní výkon ......................................................................... 50

4.10 5

Programové vývojové prostředky ................................................................ 22

Objektivní hodnocení kodeků ................................................................... 51

Program pro obsluhu STS ................................................................................. 54 6

5.1

Prostředky a požadavky .............................................................................. 54

5.2

Komunikace ................................................................................................. 54

5.3

Příkazy ........................................................................................................ 55

5.3.1

Formáty parametrů modulů ................................................................... 55

5.3.2

Pravidla příkazů .................................................................................... 55

5.3.3

Nastavení úrovně zesílení..................................................................... 56

5.3.4

Nastavení zpoždění .............................................................................. 57

5.3.5

Nastavení úrovně šumu ........................................................................ 57

5.3.6

Nastavení filtru vysílací, příjímací strany ............................................... 57

5.3.7

Nastavení kodeku a kodeku echa ......................................................... 58

5.3.8

Nastavení typu G.711 ........................................................................... 58

5.3.9

Nastavení celkové hlasitosti .................................................................. 58

5.4

Speciální parametry příkazů ........................................................................ 59

5.5

Grafické prostředí ........................................................................................ 60

5.5.1

Log ........................................................................................................ 61

5.5.2

Komunikace a její nastavení uživatelem ............................................... 61

5.5.3

Ukládání a načítání stavu STS.............................................................. 62

5.5.4

Nastavování degradujících vlivů ........................................................... 63

5.6 6

Komunikace na straně STS ............................................................................... 66 6.1

7

8

Hardwarové a softwarové požadavky .......................................................... 65

Zpracování příkazu ...................................................................................... 66

Prototyp ............................................................................................................. 69 7.1

Požadavky ................................................................................................... 69

7.2

Připojení telefonních terminálů .................................................................... 69

Závěr ................................................................................................................. 71

Příloha A ................................................................................................................... 72 Příloha B ................................................................................................................... 73 7

Příloha C................................................................................................................... 77 Příloha D................................................................................................................... 79 Příloha E ................................................................................................................... 81 Seznam použitých symbolů a zkratek ...................................................................... 82 Použitá literatura ....................................................................................................... 83

8

Seznam obrázků obr. 1 Dopad hlavních vlivů přenosu sítě na kvalitu přenosu hlasu podle (1) ........... 12 obr. 2: Intruzivní objektivní testování ........................................................................ 13 obr. 3: Neintruzivní objektivní testování .................................................................... 13 obr. 4: Konverzační subjektivní testování ................................................................. 13 obr. 5: Poslechové subjektivní testování................................................................... 14 obr. 6: Blokové schéma simulátoru telekomunikační sítě ......................................... 17 obr. 7: Blokové schéma EZ - KIT pro ADSP - BF533 podle (4) ............................... 21 obr. 8: VisualAudio designér ..................................................................................... 25 obr. 9: VisualAudio piny ............................................................................................ 26 obr. 10: VA modul pro převod dvou monofonních signálů na jeden stereofonní....... 27 obr. 11: VA modul inspektor ..................................................................................... 27 obr. 12: Formální rozdělení simulátoru ..................................................................... 32 obr. 13: Amplitudová frekvenční charakteristika Talktrough systému ....................... 33 obr. 14: Grafické rozhraní skriptu pro návrh IIR filtrů ................................................ 34 obr. 15: VisualAudio blok pro širokopásmové filtry ................................................... 35 obr. 16: Amplitudové frekvenční charakteristiky širokopásmových filtrů ................... 35 obr. 17: Složení IRS systému ................................................................................... 36 obr. 18: VisualAudio blok pro send IRS .................................................................... 37 obr. 19: Amplitudová frekvenční charakteristika send IRS........................................ 38 obr. 20: VisualAudio blok pro send mIRS ................................................................. 38 obr. 21: Amplitudová frekvenční charakteristika send mIRS ..................................... 39 obr. 22: VisualAudio blok pro receive IRS ................................................................ 39 obr. 23: Amplitudová frekvenční charakteristika receive IRS .................................... 40 obr. 24: VisualAudio blok pro receive mIRS ............................................................. 40 obr. 25: Amplitudová frekvenční charakteristika receive mIRS ................................. 41 obr. 26: VisualAudio blok vysílací části zkreslení terminálem ................................... 41 obr. 27: VisualAudio blok pro Hothův šum ................................................................ 42 obr. 28: Amplitudová frekvenční charakteristika Hothova šumu ............................... 43 obr. 29: VisualAudio blok pro jeden multiplex kodeku .............................................. 47 obr. 30: Implementační blokové schéma simulátoru ................................................. 48 obr. 31: Sčítání hlavního signálu, echa a sidetonu ................................................... 49 9

obr. 32: Grafické rozhraní TelNetSim ....................................................................... 60 obr. 33: Nastavení komunikace ................................................................................ 61 obr. 34: Schéma prototypu ....................................................................................... 70

Seznam tabulek tab. 1: Škála poslechové kvality ................................................................................ 14 tab. 2: Parametry modulů přijímací i vysílací části pro širokopásmové filtry ............. 35 tab. 3: Parametry modulů pro send IRS.................................................................... 37 tab. 4: Parametry modulů pro send mIRS................................................................. 38 tab. 5: Parametry modulů pro receive IRS ................................................................ 39 tab. 6: Parametry modulů pro receive mIRS ............................................................. 40 tab. 7: Parametry modulů pro Hothův šum ............................................................... 43 tab. 8: Zatížení DSP jednotlivými bloky STS ............................................................ 50 tab. 9: Výsledky PESQ_MOS Talktrough a implementovaných kodeků ................... 52 tab. 10: Příkazy implementované obslužným programem ........................................ 56

Seznam rovnic rov. 1: Výpočet minimálního zpoždění signálu .......................................................... 26 rov. 2: Přepočet výsledku PESQ na MOS - LQO ...................................................... 52

10

Kapitola 1 1 Úvod V úvodu

se

seznámíme

s

důvodem

požadavku

vzniku

simulátoru

telekomunikační sítě a s pojmem kvality přenosu hlasu. Dále budou následovat metody a principy testování takovéto kvality.

1.1 Důvody vzniku simulátoru telekomunikační sítě Nutnost měření a hodnocení kvality hlasu přenášeného telekomunikační sítí je nezpochybnitelným faktem. Pomocí těchto činností jsme schopni rozhodnout o použitelnosti daného řešení a nastavení v určitém prostředí. Příkladem je zavedení nového telekomunikačního systému a potřeba zjistit, jak bude daný systém pracovat, popřípadě, jestli bude splňovat požadavky na kvalitu přenosu hlasu. Objektem pro měření a následné zhodnocení výsledků může být samotná konkrétní realizace telekomunikační sítě. Jednoznačnou výhodou tohoto řešení je absolutní relevantnost výsledků. U složitých systémů se však značně navyšuje náročnost a především cena takového postupu. Realizovat pokaždé plně funkční systém s nejistotou výsledku by vedlo často k enormním nákladům. Existuje možnost uskutečnit tato měření na prostředku, simulátoru, který s požadovanou přesností dokáže reprodukovat chování reálného systému. Pokud je možnost simulátor navrhnout tak, aby byl variabilní a pokrýval velkou škálu možností využití

při

zachování

dostatečné

přesnosti

výsledků,

dospějeme

k řešení

úspornějšímu na čas i prostředky. Možnost opakovaného použití vyplývá ze samotného charakteru simulátoru. Šířka záběru nasazení v testování je určena různorodostí jeho nastavení.

1.2 Kvalita přenosu hlasu Pojmem kvalita přenosu hlasu rozumíme srozumitelnost řečového signálu pro posluchače. Je ovlivněna celou řadou parametrů cesty, kterou hlas prochází. Tyto vlastnosti mají za následek zkreslení, ovlivňují tedy kvalitu signálu. Závislost nejdůležitějších parametrů na celkovou kvalitu hovoru vyjadřuje obr. 1.

11

obr. 1 Dopad hlavních vlivů přenosu sítě na kvalitu přenosu hlasu podle (1)

1.3 Hodnocení kvality přenosu hlasu Existují dvě základní metody testování kvality přenosu hlasu. Subjektivní je získáno na základě lidského faktoru. Druhou skupinou je objektivní testování, které je čistě algoritmickou záležitostí.

1.3.1 Objektivní hodnocení Spočívá v použití měřících algoritmů. Výsledky jsou vyhodnoceny na základě převodu mezi mírou zhoršení a jejím předpokládaným dopadem na kvalitu hlasu. Výhodou je stálost výsledků při měření konkrétní degradace, nízká cena a malá časová náročnost. Negativně limitující je nemožnost přesně definovat všechny degradující jevy a především jejich společné působení na konečnou kvalitu přenosu hlasu. Další nevýhodou je složitost implementace různé míry, kterou daný typ degradace způsobuje při odlišných podmínkách. Příkladem je jazyk, ve kterém hovor probíhá. Délka zpoždění echa bude ovlivňovat kvalitu přenosu hlasu jinou měrou v japonštině než v češtině. 12

Metody objektivní dělíme na intruzivní, kdy matematický algoritmus vyhodnotí kvalitu na základě porovnání s referenčním, nezhoršeným signálem. Blokové schéma těchto metod je na obr. 2.

obr. 2: Intruzivní objektivní testování

Druhým typem jsou metody neintruzivní, jejichž princip je na obr. 3. Nemají referenci a výsledek závisí pouze na samotném algoritmu.

obr. 3: Neintruzivní objektivní testování

Trendem je zlepšovat objektivní metody a jejich algoritmy, jelikož jsou méně nákladné na provedení oproti druhé skupině způsobu testování, které je popsané v následující podkapitole. ITU - T doporučení (2) se podrobněji zabývá těmito objektivními metodami testování.

1.3.2 Subjektivní hodnocení Subjektivní hodnocení je založeno na rozhovoru dvou subjektů (osob), jedná se o typ konverzační, který je principielně uveden na obr. 4.

obr. 4: Konverzační subjektivní testování

Druhým typem je metoda poslechová, kdy subjekty hodnotí předpřipravené vzorky. Její princip je na obr. 5.

13

obr. 5: Poslechové subjektivní testování

Výhodou je nezávislost na konkrétním typu zhoršení. Výsledek je tak degradujícími jevy, respektive jejich společným působením, ovlivněn pouze tak, jak se projevuje posluchači. Na druhou stranu, výsledky tohoto typu testování jsou značně závislé na subjektech, které samotné hodnocení provádějí. Největší nevýhodou je pak cena realizace takovýchto testů, kdy náklady jsou mnohonásobně vyšší než u hodnocení objektivního. Není nezvyklé, že subjektivní metody při poslechových testech zahrnují osm či více hodnotících osob a čas testování je jeden i více dní. Mzdové náklady pro hodnotící subjekty jsou tak hlavní částí ceny testování. Subjektivní metoda podléhá řadě požadavků (minimální počet osob, obsah promluvy, délka promluvy a další). Tento druh testování ze svého principu funkce nemůže být nasazen v reálném čase na provozní síti. Více o subjektivním testování se lze dočíst v doporučení ITU - T (3).

1.3.3 Vyhodnocení kvality přenosu hlasu Obě zmíněné metody a jejich podtypy své výsledky vyjadřují pomocí různých škál ohodnocení.

Příkladem nejpoužívanější je pětibodová „Škála poslechové

kvality“ („Listening – quality scale“), jejímž výsledkem je „MOS“ („Mean Opinion Score”). Je užívána v poslechových i konverzačních metodách subjektivního testování, kde je výsledkem statistického zpracování dílčích hodnocení subjektů. Často také bývá výsledným zhodnocením algoritmu daného objektivního hodnocení kvality přenosu hlasu. Jednotlivé stupně vyjadřuje tab. 1. Hodnota České označení Anglické označení 5 Výborně Excellent 4 Dobře Good 3 Průměrně Fair 2 Špatně Poor 1 Nedostatečně Bad tab. 1: Škála poslechové kvality

14

Jelikož oba typy metod testování disponují výhodami i nevýhodami, je ideální využít v případech, kdy to bude možné, obou způsobů. Vážený průměr jejich výsledků bude nejlépe vypovídající hodnotou MOS. Ve většině případů má subjektivní hodnocení relevantnější výsledky, tedy jeho výsledek bude násoben větší váhou. Tento komplexní přístup je však jen zřídka kdy možný.

15

Kapitola 2 2 Oblast použití simulátoru, jeho principy a parametry Kapitola se zaměřuje na pole operací, pro které bude simulátor telekomunikační sítě využíván. Následně obsahem pokrývá obecné shrnutí parametrů důležitých pro komplexní simulaci vlivů na kvalitu hovoru. Poslední částí je ucelený náhled na cíl této diplomové práce.

2.1 Oblast použití simulátoru Simulátor telekomunikační sítě (dále STS), jehož vývoj je popsaný v této diplomové práci, je určen do oblasti subjektivního testování kvality přenosu hlasu. To samozřejmě ovlivňuje celou koncepci realizace, od principů až po samotné fyzické provedení prototypu. Základem subjektivního testování je posluchači poskytnuté ohodnocení, není tedy nutné, aby simulátor jakkoliv hodnotil, zaznamenával nebo měřil parametry zpracovávaného signálu. Musí však přesně definovaným způsobem signál ovlivňovat. Podtyp subjektivního testování, tedy poslechový či konverzační, žádným způsobem nekonkretizuje STS tak, aby vylučoval použitelnost druhého způsobu. To je důsledkem unifikovaného vstupu, který je nezávislý na tom, zda je elektrický signál nesoucí informaci o řeči výstupem audio zařízení generujícího vzorky, nebo mikrofonu, který získá signál z akustického tlaku. Obdobně pak výstup může být zprostředkován jednomu či více subjektům. Jednou z výhod vznikajícího STS by měla být portabilita a z ní vyplývající malé rozměry finálního výrobku. Zmíněná snadná použitelnost a přemístitelnost bude mít zásadní vliv na výběr prostředků pro jeho realizaci.

2.2 Princip funkce STS Vstupem je řečový signál, který se definovaně degraduje a předává výstupu. Simulátor je prostředkem pro realizaci zpoždění, echa a sidetonu. Dále zahrnuje zkreslení vstupním a výstupním terminálem, což je zejména filtrace. Dalším vlivem je 16

pak použitá technologie pro přenos (GSM, VoIP atd.), která je z největší části charakterizovaná použitým kodekem.

Ke vstupu se přidává nastavitelná úroveň

šumu. Blokové schéma simulátoru vyjadřuje obr. 6.

obr. 6: Blokové schéma simulátoru telekomunikační sítě

2.3 Vlivy snižující kvalitu hovoru Parametry jednotlivých degradujících vlivů musí být nastavitelné tak, aby pomocí jejich kombinací mohlo být možno realizovat co nejširší spektrum simulací. Jelikož

se

návrh

neřídí

žádnou

normou

či

doporučením

pro

simulátor

telekomunikační sítě jako takový, budou se parametry a jejich možnosti nastavení odvíjet od mezí daných reálnými telekomunikačními sítěmi.

2.3.1 Šum Jelikož se šum velkou mírou podílí na srozumitelnosti řeči, je nezbytným prvkem v implementaci simulátoru. Mělo by být umožněno zcela potlačit generovaný šum. Horní mezí úrovně šumu je pak plný rozsah výstupu. V telekomunikacích se pro simulaci šumu v místnosti používá Hothův šum, měl by tak s „šumem bílým“ tvořit dva možné typy nastavení u STS.

2.3.2 Zkreslení terminálem Zkreslení terminálem lze charakterizovat filtrací a popřípadě zesílením některých frekvenčních rozsahů. Jelikož STS bude určen nejen pro aplikace v klasické konvenční telefonii, která je v oblasti terminálů definována pomocí mIRS popřípadě

IRS,

měl

by

krom

simulace

těchto

systémů

disponovat

také

širokopásmovými filtry, které budou určeny pro testy v internetové telefonii apod.

2.3.3 Sidetone Jedná se o přenos vstupu na výstup v rámci jednoho terminálu. Jeho zpoždění bývá 30 a více milisekund, u analogových terminálů může být zpoždění blízké nule. V terminálech je uměle vytvářen z historického důvodu. Výsledky subjektivních testů 17

vykazují snížení kvality hovoru bez jeho přítomnosti. STS by měl disponovat možností nastavit jeho úroveň až na 0 dB původního signálu.

2.3.4 Zpoždění Takto se nazývá časový rozdíl mezi okamžikem výstupu daného signálu s okamžikem jeho vstupu. Vzniká součtem časových prodlev, které jsou důsledkem hardwarové a softwarové realizace dané telekomunikační cesty. Reálné cesty, provozující přenos hlasu v telekomunikacích, mají zpoždění typicky 150 - 500 ms. V extrémních případech, na hranici akceptovatelné srozumitelnosti, je až 2000 ms, což bude tedy ideální maximálně nastavitelná hodnota pro STS.

2.3.5 Kodek V oblasti přenosu hlasu se jedná o kodeky řečové. Jsou důležitým a charakteristickým prvkem daného uskupení telekomunikační sítě. Zřejmým důvodem používání kodeků je samozřejmě snížení objemu datového přenosu, což má za následek vliv na kvalitu hlasu. U bezeztrátových kodeků je to vliv na zhoršení kvality přes zpoždění, z důvodu času nutného pro zakódování a dekódování. U ztrátových kodeků pak i přímo na zkreslení, kdy dochází k „zahození“ méně důležitých částí signálu.

2.3.6 Echo Je podobné sidetonu v tom, že se jedná o přenos vstupu na výstup v rámci jednoho telefonního terminálu. Rozdílem je, že zkreslení echa je ovlivněno cestou tam a zpátky. Je tak na něj aplikováno zpoždění a zkreslení průchodem kodeků obou směrů. Úroveň bude opět vztažená k původnímu signálu do hodnoty 0 dB.

2.4 Cíl práce Cílem této práce je navrhnout a vyrobit funkční prototyp simulátoru s uvedenými nastavitelnými parametry, aby se stal nástrojem pro testování širokého spektra stavů a kombinací telekomunikační sítě při dostatečné spolehlivosti a důvěryhodnosti výsledků. Výhodou oproti již existujícím simulátorům by měl být malý rozměr. Pokud se podaří vytvořit prostorově malý simulátor, bude v jeho přenositelnosti skrytá výhoda provádění testů téměř kdekoliv. Snadno se využije pro praktickou prezentaci výsledků na konferencích.

18

Kapitola 3 3 Prostředky pro realizaci Obsahem kapitoly je výběr realizačních prvků. Nejdříve se zaměří na hardware, následně pak na možnosti prostředí vývoje programu provádějící činnost STS.

3.1 Popis hardwaru Výběr platformy pro STS je zadáním určen do oblasti ADSP. Tato kategorie je výběrem logickým, jelikož procesory z této větve disponují skvělými předpoklady pro zpracování signálu a jeho úpravu. Požadavek na přenositelnost STS a jeho komplexní činnost naznačuje nutnost výběru výpočetně výkonného DSP. Provedení všech operací úpravy signálu v akceptovatelném zpoždění pomocí jednoho signálového procesoru zaručí kompaktnost výsledného výrobku. Předním výrobcem v oblasti ADSP je firma Analog Devices (ADI). Má široký sortiment nabídky produktů a poskytuje vynikající podporu. Procesory pracující v pevné řadové čárce jsou zastoupeny řadou Blackfin. Jedná se DSP určené pro moderní, výpočetně náročné vestavěné systémy zvuku, videa a komunikační aplikace. Procesory Blackfin poskytují výhody skvělého výpočetního výkonu DSP při zpracování signálu v kombinaci s jednoduše využitelnými vlastnostmi charakteristické pro moderní mikroprocesory. Jsou tak právoplatným zástupcem ADSP. Zmíněné vlastnosti předurčují jejich využití v aplikacích, kde nahradí nutnost využití více oddělených heterogenních procesorů. Tato řada procesorů se tedy jeví jako ideální kandidát pro realizaci STS. Produkční řada procesorů Blackfin obsahuje mnoho modelů, které se liší velikostí jednotlivých pamětí, druhem periferií a výkonem. Jelikož bude STS záležitost několika kusů a nebude se jednat o masovou produkci, nemá smysl řešit finanční rozdíly několika desítek dolarů na procesor.

3.1.1 ADSP - BF533 Nejvýkonnějším procesorem s jedním jádrem řady Blackfin je ADSP - BF533, který dosahuje až 1500 MMACs při frekvenci 600 MHz. ADI téměř ke všem procesorům vyrábí vývojové kity s řadou periferií, které poskytují široký záběr využití 19

při vývoji. Tento kit je tak ideálním nástrojem pro vývoj STS. Podrobnosti o tomto procesoru jsou dostupné z (4).

3.1.2 EZ - KIT Lite pro ADSP - BF533 Jedná se o vývojový modul, který umožňuje vývoj a testování procesorů BF531, BF532 a BF533. Podrobný popis tohoto kitu lze nalézt v (5). Parametry EZ - KIT Lite pro ADSP - BF533: x

Procesor o frekvence až 756 MHz o oscilátor 27 MHz o L1 cache 148 kB SRAM na čipu o PPI, SPI, časovače, UART, 2 x SPORT, EBIU

x

Paměť RAM o 64 MB (32M x 16bit) SDRAM

x

Paměť flash o 2 MB (512K x 16bit x 2)

x

Analogové audio rozhraní o AD1836

x

-

A/D a D/A sigma - delta převodníky

-

vzorkování až 96 kHz

-

až 24 bitů

Analogové video rozhraní o ADV7183 video dekodér a ADV7171 video kodér

x

Rozhraní pro komunikaci RS - 232

x

LED diody

x

Tlačítka

Blokové schéma tohoto procesoru je na obr. 7. Pro účely STS bude pro vstup a výstup analogového signálu nesoucí informaci o hlase sloužit AD1836. Ten je s procesorem propojen pomocí SPORT0. V paměti flash bude uchován program při přerušení napájení, a bude tedy sloužit pro „bootování“. Je očividné, že 148 kB SRAM nebude stačit pro celý kód a data programu a proto se jistě využije 64MB paměti SDRAM. 20

.

obr. 7: Blokové schéma EZ - KIT pro ADSP - BF533 podle (4)

3.1.3 Ovládání a komunikace V tomto momentě je nutné rozhodnout, jakým způsobem bude realizována obsluha simulátoru. První možností je ovládání a nastavování přímo na STS. To by znamenalo přidání zobrazovacího prostředku, nejlépe displeje, jelikož možnost nastavení by pomocí LED znamenala neustálou kontrolu s dokumentací. Ovládání by pak bylo možno realizovat pomocí tlačítek na kitu. Tento způsob ale znamená poměrně velkou složitost a nepohodlnost. Lepším řešením bude komunikace s nadřazeným PC s obslužným programem. Z toho vyplývá nutnost rozhodnout o způsobu komunikace. I když je na kitu pozorovatelný konektor USB, tímto rozhraním modul nedisponuje a uvedený konektor slouží pouze pro „debugovacího“ agenta vývojového softwaru. ADI dodává rozšiřující kartu, která disponuje rozhraním USB a 21

Ethernet. Je zřejmé, že nároky na komunikaci budou minimální. Nebude vyžadován žádný přenos velkého objemu dat. Půjde pouze o posílání nastavovacích příkazů. Jediné rozhraní, kterým vývojový modul disponuje, je RS - 232. To zprostředkovává sériová data UART obvodu procesoru. Bude tak zcela dostačujícím komunikačním prostředkem s nadřazeným PC. Fyzické propojení pro sériové rozhraní RS - 232 tvoří nejčastěji devítipinový konektor (například CANNON9). Od přítomnosti tohoto typu konektoru v PC je však postupem času upouštěno. V nových, stolních i přenosných PC, není přítomen. To by mohl být zdroj komplikací s kompatibilitou při využití simulátoru třetí stranou. Zde se nabízí možnost převodu na rozhraní USB pomoci FTDI čipu. Jedná se o integrovaný obvod zajišťující zprostředkování sériových dat přes moderní USB rozhraní. Ovladače jsou k dispozici pro široké spektrum operačních systémů, včetně MS Windows. Tento čip tak umožní použití rozhraní RS - 232 na straně kitu a zprostředkuje data pomocí moderního, všude přítomného USB portu. V operačním systému je pak již dostupný jako klasický sériový port COM. Existuje v provedení, kdy je integrován do konektoru kabelu. Takové řešení realizuje firma PremiumCord, která ve svém produktu používá čip s označením FT8U232AM, který dosahuje rychlosti až 920 kBaud.

3.2 Programové vývojové prostředky ADI ke svým DSP dodává vývojové prostředí VisualDSP++, které slouží jako hlavní prostředek pro programování DSP z jejich nabídky. Pro návrh audio aplikací je možno využít programu VisualAudio.

3.2.1 IDDE visualDSP++ VisualDSP++ (dále VDSP) je určen pro operační systémy MS Windows. Umožňuje komplexní činnost při vývoji softwaru. Je v něm obsažena podpora všech DSP firmy ADI. Podporuje také přímo jednotlivé EZ - KITy. S modulem se spojuje přes USB rozhraní v PC s JTAG emulátorem na kitu. VDSP umožňuje: x

Psát, kompilovat, sestavovat a linkovat programy napsané v programovacích jazycích C, C++ a assembleru pro podporované procesory 22

x

Nahrávat, spouštět, zastavovat a krokovat program

x

Přistupovat k datové a programové paměti a přepisovat ji

x

Simulovat přerušení a I/O

S tímto prostředím je dodávána řada knihoven s matematickými funkcemi a DSP rutinami. Po instalaci je k dispozici spousta příkladů pro nejrůznější oblasti. Nástroje pro optimalizaci: x

Lineární optimalizace o výsledkem je počet inkrementací PC (program counter) o je použitelná pouze v simulaci a jejím výsledkem je profil, který optimalizuje větvení programu o ke své činnosti potřebuje vstupní data, ke kterým je výsledek vázán

x

Statistická optimalizace o aniž by zasahovala do vykonávání programu, náhodným způsobem počítá PC a přístupy do paměti o využívá se v emulaci a poskytuje informace o výkonnostních nárocích jednotlivých funkcí programu v reálném čase

Velkou výhodou pro práci s audio signálem je nástroj pro grafická zobrazení dat úseku paměti. Velmi názorně tak může být zobrazeno pole s obsahem zpracovávaného signálu a ověřena správnost mezivýsledku. VDSP obsahuje řadu dalších funkcí a disponuje velkým množstvím vlastností, jejich popis lze najít v manuálu (6) .

3.2.2 VisualAudio VisualAudio (dále VA) je nástroj a sada komponent, které slouží pro urychlení vývoje audio systémů na procesorech od firmy ADI. Obsahuje: x

Knihovnu audio modulů o kolekce optimalizovaných „real – time“ funkcí pro vývoj rozličných audio produktů

x

Designér VisualAudio 23

o MS Windows aplikace pro grafickou tvorbu sítí zpracování zvuku x

EZ-KIT platformy o „real – time frameworky“ pro jednoduchost při vývoji na modulech s procesory od ADI

Platforma je odpovědná za inicializaci, I/O zvuku, ovládání a komunikaci s okolím na konkrétním hardwaru. Designér slouží pro tvorbu Layoutu. Ten je tvořen funkcemi jednotlivých audio modulů. Zároveň je pamětí jejich stavů a parametrů. Spojením Platformy a Layoutu vzniká program, jehož princip je následovný. Platforma zpracuje vstup, předá ho Layoutu. Ten aplikuje úpravu na základě použitých modulů a po dokončení vrátí signál zpět Platformě, která jej zformátuje na výstup. 3.2.2.1 Platforma, Layout VisualAudia a jejich princip Jednotlivé platformy se od sebe výrazně liší. To je dané různými periferiemi pro zpracování zvuku. Následující informace se již budou konkrétně vztahovat k platformě pro EZ - KIT Lite pro ADSP - BF533. Základní parametry: x

Analogová PCM I/O

x

Až 4 vstupy

x

Až 6 výstupů

x

Vzorkování 48kHz

x

594 MHz BF 533 procesor

Zpracování zvuku je založeno na TDM (time division multiple access). Jak bylo uvedeno, Layout charakterizuje samotné zpracování a úpravu zvuku. Jedná se o navázání jednotlivých funkcí v zadané posloupnosti. Vždy se tak zrealizuje úprava dané funkce a ukazatel se předá na pole výsledku další, následující funkce. Během těchto operací běží pomocí DMA na úrovni přerušení ukládání hodnot z A/D převodu, a také výstup již zpracovaných hodnot pomocí D/A. Ukládání pracuje na principu dvojitého úložiště, kdy do jednoho pole se ukládají nově příchozí data, a na data z druhého pole se aplikuje úprava. V dalším cyklu se pak děje na polích přehodí. Pole první slouží pro úpravu a pole druhé je plněno novými daty. Celý děj se neustále periodicky opakuje. 24

3.2.2.2 Designér VisualAudio Celá návrhová část probíhá v MS Windows aplikaci VisualAudio Designer. Jelikož návrh ve VA tvoří důležitou část vývoje STS, bude tato aplikace a její principy podrobněji popsány. Prostředí VA designéru je na obr. 8.

obr. 8: VisualAudio designér

Bodově popsaný postup návrhu: x

Výběr EZ - KITu (Platformy)

x

Tvorba sítě zpracování zvuku pomocí modulů v designéru

x

Možnost tvorby vlastních modulů (Layout)

x

Vygenerování zdrojových souborů, které jsou součástí projektu pro VDSP

x

Potřebná úprava kódu (přizpůsobení Platformy)

x

Nahrání programu přes VisualDSP++ do kitu

x

Možnost ladit spuštěný program přes BTC (Background Telemetry Channel) přímo VA designérem

Po výběru platformy nastavíme vzorkovací frekvenci a parametr TickSize. Ten udává, kolik vzorků jednoho audio kanálu náleží jednomu cyklu úpravy vstupu. Je možné nastavit jej od 1 do 2048. Při jeho růstu dochází k optimalizaci výkonu, jelikož

25

se stejné funkce aplikují na více dat, nevýhodou je pak rostoucí zpoždění vypočitatelné dle vztahu rov. 1. ܶ݀ ൌ ܲ‫ ܼܭ‬ൈ ܶ݅ܿ݇ܵ݅‫ ݁ݖ‬ൈ

ͳ ݂‫ݖݒ‬

ܲ‫ ܼܭ‬െ ‫ݑݕݒݐ݁«݋݌‬ā݅‫ݐ‬ý݄݈ܿ݇ܽ݊õǡ ܶ݀ െ ݈݉݅݊݅݉݊À‫݋݌ݖ‬ā݀³݊Àǡ ݂‫ ݖݒ‬െ ‫ܿܽݒ݋݇ݎ݋ݖݒ‬À݂‫݁ܿ݊݁ݒ݇݁ݎ‬ rov. 1: Výpočet minimálního zpoždění signálu

Audio síť modulů se vytváří metodou „drag&drop“. Vybraný modul se ze seznamu v levé části přetáhne na návrhovou plochu. Tam se spojením jeho vstupů a výstupů, neboli pinů, zařadí do hierarchie návrhu. Existuje několik druhů pinů, jejichž grafické rozlišení je na obr. 9. Piny modulů VA: x

Mono – charakterizuje monofonní zvukový signál

x

Stereo – charakterizuje stereofonní zvukový signál

x

Control – signál sloužící pro nastavení parametru modulu

x

Complex full spectrum – FFT hodnoty reálné sekvence

x

Real full spectrum – data o amplitudě nebo fázi jednotlivých složek signálu z FFT

obr. 9: VisualAudio piny (zleva mono, stereo, control, complex full spectrum, real full spektrum)

Propojení je možné provést pouze u pinů stejného typu a pouze z výstupu do vstupu. Některé moduly obsahují více druhů pinů. Mezi tuto skupinu patří i moduly provádějící konverze. Příkladem je modul pro převod z monofonního formátu na stereofonní, který je na obr. 10.

26

obr. 10: VA modul pro převod dvou monofonních signálů na jeden stereofonní

Při dvojkliku na modul je k dispozici inspektor, který umožňuje nastavení parametrů daného prvku. Příklad takového inspektora modulu pro nastavení zesílení nízké frekvence je na obr. 11.

obr. 11: VA modul inspektor

Každý modul může být v jednom z definovaných stavů. Stavy modulu VisualAudio: x

Aktivní (Active) – vykonává svou funkci

x

Vynechaný (Bypassed) – svůj vstup beze změny předá na výstup

x

Utišený (Muted) – na svůj výstup vkládá nulové hodnoty

x

Neaktivní (Inactive) – nic se s výstupem neprovádí, a je tak v nedefinovaném stavu

Pro nastavování stavu modulu existuje funkce „AMF_SetModuleStatus“. Jejími vstupními parametry jsou modul a stav, do kterého chceme modul přepnout. Tuto funkci budeme značně využívat jako aktivátor nepoužívaných modulů. Po dokončení návrhu se generuje kód pro VDSP. Projekt se nahraje do kitu a spustí. Od této chvíle je zpřístupněn Tunning. Jedná se o proces umožňující modifikaci parametrů jednotlivých modulů za běhu. Umožňuje tak změnu nastavení, jejíž dopad následuje v reálném čase. Probíhá pomocí BTC a nutností je spuštěné VDSP, které je spojeno s kitem. Komunikace mezi VA a VDSP probíhá na základě technologie „Component Object Model“, která slouží pro meziaplikační komunikaci 27

v prostředí MS Windows. Jakmile je Tunning spuštěný, v designéru v pravé části spodní lišty jsou přístupny údaje vytížení procesoru, zvlášť je pak zaznamenaná maximální hodnota tohoto vytížení. VisualAudio je skvělým nástrojem pro urychlení vývoje audio aplikací. Umožňuje soustředit se na samotnou úpravu zvuku a automaticky obstarává nastavení periferií a architekturu. Na developera pak zbývá vývoj modulů, které nejsou v knihovně obsaženy. Některé platformy obsahují i zdrojové kódy pro komunikaci s okolím přes rozhraní na KITu. Ne tak Platforma pro BF533 EZ - KIT. Proto je bude nutné do platformy přidat. 3.2.2.3 Vývoj modulů ve VisualAudio Při práci s VA je nedílnou součástí implementace vlastních modulů, která se skládá z několika procedur. Podrobné informace o tvorbě modulu se lze dočíst v (7). Postup: x

Vytvoříme následující adresářovou strukturu o xxx\Blackfin\XML o xxx\Blackfin\Include o xxx\Blackfin\Source o xxx\Blackfin\Lib

x

Přidáme do VA cestu xxx („System → System Properties → Audio Modules Directories“)

x

Vytvoříme v adresáři „Include“ hlavičkový soubor „AMF_JménoModulu.h“ popisující strukturu instance dané třídy. Tento soubor obsahuje definici všech proměnných a parametrů, které jsou potřebné pro danou instanci. Budou zde tak alokována pole a struktury s vlastnostmi a popisem momentálního stavu

x

Do adresáře Source přidáme soubor se samotným C kódem modulu. Jeho jméno bude AMF_JménoModulu.c o bude obsahovat:

void funkci AMF_JménoModulu_Render. Tělo této funkce zastupuje vykonávaný kód v případě, kdy je úprava signálu daného modulu požadována 9 vstupními parametry jsou: o ukazatel na instanci, která funkci volá 28

o ukazatel na pole vstupních a výstupních hodnot o TickSize, který je důležitý pro určení počtu vstupních a výstupních hodnot

statickou definici objektu, která popisuje modul. Zejména uvádí ukazatel na renderovací funkci

x

Posledním krokem je vytvoření XML souboru. Ten je určen pro VA designer. Na jeho základě jsou k dispozici nastavitelné parametry dané instance pro možnosti ladění. Pomocí něj je modul zakomponován do sítě zpracování signálu

Pomocí uvedeného postupu docílíme přístupnosti modulu ve VA designeru.

3.2.3 Prostředky pro vývoj obslužného programu na PC Tvorba softwaru na osobních počítačích s operačním systémem MS Windows nabízí širokou škálu možností. Od verze MS Windows 98 je použitelný Microsoft DotNET Framework, což je komponenta souboru technologií v softwarových produktech DotNET.

Jedná se o prostředí potřebné pro běh aplikací, které je i

spouštěcím rozhraním. Důvody vzniku DotNET: x

Lepší kompatibilita mezi kódem napsaným v různých programovacích jazycích. To je umožněno díky Common Intermediate Language, což je univerzální mezičlánek mezi kódem programátora a specifickou architekturou, na které je program vykonáván

x

Automatická správa paměti pomocí garbage collectoru, který obstarává uvolňování již nepotřebné paměti

x

Zjednodušení implementace obvyklých programovacích problémů jejich přítomností v přiložených knihovnách

Existuje řada jazyků využitelných s DotNET Frameworkem. Jedním z nich je C Sharp (C#). Jedná se o objektově orientovaný jazyk, syntaxí se podobá jazyku C. V jeho principech jsou viditelné prvky jazyku JAVA a C++.

29

Nejpoužívanějším vývojovým softwarem je MS Visual Studio. Tento program, DotNET technologie a jazyk C# bude výborná kombinace pro tvorbu programu sloužícího jako obsluha STS.

30

Kapitola 4 4 Zpracování zvuku V této kapitole je popsán postup, jakým STS zpracovává zvuk. Jsou zde uvedeny možnosti nastavení a změřené parametry jednotlivých bloků. Začátek je zaměřen na koncepci STS, která umožňuje využití VA. Na konci jsou pak uvedeny údaje o vytížení procesoru a informace o testování kodeků.

4.1 Návrhové principy STS vyplývající z využití VA Aby STS umožňoval poslechové subjektivní testy, stačí, aby disponoval jedním vstupem, který bude sloužit pro příjem řečových vzorků, a jedním výstupem, který zprostředkuje signál. Pokud ale chceme také možnost provádět i testy konverzační, musí STS obsahovat výstup a vstup na každé „straně“. Dále v této práci bude k simulátoru přistupováno jako k symetrickému zařízení, které má levou a pravou stranu. Přenos signálu se tak bude realizovat ze vstupu levé strany do výstupu strany pravé (směr zleva doprava) a samozřejmě i opačně, tedy ze vstupu pravé strany do výstupu strany levé (směr zprava doleva). Obě cesty budou obsahovat stejné bloky a disponovat stejnými vlastnostmi, což tvoří zmíněnou symetričnost. Ta ale nemusí být zachována ve stavu dílčích vlivů. Bude tak možné nastavit rozdílné zkreslující jevy obou směrů. Díky tomu je možné simulovat situaci, kdy je na každé straně terminál s různými vlastnostmi. Hlavní větví příslušné strany budeme označovat cestu signálu ze vstupu přes vysílací část, kodek, zpoždění a část přijímací. Na obr. 12 je zobrazeno uvedené pojmenování směru a částí. Je třeba dát pozor na echo, jelikož i když se nachází v prostoru strany levé, přísluší ke straně pravé a naopak. Příloha B obsahuje celé schéma simulátoru tak, jak je implementováno ve VisualAudio designéru. Uskupení modulů pro jeden daný vliv budeme nazývat blokem. V podkapitole 3.2.2 byla popsána Platforma VA a z ní odvíjející se dispozice STS. Empirickou metodou bylo rozhodnuto, že z hlediska optimalizace výkonu bude nejvhodnější nastavení parametru TickSize na hodnotu 512. Touto hodnotou dosáhneme vysoké úspory výkonu, kterého bude potřeba na práci kodeků. Při využití dvou vstupů tak bude minimální zpoždění Td vypočtené z rov. 1 rovno 21, 3 ms. ܶ݀ ൌ ʹ ൈ ͷͳʹ ൈ

ͳ ൌ ʹͳǤ͵ ͶͺͲͲͲ

31

Vypočtené zpoždění se bude pravděpodobně malou hodnotou lišit od změřeného. Tato odchylka bude způsobena přidáním součtu časů průchodu signálu vstupními a výstupními obvody. Změřená hodnota je 22, 8 ms a budeme ji muset brát v potaz při vlivech jako je zpoždění, sidetone či echo.

obr. 12: Formální rozdělení simulátoru

Dále budeme muset ověřit frekvenční vlastnosti, kterými kit disponuje, a popřípadě je kompenzovat. Pro všechna měření amplitudových frekvenčních charakteristik bude použito následujícího vybavení. Jako zdroj signálu bude sloužit funkční generátor PCG10, pro měření výstupu osciloskop PC Scope PCS500. Oba tyto přístroje jsou vyráběny firmou Velleman Instrument. K jejich ovládání slouží program Lab2000 a jeho aplikace Circuit Analyzer, která automaticky nastavuje frekvence sinusových signálů v určeném kroku na generátoru a osciloskopem na kanálu 1 zaznamenává RMS hodnoty. Tabulky naměřených hodnot jsou obsahem přílohy. Měření provedeme na systému Talktrough, který vstup předává na výstup bez jakékoliv úpravy. Výsledek tohoto měření je na obr. 13. Z výsledku je patrné, že kit disponuje velmi malou závislostí na kmitočtu. Zlom na 24 kHz vyplývá ze vzorkovacího teorému. Mezi 20 Hz a 20 kHz je křivka téměř plochá, jelikož se práce STS bude pohybovat výhradně ve frekvenčních oblastech mezi 50 až 12000 Hz, není tedy potřeba jakoukoliv nelineární kompenzaci provádět. Na zmíněném rozsahu je pozorovatelný útlum 1 dB, který se lehce vykompenzuje zesílením. Tyto velmi dobré vlastnosti lze přisoudit kodeku AD1836, jelikož je určen pro digitální hudební aplikace ve vysoké kvalitě. Použití v telekomunikačních řečových aplikacích, které vyžadují značně menší kmitočtový rozsah, vylučuje potřebu jakékoliv zásadní úpravy jeho frekvenčně závislých vlastností. V následujících měřeních bude již provedena zmíněná kompenzace o zesílení 1dB.

32

Talktrough

0 -5

Zesílení [dB]

-10 -15 -20 -25 -30 -35 -40 10

100

1000 f[Hz]

10000

100000

obr. 13: Amplitudová frekvenční charakteristika Talktrough systému

4.2 Zkreslení terminálem První úpravou signálu je zkreslení terminálem. Charakterizuje vliv přístroje na degradaci signálu posílaného z mikrofonu do telekomunikační sítě. Dále také opačný směr, tedy poslání signálu ze sítě do sluchátka. Bylo rozhodnuto implementovat filtry charakterizující jak telefony přenášející konvenční pásmo 300 - 3400 Hz (IRS Intermediate reference Systém, modified IRS), tak i multimediální zařízení (VoIP, hands-free atd.).

4.2.1 Širokopásmové filtry Pro moderní systémy, které zastupuje například internetová telefonie, se zkreslení terminálem charakterizuje filtrem. Ve VA je k dispozici modul „Biquad Cascade 32-Bit“, což je filtr IIR (Infinite Impulse Response). Jelikož jsou koeficienty filtru ve VA dány speciálním číselným formátem, navržené hodnoty koeficientů v externím programu by se musely ještě převést a manuálně zadat do modulu. Existuje však možnost navrhnout filtr pomocí skriptu v prostředí Matlab, který je k instalaci VA přiložen; tento má již potřebnou konverzi implementovanou. Jedná se o skript disponující grafickým rozhraním, obr. 14, které zobrazuje amplitudovou a 33

fázovou odezvu v závislosti na frekvenci aktuálního nastavení modulu. Tato utilita umožňuje výběr návrhového typu filtru (Butterworth, Chebyschev, Eliptický atd.), zadání zlomových frekvencí a samozřejmě také druh filtru (dolní, horní a pásmová propusť a pásmová zádrž). Komunikace mezi Matlabem a VisualAudio probíhá pomocí COM technologie a je podrobně popsána v (8). Každá změna, provedená v GUI návrhu filtru, se pomocí zmíněné technologie projeví na modulu ve VA. Pokud je VA v režimu ladění, pak pomocí stejné technologie, ale již mezi VA a VDSP, se projeví v programu běžícím na kitu. Můžeme tak například pomocí spektrálního analyzátoru ověřovat výsledky vlivu filtru s aktuálními koeficienty. Během ladění není možné měnit řád filtru, pouze jeho koeficienty.

obr. 14: Grafické rozhraní skriptu pro návrh IIR filtrů

Pokud navrhneme filtry pomocí dolní a horní propusti zvlášť a umožníme přepínáním jejich kombinace, bude tak k dispozici více frekvenčních variant při menším počtu IIR filtrů. Přepínání bude umožněno modulem „DeMux 1xN1“ a „Mux 1xN1“. Zlomové frekvence horní propusti zvolíme 50, 100 a 150 Hz, u dolní pak 7000, 8000 a 12000 Hz. Dospějeme tak k možnosti 9 druhů pásmových propustí. Pro 34

maximální možnou strmost u těchto širokopásmových filtrů nastavíme nejvyšší řád (16), který modul umožní. Popsané provedení je na obr. 15 a parametry modulů jsou v tab. 2. in

out

in

left_Send_LP7000

left_Send_HP50 in1

in

out

in2

left_Send_LP8000

out1 out

in

in3

out2 out3

leftSendWBMux in

out

in

out

left_Send_HP100

leftSendWBDeMux

out

in

left_Send_LP12000

out

left_Send_HP150

obr. 15: VisualAudio blok pro širokopásmové filtry

Širokopásmové filtry vysílací i přijímací části

5 0

Zesílení [dB]

-5 -10 -15 Pásmová propust 50 - 7000 Pásmová propust 100 - 8000 Pásmová propust 150 - 12000

-20 -25 -30 -35 -40 10

100

1000 f [Hz]

10000

100000

obr. 16: Amplitudové frekvenční charakteristiky širokopásmových filtrů

Název modulu IIR filtru Typ filtru Návrhová metoda filtru Řád Zlomová frekvence [Hz] left_Send_LP7000 DP Butterworth 16 7000 left_Send_LP8000 DP Butterworth 16 8000 left_Send_LP12000 DP Butterworth 16 12000 left_Send_HP7000 HP Butterworth 16 50 left_Send_HP8000 HP Butterworth 16 100 left_Send_HP12000 HP Butterworth 16 150 tab. 2: Parametry modulů přijímací i vysílací části pro širokopásmové filtry

Na obr. 16 jsou zobrazeny výsledky tří z devíti možných širokopásmových filtrů. Frekvenční charakteristiky ostatních šesti možností se liší pouze různými 35

kombinacemi zobrazených zlomových frekvencí a pro větší přehlednost grafu je nemá smysl zobrazovat.

4.2.2 Filtry Intermediate Reference System Intermediate Reference System (IRS) je doporučení uvedené v (9). Jedná se zejména o ohodnocení hlasitosti (Loudness Rating). Vzniklo sjednocením výsledků laboratoří, které se zabývaly hodnocením kvality přenosu hlasu. Pochází z počátku 70. let dvacátého století. Reprezentují analogové telefonní terminály pásmovou propustí 300 – 3400 Hz a SRAEN filtrem (Systeme de Référence pour la détermination de l'Affaiblissement Equivalent pour la Nettete), který slouží pro vyrovnání charakteristiky přes celé frekvenční spektrum. Pro reprezentaci digitálních zařízení s kodeky s nízkou bitovou rychlostí byly filtry upraveny odstraněním filtru SRAEN. Tato úprava je pak charakterizována modified IRS (mIRS), které je popsáno v (10). IRS a mIRS má tři hlavní části: x

Vysílací část (sending part)

x

Přijímací část (receiving part)

x

Spojení (junction)

Sestavením, kalibrací a propojením těchto částí vzniká kompletní IRS, který je na obr. 17.

obr. 17: Složení IRS systému

Vysílací část je přenos signálu z mikrofonu na výstup telefonu do telekomunikační sítě. Přijímací část je přenosem signálu z telekomunikační sítě do sluchátka telefonu. Obě části jsou realizovatelné zesílením a tvarovaným filtrem. Spojení mezi těmito částmi zastupuje sidetone a útlum.

36

STS musí mít kromě širokopásmových filtrů také možnost vybrat výše popsané IRS a mIRS na vstupu (vysílací část) i výstupu (přijímací část). Realizace se provede stejně jako u širokopásmových filtrů pomocí modulu pro IIR. Doporučení udává meze, ve kterých se musí frekvenční odezva dané části vyskytovat. Bude tak potřeba kaskádovat více filtrů, jelikož požadované charakteristiky mají více zlomů než jen na dolní a horní zlomové frekvenci. Nezbytné bude také zařadit zesílení. Například ideální hodnota vysílací části IRS je na frekvenčním pásmu 300 – 3400 Hz díky SRAEN filtru zesílena až o 13 dB. 4.2.2.1 Send IRS Na obr. 19, který je výsledkem amplitudové frekvenční charakteristiky send IRS, jsou patrné zlomy i v propustné části. Aby byl výsledek v určených mezích, bylo nutné použít kaskádování tří IIR filtrů. Dolní propust prvního řádu charakterizuje mírné stoupání zesílení s rostoucí frekvencí v oblasti 200 – 2000 Hz. Druhá horní propust i propust dolní jsou pak již s nejvyšším řádem, kvůli maximální strmosti. Celý blok VA je na obr. 18. Popsané parametry jednotlivých modulů jsou v tab. 3 in

out

left_sIRS_LP

in

out

left_sIRS_HP1

in

out

left_sIRS_HP2

obr. 18: VisualAudio blok pro send IRS

Název modulu IIR filtru Typ filtru Návrhová metoda filtru Řád Zlomová frekvence [Hz] left_sIRS_LP DP Butterworth 16 3510 left_sIRS_HP1 HP Butterworth 1 1200 left_sIRS_HP2 HP Butterworth 16 190 tab. 3: Parametry modulů pro send IRS

37

send IRS

10 5 0

Zesílení [dB]

-5 -10 -15 -20 send IRS -25 horní povolená mez -30 dolní povolená mez -35 -40 100

1000 f[Hz]

10000

obr. 19: Amplitudová frekvenční charakteristika send IRS

4.2.2.2 Send mIRS Skupinu možností vysílací části uzavírá send mIRS, jehož výsledek charakteristiky je na obr. 21. Kaskáda filtrů je nastavená identicky jako u send IRS, nutné bylo ale zesílení na 1. 25 krát, což je 1. 94 dB. Blok z VA je na obr. 20 a je popsán v tab. 4. in

out

left_msIRS_LP

in

out

in

left_msIRS_HP1

out

left_msIRS_HP2

in

out

left_msIRS_Scaler

obr. 20: VisualAudio blok pro send mIRS

Název modulu IIR filtru left_msIRS_LP left_msIRS_HP1 left_msIRS_HP2 Název modulu zesílení left_msIRS_Scaler

Typ filtru DP HP HP Zesílení [dB] 1.94

Návrhová metoda filtru Butterworth Butterworth Butterworth

Řád

tab. 4: Parametry modulů pro send mIRS

38

16 1 16

Zlomová frekvence [Hz] 3510 1200 190

send mIRS

10 5 0 -5

dB

-10 -15 -20 -25

send modified IRS

-30

horní povolená mez

-35

dolní povolená mez

-40 100

10000

1000 f[Hz] obr. 21: Amplitudová frekvenční charakteristika send mIRS

4.2.2.3 Receive IRS Přijímací část IRS musí být značně zesílená. Jelikož je zesílení větší než čtyřnásobné, což je maximum zesilovacího modulu, musí se zařadit za sebe dva moduly pro požadovaný zisk. Amplitudová frekvenční charakteristika je na obr. 23. Příslušný blok VA je na obr. 22 a je popsán v tab. 5. in

out

left_rIRS_LP

in

out

left_rIRS_HP1

in

out

left_rIRS_HP2

in

out

in

left_rIRS_Scaler1

out

left_rIRS_Scaler2

obr. 22: VisualAudio blok pro receive IRS

Název modulu IIR filtru left_rIRS_LP left_rIRS_HP1 left_rIRS_HP2 Název modulu zesílení left_rIRS_Scaler1 left_rIRS_Scaler2

Typ filtru DP HP HP Zesílení [dB] 12 0.95

Návrhová metoda filtru Chebychev Butterworth Butterworth

Řád

tab. 5: Parametry modulů pro receive IRS

39

16 2 16


receive IRS

20 15 10 Zesílení [dB]

5 0 -5 -10

horní povolená mez dolní povolená mez receive IRS

-15 -20 -25 -30 100

10000

1000 f [Hz] obr. 23: Amplitudová frekvenční charakteristika receive IRS

4.2.2.4 Receive mIRS Odstraněním SRAEN filtru došlo k poklesu zesílení oproti IRS. Bude stačit jeden VA modul se čtyřnásobným zesílením. Musela se také provést úprava zlomových frekvencí filtrů. Výsledky jsou na obr. 25. Příslušný blok VA je na obr. 24 a je popsán v tab. 6. in

out

left_mrIRS_LP

in

out

in

left_mrIRS_HP1

out

in

left_mrIRS_HP2

out

left_mrIRS_Scaler

obr. 24: VisualAudio blok pro receive mIRS

Název modulu IIR filtru left_mrIRS_LP left_mrIRS_HP1 left_mrIRS_HP2 Název modulu zesílení left_mrIRS_Scaler

Typ filtru DP HP HP Zesílení [dB] 12

Návrhová metoda filtru Chebychev Butterworth Butterworth

Řád 16 1 16

tab. 6: Parametry modulů pro receive mIRS

40


receive mIRS

20 15 10 Zesílení [dB]

5 0 receive mIRS horní povolená mez dolní povolená mez

-5 -10 -15 -20 -25 -30 100

1000 f [Hz]

10000

obr. 25: Amplitudová frekvenční charakteristika receive mIRS

4.2.3 VA blok zkreslení terminálem Ovládání STS umožňuje nastavit vlastnosti popsané v podkapitolách 4.2.1 a 4.2.2. Stejně jako u širokopásmových filtrů je výběr horních a dolních mezí realizován pomocí multiplexu, bude tímto způsobem realizován výběr celého zkreslení dané části. Tento princip pak bude použit u všech bloků, kde bude nutný výběr použité větve simulátoru. in

out

in

right_mrIRS_LP

out1 out2 in

out3 out4 out5 out6

in

out

right_rIRS_LP

in

out

in

right_mrIRS_HP1

in

out

right_rIRS_HP1

out

in

right_mrIRS_HP2

in

out

in

right_rIRS_HP2

out

out

right_Receive_LP8000

out

right_Receive_HP50 in1 in2 in3

out

in

rightReceiveWBMux in

out

in

right_Receive_LP7000 in

in

right_rIRS_Scaler1 right_rIRS_Scaler2

out

rightReceiveDeMux

out

right_mrIRS_Scaler

out

out1 out2 out3

out

right_Receive_HP100

rightReceiveWBDeMux out

right_Receive_HP150

obr. 26: VisualAudio blok vysílací části zkreslení terminálem

41

in3 in4 in5 in6

out

rightReceiveMux in

in

right_Receive_LP12000

in1 in2

Vhodným rozšířením je přidání nulového zkreslení vstupní i výstupní části. Využije se pro různé možnosti testování a měření pouze určitých částí STS tak, aby nebyly výsledky degradací zkreslení terminálem ovlivněny. Z uvedeného vyplývá, že tak vzniknou čtyři VA bloky (vysílací části dvou vstupů a přijímací části dvou výstupů). Každý bude obsahovat šest větví (dvanáct, pokud bereme v úvahu vnitřní rozvětvení širokopásmových filtrů). Na obr. 26 je blok jedné vysílací části.

4.3 Šum Srozumitelnost se s růstem hlasitosti šumu značně snižuje. Jeho úroveň je definována pro celou řadu typů testů.

4.3.1 Bílý šum Realizace bílého Gaussova šumu nebude ve VA problém. VA disponuje modulem přímo pro jeho generování. Umožňuje také zadání „seedu“, pomocí kterého zajistíme nestejnost náhodnosti v levé a pravé straně STS.

4.3.2 Hothův šum Jak bylo zmíněno, v telekomunikacích se často místo bílého šumu udává šum Hothův. Jeho spektrum je nastaveno, aby simuloval typický šum v místnosti. Docílit se ho dá pomocí zesílení a filtrace šumu bílého. Využijeme tedy podobného principu jako u IRS. O nastavení a specifikaci Hothova šumu se lze více dozvědět z (11). Přizpůsobíme kmitočtovou závislost pomocí kaskády IIR filtrů a zesílíme celkový signál šumu bílého. Hothův šum je definovaný na kmitočtovém pásmu 100 až 8000 Hz. Na obr. 28 je červeně vyznačen dle normy a modře je vyznačena již změřená realizace v STS. Je špatně viditelná, jelikož poměrně přesně kopíruje specifikaci. Byly využity dva IIR filtry, tři moduly zesílení a jeden modul ekvalizace, který zesiluje lokálně na nastavené frekvenci. Blok VA je na obr. 27 a je popsán v tab. 7.

in

out

leftHothFilter1

in

out

leftHothFilter2

in

out

in

leftHothEq

out

leftHothScaler1

in

leftHothScaler2

obr. 27: VisualAudio blok pro Hothův šum

42

out

in

out

leftHothScaler3

Název modulu IIR filtru

Typ filtru

leftHothFilter1 leftHothFilter2 Název modulu Tone Control Treble leftHothEq

DP DP Zesílení [dB] 3.8 Zesílení [dB] 12 12 11

Název modulu zesílení leftHothScaler1 leftHothScaler2 leftHothScaler3

Návrhová metoda filtru Butterworth Butterworth

Řád 2 1

Zlomová frekvence [Hz] 6000 90

Frekvence [Hz] 1500

tab. 7: Parametry modulů pro Hothův šum

Hothův šum

40 30

Zesílení [dB]

20 10 STS realizace Hothova šumu

0

Hothův šum dle specifikace -10 -20 -30 100

1000 f [Hz] obr. 28: Amplitudová frekvenční charakteristika Hothova šumu

4.3.3 VA blok pro generování šumu Celý blok pro obstarání šumu tedy vychází z generování šumu bílého a při požadavku na šum Hothův se multiplexem přiřadí kaskáda modulů pro něj určených. Úroveň šumu se nastavuje přímo v modulu jeho generování až na 0 dBFS.

4.4 Kodeky Kodeky jsou důležitým prvkem na cestě signálu v telekomunikační síti. Existuje řada řečových kodeků, které jsou určeny svými parametry do různých oblastí použití. Pro STS bylo rozhodnuto zahrnout dva kodeky, aby se ověřila možnost a náročnost 43

jejich implementace. Dodatečné přidání dalších typů pak bude do budoucnosti jedním z nejdůležitějších rozšíření STS.

4.4.1 G.711 G.711

je

nejběžnějším

a

nejrozšířenějším

kodekem

používaným

v telekomunikacích. Vznikl roku 1972. Princip spočívá v logaritmické kompresi na osmibitový signál. Vzorkovaní je o kmitočtu 8 kHz. Z toho vyplývá, že bitrate je 8000 × 8 = 64 kBit/s. Existují dva typy tohoto kodeku. G.711 μ-law: x

Severní Amerika, Japonsko

x

Kóduje 14-ti bitový signál

x

Větší přesnost pro signály s velkým rozsahem

G.711 A-law: x

Zbytek světa oproti μ-law

x

Kóduje se 13-ti bitový signál

x

Více kvantizačních kroků pro signály s nižší úrovní

Existuje několik dodatků a rozšíření ke G.711: Dodatek I: x

Packet Loss Concealment (PLC) pro zahlazení stop při ztrátě paketu v paketové síti

Dodatek II : x

Discontinuous Transmission (DTX), která pomocí technologie Voice Activity Detection (VAD) a Comfort Noise Generation (CNG) redukuje šířku pásma přenosu signálu v tichých místech

4.4.1.1 Implementace G.711 Pro implementaci tohoto kodeku využijeme knihovny od firmy ADI, která je k dispozici pod názvem G.711 Appendix I Voice Codec with PLC for the Blackfin ADSP-BF5xx Processor Family. Jedná se o knihovnu, která obsahuje kodér a dekodér. Umožňuje nastavit typ (A-law, μ-law ) a podporuje i PLC dle dodatku I. 44

Abychom integrovali funkce této knihovny, budeme muset vytvořit modul pro VA. Jelikož vzorkujeme 48 kHz a tento kodek je pro 8kHz, je nutností decimace a zpětná interpolace. Jde nám o vliv daného kodeku na zkreslení, modul tedy provede kódování a hned dekódování tak, aby se projevila případná změna na kvalitě hlasu. Jelikož počet vzorků, který se zpracovává, je 512 při vzorkování 48 kHz, a kodek pro jeden rámec potřebuje osmdesát 16-ti bitových PCM vzorků na 8 kHz, je nutné redukovat každých šest vzorků na jeden (48 kHz/ 8 kHz = 6). Nejlepším způsobem bude počítat průměr z tohoto počtu, a ten teprve poskytnout kodéru G711. Vyplývá z toho, že pro jeden kompletní rámec G.711 bude potřeba 480 (80 × 6 = 480) 16-ti bitových vstupních vzorků VA. Pokud je vstupní počet 512, musíme zajistit, aby se zbylé vzorky (512 – 480 = 32) buď přidaly k předešlému nedokončenému rámci, nebo začaly tvořit počáteční část rámce nového, nebo obojí zmíněné dohromady. Využijeme principu dvojího

ukládání.

Vstup

VA se postupně podvzorkuje

průměrováním a uloží se do pole, které bude vstupním pro kódování. Jakmile dosáhneme počtu osmdesáti vzorků, dojde ke spuštění kodéru. Jeho výsledek, zakódovaná zkomprimovaná data, předáme ihned dekodéru. Synchronně se zpracováváním nového vstupu VA se bude načítat hodnota z výstupu dekodéru, který je výsledkem zpracování předešlého rámce. Abychom dosáhli opět frekvence 48 kHz, vezmeme vždy dva vzorky a pomocí interpolace dojdeme k výsledku pro aktuální vzorek. Jelikož 512 není celočíselně dělitelné číslo šesti, vždy dojdeme ke zbytku vzorků o počtu menším než šest. Abychom zajistili stejný přístup ke všem vzorkům z hlediska průměrování, rozdělíme 512 vstupních vzorků na tři pomyslné části: x

PreTick – číslo méně než šest, které udává, kolik vzorků VA vstupu se musí zpracovat pro dokončení decimace načatého vzorku z předešlého cyklu. Zároveň je k dispozici součet hodnot těchto posledních vzorků nazvaný „reminderValue“. Na základě počtu těchto nezpracovaných vzorků se k „reminderValue“ přičtou hodnoty tolika VA vstupních vzorků, aby byl celkový počet hodnot sečtených v „reminderValue“ šest. Tento součet se podělí šesti a tvoří tak následující vzorek pro kodér

x

Tick – je číslo 510 + PreTick. Může ale nastat případ, že by byl větší než 512 a to je nepřípustné. V tomto případě je nutné ještě odečíst 6. Mezi hodnotami

45

PreTick a Tick tak vznikne interval dělitelný šesti. V tomto intervalu se ve VA vstupním poli se všemi vzorky provede decimace a předají se vstupu kódování x

PostTick – je číslo 512 - Tick. Udává, kolik vzorků se má uložit do „reminderValue“, a tedy se z něj odvozuje PreTick následného cyklu zpracování

Při interpolaci bereme vždy dva vzorky, ze kterých se tato určuje. Pokud však chceme určit interpolaci pro poslední výstupní prvek rámce dekodéru, nemáme následující ještě k dispozici. Předpokládáním stejného vývoje signálu tak interpolaci určíme rozdílem s prvkem předešlým. Jak bylo pospáno, G.711 se vyskytuje na světě ve dvou verzích. Knihovna od ADI podporuje A-law i μ-law. Proto přidáme i možnost výběru, v jaké logaritmické kompresi daná instance bude pracovat. Výše uvedený postup bude jádrem renderovací funkce modulu pro kodek G.711. Nakonec ještě musíme vytvořit XML soubor, který je prostředníkem mezi VA designérem a kódem funkce modulu.

4.4.2 G.729 G.729 je druhým z kodeků, které bude STS ve své první verzi podporovat. Jedná se o kodek, který je využíván především v internetové telefonii. Důvodem je schopnost podstatně snížit šířku pásma, a to na 8 kBit/s. Příkladem aplikace využívající tento kodek je Skype. G.729 využívá technologii ACELP (Algebraic Code Excited Linear Prediction), která je rozšířením CELP na úkor zvýšení výpočetního zatížení. Jádrem je lineární předpověď vývoje diskrétního signálu na základě minulosti a využití adaptivní a fixní knihovny kódových vzorů. G.729 má dva dodatky: Dodatek A: x

Snížení nároku na výpočetní výkon snížením komplexity, což se však projevuje na degradaci kvality hlasu

46

Dodatek B: x

Podobně jako dodatek II u G.711 zahrnuje i tento přidání DTX pomocí CNG a VAD

4.4.2.1 Implementace G.729 ADI pro tento kodek nabízí knihovnu G.729AB Voice Codec for the Blackfin Processor Family. Jelikož i tento kodek předpokládá PCM vzorky o vzorkovací frekvenci 8 kHz, bude jeho implementace téměř identická s G.711. Rozdíly se budou týkat především datových typů, které knihovny potřebují.

4.4.3 Kodeky ve VA V reálném světě mohou nastat případy, kdy signál není zpracován pouze jedním, ale dvěma a popřípadě více kodeky. Z toho vznikají situace, kdy je kvalita hovoru ovlivněna jiným způsobem při různém pořadí těchto kodeků. V některých případech se kvalita hovoru prakticky nezmění, v dalších je pak řeč zcela nesrozumitelná. Tyto dramatické rozdíly někdy opravdu způsobí pouhá záměna pořadí, v jakém je signál kodeky zpracován. Řetězení kodeků tak tvoří širokou oblast pro testování, jak dané uskupení kvalitu ovlivňuje. Proto bude dobré takovouto možnost zřetězení implementovat i do STS. Limitace je samozřejmě očividná ve výkonu. Procesor není schopen v čase 21, 3 ms kódovat a dekódovat nekonečný počet vzorků. Bylo rozhodnuto, že nemá smysl snažit se o více jak trojnásobné užití kodeků na jeden signál. Celý blok kodeků jednoho směru tak bude tvořen třemi multiplexory

a

třemi

demultiplexory,

které

budou

umožňovat

výběr

z implementovaných kodeků. Jeden z těchto tří multiplexů, bude při momentálním stavu možnosti využití G.711 a G.729 vypadat jako na obr. 29.

in

out1

in1

out2

in2

out3

in3

leftCodecDeMux1

in

out

leftG711EncDec1 in

out

leftCodecMux1

out

leftG729EncDec1

obr. 29: VisualAudio blok pro jeden multiplex kodeku

47

4.5 Sidetone Sidetone je signálem jdoucím z vysílací části terminálu A, který se přičte rovnou bez úpravy k signálu jdoucímu do přijímací části stejného terminálu A. Jeho zpoždění je definováno minimem, který STS umožňuje, a to je naměřená hodnota 22,8 ms. Ideálně se hodnoty zpoždění sidetone vyskytují někde kolem 20 až 30 ms. Jeho úroveň bude nastavitelná zesílením signálu v dB.

4.6 Zpoždění Blok zpoždění realizujeme pomocí VA modulu „Delay N“. Jeho maximální hodnota bude 2000 ms. Toto maximum se zadává předem, aby VA vědělo, jak velkou paměť má alokovat. V ovládacím programu bude nutné zajistit, aby minimální hodnota, kterou lze nastavit, byla 22,8 ms, přestože hodnota v bloku bude 0. To je způsobeno základním zpožděním daným nastavením TickSize VA popsaného v podkapitole 4.1.

4.7 Echo Úroveň echa se bude stejně jako u sidetonu nastavovat v dB vztažených k vstupujícímu signálu. V bodě implementace echa se dostáváme do situace, kdy se implementace rozchází s architekturou danou blokovým schématem. Je to důsledek tvorby separátní větve echa pro cestu signálu. Pokud bychom chtěli využít cesty stávajících směrů, docházelo by k zacyklení signálu. Neustále by se přičítal silnější signál z minulého cyklu na principu zpětné vazby. Budeme tedy muset vytvořit zcela novou cestu signálu, která bude mít autonomně nastavené zpoždění, jako součet zpoždění obou směrů. Jelikož je echo ovlivněno jakoby cestou tam a zpět, krom zpoždění musíme přidat ještě kodeky ve stejném pořadí, jako jsou v druhém směru.

obr. 30: Implementační blokové schéma simulátoru

48

Existují testy, kdy se porovnává vliv čistého echa (bez ovlivnění kodeky) a echa po průchodu kodeky. Cely blok kodeků cesty echa tak bude muset být multiplexem vypínatelný. Na obr. 30 je uvedeno blokové schéma, dle kterého je provedena implementace do STS.

4.8 Ostatní operace se signálem V celém návrhu dochází k řadě sčítání větví. Po rozvětvení se signál jednotlivě upraví, a poté je nutné jej dát opět dohromady. Existuje několik metod, jakými se součet signálů zvuku provádí. Jsou vyvinuty zejména pro omezení rozsahu, aby výsledek dvou a více silných signálů nebyl na výstupu ořezáván. To má za následek, že je součet nepřímý a jednotlivé části sčítance jsou ovlivňovány koeficienty. Jelikož to zasahuje do reprezentace zvuku na výstupu, není tento způsob zcela vhodný pro STS. Chceme zvuk degradovat pouze jevy, kterými simulátor disponuje, a to co nejpřesněji. Proto budeme signály sčítat základním způsobem. Nastavování a vstupy v takovém stavu, aby nedocházelo k překročení rozsahu výstupu, bude na osobě, která s STS bude manipulovat. Sčítání je provedeno pomocí modulu „Adder“. Na obr. 31 je pozorovatelná část, která po úpravách vysílací části, kodeků a zpoždění sčítá signál přímé větve simulátoru s echem a sidetonem. in

out

in1 in2

leftSidetoneGain in1 in2

out

Adder2x12

out in

leftCodecEchoMux

out

leftEchoDelay

in

out

leftEchoGain

in1 in2

out

Adder2x13 in

out

leftRightDelay

in

out

in1 in2

rightLeftDelay in in1 in2

out

rightEchoDelay

in

out

out

Adder2x14

rightEchoGain

out

rightCodecEchoMux in1 in

out

in2

rightSidetoneGain

out

Adder2x11

obr. 31: Sčítání hlavního signálu, echa a sidetonu

49

STS nemá definitivně určeno, jaké zařízení bude na výstupu, a tedy odpovídající impedanci. Pokud se nepoužije impedanční přizpůsobení, bude to mít samozřejmě za následek nestejnost úrovní hlasitosti na výstupu. Nejen z tohoto důvodu bude dobré přidat možnost zesílit signál po průchodu celým STS. Provedeme to pomocí dvou modulů „Scaler N“. Díky tomu budeme moci dosáhnout zesílení až 24 dB.

4.9 Nároky na výpočetní výkon Koncepce VisualAudia je založena na aplikaci renderovací funkce na vstupní vzorky modulu. To má za následek, že pokud v našem návrhu máme moduly, jejichž funkci momentálně vůbec nevyžadujeme (multiplexem je vybraná jiná cesta), stejně se práce prvku provede, i když se na ovlivnění signálu nijak neprojeví. To samozřejmě zvyšuje výpočetní výkon. V našem případě by tak byly aktivní desítky filtrů IIR, a především 24 instancí kodeků, nemluvě o dalších desítkách modulů, jako je zesílení a zpoždění. Takový výkon není schopen procesor zvládnout. Zároveň to ani není potřeba, protože pokud je nastaven filtr send IRS, není třeba, aby byl ve stejném směru počítán důsledek send mIRS a všech širokopásmových filtrů. Jednou z možností, jak takovouto situaci řešit, je využití stavů modulů popsaných v podkapitole 3.2.2.2. Stav MUTED ignoruje vstupní hodnoty modulu a automaticky na výstup dává samé nuly. Pokud tedy nastavíme všechny moduly, které nejsou potřeba v daném testu do tohoto stavu, značně ušetříme výpočetní výkon. VA v režimu ladění poskytuje informaci o zatížení procesoru. Pokud vypneme všechny možné moduly tak, aby signál ještě procházel, ale nebyl nijak ovlivněn, je využití procesoru 9.19 %. Blok VisualAudia Zatížení DSP [%] STS v režimu Talktrought 9.19 Kodek G.711 5.24 Kodek G.729 5.90 Send IRS 1.84 Send mIRS 1.94 Receive IRS 1.91 Receive mIRS 1.89 Širokopásmový filtr 1.73 Bílý šum 0.04 Hothův šum 0.45 tab. 8: Zatížení DSP jednotlivými bloky STS

50

V tab. 8 jsou uvedeny nároky jednotlivých modulů či bloků, které STS využívá. Je třeba podotknout, že při zatížení více jak 70% již procesor není schopen stihnout provést vždy v každém cyklu všechny úpravy a zvuk je tak nedefinovaně zdeformovaný. Takovéto zatížení momentálně nastává pouze při použití tří kodeků v obou směrech a zároveň zapnutém echu, které je kodeky ovlivněno. Ve všech ostatních kombinacích DSP svým výkonem dostačuje.

4.10 Objektivní hodnocení kodeků Správná funkce vlivů simulátoru jako je sidetone, zpoždění a echo se snadno ověří poslechem. Parametry šumu a zkreslení terminálem ověříme pomocí frekvenčního spektra vypočítaného programem osciloskopu. Problém ověření zda STS funguje tak jak má, nastává u kodeků. Degradace hlasu řečovými kodeky je z hlediska lidského vnímání někdy těžko rozeznatelná. Z tohoto důvodu by bylo vhodné provést měření, které by nám alespoň přibližně potvrdilo správnou funkci implementovaných kodeků. Vhodným způsobem bude využití objektivního hodnocení kvality přenosu hlasu. Doporučení ITU – T P.862 specifikuje objektivní metodu PESQ (Perceptual Evaluation of Speech Quality) a je podrobně popsána v (2). ITU – T také poskytuje ANSI – C kód realizující algoritmus PESQ. Pomocí něj tak budeme schopni získat potřebné informace o implementovaných kodecích v STS. Vstupními parametry programu pro zjištění výsledku pomocí PESQ jsou vzorkovací frekvence, referenční vzorek a vzorek degradovaný. Je tedy zřejmé, že se jedná o metodu intruzivní. Předem je nutno podotknout, že výsledky nelze brát absolutně, jelikož měření provedeme v akusticky i elektromagneticky značně nevyhovujícím prostředí. Dalším negativem bude vybavení. Využijeme obyčejné PC se zvukovou kartou. Nejen že bude zdrojem, který bude poskytovat referenční vzorek, ale také bude zaznamenávat degradaci hlasu pomoci vstupu „Line In“. Výše uvedené znamená, že výsledky budou velmi rozdílné od hodnot, které PESQ na kodecích dosahuje v laboratorních podmínkách. Abychom mohli vztahovat výsledky vůči relevantní hodnotě, provedeme nejdříve degradaci referenčního řečového vzorku samotným systémem a to dokonce i bez STS. Zjistíme tedy, jaký vliv na výsledek bude mít jen to, že vzorek pošleme 51

z výstupu zvukové karty do jejího vstupu. Záznam provedeme vždy desetkrát a určíme aritmetický průměr. Poté provedeme měření včetně STS bez toho, aby jakkoliv signál ovlivňoval. Zjistíme tak, zda opravdu použitý hardware a software pro simulátor nedegraduje signál, aniž bychom chtěli. Následovat pak budou jednotlivé kodeky a jejich řetězení. Nakonec ověříme, zdali má pořadí G.711 a G.729 vliv na kvalitu hlasu. Výsledkem algoritmu PESQ je pouze „surová“ hodnota v rozmezí -0.5 až 4.5. Pokud chceme získat MOS – LQO (Mean Opinion Score – Listening Quality Objective), musíme ji vypočíst dle doporučení (12). MOS – LQO nám umožní lineární porovnání s MOS. V doporučení je uvedena funkce pro přepočítání a vyjadřuje ji rov. 2.

ǦൌͲǤͻͻͻ൅

ͶǤͻͻͻȂͲǤͻͻͻ ͳ൅ሺǦͳǤͶͻͶͷൈሻ൅ͶǤ͸͸Ͳ͹

rov. 2: Přepočet výsledku PESQ na MOS - LQO

V tab. 9 jsou výsledné změřené, a vypočtené hodnoty. Příloha D obsahuje všechny naměřené hodnoty. Popis měřeného systému hodnota PESQ MOS – LQO Vystup a vstup zvukové karty je propojen 2.969 2.776 STS je v režimu Talktrough 2.949 2.746 Kodek G.711 A - law 2.810 2.546 Kodek G.711 μ - law 2.719 2.419 Kodek G.729 2.733 2.438 3 × G.711 za sebou 2.635 2.306 3 ×G.729 za sebou 2.764 2.482 1.kodek G.711 μ - law, 2.kodek G.729 2.824 2.565 1.kodek G.729, 2.kodek G.711 μ - law 2.751 2.463 tab. 9: Výsledky PESQ_MOS Talktrough a implementovaných kodeků

Z výsledků

je

patrné,

že

STS

v režimu

z degradujících vlivů, téměř signál neovlivňuje.

kdy

není

nastaven

žádny

U výsledků kodeků je viditelné

snížení hodnoty oproti Talktrough, což potvrzuje jejich vliv na kvalitu hlasu a tedy správnou funkci v STS. Hodnota 2.482 u trojnásobného řetězení G.729 je matoucí. Je velmi blízká hodnotě (paradoxně vyšší), kdy je aktivní pouze jeden kodek G.729. Je pravděpodobné, že ze svého principu funkce, u tohoto kodeku narůstá degradace hlasu s násobností jeho výskytu velmi málo. Poslední dvě hodnoty v tabulce ukazují, že pořadí u kodeků G.711 a G.729 opravdu kvalitu hlasu ovlivňuje. 52

Na závěr této podkapitoly musí být opět zdůrazněno, že výsledky jde porovnávat opravdu jen mezi sebou a i tento přístup má jen velmi přibližnou vypovídací hodnotu. Toto tvrzení lze podložit jednoduchým faktem. Kodek G.711 v obou typech (A – law, μ - law) vykazuje v ideálních laboratorních podmínkách hodnotu MOS – LQO = 4.518. V našich podmínkách jsme naměřili hodnotu 2.546.

53

Kapitola 5 5 Program pro obsluhu STS Kapitola se zabývá popisem vývoje a vlastností programu, který bude STS ovládat.

5.1 Prostředky a požadavky Jak bylo zmíněno v podkapitole 3.2.3, pro vývoj využijeme DotNet Framework pomocí jazyka C# ve vývojovém prostředí Visual Studio. Jelikož se jedná o aplikaci určenou pro operační systém MS Windows a jde především o grafické rozhraní, nemá smysl ohlížet se po jiných technologiích než WinForms, popřípadě WPF (Windows Presentation Foundation). WPF je poměrně novou technologií. Jejími výhodami je posílení data bindingu a přímá podpora DirectXu, a s tím spojená 3D grafika. Jelikož žádnou z těchto výhod nebudeme potřebovat, využijeme starší, ovšem neustále využívané a podporované WinForms. Program musí být schopen nastavit části STS tak, aby bylo možno využít celý potenciál simulátoru. Uživatel by měl být schopen program obsluhovat bez znalosti hardwarové či softwarové stránky simulátoru.

5.2 Komunikace Jak bylo rozhodnuto, komunikace bude probíhat pomocí sériového portu. DotNet Framework v namespace „System.IO.Ports“ disponuje objektem „SerialPort“, který má všechny potřebné vlastnosti pro komunikaci pomocí tohoto rozhraní. Nastavení sériové komunikace: x

Rychlost 115200 Baud

x

Žádná parita

x

8 datových bitů

x

Jeden stop bit

Příjem a zpracování příkazů na straně procesoru bude popsáno v další kapitole.

54

5.3 Příkazy Nastavování STS budeme provádět pomocí specifických příkazů. Pokud se jedná o vliv, který je na obou stranách STS, jeho syntaxe z levé nebo pravé strany vychází, jelikož určuje první písmeno příkazu, za ním následují písmena charakterizující jev, který se nastavuje. Pokud tedy měníme zesílení levého echa, příkaz bude ve formátu LEG (Left Echo Gain) a po mezeře bude následovat hodnota, na kterou si přejeme prvek nastavit.

5.3.1 Formáty parametrů modulů Příkazy budou nastavovat jednotlivé parametry modulů, tedy struktur charakterizujících

prvky

VisualAudia.

Zde

je

třeba

brát

ohled

na

formát

nastavovaného parametru. VA užívá řadu formátů pro parametry modulů. Vyplývá to z individuální potřeby přesnosti a rozlišitelnosti a zejména z celočíselného formátu zpracování procesorem Blackfin. Často využívá Q číselný formát. Je definován jako Qm.n, kde m je počet bitů pro celočíselnou část a n je počet bitů pro část za desetinnou čárkou. Převod z desetinného čísla do Qm.n formátu: 1. Vynásobíme číslo hodnotou 2^n 2. Zaokrouhlíme na nejbližší celé číslo Převod z Qm.n formátu na desetinné číslo: 1. Přistupujeme k číslu, jako když se jedná o INTEGER 2. Vynásobíme jej hodnotou 2^-n Je třeba myslet na to, zda je celé číslo v doplňkovém kódu.

5.3.2 Pravidla příkazů Zesílení se bude nastavovat v dB, což znamená převod na nelogaritmickou stupnici, jelikož parametry jednotlivých modulů jsou ve stupnicích lineárních. Ověření bezchybné komunikace se provádí programově. Po vyslání příkazu ze strany PC je v nastaveném intervalu očekávaná odpověď. Kromě příkazu na test komunikace se u všech ostatních příkazů PC očekává identický řetězec, který byl do simulátoru vyslán. 55

Příklad: Test komunikace. do STS pošleme COMTEST 123 a očekáváme COMTEST 321 Nastavení zesílení pravého sidetonu. do STS pošleme RSG 78451 a očekáváme odpověď RSG 78451 Seznam všech příkazů je uveden v tab. 10. Vliv Příkaz Formát Úroveň echa LEG / REG Q1.15 Úroveň sidetonu LSG / RSG Q1.15 Zpoždění LRD / RLD zpoždění (s) × fvz Úroveň šumu LXG / RXG Q1.31 Typ šumu LNT / RNT index větve Vysílací část LSF / RSF index větve Přijímací část LRF / RRF index větve Celková hlasitost LOG1, LOG2 / ROG1,ROG2 Q3.29 Kodek LCO / RCO pořadí Kodek v echu LEC / REC pořadí Nastavení typu G.711 kodeků G711CONFIG pořadí Test komunikace COMTEST speciální tab. 10: Příkazy implementované obslužným programem

5.3.3 Nastavení úrovně zesílení Pro sidetone a echo je využit modul „Scaler“, který disponuje parametrem „amplitude“. Ten je ve formátu Q1.15. Příklad: Nastavení zesílení pravého sidetonu na - 8 dB. lineárního zesílení = 10^(- 8/20) = 0.39810717 hodnota v Q1.15 = 0. 39810717×(2^15 – 1) =13044.77764 do STS pošleme příkaz RSG 13045

56

5.3.4 Nastavení zpoždění Hodnota zpoždění u modulu „Delay“ je udána v počtu vzorků. V obslužném programu zadáme zpoždění v milisekundách. Musíme tak hodnotu přizpůsobit dle vzorkovací frekvence a nesmíme zapomenout odečíst již trvalé základní zpoždění 22.8 ms. Příklad: Nastavení zpoždění zleva doprava na 260 ms. Hodnota = (260-22.8)*48 =11385.6 do STS pošleme příkaz LRD 11386

5.3.5 Nastavení úrovně šumu Modul „Test Signal White Noise Uniform Distribution“ disponuje parametrem „scale“, který udává poměr úrovně šumu vůči plnému rozsahu. Jeho hodnota je ve formátu Q1.31. Příklad: Nastavení úrovně šumu levé strany na -15 dBFS. lineárního zesílení = 10^(-15/20) = 0.177827941 hodnota v Q1.31 = 0.177827941×(2^15 – 1) = 381882595.3 do STS pošleme příkaz LXG 381882595

5.3.6 Nastavení filtru vysílací, příjímací strany Výběr provedeme pomocí pořadí větve. Pořadí má nulový základ. Stejný princip je užit u výběru šumu. Příklad: Výběr širokopásmového filtru 100 – 8000 Hz na levé vysílací části. Tento filtr je osmou možností. do STS pošleme příkaz RRF 7

57

5.3.7 Nastavení kodeku a kodeku echa Příkaz se bude opět odvíjet od umístění daného prvku v simulátoru. Umístění bude korespondovat s pozicí v parametru příkazu. První kodek, kterým signál prochází, bude mít index 0, druhý 1 a třetí hodnotu 2. Na dané pozici se objeví hodnota, která vybírá danou větev multiplexu. Stejným principem realizujeme nastavení kodeků ve větvi echa. Příklad: Chceme, aby ve směru zleva doprava byl první kodek G.711 (index větve 1), druhý nebyl (index větve 0) a třetí G.729 (index větve 2). do STS pošleme LCO 102

5.3.8 Nastavení typu G.711 Příkaz pro nastavení typu kodeku G.711 nemá rozlišení strany. Na první pozici parametru je index pořadí kodeku, pro který typ nastavujeme. Indexy 0, 1, 2 jsou pro směr zleva doprava a indexy 3, 4, 5 jsou pro směr zprava doleva. Druhá pozice parametru indexem 0 označuje A-law a indexem 1 μ-law. Příklad: Nastavení druhého kodeku G.711 ve směru zprava doleva na μ-law. do STS pošleme G711CONFIG 41 Jelikož kodeky v cestě echa jsou realizovány separátně, je nutné, aby byly nastavovány tak, jak vyplývá z logiky cesty signálu. Pro echo levé strany musí být kodeky větve echa nastaveny stejně, jako jsou kodeky v hlavní větvi směru zprava doleva. Tuto podmínku zajistíme přímo z programu správnou kombinací příkazů. Pokud chceme ve směru zleva doprava kodeky G.711, G.729 a poslední opět G.711, docílíme toho příkazem LCO 121. Při zapnutí echa ovlivněného kodeky na pravé straně musí být kodeky echa nastaveny shodně, tedy příkaz REC 121.

5.3.9 Nastavení celkové hlasitosti Nastavení celkové úrovně hlasitosti strany je realizováno pomocí dvou modulů „Scaler N“, který má při jednom vstupu parametr „amp[0] “. Ten je ve formátu Q3.29.

58

Příklad: Zesílení levé celkové hlasitosti o 16 dB. lineární zesílení 1 = 10^(12/20) = 3.981071706 lineární zesílení 2 = 10^(4/20) = 1.584893192 hodnota zesílení 1 v Q3.29 = 3.981071706×(2^29) =2137321598 hodnota zesílení 2 v Q3.29 = 1.584893192×(2^29) =850883053.4 do STS pošleme příkaz LOG1 2137321598 a následně LOG2 850883053

5.4 Speciální parametry příkazů Často budeme potřebovat hlasitost jevu zcela vypnout. Docílit toho můžeme pomocí nastavení hodnoty zesílení až na minimální hodnotu. To ale není zcela vhodné řešení. Pokud chceme například ověřit, jak je výstup ovlivněn při zapnutém sidetonu na úrovni zesílení - 20 dB, a následně když je sidetone zcela vyřazen, musíme neustále nastavovat úroveň na - 100dB, tedy minimum, a pak nastavit opět hodnotu - 20 dB. Nejen z tohoto důvodu implementujeme parametr MUTED do příkazů, které nastavují zesílení. Ten bude znamenat, že má být výstup modulu v každém cyklu nulový. Příklad: Nechceme, aby z pravého výstupu šel jakýkoliv signál. do STS pošleme ROG1 MUTED a následně ROG2 MUTED Obdobný případ bude u echa. Často se porovnává vliv echa ovlivněného kodeky a echa „čistého“. Pro tento případ bude sloužit parametr „NONCODED“, který bude charakterizovat výběr větve echa, které není kodeky ovlivněno. Příklad: Nastavení, kdy pravé echo nemá procházet kodeky. do STS pošleme REC NONCODED

59

5.5 Grafické prostředí Jelikož blokové schéma simulátoru je velmi intuitivní, bude výhodné místo různých karet s nastavením pojmout program jako zobrazení tohoto schématu s příslušnými nastavovacími komponenty vlivů na místech, kde se vyskytují. Pracovní plochu rozdělíme na dvě části. Horní větší polovina bude zmíněné schéma simulátoru s možnostmi nastavení. V dolní části bude informační okno se zprávami o stavu STS. V menu umožníme nastavit základní věci týkající se připojení k STS a vhodné bude také možnost uložit či načíst nastavení simulátoru. Grafické prostředí bude uspořádáno pro testy konverzační. Pro poslechové testování použijeme pouze jeden směr. Program byl pojmenován TelNetSim (Telecommunication Network Simulator). Na obr. 32 je zobrazeno výsledné grafické prostředí TelNetSim.

obr. 32: Grafické rozhraní TelNetSim

60

5.5.1 Log V dolní části GUI se zobrazuje log. Je přístupný také z adresáře aplikace, kde jsou textové soubory v názvu s datem vytvoření. Každý popis události je opatřen časovou známkou jeho vzniku. Přehlednost je umocněna alternací barev řádků.

5.5.2 Komunikace a její nastavení uživatelem Možnosti nastavení aplikace jsou přístupné z klasického menu. Variabilnost je pro jednoduchost minimální. V „Application→Properties“ je nastavení prioritního portu a maximální doba, kterou program pro ovládání STS čeká na očekávanou odpověď příkazu. Na obr. 33 je zobrazeno příslušné okno těchto možností.

obr. 33: Nastavení komunikace

V menu „Application→Connection“ je k dispozici příkaz „Scan for Hardware“. Ten ověřuje přítomnost STS na portu. Při spuštění aplikace je automaticky inicializován. I při nalezení STS a normálním chodu aplikace je ale stále uživateli k dispozici. „Scan for Hardware“ prvotně vyzkouší port, který je nastavený jako defaultní („menu→Application→Properties→Default port“). Pokud na něm STS neidentifikuje, následuje postupné skenování na portech COM 1 až 5, kromě již vyzkoušeného defaultního portu. Pokud na některém portu simulátor nalezne, automaticky je tento port nastaven jako defaultní, aby byl při příštím použití otestován prioritně. Pokud program simulátor nenalezne, může uživatel „Scan for Hardware“ využít pro nový pokus o spojení po zkontrolování a opravení chyby, kvůli které se spojení nezdařilo napoprvé. Ve stejné položce „Connection“, je možnost příkazu „Test connection“, který ověří správnost komunikace při již navázaném spojení. Je zaručeno, že při neexistujícím či nesprávném spojení nemá uživatel možnost nastavovat v programu jakékoli parametry STS. Toho je dosaženo pomocí nezviditelnění pracovní plochy při kterékoliv chybě komunikace. To trvá do doby, než je problém vyřešen. 61

V levé horní části je k dispozici hodnota, která uvádí, jak dlouhý čas uplynul mezi vysláním příkazu a příchodem očekávané odpovědi. Je aktualizována pokaždé, když je jakýkoliv příkaz provedený. Uživatel tak má kontrolu, zda aplikace reaguje na jeho vstupy. Příkazy se vysílají pomocí třídy „SendToSerialPortCommand“. Jedná se o objekt implementovaný v návrhovém vzoru „Command Pattern“. Každý příkaz je nová instance. Parametry pro konstruktor jsou sériový port, textový řetězec příkazu a řetězec očekávané odpovědi. Každý příkaz je do simulátoru vyslán pomocí funkce „execute“ této třídy. public object Execute(){ try{ //uchováme časovou známku startu vyslání příkazu var start = Stopwatch.GetTimestamp(); //zapíšeme příkaz na sériový port serialPort.WriteLine(command); try{ //čekáme na odpověď na sériovém portu var answer = serialPort.ReadLine(); //po příchodu zjistíme časovou známku a vypočteme interval responseTime = TimeSpan.FromTicks(Stopwatch.GetTimestamp()-start); //pokud je odpověď řetězec „Error“, STS příkaz nerozpoznal if (answer == "Error"){ Logging.TraceLine("command not recognized on hardware side"); return null; } //odpověď je shodná s předpokládanou, STS správně přijal příkaz if (answer == expectedAnswer){ return new object();} //odpověď nesouhlasí, vracíme null, tedy chybu připojení else{ Logging.TraceLine(String.Format("not expected data returned (expected: {0}, returned: {1})",answer,expectedAnswer)); return null; } } //vypršel časový interval catch { Logging.TraceLine("data not returned in timeout interval (check connection)"); } } //nastala chyba v komunikaci catch { Logging.TraceLine("communication error (check connection)"); } return null; }

5.5.3 Ukládání a načítání stavu STS Umožnit uživateli uvést simulátor do definovaného stavu je usnadněno pomocí ukládání a načítání. Obsluha má k dispozici dvě pozice, „Default“ a “Save 1“. 62

Jakékoliv nastavení STS může být do těchto pozic uloženo a načteno, a je tak umožněno lehce přepínat a porovnávat vliv na signál komplexních změn v nastavení. Uložení je stále k dispozici i po vypnutí aplikace, a je tak použitelné při přerušení provádění testu. K těmto příkazům je přístup přes „menu→Save/Load“. Pro synchronizaci nastavení programu a simulátoru je po navázání komunikace simulátor uveden automaticky do stavu z defaultního uložení.

5.5.4 Nastavování degradujících vlivů Uživatel má možnost nastavovat úrovně hlasitosti a hodnotu zpoždění buď zadáním požadované hodnoty do „TextBoxu“, pomocí jeho šipek, nebo tažením příslušného „TrackBaru“. Zaškrtnutí „CheckBoxu“ s názvem „Mute“ vypne příslušnou větev simulátoru. Stejně pak tatáž komponenta s popisem „Codecs“ u echa přepíná, jestli je echo ovlivněno kodeky či nikoliv. Nastavení výběrů jednotlivých větví je zpřístupněno pomocí komponenty „ComboBox“. To platí pro výběry vysílacích a přijímacích částí, typu šumu, kodeků a jejich nastavení. Pokud vybereme alespoň jeden kodek typu G.711, automaticky se zviditelní výběr typu jeho logaritmického kódování. Různá nastavení v grafickém prostředí často implementují více příkazů. Mnohdy je vysláno při jedné změně opětovné nastavení celého bloku tak, aby byla zajištěna neustálá synchronizace nastavení simulátoru se zobrazením v programu na PC. Funkce nastavení echa v sobě nese například nejen příkaz pro úroveň signálu, ale také nastavení kodeků v bloku echa. private void rightEcho_ValueChanged(object sender, EventArgs e){ //převezmeme hodnotu, kterou uživatel nastavil var res = (sender as NumericUpDown).Value; //zjistíme, zda je MUTE aktivní if (cbRightEchoMute.Checked == false){ //pošleme nastavenou hodnotu do STS, nejdříve ji delogaritmujeme a převedeme na Q formát OnValueChanged("REG", ((int)(UnLogharitmer(res) * 32767)).ToString()); //test, zda má být echo ovlivněno kodekem if (cbRightEchoType.Checked == true) { //nastavíme kodeky pravého echa podle kodeků levé hlavní větve string res1 = String.Empty; res1 += cbLeftFirstCodec.SelectedIndex.ToString(); res1 += cbLeftSecondCodec.SelectedIndex.ToString(); res1 += cbLeftThirdCodec.SelectedIndex.ToString(); //odešleme nastavení kodeků echa OnValueChanged("REC", res1);

63

} else{ //echo nemá být kodeky ovlivněno OnValueChanged("REC", "NONCODED"); } } else{ //echo je neaktivní, tedy parametr MUTED, a zároveň vypneme kodeky echa, jelikož nejsou potřeba OnValueChanged("REG", "MUTED"); OnValueChanged("REC", "NONCODED"); } //nastavíme TrackBar na hodnotu tak, aby korespondovala s nastavením v TextBoxu tbRightEcho.Value = Convert.ToInt32(res); }

Integrace dílčích příkazů do jedné funkce pak ještě více potvrzuje následující kód, který se stará o nastavení kodeků v hlavní větvi, konkrétně zleva doprava. Ten nejen že nastavuje kodeky a logaritmickou kompresi eventuelních G.711 kodeků, ale také zahrnuje výše uvedenou funkci nastavení kodeků echa a s tím spjaté nastavení úrovně echa. Je to logický důsledek relace kodeků hlavní části s kodeky echa. private void setLeftCodecs() { string res = String.Empty; //do proměnné res uložíme postupně indexy všech výběrů kodeků res += cbLeftFirstCodec.SelectedIndex.ToString(); res += cbLeftSecondCodec.SelectedIndex.ToString(); res += cbLeftThirdCodec.SelectedIndex.ToString(); //vyšleme příkaz nastavení levých kodeků OnValueChanged("LCO", res); //následuje funkce pro nastavení kodeků levého echa leftEcho_ValueChanged(leftEchoGain, null); //pokud res obsahuje alespoň jednu jedničku, je užit G.711 a je třeba nastavit jeho typ if (res.Contains("1") { //zviditelníme penel pro výběr typu G.711 paLeftCodecsProperties.Visible = true; //uvedeme všechny komponenty do stavu, kdy nereagují na vstup cbLeftFirstCodecProperties .Enabled = false; cbLeftFirstCodecProperties.SelectedIndex = -1; cbLeftSecondCodecProperties.Enabled = false; cbLeftSecondCodecProperties.SelectedIndex = -1; cbLeftThirdCodecProperties.Enabled = false; cbLeftThirdCodecProperties.SelectedIndex = -1; //pokud daná pozice obsahuje 1, nastavíme danou instanci na A-law pomocí příkazu G711CONFIG if (cbLeftFirstCodec.SelectedIndex == 1) { cbLeftFirstCodecProperties.Enabled = true; cbLeftFirstCodecProperties.SelectedIndex = 0; OnValueChanged("G711CONFIG", "00"); } if (cbLeftSecondCodec.SelectedIndex == 1) { cbLeftSecondCodecProperties.Enabled = true; cbLeftSecondCodecProperties.SelectedIndex = 0;

64

OnValueChanged("G711CONFIG", "10"); } if (cbLeftThirdCodec.SelectedIndex == 1) { cbLeftThirdCodecProperties.Enabled = true; cbLeftThirdCodecProperties.SelectedIndex = 0; OnValueChanged("G711CONFIG", "20"); } } else { paLeftCodecsProperties.Visible = false; } }

Shrnutí fungování TelNetSim, které bylo v individuálních částech principielně ukázáno, je tedy následující. Program naváže komunikaci se simulátorem. V případě chyb je uživateli neumožněno cokoliv provádět, pokud komunikaci neuvede do chodu. Komponenty pracovní plochy integrují ve funkcích svých eventů více příkazů a často provádějí transformaci formátu zadaného uživatelem na formát, který akceptuje struktura modulu VisualAudio. Logika možností nastavení je řešena na úrovni PC, nikoliv v kitu s programem simulátoru.

5.6 Hardwarové a softwarové požadavky Softwarové požadavky: x

MS Windows (Windows XP, Windows Vista, Windows 7)

x

DotNET Framework 3.5

Hardwarové požadavky: x

PC IBM kompatibilní

x

Minimální rozlišení grafické karty/displej VGA (1024/768)

x

USB port

65

Kapitola 6 6 Komunikace na straně STS Tato

kapitola

popisuje

principy,

jakými

simulátor

obsluhuje

příkazy

z nadřazeného PC.

6.1 Zpracování příkazu Simulátor reaguje na příchod UART dat voláním „callback“ funkce. Pokud již přijal

celý

příkaz,

což

je

označeno

„\0",

celý

řetězec

předá

funkci

„Process_Uart_Data“. Ta má za úkol rozpoznat, o jaký příkaz se jedná a provést z toho vyplývající nastavení na STS. Příkazy jsou uloženy ve struktuře, která jednotlivým příkazům přiřazuje jménem označenou celočíselnou identifikační hodnotu. section("sdram0") typedef struct{ int id; char *command; }CommandStruct;

Následuje pole uvedených struktur, které pojímá všechny příkazy a definuje jejich ID. section("constdata") static CommandStruct CmdTable[]= { ID_RIGHT_ECHO_GAIN,"REG", ID_LEFT_ECHO_GAIN,"LEG", ID_LEFT_SIDETONE_GAIN,"LSG", . . . ID_G711_CONFIGURE,"G711CONFIG", };

Funkce ResolveCommand po přijetí ukončovacího znaku rozpozná podle porovnání řetězce příkaz a dle hodnoty provede potřebné funkce. Nejdříve rozpoznáme mezeru v řetězci a zjistíme tak počet znaků, které přísluší příkazu. Zjistíme ID z tabulky, které přijatému znaku odpovídá, a pomocí „switch“ příkazu provedeme příslušné nastavení. Pokud se jedná například o příkaz nastavení úrovně zesílení, nejdříve ověříme možnost, zda nemá parametr „MUTED“. Pokud ano, nastavíme příslušný modul do tohoto stavu, pokud ne, převedená hodnota pomocí 66

funkce „atoi“ (ASCII To Integer) je přímo hodnota pro nastavení parametru modulu, jelikož potřebné úpravy jsou provedeny již v programu na PC. Protože je někdy parametr příkazu text („MUTED“, „CODED“) a někdy číslo, uchováváme obě možnosti, tedy proměnnou v obou formátech „stringValue“ a „value“. Následující kód je část zmíněného „switch“ větvení v případě, že byl příkaz rozpoznán jako nastavení úrovně levého echa. Pomocí funkce „AMF_SetModuleStatus“ nastavíme status modulu a číselná hodnota parametru je přiřazena parametru „amp“. Nakonec si přednastavíme očekávanou odpověď do výstupního pole „OutboundData“ a nastavíme „notRecognizedCMDFlag“ na nulu, protože se jedná o známý příkaz. case ID_LEFT_ECHO_GAIN: if(strcmp(stringValue,"MUTED")==0){//test, zda má být neaktivní AMF_SetModuleStatus(&(Layout1_leftEchoGain.b),AMFModuleStatus_MUTED); }else{ Layout1_leftEchoGain.amp = value;//nastavíme hodnotu a zaktivujeme modul AMF_SetModuleStatus(&(Layout1_leftEchoGain.b),AMFModuleStatus_ACTIVE); } strcat(strcpy(OutboundData,"LEG "),stringValue);//odešleme odpověď notRecognizedCMDFlag =0;//vynulujeme flag pro nerozpoznání příkazu break;

V příkazech, kde dochází k výběru větve, musíme dbát na to, aby byl simulátor vždy celkově uveden do požadovaného nastavení. To lze vidět i v předešle uvedeném kódu, kde automaticky nastavujeme modul do aktivního stavu při přijetí číselné hodnoty parametru. Nevíme totiž, zda byl modul před tím aktivní nebo s nulovým výstupem. To se více zkomplikuje při zmíněném výběru větve. Musíme zajistit, aby se všechny elementy na možných větvích vynulovaly a následně se aktivovala pouze vybraná větev. To zajistí šetření výkonu procesoru popsané v podkapitole 4.9. Příkladem je funkce, která uvádí všechny moduly levé vysílací části do stavu „MUTED“. Příloha A, část 1 tuto funkci obsahuje. Poté následuje aktivace vybrané větve. Tato inicializace musí nejen zahrnovat nastavení modulů do stavu

„ACTIVE“,

ale

zároveň

také

nastavení

příslušných

multiplexorů

a

demultiplexorů na požadovaný index. Příkladem je následující kód pro výběr širokopásmového filtru 100 - 12000 Hz.

67

section("sdram0") void activateLeftSendFilter_100_12000(void){ Layout1_leftSendDeMux.Select = 5;//výběr potřebných indexů multiplexu Layout1_leftSendWBMux.Select = 2; Layout1_leftSendWBDeMux.Select = 1; Layout1_leftSendMux.Select = 4; //aktivujeme pouze moduly v dané větvi AMF_SetModuleStatus(&(Layout1_left_Send_LP12000.b),AMFModuleStatus_ACTIVE); AMF_SetModuleStatus(&(Layout1_leftSendWBMux.b.b),AMFModuleStatus_ACTIVE); AMF_SetModuleStatus(&(Layout1_leftSendWBDeMux.b.b),AMFModuleStatus_ACTIVE); AMF_SetModuleStatus(&(Layout1_left_Send_HP100.b),AMFModuleStatus_ACTIVE); }

Tyto dvě naposledy uvedené části kódu jsou pak dohromady ve funkci, která vybírá podle parametru příkazu, tedy indexu, kterou část aktivuje. Příloha A, část 2 tuto funkci uvádí. Stejným principem jsou nastavovány všechny větvené části simulátoru. U bloků, kde se parametr příkazu skládá z více indexů, je nutné jej rozdělit. Pro výběr levých kodeků je příkaz například ve formátu LCO 201. Ten rozdělíme na jednotlivé indexy pomocí následujícího kódu a poté již postupujeme v nastavování stejným principem, jak bylo uvedeno v příkladu pro výběr vysílací části. section("sdram0") void setRightCodec(char *codecSetup){ char muxResolver[2];//délka pole znaků je 2 muxResolver[1] = '\0';//na druhou pozici uložíme ukončovací znak řetězce muteRightCodec();//funkce pro deaktivaci všech modulů v pravé části kodeků muxResolver[0] = codecSetup[0];//první index je první znak ze vstupního parametru, což je ukazatel na pole, které je parametrem přijatého příkazu RCO setRightFirstCodec(atoi(muxResolver));//znak je pomocí funkce atoi převeden na číslo. Dle něj nastavíme kodek (0-žádný, 1 – G.711, 2 – G.729) muxResolver[0] = codecSetup[1];// přepíšeme první pozici druhým znakem z parametru a postupujeme obdobně jako u prvního kodeku setRightSecondCodec(atoi(muxResolver)); muxResolver[0] = codecSetup[2]; setRightThirdCodec(atoi(muxResolver)); }

68

Kapitola 7 7 Prototyp Posledním krokem k dokončení práce na STS je vytvoření prototypu. V této kapitole bude stručně uvedeno, jakým způsobem se prototyp vyrobil.

7.1 Požadavky Konstrukčně musíme vyrobit prototyp tak, aby vyhovoval požadavku na kompaktnost a přenositelnost. Vzhledem k tomu, že veškerý potřebný hardware je již na kitu, stačí, abychom jej vložili do příhodného „obalu“ a vyvedli konektory. Bylo rozhodnuto, že prototyp by měl být konstrukčně rovnou připravený pro užití ve stávající laboratoři, která užívá telefonní terminály Panasonic KX-TS500CXW. Musíme tedy prototyp připravit tak, aby se k němu tyto terminály jednoduše připojily.

7.2 Připojení telefonních terminálů Terminály, které se budou k STS připojovat, jsou pouze skeletem klasického telefonního přístroje. Vodiče sluchátka a mikrofonu jsou přímo vyvedeny na konektor „CANON9 zástrčka“ v zadní části přístroje a zbytek telefonu je zcela nefunkční. Co se týče vstupu, víme, že se jedná o elektretový, kondenzátorový mikrofon. Je třeba zajistit jeho fantomové napájení. Ani po rozebrání sluchátka nebylo možno určit typ mikrofonu, jelikož nemá žádné označení. Parametry fantomového napájení tak musí být určeny empiricky. Nejlepší vlastnosti mikrofon vykazoval při kombinaci napájení + 5 V s rezistorem o hodnotě 8k2 Ω. + 5 V hodnotu získáme stabilizací napájení kitu, které je + 7,5 V, pomocí verze 7805 stabilizátoru. I když je audio vstup kitu střídavě vázaný, přece jen bude vhodné použít kondenzátor o hodnotě 10 μF, abychom eliminovali stejnosměrnou složku. Na obr. 34 je zobrazeno schéma zapojení. Pro souhlas vodičů na fyzické vrstvě komunikace je kvůli zapojení konektoru v kabelu s FTDI čipem nutné překřížit signály. Kabely pro propojení telefonů a STS musí být také křížené. Pro malé množství součástek, které jsou zapotřebí pro fantomové napájení mikrofonů, nemá smysl vyrábět samostatný dedikovaný plošný spoj. Využijeme univerzální pájivé pole a snadno tak umožníme přidání obvodů pro eventuelní 69

impedanční přizpůsobení či modifikaci úrovně signálu. Odzkoušeli jsme, že maximální hlasitost na výstupu telefonu je i při přímém připojení více než dostatečná a nemá smysl v tomto případě výstup modifikovat. CON1 CON2 CANNON9 F 7,5V DC 2,14A

CON3 CANNON9 M

1 C1 470nF

IO1 L7805

Telefon 1 MIC1

+ R1 8k2

3 C2 100nF

2

SPEAKER1

R2 8k2

MIC2

C3 10uF 16V

C4 10uF 16V

CON4 CANNON9 M

+ SPEAKER2

Telefon 2

P2 CANNON9 M

J9

ADC1 DAC1

ADC2

DAC2

BF533 EZ-KIT Lite board

obr. 34: Schéma prototypu

Pro použití simulátoru v poslechových testech použijeme pouze redukci, která převede v audio oblasti nevyužívaný konektor CANNON9 na XLR, nebo CINCH zástrčku, v závislosti na tom, jakým konektorem bude disponovat zařízení, které bude zdrojem předpřipravených vzorků. Příloha C obsahuje fotografie finálního prototypu.

70

Kapitola 8 8 Závěr V diplomové práci jsem splnil její zadání vytvořením simulátoru telekomunikační sítě pro subjektivní testování kvality přenosu hlasu. Dle mého názoru jsem vyřešil a implementoval všechny vlastnosti, které byly požadovány. Vytvořil jsem tak zařízení, které definovaně degraduje signál řeči pomocí vlivů sidetone, echo, zkreslení terminálu, šum, zpoždění a použitý řečový kodek. Vytvořil jsem prototypní výrobek umožňující konverzační i poslechové testy. Pro jeho realizaci jsem naprogramoval DSP, které vykonává simulaci a komunikaci s nadřazeným ovládacím PC. PC komunikuje pomocí USB portu, přes konverzi na rozhraní RS-232, díky FTDI čipu. Ovládací program je vybaven grafickým rozhraním, které umožňuje nastavovat všechny jednotlivé části simulátoru. Toho je dosaženo integrací příkazů nastavení, které program na DSP podporuje. Uživatel programu tak pouze nastavuje simulátor z úrovně, kdy nemusí mít žádné znalosti o jeho hardwarovém či softwarovém řešení. Vytvořené zařízení by mělo být nástrojem pro provádění subjektivního testování kvality hlasu, ale také pro prezentaci a názornou ukázku vlivu daného nastavení na kvalitu hlasu. Jeho výhodou proti existujícím zařízením je zejména malý rozměr. Výbornou vlastností je pak i možnost řetězit kodeky za sebou a zkoumat tak jejich aditivní vliv na degradaci, a to i v závislosti na jejich pořadí. Do budoucna doporučuji pracovat na rozšíření rodiny kodeků, kterými simulátor disponuje, jelikož práce s nimi je jeho velkou výsadou. Pro užití s různými výstupními audio zařízeními by bylo vhodné přidat obvody pro impedanční přizpůsobení a případně zesilovač koncového stupně. V budoucnu by se také mělo provést rozsáhlé testování simulátoru a všech jeho vlastností.

71

Příloha A Část 1: funkce pro nastavení celého bloku VA levé vysílací části do neaktivního stavu section("sdram0") void muteLeftSendFilters(void){ //je třeba deaktivovat veškeré moduly v daném bloku, včetně multiplexorů a demultiplexorů AMF_SetModuleStatus(&(Layout1_left_msIRS_LP.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_msIRS_HP1.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_msIRS_HP2.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_msIRS_Scaler.b.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_sIRS_LP.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_sIRS_HP1.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_sIRS_HP2.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_Send_LP7000.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_Send_LP8000.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_Send_LP12000.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_Send_HP50.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_Send_HP100.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_left_Send_HP150.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_leftSendWBMux.b.b),AMFModuleStatus_MUTED); AMF_SetModuleStatus(&(Layout1_leftSendWBDeMux.b.b),AMFModuleStatus_MUTED); }

Část 2: funkce pro aktivaci větve levé vysílací části dle přijatého indexu section("sdram0") void setLeftSendFilter(int filterEnum){ //všechny moduly celého bloku deaktivujeme podle přílohy A.1 muteLeftSendFilters(); //dle indexu aktivujeme pouze vybranou větev switch (filterEnum) { case 0:activateLeftSendFilter_msIRS();break; case 1:activateLeftSendFilter_sIRS();break; case 2:activateLeftSendFilter_None();break; case 3:activateLeftSendFilter_50_7000();break; case 4:activateLeftSendFilter_100_7000();break; case 5:activateLeftSendFilter_150_7000();break; case 6:activateLeftSendFilter_50_8000();break; case 7:activateLeftSendFilter_100_8000();break; case 8:activateLeftSendFilter_150_8000();break; case 9:activateLeftSendFilter_50_12000();break; case 10:activateLeftSendFilter_100_12000();break; case 11:activateLeftSendFilter_150_12000();break; } }

72

Příloha B

Celá implementace simulátoru ve VisualAudio designéru.

in

out1 out2

in

out

out

left_msIRS_LP

in left_sIRS_LP

in

out

left_msIRS_HP1

in

in

out

left_msIRS_HP2

out

left_sIRS_HP1

out

in

out

in

out

out

left_msIRS_Scaler

in

out

left_sIRS_HP2

in

out

out

out

out

leftHothEq

in

rightHothEq

out

out

out

out

out right_Send_HP150

in

right_Send_HP100

in

right_Send_HP50

in

right_sIRS_HP2

in

right_msIRS_Scaler

rightHothFilter2

out

out3

out2

out1

right_msIRS_HP2

out

in

rightSendWBDeMux

in

left_Send_HP150

in

left_Send_HP100

in

left_Send_HP50

in1 in2

in1 in2 in3 in4 in5 in3

out

out

out

rightSendMux

out

rightHothScaler1

in

leftHothScaler1

in

leftSendMux

in6

in5

in3

out1 out2 out3

in

leftSendWBDeMux

in

out3 out

in1 in3

out

leftHothFilter2

in

out

out

rightHothScaler2

in

leftHothScaler2

in

out

out

rightHothScaler3

in

leftHothScaler3

out

out

rightNoiseMux

in2

in1

leftNoiseMux

in1

out

in

rightHothFilter1

in

leftHothFilter1

in2

out1 out2

in

out

right_sIRS_HP1

right_msIRS_HP1

in1 in2 in3 rightSendWBMux

in

out1

out

in

out2 in

leftSendWBMux

out

in4 in

out

left_Send_LP7000 in

out

left_Send_LP8000

in

out

rightNoiseDeMux

in

leftNoiseDeMux

in

left_Send_LP12000

out

in

out

right_msIRS_LP

in

out

right_sIRS_LP

in

right_Send_LP7000

out

in2

out4 out5 out6

out4

out3

out2

out1

rightNoiseGenerator

out

leftNoiseGenerator

leftSendDeMux

in

out5 out3 rightSendDeMux

in

out

right_Send_LP8000

in

right_Send_LP12000

in1

in2

out

out

leftAdder1

in1

in2

rightAdder1

73

in

in1

in1 in2 in3

out

rightCodecMux1

out

leftCodecMux1

in3

out1

out

in2 in

out

out

out

rightG711EncDec1

in

leftG729EncDec1

in

leftG711EncDec1

out2 out3

out2

out1

leftCodecDeMux1

in out3 rightCodecDeMux1 in rightG729EncDec1

in

in1

in1 in2 in3

out

in

in1 out

out

rightCodecMux3

in3

in2

in1

leftCodecMux3

in3

in2 out

out1

in

out

out

out rightG729EncDec3

in

rightG711EncDec3

in

leftG729EncDec3

in

leftG711EncDec3

out2 out3

out2

out1

leftCodecDeMux3

in

out3 rightCodecMux2 rightCodecDeMux3

out

leftCodecMux2

in3

out1

out

in2 in

out

out

out

rightG711EncDec2

in

leftG729EncDec2

in

leftG711EncDec2

out2 out3

out2

out1

leftCodecDeMux2

in

out3 rightCodecDeMux2

in

rightG729EncDec2

in

out

out

out

out

out

rightCodecMux4

in3

in2

in1

leftCodecMux4

in3

in1

out

in2

in

out1

in

rightG711EncDec4

in

leftG729EncDec4

in

leftG711EncDec4

out2

out3

out2

out1

leftCodecDeMux4

in

out3

rightCodecDeMux4

rightG729EncDec4

74

in

out

out

out

in1 in2 in3

out

in

in1 out

out

rightCodecMux6

in3

in2

in1

leftCodecMux6

in3

out1

out

in2 in

out

out

out rightG729EncDec6

in

rightG711EncDec6

in

leftG729EncDec6

in

leftG711EncDec6

out2 out3

out3

out2

out1

leftCodecDeMux6

in

rightCodecMux5 rightCodecDeMux6

out

leftCodecMux5

in3

in1

out

out1

in

in2

in

rightG711EncDec5

in

leftG729EncDec5

in

leftG711EncDec5

out2 out3

out3

out2

out1

leftCodecDeMux5

in

rightCodecDeMux5

rightG729EncDec5

in

in1 in2

out

out

leftCodecEchoMux

out

out

leftRightDelay

in

rightLeftDelay

in1 in2

rightCodecEchoMux

in

out

out

leftSidetoneGain

in

out

leftEchoDelay

in

out

rightEchoDelay

in

rightSidetoneGain

in

out

out

leftEchoGain

in

rightEchoGain

in1

in2

out

out

Adder2x13

in1

in2

Adder2x14

in1

in2

out

out

Adder2x12

in1

in2

Adder2x11

75

in

out1 out2 out3 out4 out5 out6

out3

out2

out1

leftReceiv eDeMux

in out4 out5 out6 rightReceiv eDeMux

in

out

out

left_mrIRS_LP

in

out

left_rIRS_LP

in

out

left_Receiv e_LP7000 in

out

left_Receiv e_LP8000

in

out

left_Receiv e_LP12000

in

out

right_mrIRS_LP

in

out

right_rIRS_LP

in

out

right_Receiv e_LP7000 in

out

right_Receiv e_LP8000

in

right_Receiv e_LP12000

in

in

out

out

out

in

out

out

in

out

out3

out2

out1

out

left_rIRS_Scaler1

in

left_mrIRS_HP2

in

out

out3

out2

out1

out right_rIRS_Scaler1

in

right_mrIRS_HP2

in

leftReceiv eW BDeMux

in

left_rIRS_HP2

out

left_mrIRS_HP1

in

right_mrIRS_HP1

out

out

rightReceiv eW BDeMux

right_rIRS_HP2

in

leftReceiv eW BMux

in3

in2

in1

left_rIRS_HP1

in

right_rIRS_HP1

in1 in2 in3 rightReceiv eW BMux

in

out

out

left_mrIRS_Scaler

in

out

left_rIRS_Scaler2

in

out

left_Receiv e_HP50

in

out

left_Receiv e_HP100

in

out

left_Receiv e_HP150

in

out

right_mrIRS_Scaler

in

out

right_rIRS_Scaler2

in

out

right_Receiv e_HP50

in

out

right_Receiv e_HP100

in

right_Receiv e_HP150

in1 in2 in3 in4 in5 in6

out

out

leftReceiv eMux

in1 in2 in3 in4 in5 in6 rightReceiv eMux

in

out

out

leftOv erallGain1

in

rightOv erallGain1

in

out

out

leftOv erallGain2

in

rightOv erallGain2

76

Příloha C Fotografie hotového prototypu.

77

78

Příloha D Tabulky naměřených hodnot PESQ_MOS. I/O zvukové karty

STS v režimu Talktrough

Kodek G.711 A-law

Název vzorku

PESQ

Název vzorku

PESQ

Název vzorku

PESQ

degPC0.wav

3.012

degTNS0.wav

3.011

G711alaw0.wav

2.920

degPC1.wav

2.913

degTNS1.wav

2.863

G711alaw1.wav

2.919

degPC2.wav

2.874

degTNS2.wav

2.868

G711alaw2.wav

2.822

degPC3.wav

3.024

degTNS3.wav

2.967

G711alaw3.wav

2.730

degPC4.wav

2.945

degTNS4.wav

3.003

G711alaw4.wav

2.818

degPC5.wav

3.002

degTNS5.wav

2.878

G711alaw5.wav

2.886

degPC6.wav

2.898

degTNS6.wav

3.108

G711alaw6.wav

2.816

degPC7.wav

3.008

degTNS7.wav

3.032

G711alaw7.wav

2.750

degPC8.wav

3.008

degTNS8.wav

2.891

G711alaw8.wav

2.678

degPC9.wav

3.004

degTNS9.wav

2.864

G711alaw9.wav

2.761

Průměr

2.969

2.949

2.810

MOS - LQO

2.776

2.746

2.546

Kodek G.711 A-law

Kodek G.729

3 × kodek G.711 A-law

Název vzorku

PESQ

Název vzorku

PESQ

Název vzorku

PESQ

G711milaw0.wav

2.708

G729_0.wav

2.702

3xG711alaw0.wav

2.643

G711milaw1.wav

2.708

G729_1.wav

2.747

3xG711alaw1.wav

2.646

G711milaw2.wav

2.672

G729_2.wav

2.876

3xG711alaw2.wav

2.626

G711milaw3.wav

2.821

G729_3.wav

2.743

3xG711alaw3.wav

2.638

G711milaw4.wav

2.652

G729_4.wav

2.748

3xG711alaw4.wav

2.678

G711milaw5.wav

2.734

G729_5.wav

2.663

3xG711alaw5.wav

2.579

G711milaw6.wav

2.670

G729_6.wav

2.757

3xG711alaw6.wav

2.599

G711milaw7.wav

2.731

G729_7.wav

2.714

3xG711alaw7.wav

2.68

G711milaw8.wav

2.768

G729_8.wav

2.693

3xG711alaw8.wav

2.616

G711milaw9.wav

2.728

G729_9.wav

2.687

3xG711alaw9.wav

2.643

Průměr

2.719

2.733

2.635

MOS – LQO

2.419

2.438

2.306

79

3 × kodek G.729

1 × G.711 μ - law, 1 × G.729

1 × G.729, 1 × G.711 μ - law

Název vzorku

PESQ

Název vzorku

PESQ

Název vzorku

PESQ

3xG729_0.wav

2.854

G711miG729_0.wav

2.813

G729_G711mi_0.wav

2.743

3xG729_1.wav

2.697

G711miG729_1.wav

2.912

G729_G711mi_1.wav

2.886

3xG729_2.wav

2.687

G711miG729_2.wav

2.746

G729_G711mi_2.wav

2.815

3xG729_3.wav

2.678

G711miG729_3.wav

2.931

G729_G711mi_3.wav

2.707

3xG729_4.wav

2.906

G711miG729_4.wav

2.759

G729_G711mi_4.wav

2.662

3xG729_5.wav

2.755

G711miG729_5.wav

2.938

G729_G711mi_5.wav

2.716

3xG729_6.wav

2.725

G711miG729_6.wav

2.801

G729_G711mi_6.wav

2.863

3xG729_7.wav

2.91

G711miG729_7.wav

2.766

G729_G711mi_7.wav

2.736

3xG729_8.wav

2.754

G711miG729_8.wav

2.836

G729_G711mi_8.wav

2.697

3xG729_9.wav

2.677

G711miG729_9.wav

2.736

G729_G711mi_9.wav

2.688

Průměr

2.764

2.824

2.751

MOS – LQO

2.482

2.565

2.463

80

Příloha E Obsah CD CD ├───CodecPack │ ├───Include │ ├───Lib │ ├───Source │ └───XML ├───DiplomovaPrace │ ├───Dokument │ ├───Fotografie │ ├───Grafy │ ├───Literatura │ │ └───T-REC-P.862-200102-I!!SOFT-ZST-E │ │ └───P862 │ │ └───Software │ │ ├───Conform │ │ └───source │ │ └───Debug │ └───Obrázky ├───PESQ ├───TelNetSim_Instalace │ └───Application Files │ ├───TelNetSim_1_0_0_0 │ └───TelNetSim_1_0_0_5 ├───TelNetSim_SourceCode │ └───TelNetSim │ ├───Commands │ ├───ExternalLibraries │ ├───Graphics │ ├───obj │ │ ├───Debug │ │ │ ├───cs-CZ │ │ │ ├───Refactor │ │ │ └───TempPE │ │ ├───Release │ │ │ ├───cs-CZ │ │ │ ├───Refactor │ │ │ └───TempPE │ │ ├───x64 │ │ │ ├───Debug │ │ │ │ └───TempPE │ │ │ └───Release │ │ │ └───TempPE │ │ └───x86 │ │ ├───Debug │ │ │ ├───cs-CZ │ │ │ ├───Refactor │ │ │ └───TempPE │ │ ├───koklo │ │ │ └───TempPE │ │ └───Release │ │ ├───cs-CZ │ │ ├───Refactor │ │ └───TempPE │ ├───Presenters │ ├───Properties │ │ └───DataSources │ ├───Resources │ ├───Settings │ ├───Utils │ └───Views └───VisualAudio_Projekt └───TelNetSim.presets

81

Seznam použitých symbolů a zkratek MOS – Mean Opinion Score STS – Simulátor Telekomunikační Sítě IRS – Intermediate Reference System mIRS – modified Intermediate Reference System VoIP – Voice over Internet Protocol GSM – Global System for Mobile Communication ADSP – Advanced Digital Signal Processing MMACs - Million Multiply Accumulate Cycles per second PPI – Point to Point Interface SPI – Serial Peripheral Interface EBIU – External Bus Interface Unit VDSP – visualDSP++ VA – VisualAudio PC – Program Counter, Personal Computer BTC – Background Telemetry Channel PKZ – počet kanálů zvuku TickSize – počet vzorků pro zpracování VA designérem ADI – Analog Devices DSP – Digital Signal Processor COM – Component Object Model PESQ – Perceptual Evaluation of Speech Quality MOS – LQO – Mean Opinion Score – Listening Quality Objective

82

Použitá literatura 1. Mička, J.: Programové vybavení simulátoru pro měření konverzační kvality. Praha, 2009. 76 s. Diplomová práce na Elektrotechnické fakultě ČVUT na katedře měření. 2. Doporučení ITU-T P.862. Perceptual evaluation of speech quality (PESQ), an objective method for end-to-end speech quality assessment of narrowband telephone networks and speech codecs. ITU, 2001. 21 s. 3. Doporučení ITU-T P.800. Methods for Subjective Determination of Transmission Quality. ITU, 1996. 28 s. 4. ADSP-BF533 Blackfin Processor Hardware Reference. Analog Devices, 2008. 5. ADSP-BF533 EZ-KIT Lite Evaluation System Manual. Analog Devices, 2007. 6. VisualDSP++ 5.0 Getting Started Guide. Analog Devices, 2007. 7. Developing VisualAudio modules. Analog devices, 2007. 56 s. 8. VisualAudio MATLAB Interface Guide. Analog Devices, 2006. 58 s. 9. Doporučení ITU-T P.48. Specifications for an intermediate reference system. ITU, 1993. 7s. 10. Doporučení ITU-T P.830. Subjective performance assessment of telephone-band and wideband digital codecs. ITU, 1996. 22s. 11. IEEE Standart 269-2001. Draft Standard Methods for Measuring Transmission Performance of Analog and Digital Telephone Sets, Handsets and Headsets. IEEE, 2001. 125 s. 12. Doporučení ITU-T P.862.1. Mapping function for transforming P.862 raw results scores to MOS - LQO. ITU, 2003. 3s.

83

Diplomová práce Vývoj a implementace simulátoru telekomunikační sítě

Recommend Documents