1. Faktorer som påvirker talekvaliteten

Transkript

1 Olav Skundberg Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV376D IP-telefoni 1. Resymé: Lyd omdannes til en bitstrøm og tilbake til lyd igjen med en talekoder og dekoder, en såkalt kodek. De to viktigste komponentene som påvirker lydkvaliteten er talekodek og forsinkelse (foruten selve endeutstyret da). Valg av kvalitet på talekodek er en avveining i forhold til båndbredde og forsinkelse. Forsinkelse er dessuten knyttet til nettets tjenestekvalitet. Overføring av sanntids tale bruker en protokoll som heter Real Time Protocol (RTP). Variasjon i overføringshastighet kan motvirkes av et jitterbuffer, men som samtidig introduserer ytterligere forsinkelse Innledning Talekvalitet er en subjektiv opplevelse av lyden man hører. De to viktigste faktorene som påvirker dette er (1) valg av talekodek for å omdanne det analoge signalet til datapakker og (2) kvaliteten på nettet som overfører pakkene. Merknad: en tredje viktig faktor for hvordan man opplever talekvaliteten er selve terminalutstyret (gir håndsettet god lyd, er det mye tilbakekobling av lyd gjennom hodesettet, har man mikrofon som fanger opp all støy...). Man kan ikke forvente all verden med et mikrofon/hodesett til 75 kroner selv om nettet er utmerket og kodeken gir høy kvalitet. Om koding og kompresjon av lyd Lyd er et kontinuerlig varierende signal som samples (punktprøves) regelmessig og verdien av hvert sample vises med et antall bits. Avveiningen er (1) hvor ofte det skal tas punktprøver, og (2) hvor nøyaktig skal samplene vises i antall bits. Den grunnleggende regelen er at et signal må punktprøves med minst dobbel frekvens for å kunne gjenskapes rett. Vanlig hørsel oppfatter frekvenser opp til 20 khz, hvilket krever minst 40 khz samplingsrate (CD-kvalitet). Kompresjon innebærer å skrelle av informasjon slik at resultatet allikevel gir tilfredsstillende lydkvalitet. En metode er å se flere sampler under ett, typisk en 20 ms periode, og analysere og overføre lydbølgens kjennetegn. Når signalet gjenskapes vil det ikke være identisk med det opprinnelige, men bra nok. Om sanntids overføring på nettet Internett gir ingen garantier for kvaliteten på overføringen. Det jobbes riktignok med standarder for QoS (tjenestekvalitet) på Internett, men dette er ikke tatt i bruk i noe omfang. Man har noe større grad av kontroll over kapasitetsutnyttelsen på bedriftinterne datanett. Kommunikasjonsprotokollene er gruppert lagdelt. Applikasjonslaget styrer selve oppkopling av forbindelsen og foretar avspilling ( gjenskaping ) av lyden.

2 Transportlaget håndterer ende-ende forbindelsen mellom partene og er opptatt av at lydpakker spilles av i rett sekvens og tempo. På nettverkslaget (IP-laget) rutes en pakke fra avsender til mottaker etter beste evne. Den spesialløsning på nettverkslaget er at dersom mange lytter på samme sending så er det sløseri å sende identiske pakker i parallell fra kilden til hver mottaker især (unicast). Derfor er multicast en løsning som kan brukes i konferanser Koding og kompresjon av lyd Siktemålet her er å gi et innblikk i hvordan lyd omdannes til en bitstrøm og hvilke metoder man benytter for få best mulig lyd i forhold til bit raten som genereres. Selve lydkoden vil opptre som nyttelast i kommunikasjonsprotokollene. Koding av lyd Puls Kode Modulering, PCM (G. 711) Det analoge lydsignalet blir samplet regelmessig, dvs. man tar punktprøver. Verdien av hver punktprøve oppgis i et antall bits, og for G.711 er det valgt 8 bit (jo flere desto mer nøyaktig). Dette produserer en jevn bitrate. Vanlig analog telefonkvalitet overfører frekvenser opp til ca 4 khz. Man sampler derfor telefonsignalet 8000 ganger i sekunder, og hvert sample har 8 bit. Dette blir en bitrate på 64 kbps, hvilket tilsvarer en ISDN kanal. PCM u-law og A-law Når man gir punkprøven en diskret verdi betyr det at det analoge signalet blir avrundet til nærmeste trappetrinn. Dette gir en unøyaktighet som kalles kvantiseringsstøy. Med G.711 blir det samme mengde støy både i stille perioder og ved høye amplituder. Øret oppfatter ikke bakgrunnsstøy (sus) når lyden er høy. Derfor er det tatt i bruk en metode for å omforme signalet før det samples, slik at man forsterker lave amplituder og demper de høye. Dette har samme effekt som å ha små trappetrinn for lave amplituder (= mer nøyaktig) og store trappetrinn når signalet kraftig. Metoden gir en hørbar forbedring som tester viser at tilsvarer punktprøver med 12 bits nøyaktighet. Denne metoden med forsterkning/dempning (eng. companding) er implementert i to former (PCM u-law og A-law) med litt forskjellige dempningskurver, og kommer fra henholdsvis USA og Europa. Det er ikke lett å bli enige om standarder! Det må uansett brukes samme kodek i begge ender. Kompresjonsteknikker for lyd Adaptiv Differensiel PCM, G.721 og G.722 En videreutvikling av rett fram PCM sampling er å overføre informasjon om endringen i sampelverdi, ikke verdien på hele samplet. Man kan vise endringen med et fast antall bits, enten endringen er liten eller stor. Dette kalles differensiell koding. Kodingen kan bli enda mer effektiv ved at små endringer bruker få bits og større endringer flere bits, det kalles adaptiv differensiell koding. ITU har definert G.721 og G.722 som standarder for ADPCM (Adaptiv Differrential PCM). G.722 har noe høyere båndbredde (og dermed også bedre lydkvalitet) enn G.721. side 2 av 6

3 Kode-eksitert prediktiv koding (CELP): G.728, 729, 729(A) og Hittil har kodingen vist PCM-varianter som kan gjenskape det analoge signalet på grunnlag av en sekvens punktprøver. Neste gruppe av kodeker går ett skritt videre og ser på flere punkprøver i sammenheng og koder ut fra dette. Man samler opp punkprøver typisk over ms og gjør en analyse av lydens bølgeform innenfor denne perioden. Man velger ut de viktigste kjennetegnene (grunntone, hvor kraftig man snakker, stemte og ustemte lyder m.m.) og overfører disse. Hos mottaker må man bruke en form for lydsyntetisering for å gjenskape signalet. Lydsyntetisering bruker modeller for hvordan taleorganet virker, og krever digital signal prosessering som er mer CPU-krevende enn vanlig PCM konvertering. Alle kodeker som samler opp og analyserer flere punkprøver sett under ett vil introdusere forsinkelse i overføringen. Den enkleste av denne typen koding kalles linear predictive coding (LPC). Hver blokk med oppsamlede punkprøver får et antall (10-20) koeffisienter som beskriver lydbølgen innenfor denne perioden. Her er det snakk om reduksjon i bitrate med en faktor på 1000! Det oppnår man ved å overføre koeffisienten istedenfor alle punktprøvene. En grunn til at dette går bra, er at lyden vi produserer når vi snakker er stort sett uendret innenfor noen millisekunder. Med LPC kan man oppnå forståelig tale selv med bitrater under 1 kbps. Lydkvaliteten oppfattes som syntetisk og brukes ikke kommersielt. En videreutvikling av LPC kalles Code-excited LPC (CELP). Teknikken her er at kjennetegnene ved lydens bølgeform blir kodet til et antall koeffisienter som til sammen kalles et kodeord (som i LPC). Så finnes det et antall forhåndsdefinerte kodeord som er samlet i en kodebok (ikke kokebok). Man overfører bare indeksen til kodeordet (for å spare ytterligere båndbredde). Kodeboken gir en kontinuitet mellom rammene som overføres, lyden endres ikke brått. ITU har definert flere standarder i CELP-klassen: G.728, 729, 729(A) og Karakteristikker av noen kodeker: Standarder Bit rate Forsinkelse Anvendelse PCM-kodeker (punktprøver) G.711, A-law og u-law *) ISDN, fastnett telefoni G *) Konferansekvalitet over IP G *) Konferansekvalitet over IP CELP-kodeker (analyse av flere punktprøver, overføre lydbølgens koeffisienter) G Lav bitrate telefoni G Telefoni i cellulære radionett G / Internett telefoni *) Ved samplingsrate 8 khz blir avstand mellom to punkprøver: 1sek/8000= 0,125ms, egentlig ingen forsinkelse i det hele tatt. side 3 av 6

4 Persepsjonskompresjon Hittil har vi sett på ren PCM og CELP-kodeker, hvor CELP-syntetisering av lyd bygger på taleorganets virkemåte. En tredje form av lydkompresjon er å utnytte egenskaper ved øret/ hørselen og vår persepsjon (oppfatning) av lyd. Dette kalles persepsjonskoding. Kjennetegn ved hørsel og vår oppfatning av lyd: - Sensitivitet: ikke alle frekvenser er like viktige for å forme et inntrykk. Øret er mest sensitivt i området 2-5 khz. - Frekvens maskering: Øret har auto volumkontroll Det betyr at en kraftig tone vil redusere hørselen for denne frekvensen og for toner i nærheten. En samtidig, svak tone med omtrent samme frekvens blir ikke oppfattet i det hele tatt. - Tids maskering: Dempingseffekten fra en kraftig lyd strekker seg også ut i tid, selv etter at denne lydkilden er borte. Vi oppfatter derfor ikke svake lyder som kommer rett etter sterke i relativt samme frekvensområde. Poenget er at man kan utnytte persepsjonskoding til å skrelle av overflødig informasjon som vi allikevel omtrent ikke hører. Persepsjonskoding benyttes i flere sammenhenger, mest kjent som MP3-filer og i Dolby lydsystemer. Dette er koding som krever at man kan jobbe på hele lydfiler, og brukes ikke som talekodeker i IP-telefoni Overføre data ende-ende over nettet (transportlaget) Mellom sender og mottaker ligger et IP-nett (eller Internett), og IP er kjent for best-effort. Det betyr at pakker kan forsvinne, komme i ombyttet rekkefølge og med ujevnt tempo. Det ville ikke høre pent ut i avspillingen, og det er derfor laget en egen protokoll RTP (Real Time Protocol) som skal avhjelpe problemet med manglende IP overføringskvalitet. RTP, Real Time Protocol RTP pakker inn nyttelasten (en eller flere blokker av komprimert lyd) inn med en ny header som skal hjelpe mottaker til rett avspilling. RTP plasseres på transportlaget oppå UDP eller TCP, og kan bruke begge disse protokollene for overføring. Imidlertid er UDP vanligst, fordi det er ulogisk med TCP retransmisjoner når overføringen er sanntid. Dessuten sparer man båndbredde ved å velge UDP fremfor TCP (mindre innpakking, kvitteringer etc). For å forstå hvordan RTP virker er det naturlig å se hvilke headerfelter som er definert. En protokoll kan ikke yte mer service enn informasjon i header gir mulighet for. Headeren består av 12 byte og blant de viktigste feltene finner vi: nyttelast type (slik at mottaker kan identifisere rett kodek) timestamp (for avspilling til rett tempo) sekvensnummer (for å kunne håndtere feil i overføringen) Kildeidentifisering (i fall du avspiller flere mediastrømmer samtidig) Når man bruker Ethereal til å analysere RTP- pakker, må man angi at nyllelasten i UDP er nettopp RTP (marker en pakke, velg Tools/Decode As og velg RTP). Hvorfor? Jo, Ethereal bestemmer automatisk protokoller for faste porter (<1023), men RTP kan komme over tilfeldige, kortlivde porter (>1023). Her er et bilde fra Ethereal som viser de omtalte feltene: side 4 av 6

5 Nyttelast type er vist med et nummer, i dette tilfellet 34. RTP-standarden har definert hvilke nummer som betyr hva. I denne loggen ser vi at type 34 er oversatt med ITU-T H.263 (som tilfedigvis er en videokodek, men det kunne ha vært en talekodek). Sekvensnummer øker ett hakk for hver pakke, mens timestamp øker i byks avhengig av hvilken kodek/samplingsrate som er benyttet. Det hjelper ikke med timestamp dersom forsinkelse gjør det ikke er noen pakker å spille av for øyeblikket. For å motvirke variasjon i overføringshastighet må man innføre et buffer hos mottaker, slik at pakkene kan ankomme uregelmessig men avspilles i jevnt tempo. Dette kalles et jitter buffer. Hvis det blir for lenge opphold i ankomsten blir det avbrekk i avspillingen Forsinkelser Forsinkelser er en avgjørende faktor for hvordan man opplever talekvaliteten, i tillegg til kvaliteten på selve kodingen. Det finnes som kjent ingen "gratis lunsj". Derfor vil reduksjon av tidsforsinkelse (som er bra) også kunne gi dårligere lydkvalitet eller øke bitraten. Vi skal nå se nærmere på de avveininger man står ovenfor. Forsinkelse som følge av talekodingen Valg av rammestørrelse For å virke optimalt må DSP ha en viss datamengde å jobbe på, samles opp i en ramme som den kan komprimere. Her kommer den første avveiningen, hvor mye data skal samles opp? I de ulike kodek-standardene er valget på rammestørrelse foretatt. Det vi som sluttbruker kan gjøre er å velge hvilken type kodek vi vil benytte. Imidlertid kreves det at begge parter har samme kodek installert, i og med at utpakkingen er en revers prosessen. Prosesseringstid Etter at en ramme er fylt opp, kan DSP starte med komprimering av denne. I mellomtiden starter den kontinuerlige strømmen med samples å fylle opp påfølgende ramme. DSP har da maksimalt tiden det tar å fylle opp en ramme (rammens lengde) på å utføre komprimeringsjobben. Hvis DSP ikke rakk dette, ville det bli skjæring. Prosesseringstiden avhenger av hva slags DSP man har og hvor beregningskrevende kodek man bruker. Prosesseringstiden er forsinkelse som kommer i tillegg til talerammens varighet. side 5 av 6

6 Oppsummert: Hoveddilemmaet for valg av prosessering er at hvis man samler opp "mye" tale, komprimerer og bufrer opp dette så får man maksimal lyd med minst krav til båndbredde. Men dette gir samtidig stor forsinkelse. Hvis man derimot "pøser ut" taledata så krever dette mye båndbredde og man kan bli utsatt for pakketap og metning i nettet. Men tidsforsinkelsen blir minimal. Forsinkelse som følge av overføring på nettet Pakketering Pakketering går ut på å legge lydblokker inn i RTP/UDP/IP-pakker slik at de kan overføres over nettet. Man ender opp med 40 byte overhead for hver sending. (IP=20 byte, UDP=8 byte, RTP=12 byte i header). Man står da ovenfor et nytt valg: Hvor mange taleblokker skal jeg legge inn i hver datapakke jeg sender? Man kan sende umiddelbart, uten forsinkelse. Da blir resultatet "katastrofalt" når det gjelder å utnytte båndbredde. Ta et regneeksempel med G.729a. En selger av et IP-telefoni system sier at kodek'en komprimerer så mye at den krever "bare" 8 kbps. Hvis den sender uten pakkeforsinkelse vil den kreve 40 byte overhead for hver 10 byte den sender! Vi er da oppe i 40 kbps krav til båndbredde. Hvis vi legger inn 3 talepakker i hver sending blir det noe bedre: 40 byte overhead pluss 30 byte tale krever en båndbredde på omlag 18 kbps...men nå til en kostnad av 20 ms innlagt forsinkelse! Man kan ikke se på kodek alene for å vite hvilken båndbredde som kreves! Man kan i noen IP-telefoni systemer velge grad av pakketering sjøl, ofte styrt av en glider som styres mellom lav båndbredde og lav forsinkelse. Jitterbuffer Siden datanettet ikke kan garantere pakkeleveransen (IP er "best effort") er det vanlig å legge inn et buffer som fanger opp variasjon i hastighet for når de kommer og rekkefølge på pakkene. Hensikten er å gi en mest mulig jevn datastrøm inn til mottakers dekoder/avspiller. Og variasjon i ankomst er like problematisk som at en pakke går tapt. Det gjelder å "fore" DSP med en javn strøm av dataa. Jitterbuffer samler altså opp noe data før de spilles av, og dette betyr nok en forsinkelse. Forsinkelse i selve nettverk Forsinkelse i nettet er vanskeligere å gjøre noe med enn bare å velge annen kodek eller pakketering. Som privatperson kan man velge en Internett-leverandør med det beste stamnettet. Hvis man har bedriftsinterne nett så har man litt mer kontroll på kapasiteten. Spesielt bemerkes at dersom pakker må passere brannmurer og proxy-tjenere så kan det introdusere så store forsinkelser at IP-telefoni ikke er brukbart, hvis samtalen i det hele tatt slipper gjennom. Effekten av tidsforsinkelse I praksis viser det seg at mindre enn 150 ms "round-trip delay" signalforsinkelser (tiden frem og tilbake for overføring av en pakke) ikke er merkbar for samtalen. For vanlig telefoni så er tidsforsinkelsen ubetydelig. Det er viktig med så rask respons fordi samtalen består nemlig også av lyder som "mm--m" og "ah...", og disse må komme på rett sted i samtalen. Hvis det blir markert forsinkelse, over 450 ms, kan man ikke føre normal samtale lenger. Da blir det mer som "hva sa du...over". side 6 av 6