Joonas Siikavirta

Signaalinkäsittely ja äänen miksaami-nen WebRTC-sovelluksessa

Metropolia Ammattikorkeakoulu

Insinööri (AMK)

Tieto- ja viestintätekniikka

Insinöörityö

12.5.2020

Tiivistelmä

Tekijä Otsikko Sivumäärä Aika

Joonas Siikavirta Signaalinkäsittely ja äänen miksaaminen WebRTC-sovelluk-sessa 51 sivua 12.5.2020

Tutkinto insinööri (AMK)

Tutkinto-ohjelma Tieto- ja viestintätekniikka

Ammatillinen pääaine Ohjelmistotuotanto

Ohjaajat

yliopettaja Ville Jääskeläinen teknologiajohtaja Kari Heikkilä

Työn tavoitteena oli löytää selityksiä ja ratkaisuja reaaliaikaisten ja kaksisuuntaisten etä-palveluiden välittämiseen kehitetyn WebRTC-teknologiaan perustuvan kuvapuhelusovel-luksen äänen- ja kuvanlaadun ongelmiin tutkimalla WebRTC-ohjelmistoprojektin teknologi-oita ja signaalinprosessointikomponenttien toimintaa. Lisäksi työssä selvitettiin mahdolli-suuksia helppokäyttöisen mikserisovelluksen toteuttamiseen, jota voitaisiin käyttää tausta-musiikin miksaamiseen ohjaajan äänistriimiin. Tämän avulla voitaisiin luopua kalliiden ja ääniteknistä osaamista vaativien ulkoisten äänilaitteiden käytöstä. Työn ensimmäinen vaihe oli tutkia WebRTC:n arkkitehtuurin, rajapintojen ja protokollien määrittelyjä. Näin saatiin selville, mitkä tekijät WebRTC-sovelluksessa voivat vaikuttaa hei-kentävästi äänen- ja kuvan laatuun. Työn toisessa vaiheessa tutustuttiin tarkemmin WebRTC:n signaalinkäsittelykomponenttien toimintaan sekä testattiin niiden toimivuutta erilaisille äänisignaaleille. Työn kolmannessa vaiheessa suunniteltiin, miten Sanoste Oy:n ohjaajan selainsovellukseen integroitava ja automatisoitu äänimikserisovellus voitaisiin to-teuttaa olemassa olevien teknologioiden ja Web API:en avulla. Suunnittelutyössä kehitetty-jen ratkaisujen todentamiseksi työn aikana kehitettiin myös toimiva mikserisovelluksen pro-totyyppi. Työn aikana tehdyn tutkimustyön ja testausten tuloksena syntyi selkeä kuva siitä, miten WebRTC:n signaalinkäsittelykomponentit vaikuttavat äänenlaatuun etenkin musiikkia sisäl-tävien äänisignaalien kohdalla. Lisäksi tutkimuksien avulla löydettiin myös muita tekijöitä, kuten WebRTC:n ruuhkanhallintaominaisuus, jotka voivat vaikuttaa äänen- ja kuvanlaa-tuun usean osallistujan kuvapuhelussa. Mikserisovelluksen prototyypin avulla voitiin myös osoittaa, että taustamusiikin miksaamiseen vaadittavat ominaisuudet tarjoavan mikseriso-velluksen toteuttaminen on mahdollista olemassa olevien Web API:en avulla.

Avainsanat WebRTC, signaalinkäsittely, mikserisovellus

Abstract

Author Title Number of Pages Date

Joonas Siikavirta Signal Processing and Audio Mixing in a WebRTC Application 51 pages 12 May 2020

Degree Bachelor of Engineering

Degree Programme Information and Communication Technology

Professional Major Software Engineering

Instructors

Ville Jääskeläinen, Principal Lecturer Kari Heikkilä, CTO

The goal of this thesis was to find explanations and solutions for audio and video quality issues found in a WebRTC based video chat application designed for delivering remote services by researching the technologies and signal processing components used in the WebRTC project. Another objective was to find out if it is feasible to implement an easy-to-use audio mixing application for adding background music to the instructor’s audio stream, which would remove the need for expensive audio equipment that require skills in audio technology to operate. The first phase was to research the architecture, APIs and protocols defined by the WebRTC project and to find which factors may contribute to the poor audio and video qual-ity in a WebRTC application. The second phase was to look at the signal processing com-ponents of WebRTC more closely and to test their behavior with different audio signals. The third phase was to research how a highly automated audio mixing application that can be integrated into Sanoste’s instructor’s browser application could be implemented. This was done by studying the existing technologies and Web APIs, and also testing the tech-nologies and solutions in practice by making a prototype of the audio mixing application. As a result of the research and testing done during the study, a clear understanding on how the signal processing in a WebRTC application affect the audio quality, especially when music is involved, was formed. Also, it was found that there are other factors, such as the congestion control of WebRTC, which may impact the audio and video quality in a multiparty video chat. With the developed audio mixing application prototype, it was shown that by using only the existing Web APIs, it is possible to implement an easy-to-use audio mixing application that can offer all the functionalities required for mixing background mu-sic.

Keywords WebRTC, signal processing, mixing application

Sisällys

Lyhenteet

1 Johdanto 1

2 WebRTC 3

2.1 WebRTC yleisesti 3 2.2 Ohjelmointirajapinnat 5 2.3 Istunnonhallinta 5 2.4 Tiedonsiirto 6

2.4.1 Tiedonsiirtoprotokolla 7 2.4.2 Tietoliikenteen salaaminen ja varmentaminen 7 2.4.3 Tiedonsiirron hallinta 8 2.4.4 Vertaisverkkoyhteyden muodostus ja hallinta 9

2.5 VideoEngine ja VoiceEngine 10 2.6 Ongelmien jäljittämisen työkalut 11 2.7 Tehdyt havainnot 12

3 Sanoste Oy:n kuvapuhelujärjestelmä 14

3.1 Kuvapuhelujärjestelmän WebRTC-toiminnallisuus 14 3.2 Kuvapuhelujärjestelmän arkkitehtuuri 17 3.3 Osallistujan sovellus 18 3.4 Palveluntuottajan sovellus 18

4 Signaalinkäsittely WebRTC-sovelluksissa 20

4.1 WebRTC:n signaalinkäsittelystä yleisesti 20 4.2 Kuvan ja äänen pakkausmenetelmät 21 4.3 Puheaktiivisuuden tunnistaminen - VAD 22 4.4 Äänen kierto ja sen ehkäiseminen - AES ja AEC 24 4.5 Melunvaimennus - NS 26 4.6 Automaattinen äänentason hallinta - AGC 27 4.7 Web Audio API 28

5 WebRTC:n signaalinkäsittelykomponenttien testaaminen 30

5.1 Testiohjelma 30 5.2 Testisignaalien muodostaminen 31 5.3 Testauksen tulokset 32

6 Äänten miksaaminen Sanoste Oy:n sovelluksessa 35

6.1 Mikserisovelluksen vaatimukset 35 6.2 Mikserisovelluksen teknologiat ja integrointi 36 6.3 Laitekokoonpanot ja signaalin esikäsittely 37 6.4 Äänilähteet ja niiden hallinta 38 6.5 Striimien alustaminen 39 6.6 Multimedialaitteiden valinta ja asetukset 40 6.7 Äänentasojen analysointi ja hallinta 41 6.8 Talkover-toiminto 42 6.9 Striimien reitittäminen ja miksaaminen 43 6.10 Asetusten tallentaminen 44 6.11 Mikserisovelluksen toimintojen testaaminen 47

7 Yhteenveto 49

Lähteet 50

Lyhenteet

AEC Acoustic Echo Cancellation. Termi, jota käytetään kaiuttimesta saapuvan

äänen poistamisesta äänilähteen sisääntulosignaalista kaksisuuntaisessa

reaaliaikaisessa kommunikaatiosovelluksessa.

AGC Automatic Gain Control. Termi, jota käytetään äänilähteen sisääntulotason

asettamisesta automatisoidusti sisääntulosignaalin perusteella.

CPU Central Processing Unit. Yleissuoritin, joka on suunniteltu suorittamaan eri-

laisia tietokoneohjelmien sisältämiä laskentatehtäviä.

DTLS Datagram Transport Layer Security. Yhteydettömän tietoliikenteen suojaa-

miseen käytettävä salausprotokolla.

ICE Interactive Connection Establishment. Protokolla, joka hallinnoi vertais-

verkkoyhteyden muodostamista julkisen osoiteavaruuden ylitse.

IETF Internet Engineering Task Force. Verkkoteknologioiden ja -protokollien ke-

hittämiseen keskittyvä kansainvälinen yhteisö.

IoT Internet of Things. Käsite, jolla kuvataan tiedonsiirtoverkkoon kytkettyjen

laitteiden keskinäistä tiedonsiirtoa.

IP Internet Protocol. Internetin verkkokerroksessa käytettävä protokolla.

NR Noise Reduction. Termi, jota käytetään ympäristöstä aiheutuvan taustame-

lun määrän vähentämisestä äänilähteen sisääntulosignaalista.

RTC Real Time Communications. Käsite, jolla kuvataan lähes viiveetöntä tie-

donsiirtoa kahden tai useamman osapuolen välillä.

RTCP Real-time Transport Control Protocol. RTP-liikenteen seuraamiseen ja hal-

lintaan tarkoitettu tietoliikenneprotokolla.

RTP Real-time Transport Protocol. Reaaliaikaiseen median striimamiseen käy-

tettävä tietoliikenneprotokolla.

SCTP Stream Control Transport Protocol. Internetin kuljetuskerroksessa käytet-

tävä yhteydellinen viestipohjainen tiedonsiirtoprotokolla.

SDP Session Description Protocol. Reaaliaikaisissa kommunikaatio- ja strii-

maussovelluksissa istunnon yksityiskohtien kuvaamiseen käytettävä pro-

tokolla.

SRTCP Secure Real-time Transport Control Protocol. RTCP-tietoliikenneprotokol-

lan profiili, joka tarjoaa suojausmekanismin RTCP-liikenteelle.

SRTP Secure Real-time Transport Protocol. RTP-tietoliikenneprotokollan profiili,

joka tarjoaa suojausmekanismin RTP-liikenteelle.

STUN Session Traversal Utilities for NAT. Protokolla, jota käytetään asiakaspään

laitteen julkisen verkko-osoitteen selvittämisessä.

TCP Transmission Control Protocol. Internetin kuljetuskerroksessa käytettävä

yhteydellinen tavujonopohjainen tiedonsiirtoprotokolla.

TLS Transport Layer Security. Yhteydellisen tietoliikenteen suojaamiseen käy-

tettävä salausprotokolla.

TURN Traversal Using Relays around NAT. Protokolla, jota käytetään silloin, kun

vertaisverkkoyhteyden muodostaminen STUN-protokollan avulla epäon-

nistuu.

UDP User Datagram Protocol. Internetin kuljetuskerroksessa käytettävä yhtey-

detön viestipohjainen tiedonsiirtoprotokolla.

VAD Voice Activity Detection. Termi, jota käytetään puhetta sisältävien jaksojen

tunnistamisesta äänilähteen sisääntulosignaalista.

VoIP Voice Over IP. Termi, jota käytetään äänen reaaliaikaista striimaamisesta

internet protokollan avulla.

W3C World Wide Web Consortium. Web-standardien kehittämiseen keskittyvä

kansainvälinen yhteisö.

1

1 Johdanto

Työn tilaaja Sanoste Oy on kehittänyt palvelualustan etäpalveluiden tuottamiseen, jonka

avulla palveluiden tuottajat pystyvät tarjoamaan palveluitaan suuremmalle asiakasjou-

kolle ja pienemmin kustannuksin kuin perinteisin keinoin olisi mahdollista. Sanoste Oy:n

palvelualustan ytimessä on WebRTC-teknologiaan (Web Real Time Communication) pe-

rustuva kuvapuhelusovellus, jonka avulla palveluntuottajat voivat välittää palveluitaan

usealle osallistujalle samanaikaisesti osallistujien maantieteellisestä sijainnista riippu-

matta.

Sanoste Oy:n kuvapuhelusovelluksen avulla välitettävät palvelut ovat reaaliaikaisia ja

kaksisuuntaisia, jonka ansiosta palvelun ohjaaja pystyy antamaan reaaliaikaista ohjeis-

tusta ja palautetta palvelun osallistujille. Palveluiden reaaliaikaisuus ja kaksisuuntaisuus

luo kuitenkin teknisiä haasteita etenkin äänen välittämisen suhteen, sillä ilman oikean-

laisia ratkaisuja ääni pääsisi kiertämään ohjaajan ja osallistujien välillä. Muita ääneen

liittyviä ongelmia ovat mahdollinen taustamelu ja äänenvoimakkuuden pitäminen sopi-

valla tasolla.

Vaikka WebRTC tarjoaa ratkaisut edellä mainittuihin ongelmiin, on niiden käyttö Sanoste

Oy:n tapauksessa ongelmallista, sillä ne luovat rajoitteita palveluiden sisällön suhteen.

WebRTC:n tarjoamat ratkaisut toimivat kohtalaisen hyvin palveluissa, joissa osallistujille

välitetään ainoastaan puhetta, mutta niiden on havaittu aiheuttavan suuria ongelmia mu-

siikkia sisältävien palveluiden kohdalla. Musiikkia sisältäviä palveluita ovat muun mu-

assa yhteislaulupalvelut ja liikuntapalvelut, joissa liikkeitä tehdään musiikin tahtiin. Ha-

vaitut ongelmat ovat moninaisia ja niiden vaikutus palvelun laatuun on merkittävä. Ha-

vaittuja ongelmia ovat muun muassa äänen puuroutuminen ja säröytyminen, kuvan pät-

kiminen ja pikselöityminen sekä äänen ja kuvan epäsynkronisuus.

Liikuntapalveluihin, joissa käytetään taustamusiikkia, liittyy myös toinen haaste. Musiikin

ja ohjaajan puheen miksaaminen vaatii ulkoisten ääniteknisten laitteiden käyttöä, jotka

ovat palveluntuottajan näkökulmasta katsottuna ongelmallisia sekä hintansa että niiden

käyttöön vaaditun ääniteknisen osaamisen takia.

2

Tämän insinöörityön tavoitteena oli tutkia WebRTC:n ja sen sisältämien signaalinkäsit-

telykomponenttien toimintaa ja tätä kautta löytää selityksiä ja ratkaisuja musiikkia sisältä-

vien palveluiden ongelmiin. Lisäksi tarkoituksena oli ratkaista äänten miksaamiseen liit-

tyviä ongelmia selvittämällä mahdollisuuksia palveluntuottajan kuvapuhelusovellukseen

integroitavan mikserisovelluksen kehittämiseen, jonka avulla voitaisiin mahdollistaa ään-

ten miksaaminen ilman ääniteknistä osaamista ja ulkoisia lisälaitteita.

Työ jakaantui kolmeen eri vaiheeseen. Työn ensimmäisessä vaiheessa tutustuttiin

WebRTC-ohjelmistoprojektiin ja sen teknologisiin ratkaisuihin, jotta voitaisiin ymmärtää

paremmin, mitkä kaikki seikat voivat vaikuttaa Sanoste Oy:n palveluiden laatuun heiken-

tävästi. Työn toisessa vaiheessa tutkittiin WebRTC:n signaalinkäsittelykomponenttien

toimintaa tarkemmin sekä testattiin niiden toimivuutta erilaisten äänisignaalien kanssa.

Näin pystyttiin selvittämään miten ne vaikuttavat äänisignaalin laatuun etenkin musiikkia

sisältävien palveluiden tapauksessa. Työn viimeisessä vaiheessa tutkittiin mahdollisuuk-

sia helppokäyttöisen Sanoste Oy:n ohjaajan kuvapuhelusovellukseen integroitavan

mikserisovelluksen toteuttamiseen kehittämällä mikserisovelluksen prototyyppi Web Au-

dio API:n avulla.

3

2 WebRTC

Työ aloitettiin tutkimalla WebRTC:n arkkitehtuurin, rajapintojen ja protokollien määritte-

lyjä. Tämän avulla pyrittiin selvittämään, mitkä WebRTC:n toiminnallisuudet voivat vai-

kuttaa WebRTC-sovelluksen äänen- ja kuvanlaatuun ja mitkä näistä ovat sovelluskehit-

täjän hallittavissa. Tässä luvussa esitellään ensin WebRTC yleisellä tasolla. Tämän jäl-

keen käydään läpi WebRTC:n arkkitehtuurin eri kerrokset sekä rajapinta- ja protokolla-

määrittelyiden tärkeimmät osat. Luvun lopussa tehdään yhteenveto äänen- ja kuvanlaa-

dun kannalta merkittävimmistä havainnoista.

2.1 WebRTC yleisesti

WebRTC on ohjelmistoprojekti, jonka pyrkimyksenä on mahdollistaa reaaliaikainen me-

dian striimaaminen eri alustojen välillä ilman erikseen asennettavia liitännäisohjelmia.

Alun perin WebRTC-projekti on keskittynyt ratkaisemaan verkkoselainten RTC-toimin-

nallisuuteen ja eri selainten yhteistoimivuuteen liittyviä ongelmia, joita ovat

• käyttäjän laitteiston multimediaresurssien hallinta selaimessa

• vertaisverkkoyhteyden luominen yksityisten verkkojen välillä

• osapuolten välinen signalointi istunnon aloittamisesta

• pakettihävikin ja tiedonsiirtoviiveiden hallinta

• tiedonsiirto- ja tiedonpakkausmenetelmien tuki eri alustoilla

• reaaliaikaisuudesta ja kaksisuuntaisuudesta aiheutuvien ongelmien, kuten äänen kierron ja taustamelun hallinta.

Nykyään WebRTC-projekti käsittää myös erilaiset mobiilialustat ja IoT-laitteet.

WebRTC:n lähdekoodin hallinnoinnista vastaa Google, ja se on julkaistu avoimen lähde-

koodin lisenssillä.

Käytännössä WebRTC on kokoelma tiedonsiirtoprotokollia, dataformaatteja ja ohjel-

mointirajapintoja (API) määrittäviä standardeja, joiden avulla varmistetaan palveluiden

toimivuus alustasta riippumatta. WebRTC:n standardoinnista vastaa kaksi eri tahoa. Oh-

jelmointirajapintojen standardoinnista vastaa W3C:n (World Wide Web Consortium)

WebRTC-työryhmä. Protokollien ja dataformaattien standardoinnista vastaa IETF:n (In-

ternet Engineering Task Force) RTCWEB-työryhmä.

4

Protokollatason standardoinnin tavoitteena on määrittää vaadittavat tiedonsiirtoprotokol-

lat ja dataformaatit, joiden avulla mahdollistetaan vertaisverkkoyhteyden yli tapahtuva

reaaliaikainen median striimaaminen sekä varmistetaan eri alustoille kehitettyjen sovel-

lusten yhteentoimivuus. Ohjelmointirajapintatason standardoinnin tavoitteena on puoles-

taan varmistaa verkkoselaimelle kehitettyjen sovellusten toimivuus kaikissa niissä se-

laimissa, joiden valmistajat ovat toteuttaneet protokollatason standardoinnissa esitetyt

vaatimukset. [1.]

Kuva 1. WebRTC:n arkkitehtuurin kuvaus. [2.]

WebRTC:n arkkitehtuuri koostuu useasta kerroksesta, joista osa on toteutettu valmiiksi

ja osa on jätetty selainvalmistajan toteutettavaksi (ks. kuva 1). WebRTC:n arkkitehtuurin

ylin taso käsittää JavaScript API:n ja sen toteuttamiseen tarkoitetun C++ API:n. Arkki-

tehtuurin seuraava kerros käsittää istunnon hallinnan ja osapuolten välisen signaloinnin

määrittelyt. Seuraava kerros sisältää varsinaisen RTC-toiminnallisuuden toteutukset, eli

vertaisverkkoyhteyksien muodostuksen, osapuolten välisen tiedonsiirron hallinnan ja

mediastriimien käsittelyyn vaadittavat komponentit. Arkkitehtuurin alin kerros toimii raja-

pintana WebRTC-sovelluksen ja käyttäjän laitteiston välillä.

5

2.2 Ohjelmointirajapinnat

WebRTC:n arkkitehtuuri käsittää kaksi erillistä ohjelmointirajapintaa, joiden tehtävänä on

mahdollistaa istuntojen ja yhteyksien sekä käyttäjän laitteiston multimediaresurssien hal-

linta JavaScript-ohjelmointirajapintojen kautta.

WebRTC C++ API on selainvalmistajille suunnattu ohjelmointirajapinta, joka tarjoaa se-

lainvalmistajalle työkalut Web API -standardin mukaisten JavaScript-ohjelmointirajapin-

tojen toteuttamiseen. JavaScript-ohjelmointirajapintojen tehtävänä puolestaan on tarjota

selainsovelluskehittäjille tarvittavat työkalut RTC-toiminnallisuuden integroimiseksi se-

lainsovellukseen varmistaen samalla sovelluksen toimivuus kaikissa niissä selaimissa,

jotka toteuttavat Web API -standardin määrittämät JavaScript-ohjelmointirajapinnat.

Web API -standardi sisältää JavaScript-ohjelmointirajapintojen määrittelyt selainten vä-

liseen kommunikointiin (WebRTC 1.0: Real-time Communication Between Browsers) ja

median sieppaamiseen ja striimaamiseen (Media Capture and Streams). WebRTC 1.0:

Real-time Communication Between Browsers -määrittely kattaa kaikki istuntojen luontiin,

yhteyksien muodostamiseen ja tiedonsiirtoon liittyvät ohjelmointirajapinnat [3]. Media

Capture and Streams -määrittely puolestaan määrittää ohjelmointirajapinnat, joiden

avulla mahdollistetaan käyttäjän multimedialaitteiston sekä kuva- ja äänistriimien hallinta

verkkoselaimessa [4].

JavaScript-ohjelmointirajapintojen toteuttamisen lisäksi WebRTC C++ API:a voidaan

hyödyntää myös natiivisovellusten kehittämisessä, vaikkakin WebRTC-projekti tarjoaa

nykyään valmiit ohjelmistokehitystyökalut (SDK) sekä Android- että iOS-käyttöjärjestel-

mille.

2.3 Istunnonhallinta

WebRTC:n istunnonhallintakerroksen tehtävänä on viestiä istunnon aloituksesta osallis-

tujien kesken ja samalla varmistaa, että toinen osapuoli on tavoitettavissa ja kykenevä

käsittelemään istunnossa käytettäviä mediaformaatteja. Tämä on toteutettu ns. Tarjous-

vastaus -menetelmän avulla. Istunnon luonti alkaa siten, että istunnon aloittava osapuoli

lähettää toiselle osapuolelle ”tarjouksen” signalointipalvelimen välityksellä. Jos toinen

6

osapuoli vastaa tarjoukseen signalointipalvelimen välityksellä, voidaan varsinaisen yh-

teyden muodostus aloittaa.

Istunnon aloituksen yhteydessä toiselle osapuolelle välitetään tietoja istunnon yksityis-

kohdista, joihin lukeutuvat tiedot istunnossa käytettävistä mediaformaateista, pakkaus-

menetelmistä ja tiedonsiirtoprotokollista. Istunnon yksityiskohtien kuvaamiseen käytettä-

vää protokollaa kutsutaan SDP:ksi (Session Description Protocol). SDP:tä käytetään

myös ilmoittamaan vastaanottajalle istunnon tietojen (esim. lähettävän osapuolen portin)

muuttumisesta käynnissä olevan istunnon aikana. [5.]

Istunnonhallintakerroksen toteutus on jätetty sovelluskehittäjän vastuulle, jotta signaloin-

tikanavan toteutus ja signalointiprotokolla voidaan sovittaa sovelluksen tarpeisiin. Tämän

avulla myös mahdollistetaan sovelluksen käyttäminen olemassa olevien kommunikointi-

järjestelmien kanssa, kuten puhelinverkko- tai VoIP (Voice Over IP) -järjestelmien

kanssa. WebRTC-standardi ei myöskään ota kantaa siihen, miten signalointikanava löy-

tää tai autentikoi käyttäjät, vaan käyttäjien hallinta on täysin signalointikanavan toteutta-

jan vastuulla.

2.4 Tiedonsiirto

WebRTC:n arkkitehtuurin tiedonsiirtokehys käsittää vertaisverkkoyhteyden muodostami-

sessa, hallinnassa ja tiedonsiirrossa käytettävät protokollat, palvelut ja tiedon salausme-

netelmät. Nämä on määritelty osana protokollatason standardointia.

WebRTC tarjoaa kaksi erillistä tiedonsiirtokanavaa. RTCPeerConnection-kanava on tar-

koitettu reaaliaikaiseen median striimaamiseen. RTCDataChannel on tarkoitettu ennalta

määrittelemättömän tiedon reaaliaikaiseen siirtoon osallistujien välillä.

RTCDataChannelin kautta voidaan siirtää esimerkiksi tekstidataa, anturidataa tai tiedos-

toja. Toisin kuin RTCPeerConnection-kanavan, sen tiedonsiirtoprotokollan asetukset

ovat sovelluskehittäjän muokattavissa.

7

2.4.1 Tiedonsiirtoprotokolla

Koska reaaliaikaisessa kommunikaatiosovelluksessa tiedonsiirron ajoitus ja viiveiden

minimoiminen ovat tärkeämpiä kuin siirretyn tiedon eheyden varmistaminen, on

WebRTC:n ensisijaiseksi tiedonsiirtoprotokollaksi valittu UDP (User Datagram Protocol).

UPD soveltuu hyvin kuvan ja äänen striimaamiseen, sillä toisin kuin TCP:ssä (Transmis-

sion Control Protocol) UDP:ssä ei jäädä odottamaan kuittausta vastaanottavalta osapuo-

lelta lähetetyn paketin saapumisesta, eikä epäonnistuneen paketin lähetystä yritetä uu-

delleen. Toisin sanoen UDP:ssä pakettien perillemenoa tai järjestystä ei varmisteta

päästä päähän.

Koska pakettien perillemenoa ja järjestystä ei varmisteta, voi osa paketeista hukkua mat-

kalla tai saapua väärässä järjestyksessä. Tällä on kuitenkin yleensä hyvin vähän vaiku-

tusta WebRTC-sovelluksen kuvan- tai äänenlaatuun, sillä WebRTC:ssä käytetyt pak-

kausmenetelmät kykenevät täyttämään pieniä aukkoja tiedonsiirrossa melko huomaa-

mattomasti.

2.4.2 Tietoliikenteen salaaminen ja varmentaminen

Verkon yli tapahtuvan tietoliikenteen salaaminen on tärkeä osa WebRTC:n protokollata-

son standardointia. WebRTC:ssä käytetään DTLS-protokollaa (Datagram Transport

Layer Security) tietoliikenteen salaamiseen.

DTLS-protokolla perustuu TLS-protokollaan (Transport Layer Security), mutta toisin kuin

TLS-protokolla, joka edellyttää TCP-tiedonsiirtoprotokollan käyttöä, DTLS-protokolla on

suunniteltu toimimaan myös sellaisten tiedonsiirtoprotokollien kanssa, jotka eivät takaa

pakettien järjestystä tai perillemenoa. [6.]

Yksi tärkeä eroavaisuus TLS- ja DTLS-protokollien välillä on, että DTLS-protokollan kä-

denpuristus (engl. handshake) perustuu asiakaspään itse allekirjoittamiin sertifikaattei-

hin, jolloin se ei tarjoa mitään takeita osapuolten oikeasta identiteetistä. WebRTC-sovel-

luksen on siis toteutettava osapuolten identiteetin varmistaminen muilla keinoin, kuten

sovelluksen oman tai kolmannen osapuolen identiteettipalvelun avulla.

8

Koska UPD-tiedonsiirtoprotokollan tiedonsiirtoformaatti RTP (Real-Time Transport Pro-

tocol) ei tarjoa minkäänlaista keinoa siirrettävien pakettien salaamiseksi, käytetään

WebRTC:n RTCPeerConnection-kanavan tiedonsiirtoformaattina SRTP:tä (Secure

Real-Time Transport Protocol). Käytännössä SRTP laajentaa RTP:tä tarjoamalla meka-

nismin RTP-pakettien salaamiseen tiedonsiirtokerroksessa ja salauksen purkamiseen

sovelluskerroksessa DTLS-kädenpuristuksen yhteydessä vaihdettujen salausavaimien

avulla. Tämä mahdollistaa vastaanotetun tiedon varmentamisen samaan tapaan kuin

TLS-protokollaa käytettäessä.

Koska SRTP-tiedonsiirtoformaatti ei tarjoa mekanismia pakettien järjestyksen tai perille-

menon hallitsemiseksi, soveltuu se vain sellaisen tiedon siirtoon, jonka eheydellä ei ole

suurta merkitystä. Tämän takia RTCDataChannelin tiedonsiirtoformaatiksi on valittu

SCTP (Stream Control Transmission Protocol). Se tarjoaa samanlaisen salausmekanis-

min kuin SRTP, mutta se mahdollistaa tarvittaessa TCP:n tasoisen pakettien toimitus-

varmuuden. Toisin kuin TCP:ssä SCTP:ssä toimitusvarmuus on sovelluskehittäjän hal-

littavissa.

2.4.3 Tiedonsiirron hallinta

Koska reaaliaikaisen kommunikaatiosovelluksen toiminnan kannalta tiedonsiirron ajoitus

ja viiveiden minimointi on ensisijaisen tärkeää, tulee näitä kyetä hallitsemaan jollain ta-

paa myös normaalissa verkkoympäristössä, jossa verkkoyhteyksien laatu vaihtelee jat-

kuvasti.

Jotta tiedonsiirron ajoitusta, viivettä ja pakettihäviötä voidaan hallita, tulee lähettävän

pään olla tietoinen vastaanottavan pään kyvystä vastaanottaa ja prosessoida lähetettyä

dataa. Tämän toteuttamiseksi WebRTC:ssä käytetään SRTCP:tä (Secure Real-time

Transport Control Protocol), joka on salausmekanismin sisältävä toteutus RTCP:stä

(Real-time Transport Control Protocol). Yhdessä SRTP-tiedonsiirtoformaatin kanssa

käytettäessä, SRTCP tarjoaa vastaanottajalle keinon havainnoida pakettihäviötä ja tie-

donsiirtoviivettä, sekä ilmoittaa tästä lähettäjälle. SRTP-paketit sisältävät vastaanotta-

jalle oleellista metadataa, kuten paketin järjestysnumeron ja aikaleiman. Näiden tietojen

avulla vastaanottaja voi havaita, jos osa paketeista ei saavu perille tai jos viive pakettien

saapumisen välillä kasvaa liian suureksi.

9

SRTCP:n tehtävänä on pitää kirjaa vastaanotettujen SRTP-pakettien statistiikasta, kuten

puuttuvien pakettien lukumäärästä ja viimeksi saapuneen paketin järjestysnumeron. Tie-

donsiirron osapuolet vaihtavat näitä tietoja ajoittain, joka mahdollistaa lähettävän osa-

puolen säätää lähetettävän striimin laatua vastaanottajan vastaanottokyvyn mukaiseksi.

WebRTC:ssä tätä ominaisuutta kutsutaan ruuhkanhallinnaksi (engl. congestion control).

Käytännössä ruuhkanhallintaominaisuus tarkoittaa sitä, että WebRTC-sovelluksella ei

oikeasti ole mahdollisuutta kontrolloida kuvan- ja äänenlaatua, vaan ne muuttuvat dy-

naamisesti osapuolten välisten tiedonsiirtonopeuksien mukaan.

2.4.4 Vertaisverkkoyhteyden muodostus ja hallinta

Vertaisverkkoyhteyden muodostaminen tilanteessa, jossa osapuolet ovat erillisissä yk-

sityisissä verkoissa, on haasteellista, sillä ensin kummankin osapuolen on selvitettävä

oma julkinen IP-osoite ja porttinumero sekä välitettävä nämä tiedot toiselle osapuolelle.

Haasteelliseksi tämän tekee se, että yksityiseen verkkoon kytketty laite voi olla yhden tai

useamman NAT-solmun (Network Address Translation) ja palomuurin takana.

NAT on internetissä käytettävä menetelmä, joka reitittää yksityisen verkon koko IP-osoi-

teavaruuden yhden julkisen IP-osoitteen kautta. Käytännössä tämä tarkoittaa sitä, että

yksityiseen verkkoon kytketty laite tietää paikallisen IP-osoitteensa, mutta ei NAT:n mää-

rittämää julkista osoitettaan.

Vertaisverkkoyhteyden muodostamisessa ja hallinnassa keskeisiä komponentteja ovat

• ICE-agentti (Interactive Connection Establishment)

• STUN-palvelin (Session Traversal Utilities for NAT)

• TURN-palvelin (Traversal Using Relays around NAT).

Yhteyden muodostus tapahtuu siten, että ensin ICE-agentti selvittää laitteen paikallisen

IP-osoitteen. Tämän jälkeen ICE-agentti selvittää laitteen julkisen IP-osoitteen lähettä-

mällä kyselyn ulkoiselle STUN-palvelimelle, joka palauttaa vastauksena IP-osoitteen,

josta kysely saapui. Jos tämä epäonnistuu esimerkiksi palomuuriasetusten takia, ICE-

agentti luopuu vertaisverkkoyhteydestä ja reitittää osapuolten välisen liikenteen erillisen

TURN-palvelimen kautta.

10

2.5 VideoEngine ja VoiceEngine

VideoEngine ja VoiceEngine toimivat rajapintoina käyttäjän laitteiston kuva- ja ääniläh-

teiden ja selaimen välillä mahdollistaen niiden kutsumisen JavaScript-ohjelmointirajapin-

nan avulla. WebRTC-projekti vastaa molempien rajapintojen toteutuksesta, jolloin aino-

astaan JavaScript-ohjelmointirajapinnan toteutus jää selainvalmistajan vastuulle.

Kuvan ja äänen reaaliaikaiseen striimamiseen liittyy useita haasteita. Näitä ovat muun

muassa viive, pakettihävikki, synkronointivirheet, taustamelu, äänentasojen hallinta ja

äänen kierto osallistujien välillä. VideoEngine ja VoiceEngine sisältävät tarvittavat kom-

ponentit näiden hallitsemiseksi, joita ovat

• Jitter Buffer

• AGC (Automatic Gain Control)

• AEC (Acoustic Echo Cancellation)

• NR (Noise Reduction).

Reaaliaikaisen median striimaamisen ongelmana on, että lähetettyjen pakettien saapu-

misjärjestystä ja pakettien saapumisen välistä viivettä ei voida taata vastaanottajalle. Jit-

ter Buffer -mekanismin tehtävänä on puskuroida saapuneita RTP-paketteja ja järjestää

ne niiden järjestysnumeroiden mukaan ennen niiden sisältämien kuva- ja äänikehysten

saattamista edelleen käsiteltäväksi. Tämän avulla voidaan huomattavasti vähentää tie-

donsiirrosta johtuvia kuvan- ja äänenlaadun ongelmia sekä mahdollistaa kuva- ja äänist-

riimien synkronoinnin vastaanottajan päässä RTP-pakettien sisältämien aikaleimojen

perusteella.

WebRTC-standardi määrittää, että siirrettävän äänen tason tulisi pysyä tasolla -19 dBm0

(+/- 6 dB), joka vastaa suunnilleen arvoa 2600 RMS 16-bittisellä lineaarisella PCM-for-

maatilla näytteistetyllä äänisignaalilla [7]. Tämän tarkoituksena on varmistaa yhteentoi-

mivuus eri järjestelmissä, kuten puhelinverkoissa käytettävien äänenpakkausformaattien

kanssa. Koska ei ole kohtuullista olettaa, että käyttäjät voisivat säädellä mikrofoninsa

äänenvoimakkuutta suositellulle tasolle, etenkään kommunikaatiotilanteen aikana, tar-

joaa VoiceEngine AGC-mekanismin äänentason automaattiseen hallintaan.

Reaaliaikaisessa kommunikaatiosovelluksessa ääni voi päästä kiertämään osallistujien

välillä silloin, kun ääni pääsee kulkeutumaan laitteiston kaiuttimesta takaisin laitteiston

11

mikrofoniin. Koska äänen kierto voi helposti tehdä kommunikoinnista mahdotonta, on

AEC:n tehtävänä ehkäistä tätä äänen kiertoa.

NR puolestaan pyrkii poistamaan ympäristöstä ja laitteistosta johtuvaa taustamelua ää-

nisignaalista. Tämän avulla pyritään siihen, että äänisignaali olisi mahdollisimman häi-

riötöntä ja että osallistujat voivat saada toistensa puheesta selvää myös meluisassa ym-

päristössä.

Vaikka edellä mainitut signaalinkäsittelykomponentit parantavat normaalin kommunikaa-

tiotilanteen äänenlaatua, WebRTC-standardi suosittaa, että kaikkien signaalinkäsittely-

komponenttien tulisi olla kytkettävissä pois päältä sellaisten sovellusten osalta, joissa ne

eivät välttämättä toimi toivotulla tavalla, kuten musiikki- ja näytönjakosovelluksissa.

WebRTC-sovellusten yhteentoimivuuden varmistamiseksi pakolliset kuvan ja äänen

pakkausmenetelmät ovat määritelty osana protokollatason standardointia. Pakollisia

pakkausmenetelmiä kuvalle ovat

• VP8

• H.264

ja äänelle

• Opus

• G.711 (A-law)

• G.711 (µ-law).

Pakollisten pakkausmenetelmien lisäksi selainvalmistaja voi vapaasti tukea myös muita

pakkausmenetelmiä, mutta tällöin sovellusten yhteentoimivuutta eri selainten välillä ei

pystytä takaamaan.

2.6 Ongelmien jäljittämisen työkalut

WebRTC-istuntoihin liittyy useita potentiaalisia ongelmakohtia, joiden takia tiedonsiir-

rossa ja ääni- ja kuvastriimeissä voi esiintyä ongelmia tai istunnon luonti voi epäonnistua

kokonaan. WebRTC:n Statistics API tarjoaa sovelluskehittäjälle rajapinnan WebRTC-is-

tunnon yksityiskohtien reaaliaikaiseen tarkasteluun. Lähtökohtaisesti Statistics API:n

12

getStats()-metodi palauttaa kaiken istuntoon liittyvän statistiikan, mutta sille voidaan kut-

sun yhteydessä antaa parametrina MediaStreamTrack-objekti, jolloin metodi palauttaa

kyseisen mediastriimin statistiikan.

WebRTC-standardi määrittää tärkeimmät vertaisverkkoyhteyden, tiedonsiirron ja ääni-

ja kuvastriimien tarkkailemiseen vaadittavat statistiikkatiedot, joita ovat mm.

• lähtevien ja saapuvien RTP-pakettien tiedot

• ICE-kandidaattien tiedot (verkko-osoitteet, portit, verkkoyhteyden tyyppi)

• kuva- ja äänistriimien laadun rajoittamisen syy

• lähtevien ja saapuvien ääni- ja kuvastriimien tiedot (puskuroinnin viiveet, akustisen kaiunpoiston määrä, aikaleimat)

• äänen ja kuvan käsittelijöiden tiedot (äänentaso, puheaktiivisuus, kuvataa-juus, resoluutio)

• äänen- ja kuvanpakkausmenetelmien tiedot (pakkausalgoritmi, kellotaa-juus, kanavien lukumäärä).

Useimmat selainvalmistajat tarjoavat käyttöliittymän Statistics API:n tärkeimpien tietojen

tarkkailuun graafisessa muodossa. Esimerkiksi Google Chrome -selaimessa tämä löytyy

osoitteesta chrome://webrtc-internals. WebRTC-istunnon tietojen tarkkailun lisäksi aina-

kin Google Chrome -selaimen käyttöliittymä tarjoaa myös mahdollisuuden lähtevien ja

saapuvien äänistriimien tallentamiseen (Create Dump -valikko), jonka avulla voidaan

pyrkiä selvittämään signaalinkäsittelykomponenttien toimintaan liittyviä ongelmia.

2.7 Tehdyt havainnot

Selvitystyön avulla saatiin muodostettua hyvä kuva WebRTC:n toiminnasta ja sisäisistä

rakenteista sekä äänen- ja kuvanlaatuun vaikuttavista tekijöistä. Yksi merkittävimmistä

havainnoista, joka kävi ilmi WebRTC:n tiedonsiirtokerrosta tutkimalla oli WebRTC:n

ruuhkanhallintaominaisuuden toiminta, joka käytännössä tarkoittaa, että vertaisverkko-

yhteyttä käytettäessä, ei lähetettävän striimin laatua pystytä takaamaan ja että yhden

osallistujan heikko verkkoyhteys tai laitteiston kuormittuminen voi johtaa striimin laadun

heikkenemiseen kaikille osallistujille.

13

Tämän työn kannalta selvitystyössä tehdyistä havainnoista merkittävimpänä voidaan pi-

tää sitä, että jopa WebRTC:n protokollamäärittelyssä todetaan, että signaalinkäsittely-

komponenttien tulisi olla kytkettävissä pois päältä musiikkia sisältävien sovellusten

osalta. Tämä on tärkeä tieto, sillä se tarkoittaa, että signaalinkäsittelykomponenttien

käyttäminen WebRTC-sovelluksessa on ja tulee todennäköisesti myös tulevaisuudessa

olemaan sovelluskehittäjän hallittavissa. Myös automaattisen äänentason hallinnan

määrittely oli työn kannalta oleellinen, sillä tietoa määritellyistä äänentasoista voitiin hyö-

dyntää mikserisovelluksen suunnittelussa.

14

3 Sanoste Oy:n kuvapuhelujärjestelmä

Sanoste Oy:n kuvapuhelujärjestelmä käsittää sekä palveluntuottajan että osallistujan

WebRTC-teknologiaan perustuvat kuvapuhelusovellukset. Palveluntuottajan sovellus on

saatavilla ainoastaan selainversiona. Osallistujan sovellus on saatavilla selainversion li-

säksi myös natiivisovelluksina iOS- ja Android-käyttöjärjestelmille.

Asiakaspään sovellusten lisäksi Sanoste Oy:n kuvapuhelujärjestelmä käsittää myös

taustajärjestelmän, joka koostuu useasta eri mikropalveluarkkitehtuuria toteuttavasta

komponentista. Taustajärjestelmän tehtävänä on ylläpitää tietoja aktiivisista tilauksista ja

laitteista, luoda istuntoja sekä ilmoittaa istuntojen alkamisesta palveluun osallistuville lait-

teille.

Sanoste Oy:n välittämät palvelut toteutetaan aina yhden suhde moneen -yhteydellä, eli

palvelussa on aina yksi ohjaaja ja yksi tai useampi osallistuja. Ohjaaja siis näkee ja kuu-

lee kaikki osallistujat ja osallistujat näkevät sekä kuulevat ohjaajan, mutta eivät toisiaan.

Tämän avulla mahdollistetaan usean osallistujan yhtäaikainen ohjaaminen.

3.1 Kuvapuhelujärjestelmän WebRTC-toiminnallisuus

Sanoste Oy:n kuvapuhelusovellukset on rakennettu OpenTok-palvelualustalle. OpenTok

on TokBox-nimisen palveluntarjoajan kehittämä WebRTC-teknologiaan perustuva pal-

velualusta. OpenTok-palvelualusta tarjoaa REST-rajapinnan istuntojen luontiin sekä työ-

kalut palvelin- ja asiakaspään ohjelmistojen kehittämiseen (Server SDK ja Client SDK).

OpenTok-palvelualustan etuna on, että se kätkee suurimman osan istuntojen ja verkko-

yhteyksien luontiin liittyvästä monimutkaisuudesta sekä huolehtii palveluiden skaalautu-

vuudesta ja saatavuudesta.

15

Kuva 2. OpenTok-palvelualustan istunnonluonnin kuvaus. [8.]

Sanoste Oy:n WebRTC-toiminnallisuuden toteutuksessa taustajärjestelmä huolehtii is-

tuntojen luonnista ja istuntotunnisteiden välittämisestä asiakaspäänsovelluksille. Varsi-

nainen yhteyksien muodostus tapahtuu pilvipalvelussa taustajärjestelmän välittämien is-

tuntotunnisteiden avulla (ks. kuva 2). Asiakaspään sovelluksissa istuntoihin liittyminen ja

striimien luonti tapahtuu OpenTok Client SDK:n metodeja kutsumalla [9].

Istuntoihin liittymisen ja striimien luonnin lisäksi OpenTok Client SDK tarjoaa myös help-

pokäyttöiset rajapinnat istuntoon liittyvien tapahtumien kuuntelemiseen asiakaspään so-

velluksessa. Tällaisia tapahtumia ovat muun muassa

• osallistujan liittyminen tai poistuminen istunnosta

• striimin luominen tai tuhoutuminen

• striimin ominaisuuksien muuttuminen.

16

Tapahtumat välitetään asiakaspään sovellukselle erillisen WebSocket-yhteyden avulla.

Näiden tapahtumien avulla asiakaspään sovellus voi esimerkiksi poistaa osallistujan vi-

deoelementin, kun osallistuja poistuu istunnosta tai kun osallistujan striimi tuhoutuu. [10;

11.]

Vertaisverkkoyhteyden lisäksi OpenTok tarjoaa myös mahdollisuuden reitittää osallistu-

jien välinen verkkoliikenne OpenTokin mediapalvelimen kautta. Periaatteessa mediapal-

velimen kautta reititetty yhteys toimii samaan tapaan kuin yhteyden reitittäminen TURN-

palvelimen kautta.

Sanoste Oy:n ratkaisussa käytetään nimenomaan reititettyä yhteyttä, sillä tällöin, toisin

kuin vertaisverkkoyhteyttä käytettäessä, palveluntuottajan ei tarvitse lähettää omaa ääni-

ja kuvastriimiään jokaiselle osallistujalle erikseen, koska OpenTokin mediapalvelin huo-

lehtii striimien monistamisesta ja välittämisestä osallistujille.

Vaikka yhteyksien reitittäminen mediapalvelimen kautta tuo kuvapuheluun jonkin verran

lisää viivettä, vähentää se samalla huomattavasti palveluntuottajan verkkoliikennekuor-

maa ja mahdollistaa striimaamisen lähes rajattomalle määrälle osallistujia. Käytännössä

osallistujien määrää kuitenkin rajoittaa palveluntuottajan verkkoyhteyden latausnopeus

ja laitteiston suorituskyky, sillä palveluntuottaja joutuu vastaanottamaan ja käsittelemään

jokaisen osallistujan striimin erikseen, jotta ne voidaan näyttää palveluntuottajan näytöllä

yhtäaikaisesti.

OpenTokin mediapalvelimen ominaisuuksiin kuuluu myös Scalable Video. Scalable Vi-

deo -ominaisuus tarkoittaa sitä, että kuvastriimin julkaisija lähettää yhden kuvastriimin

sijaan useita versioita striimistä eri resoluutioilla ja kuvataajuuksilla, joista OpenTokin

mediapalvelin pyrkii valitsemaan kullekin striimin vastaanottajalle sopivimman version

vastaanottajan sen hetkisen verkkoyhteyden laadun perusteella.

Ilman Scalable Video -ominaisuuden käyttöä yhden vastaanottajan verkkoyhteyden laa-

dun heikentyminen johtaisi siihen, että kuvastriimin laatu heikkenisi kaikille vastaanotta-

jille WebRTC:n ruuhkanhallintaominaisuuden seurauksena. Scalable Video -ominaisuu-

den käyttö edellyttää VP8-kuvanpakkausmenetelmän käyttöä, joten H.264-kuvanpak-

kausmenetelmää ei voi tällöin käyttää, vaikka kaikki istunnossa mukana olevat laitteet

tukisivatkin sen laitteistokiihdytteistä pakkaamista ja purkamista [12].

17

3.2 Kuvapuhelujärjestelmän arkkitehtuuri

Sanoste Oy:n kuvapuhelujärjestelmä sisältää asiakaspäänsovellusten lisäksi näiden

taustajärjestelmät sekä erillisen aktiivisten tilausten hallinnoinnista ja istuntojen luonnista

vastaavan taustajärjestelmän (Channel Backend). Näiden lisäksi kuvapuhelujärjestelmä

käsittää myös asynkroonisen viestityspalvelun (Channel Worker), jonka avulla tieto is-

tuntojen alkamisesta välitetään osallistujien sovelluksien taustajärjestelmälle (Mobile

Backend).

Kuva 3. Sanoste Oy:n kuvapuheluyhteyksien topologia.

Sanoste Oy:n kuvapuhelujärjestelmässä istuntojen luonti ja striimien hallinta on toteu-

tettu siten, että jokaiselle osallistujalle ja ohjaajalle luodaan oma istuntonsa. Palvelun-

tuottajan sovellukselle välitetään tieto ohjaajan ja jokaisen osallistujan istunnoista. Osal-

listujan sovellukselle puolestaan välitetään tiedot ainoastaan ohjaajan ja osallistujan

omasta istunnosta. Tällöin palveluntuottajan sovellus pystyy vastaanottamaan jokaisen

osallistujan lähettämän striimin erillistä kanavaa pitkin ja julkaisemaan ohjaajan strii-

minsä kaikille osallistujille yhtä kanavaa pitkin (ks. kuva 3). Osallistujan sovellus puoles-

taan voi julkaista oman striiminsä palveluntuottajalle ilman, että muut osallistujat voivat

päästä siihen käsiksi.

…

…

OpenTok

Media Server

Participant 1

Instructor

Participant 2 Participant N

18

3.3 Osallistujan sovellus

Osallistujan sovelluksen tärkein toiminnallisuus on palveluiden vastaanottaminen. Sovel-

luksen muut toiminnot lähinnä tukevat tätä tarkoitusta. Osallistujan sovellukset ovat

suunniteltu siten, että palveluiden vastaanottaminen olisi mahdollisimman helppoa.

Tämä on toteutettu siten, että osallistujan laite alkaa soimaan, kun ohjaaja aloittaa pal-

velun ja palveluun osallistuminen tapahtuu yhtä painiketta painamalla. Laitteen soimisen

ja palveluun osallistumisen edellytyksenä on tietysti, että käyttäjä on kirjautunut sovel-

lukseen ja että laite on verkossa.

Istunnon alkamisen signaloinnista vastaa sovellusten taustajärjestelmä. Tämän mahdol-

listamiseksi laitteen tulee rekisteröityä taustajärjestelmään sisäänkirjautumisen yhtey-

dessä ja sovelluksen tulee kuunnella taustajärjestelmän lähettämiä ilmoituksia. Ilmoitus-

ten välittämiseen taustajärjestelmä käyttää Google:n FCM-palvelua (Firebase Cloud

Messaging) Android- ja selainsovelluksille ja Applen APNS:ää (Apple Push Notification

Service) iOS-sovelluksille. Tällöin sovellukset kykenevät reagoimaan soittoihin, vaikka

sovellus olisi laitettu taka-alalle.

Istuntoihin liittyminen tapahtuu taustajärjestelmän välittämien istuntotunnisteiden avulla,

jotka sovellus hakee taustajärjestelmästä saadessaan ilmoituksen istunnon alkamisesta.

Yhteyksien muodostamisessa ja striimien luomisessa asiakaspäänsovellukset hyödyn-

tävät OpenTok Client SDK:ta.

3.4 Palveluntuottajan sovellus

Palveluntuottajan sovellus sisältää toiminnallisuudet sekä palveluiden hallinnointiin että

niiden toteuttamiseen. Toteutustavaltaan palveluntuottajan sovellus on hyvin perinteinen

palvelinpäässä renderöitävä verkkoselainsovellus. Palveluntuottajan sovellus on toteu-

tettu Flask-ohjelmointikehyksen avulla.

Palveluntuottajan sovelluksen kuvapuhelutoiminnallisuutta käsitellään kahdessa eri nä-

kymässä. Ns. esikatselunäkymässä ohjaaja voi valmistautua istunnon aloittamiseen.

Esikatselunäkymässä ohjaaja näkee oman kuvansa, jonka avulla ohjaaja voi tarkistaa

kameran toimivuuden ja asettautumisensa kuvassa. Esikatselunäkymässä näytetään

19

myös äänentasomittari, jonka avulla ohjaaja voi varmistaa mikrofonin toimivuuden. Oh-

jaajan mikrofonisignaalia ei toisteta esikatselunäkymässä ohjaajalle, sillä se aiheuttaisi

äänen kiertoa, mikäli ohjaajalla ei ole kuulokkeita käytössään. Tämän huonona puolena

on, että ohjaaja ei voi tarkistaa mikrofoninsa äänenlaatua esikatselunäkymässä.

Varsinaiseen kuvapuhelunäkymään siirrytään, kun ohjaaja klikkaa istunnon aloituspaini-

ketta esikatselunäkymässä. Kun ohjaaja siirtyy kuvapuhelunäkymään, palveluntuottajan

sovelluksen taustajärjestelmä signaloi aktiivisten tilausten hallinnoinnista ja istuntotun-

nisteiden luonnista vastaavalle taustajärjestelmälle istunnon alkamisesta, joka palauttaa

istuntotunnisteet, joiden avulla palveluntuottajan sovellus voi julkaista ohjaajan striimin

ja vastaanottaa kaikkien osallistujien julkaisemat striimit. Samalla istuntotunnisteiden

luonnista vastaava taustajärjestelmä lähettää ilmoituksen istunnon alkamisesta kaikille

osallistujille.

20

4 Signaalinkäsittely WebRTC-sovelluksissa

Työn toisessa vaiheessa tutustuttiin tarkemmin WebRTC:n signaalinkäsittely kompo-

nenttien toimintaperiaatteisiin tutkimalla signaalinkäsittelykomponenttien erilaisia toteu-

tustapoja sekä tarkastelemalla WebRTC:n lähdekoodia.

Tässä luvussa kerrotaan ensin WebRTC:n signaalinkäsittelystä yleisellä tasolla, jonka

jälkeen käsitellään WebRTC:n yleisimmin käytettyjen kuvan ja äänen pakkausmenetel-

mien eroavaisuuksia. Tämän jälkeen tarkastellaan signaalinkäsittelykomponenttien toi-

mintaperiaatteita yksityiskohtaisemmin ja lopuksi tutustutaan WebRTC:n rajapintojen

avulla saatavien äänistriimien käsittelyyn soveltuvaan Web Audio API:hin.

4.1 WebRTC:n signaalinkäsittelystä yleisesti

WebRTC-standardi määrittää tärkeimmät ääni- ja kuvasignaalinkäsittelykomponentit,

joiden tarkoituksena on parantaa kommunikaatiosovelluksen käyttäjäkokemusta ja vä-

hentää verkkoliikenteen kuormaa sekä pakettihävikistä aiheutuvia kuvan- ja äänenlaa-

dun ongelmia. Näihin lukeutuvat video- ja äänisignaalien pakkausmenetelmät sekä eri-

laiset äänisignaalinkäsittelykomponentit, joiden avulla pyritään ehkäisemään kaksisuun-

taisten kommunikaatiosovellusten reaaliaikaisuuteen liittyviä ongelmia, kuten äänen

kiertoa ja meluisesta ympäristöstä johtuvia ongelmia.

WebRTC:n signaalinkäsittelyalgoritmit ovat edelleen aktiivinen kehityksen kohde ja uu-

sia innovaatioita tehdään jatkuvasti. Etenkin koneoppimisen saralla tapahtunut kehitys

on avannut uusia mahdollisuuksia älykkäämpien signaalinkäsittelyalgoritmien kehittämi-

selle. Koneoppimista voidaan hyödyntää mm. puheen ja taustamelun tunnistuksessa,

joka puolestaan mahdollistaa luotettavan puheaktiivisuuden tunnistamisen myös melui-

sissa ympäristöissä.

Vaikka WebRTC:n signaalinkäsittelykomponentit kykenevät estämään äänen kiertoa,

poistamaan taustamelua ja muutenkin parantamaan kuvapuhelun laatua normaaleissa

kuvapuhelusovelluksissa tehokkaasti ja luotettavasti, voi niillä olla päinvastainen vaiku-

tus sekä kuvan- että äänenlaatuun silloin, kun äänisignaali sisältää musiikkia. Tämän

21

takia WebRTC-standardi määrittää, että selainvalmistajien tulisi tarjota selainsovelluske-

hittäjille mahdollisuus kytkeä signaalinkäsittelykomponentteja pois käytöstä sellaisissa

sovelluksissa, jotka eivät hyödy WebRTC:n signaalinkäsittelykomponenttien toiminnasta

[7].

Potentiaalisesti WebRTC-sovelluksessa käytettävillä signaalinkäsittelykomponenteilla ja

kuvan ja äänen pakkausmenetelmillä voi olla myös muita haittavaikutuksia, mikäli ne

kuormittavat laitteiston laskentayksikköä liiaksi. Tällöin saapuvien RTP-pakettien käsit-

tely saattaa hidastua, jolloin WebRTC:n ruuhkanhallintaominaisuus alkaa rajoittaa lähet-

tävän pään äänen- ja kuvanlaatua. Useamman osallistujan kuvapuhelussa tämä voi hei-

kentää kuvapuhelunlaatua kaikkien osallistujien osalta.

4.2 Kuvan ja äänen pakkausmenetelmät

WebRTC-sovelluksissa yleisimmin käytetyt pakkausmenetelmät ovat kuvalle VP8 ja

H.264 ja äänelle Opus. Opus on WebRTC-standardin määrittelemistä äänenpakkaus-

menetelmistä ainoa, joka tukee täyden kaistan näytteenottotaajuutta (48 kHz) stereoää-

nelle. Se siis soveltuu hyvin puheen pakkaamisen lisäksi myös musiikin pakkaamiseen.

Toisaalta, toisin kuin muut musiikin pakkaamiseen käytetyt äänenpakkausmenetelmät,

Opus tukee myös hyvin alhaisia näytteenottotaajuuksia (8 kHz). Koska Opus sallii bitti-

nopeuden muuttamisen dynaamisesti, soveltuu se hyvin käytettäväksi WebRTC:n ruuh-

kanhallintaominaisuuden kanssa [13].

VP8- ja H.264-kuvanpakkausmenetelmien merkittävin ero on siinä, että VP8-pakkaus-

menetelmälle erikoistuneet suoritusyksiköt ovat harvinaisia, eli käytännössä pakkaami-

sen ja purkamisen suorittaminen tapahtuu yleensä tietokoneen CPU:ssa (Central Pro-

cessing Unit). H.264:lle puolestaan useimmissa laitteissa on sen pakkaamiseen ja pur-

kamiseen suunniteltu erillinen suoritusyksikkö, jolloin sen pakkaaminen ja purkaminen

eivät rasita laitteen CPU:ta ja myös virrankulutus on vähäisempää.

Kuvanlaadun kannalta pakkausmenetelmien välillä ei ole suurta eroa [14], mutta mikäli

laitteisto tukee laitteistokiihdytteistä H.264-pakkausmenetelmää, on sen etuna myös se,

että laitteen CPU:n muut tehtävät eivät vaikuta kuvan pakkaamiseen ja purkamiseen.

Tämä puolestaan voi pienentää kuvastriimin käsittelystä aiheutuvaa viivettä. Koska

22

CPU:lle jää myös enemmän resursseja muiden tehtävien suorittamiseen, voi se suoriu-

tua muista tehtävistään, kuten äänistriimin käsittelystä, nopeammin.

H.264-pakkausmenetelmän ongelmana on, että jotkin Android SDK- ja Android Chrome

-versiot eivät tue sitä lainkaan, jolloin sen käyttäminen sovelluksessa, jonka tulee tukea

kaikkia mahdollisia laitteita, ei ole suositeltavaa.

4.3 Puheaktiivisuuden tunnistaminen - VAD

VAD-komponentin (Voice Activity Detection) tehtävänä on analysoida sisään tulevaa ää-

nisignaalia ja erottaa puhetta sisältävät ja sisältämättömät signaalin osat toisistaan.

VAD-komponentilla on keskeinen rooli WebRTC:n äänisignaalinkäsittelyketjussa, sillä

sitä voidaan hyödyntää muiden signaalinkäsittelykomponenttien sisääntulosignaalin esi-

prosessoinnissa tai käyttää eräänlaisena ohjauspiirinä. Tämän takia on hyvin tärkeää,

että VAD-algoritmi kykenee tunnistamaan puheaktiivisuuden riittävän luotettavasti kai-

kissa tilanteissa.

Yksinkertaisimmillaan VAD-algoritmi voidaan toteuttaa tarkkailemalla signaalin koko-

naisamplitudia. Tällaisessa toteutuksessa puheeksi tulkittaisiin kaikki sellaiset signaalin

osat, joiden amplitudi ylittää ennalta määritetyn raja-arvon. Ongelmaksi muodostuu kui-

tenkin se, että puheen amplitudi vaihtelee voimakkaasti myös puhetta sisältävän signaa-

lin osan aikana. Tämä puolestaan saattaa helposti johtaa siihen, että VAD-algoritmi luo-

kittelee yksittäisen sanan tai lauseen aikana esiintyviä alhaisemman amplitudin osioita

puhetta sisältämättömiksi. Tämä puolestaan tekisi ulostulosignaalista hyvin katkonaista,

mikäli VAD-algoritmin luokittelua käytetään ohjaamaan esim. melunpoistoalgoritmin toi-

mintaa.

Edellä mainittua ongelmaa voidaan pyrkiä ehkäisemään eräänlaisen hystereesin avulla,

eli muuttamalla VAD-algoritmin toimintaa siten, että raja-arvon ylittäneen jakson jälkeen

arvoja puskuroidaan hetken ajan ennen uuden päätöksen tekoa. Mikäli yksikin odottelu-

jakson aikana puskuroiduista amplitudiarvoista ylittää ennalta määritetyn raja-arvon, voi-

daan tulkita signaalin olevan edelleen puhetta.

23

Pelkän kokonaisamplitudin analysointiin perustuvan toteutuksen huonona puolena on,

että se toimii heikosti meluisissa ympäristöissä, sillä melun amplitudi voi olla sama tai

korkeampi kuin varsinaisen puheen amplitudi. Toisaalta myös puhujan ja mikrofonin vä-

lisen etäisyyden kasvaminen voi laskea puheen amplitudia niin paljon, että se ei enää

ylitä ennalta määritettyä raja-arvoa.

Meluisasta ympäristöstä aiheutuvat ongelmat voidaan pyrkiä ratkaisemaan jakamalla

signaali useampaan osaan taajuusalueiden mukaan ja tarkkailemalla niiden taajuusalu-

eiden amplitudia, joille puheäänen perustaajuus yleensä sijoittuu, joka on noin 80 Hz -

450 Hz. Tämä ei kuitenkaan yksistään riitä, sillä ensinnäkin myös taustamelun amplitudi

voi olla korkea samaisella taajuusalueella, jolloin algoritmin tulisi huomioida myös sig-

naalin kokonaisspektri, ja toisekseen puheen konsonantit sijoittuvat huomattavasti kor-

keammille taajuuksille. Esimerkiksi ”s”-konsonantin korkein energia sijoittuu yleensä vä-

lille 4 kHz - 5 kHz. Mikäli puheeksi tulkittaisiin vain ne signaalin osat, joilla taajuusalueen

80 Hz - 450 Hz amplitudi on korkea, saattaisi melunpoistoalgoritmi poistaa sanojen

alussa olevia konsonantteja, tehden puheesta vaikeasti ymmärrettävää.

Jotta puheaktiivisuuden tunnistaminen toimisi luotettavasti kaikissa tilanteissa, tulisi sig-

naalista pyrkiä löytämään useampia ominaisuuksia, jotka erottavat puheen muusta sig-

naalin sisällöstä, jolloin päätöksen koostamisessa voidaan huomioida puhesignaalille

ominaisten piirteiden lisäksi myös taustamelulle ominaisia piirteitä. Lopullisen päätöksen

koostamiseen on useita eri vaihtoehtoja, joilla on erilaisia vaatimuksia laskenta-ajan suh-

teen. WebRTC-sovelluksessa pääpaino on yleensä mahdollisimman pienessä laskenta-

ajassa kommunikaatiotilanteen reaaliaikaisuudesta johtuen.

Mikäli VAD-algoritmin päätöksen koostamiseen käytettäviä ominaisuuksia ei ole kovin

montaa, voidaan päätöksen koostamiseen käyttää päätöspuuta, jossa jokaisen analy-

sointivaiheen lopputulos vaikuttaa siihen, mitä haaraa pitkin edetään, kunnes lopullinen

päätös on saavutettu. Tämä malli on yksinkertainen toteuttaa, mutta vaatii raja-arvojen

manuaalista hienosäätämistä ja saattaa helposti antaa väärän lopputuloksen, mikäli yk-

sikin analysointivaihe antaa väärän tuloksen. Mikäli päätöksenteossa käytettäviä ominai-

suuksia on runsaasti, voidaan päätöksen muodostamisessa käyttää esimerkiksi kaikkien

ominaisuuksien painotettua keskiarvoa.

24

Modernit VAD-algoritmit hyödyntävät koneoppimista tavalla tai toisella. Esimerkiksi

WebRTC:n VAD-algoritmin toiminta perustuu esiopetettujen puhe- ja melumallien käyt-

töön. Päätöksen muodostamiseen WebRTC:n VAD-algoritmi käyttää GMM-menetelmää

(Gaussian Mixture Model), jonka on todettu toimivan erittäin hyvin erilaisissa puheentun-

nistussovelluksissa [15; 16]. Myös edistyneempiä malleja, kuten neuroverkkoja voidaan

käyttää puheaktiivisuuden tunnistamiseen, mutta välivaiheiden määrästä riippuen niiden

vaatimat laskentaresurssit ovat helposti liian suuria reaaliaikaisiin sovelluksiin. Koneop-

pimiseen perustuvat VAD-algoritmit eivät ole myöskään automaattisesti perinteisiä VAD-

algoritmeja tarkempia, vaan niiden tarkkuus riippuu pitkälti mallin opettamiseen käytetyn

datan määrästä ja laadusta.

Koska normaalin puhesignaalin kaikki puheaktiivisuuden tunnistamiseen vaadittavat taa-

juudet sijoittuvat korkealaatuisen äänisignaalin Nyquistin taajuutta alhaisemmille taa-

juuksille, voidaan VAD-algoritmin vaatimaa laskenta-aikaa vähentää skaalaamalla sig-

naalin näytteenottotaajuutta alaspäin ennen sen syöttämistä algoritmin käsiteltäväksi.

Äänenlaatuun tällä ei ole vaikutusta, sillä VAD-algoritmi ei muokkaa signaalia, vaan se

ainoastaan analysoi sitä.

4.4 Äänen kierto ja sen ehkäiseminen - AES ja AEC

Kaksisuuntaisissa kommunikaatiosovelluksissa esiintyy aina äänen kiertoa. Äänen kierto

syntyy, kun lähettäjän äänisignaali pääsee kulkeutumaan vastaanottajan kaiuttimesta,

joko suoraan tai heijasteina huoneen seinistä, vastaanottajan mikrofoniin ja sitä kautta

takaisin lähettäjälle.

Äänen kiertoa voidaan ehkäistä useilla eri tavoilla, joista yksinkertaisin on eristää mikro-

foni ja kaiutin toisistaan siten, että kaiuttimesta tulevan äänen paine on erittäin alhainen

mikrofoniin kulkeutuessaan. Toisin sanoen kuulokkeita käyttämällä voidaan äänen kier-

toa ehkäistä erittäin tehokkaasti, mikäli mikrofonin ja kuulokkeiden välinen akustinen

eristys on riittävä.

Toinen tehokas keino äänen kierron ehkäisemiseen on akustisen kaiun vaimennus, eli

AES (Acoustic Echo Suppression). AES on ns. half-duplex-menetelmä, jossa äänisig-

25

naali voi kulkea vain yhteen suuntaan kerrallaan. Vaikka tällä tavalla äänen kiertoa voi-

daan estää tehokkaasti, soveltuu AES huonosti tilanteisiin, joissa tavoitteena on luoda

luonnollinen kommunikointitilanne, sillä molemmat osapuolet eivät voi olla äänessä yhtä

aikaa.

WebRTC-sovelluksissa yleisesti käytössä oleva tapa äänen kierron ehkäisemiseksi on

akustisen kaiun mitätöinti, eli AEC (Acoustic Echo Cancellation). Toisin kuin AES, AEC

on full-duplex-menetelmä, jolloin äänisignaali voi kulkea yhtä aikaa molempiin suuntiin.

AEC-algoritmin toiminta perustuu kaikureitin impulssivasteen, eli kaiuttimen ja huo-

neakustiikan aiheuttaman signaalin vääristymän mallintamiseen. Impulssivasteen perus-

teella voidaan luoda suodatin, joka poistaa kaiuttimesta tulleen äänen mikrofonisignaa-

lista ennen kuin se lähetetään vastaanottajalle.

Vaikka AEC:n toimintaperiaate on melko yksinkertainen, liittyy siihen kuitenkin useita

muuttujia, jotka mutkistavat tilannetta. WebRTC-sovelluksissa vaikeimmin käsiteltävä

muuttuja on järjestelmästä syntyvä viive. Viivettä syntyy niin laitteistossa kuin akusti-

sessa ympäristössäkin. AEC:n toiminnan kannalta viive on ongelmallinen, koska sen

määrä ei ole vakio vaan se saattaa muuttua esimerkiksi silloin, kun mikrofonia liikutellaan

suhteessa kaiuttimiin tai seiniin. Tämä puolestaan tarkoittaa sitä, että aiemmin muodos-

tettu suodatin ei enää vastaa kaikureitin aiheuttamaa signaalin vääristymää, jolloin

kaiunpoiston teho joko heikkenee tai pahimmassa tapauksessa jopa voimistaa kaiutti-

mesta tulleen äänen voimakkuutta.

Useimmissa AEC-algoritmeissa viiveen muuttumisesta aiheutuvat ongelmat on pyritty

ratkaisemaan mukautuvan suodattimen avulla, jossa suodattimen kertoimia pyritään päi-

vittämään jatkuvasti. Kertoimien päivittämistä ei kuitenkaan voida suorittaa silloin, kun

molemmat osapuolet ovat yhtä aikaa äänessä, koska lähettävän osapuolen oma puhe

estää oikeanlaisen impulssivasteen muodostamisen. Toisin sanoen, mukautuvan suo-

dattimen kertoimien muuttuminen täytyy estää yhtäaikaisen puheen aikana. Yhtäaikai-

sen puheen havaitsemiseksi AEC-algoritmeissa käytetään DTD-komponenttia (Double

Talk Detection), joka pohjautuu VAD-algoritmiin [17]. Kun DTD-komponentti tulkitsee,

että molemmat osapuolet ovat äänessä, AEC-algoritmi käyttää viimeksi muistissa ollutta

kaikureitin mallia tai vaihtoehtoisesti toimii half-duplex-tilassa, kunnes taas vain toinen

puhujista on äänessä.

26

Kahdenkeskeisessä kommunikaatiotilanteessa AEC:n avulla voidaan saavuttaa melko

häiriötön ja luonnollinen keskustelutilanne, mutta usean osallistujan tapauksessa tilanne

on jo selvästi hankalampi, sillä yhtäaikaista puhumista esiintyy huomattavasti enemmän.

Myös mallinnettavassa tilassa esiintyvä taustamelu voi häiritä AEC-algoritmin suodatti-

men kertoimien päivittymistä, mikäli taustamelu on luonteeltaan sellaista, että DTD-kom-

ponentti tulkitsee sen puheeksi (esim. tilassa soiva taustamusiikki tai taustalla käytävä

keskustelu).

4.5 Melunvaimennus - NS

Melunvaimennuksen, eli NS-komponentin (Noise Suppression) avulla äänisignaalista

pyritään poistamaan ympäristöstä tai laitteistosta aiheutuvaa taustamelua. Poistettavaa

melua voi olla esimerkiksi järjestelmästä syntyvä kohina, näppäimistöäänet tai toisten

ihmisten aiheuttamat äänet.

Yksinkertaisimmillaan NS-algoritmi voi toimia samaan tapaan kuin VAD-algoritmi, eli se

voi pyrkiä löytämään signaalista ne osat, jotka eivät sisällä puhetta ja vaimentamaan

näiden signaalin osien amplitudia. Tämä kuitenkin ratkaisee vain puolet ongelmasta, sillä

usein melu on häiritsevintä juuri puhetta sisältävien jaksojen aikana, sillä mikäli melu on

hyvin voimakasta, voi puheesta olla vaikea saada selvää.

Edellä mainittu ongelma voidaan pyrkiä ratkaisemaan muuttamalla NS-algoritmin toimin-

taperiaate muistuttamaan AEC-algoritmin toimintaa. Tällöin, samaan tapaan kuin AEC-

algoritmissa, melusta luodaan malli, jota voidaan käyttää negaatiosignaalina myös pu-

hetta sisältäville signaalin osille. Tämän avulla voidaan parhaimmillaan kyetä jopa koko-

naan poistamaan melu signaalista. Tällainen toteutus voi toimia hyvin tasaiselle melulle,

kuten kohinalle tai sähköisille häiriöäänille. Äkillisen ja lyhytkestoisen melun, kuten näp-

päimistöäänten tai muiden ihmisten aiheuttamien äänten poistoon tällainen menetelmä

ei kuitenkaan sovellu.

27

Kuva 4. Melunpoistoalgoritmin toimintaperiaate. [18.]

Melun reaaliaikaiseen mallintamiseen perustuvan ratkaisun ongelmana on myös, että

mallia voidaan tarkentaa ainoastaan silloin, kun signaali ei sisällä puhetta. Tämä voidaan

kuitenkin ratkaista esimerkiksi käyttämällä VAD-komponenttia ohjaamaan NS-algoritmia

siten, että konvoluutiomallia tarkennetaan ainoastaan puhetta sisältämättömien signaa-

linjaksojen aikana (ks. kuva 4).

Mikäli signaalista halutaan tehokkaasti poistaa myös muut häiriöäänet, tarvitaan NS-al-

goritmin toteutukseen älykkäämpiä ratkaisuja, kuten neuroverkkoja. [18.] Tällöin NS-al-

goritmi voi pyrkiä tunnistamaan signaalista ennalta opetettuja erilaisia meluksi luokitel-

tuja malleja ja poistamaan nämä signaalista. Tällaisen ratkaisun toimivuus riippuu hyvin

pitkälti käytetyn opetusdatan määrästä ja laadusta.

4.6 Automaattinen äänentason hallinta - AGC

AGC-komponentin tehtävänä on pitää lähetettävän äänisignaalin taso optimaalisella ta-

solla WebRTC-istunnon aikana. WebRTC:n standardin mukaan lähetettävän puhesig-

naalin tason tulisi olla noin 2600 RMS 16-bitin sananpituudella näytteistetyllä signaalilla,

joka vastaa noin -22 dBFS:ää (Decibels relative to Full Scale). Periaatteessa tämän to-

teuttaminen ei vaadi muuta kuin äänisignaalin RMS-tason mittaamista ja signaalin vah-

28

vistamista tai vaimentamista signaalin RMS-tason ja tavoitetason erotuksen verran. Käy-

tännössä tämä ei kuitenkaan riitä, sillä AGC-algoritmi vahvistaisi myös puhetta sisältä-

mättömien signaalinjaksojen äänentasoa.

Jotta AGC-algoritmi vahvistaisi ja vaimentaisi vain puhetta sisältäviä signaalinjaksoja,

voidaan myös AGC-algoritmin toiminnan ohjaamiseen käyttää VAD-komponenttia. Tällä

tavoin AGC-algoritmi voi jättää puhetta sisältämättömät signaalin osat huomioimatta

sekä vahvistuksen määrän laskennassa että vahvistuksen täytäntöönpanossa. Myös

taustamelun poistaminen ja akustisen kaiun mitätöinti on suotavaa suorittaa ennen sig-

naalin syöttämistä AGC-algoritmin käsiteltäväksi, sillä muutoin voimakas taustamelu tai

käyttäjän kaiuttimesta tullut ääni vaikuttaisi AGC-algoritmin laskemaan vahvistuksen tai

vaimennuksen määrään.

Koska AGC-algoritmi pyrkii vahvistamaan signaalia sen RMS-tason perusteella, tulisi

sen sisältää myös jonkinlainen kompressoripiiri, joka alentaa yksittäisten 0-tason ylittä-

vien signaalin huippuarvojen tasoa äänen säröytymisen estämiseksi.

4.7 Web Audio API

Web Audio API on JavaScript-ohjelmointirajapinta, joka mahdollistaa signaalinkäsittelyn

ja signaalien reitittämisen selainsovelluksissa. Web Audio API tarjoaa laajan valikoiman

erilaisia valmiiksi toteutettuja signaalinkäsittelykomponentteja, ja se myös tarjoaa raja-

pinnat omien signaalinkäsittelykomponenttien toteuttamiseen. Web Audio API on määri-

telty osana samaa Web API -standardia kuin WebRTC:n JavaScript-ohjelmointirajapin-

nat, ja se on myös suunniteltu toimimaan WebRTC-sovellusten kanssa [19].

Web Audio API:n keskeisiä käsitteitä ovat AudioContext ja AudioNode. AudioNode-raja-

pinta kuvaa yhtä solmua (sisääntulo, ulostulo tai signaalinkäsittelykomponentti) signaa-

liketjussa. AudioContext-rajapinta puolestaan koostuu AudioNode-objekteista ja kuvaa

koko signaaliketjua. Koska kaikki Web Audio API:n signaalinkäsittelykomponentit ilmen-

tävät AudioNode-rajapintaa, voidaan ne yhdistää vapaasti toisiinsa missä järjestyksessä

tahansa, jolloin signaalien reitittäminen on täysin modulaarista.

29

Koska JavaScript on luonteeltaan yksisäikeinen näkymän päivittämiseen tarkoitettu oh-

jelmointikieli, on tärkeää pyrkiä siihen, että raskaat signaalinprosessointitehtävät eivät

estäisi tai hidastaisi näiden toimintojen suorittamista. Tämän takia Web Audio API:n Au-

dioContext on suunniteltu toimimaan omassa säikeessään Worker-rajapintaa hyödyn-

täen.

Web Audio API:n integrointi WebRTC-sovellukseen on melko yksinkertaista. Sen Media-

StreamTrackAudioSourceNode-rajapinta mahdollistaa MediaStream-objektin, eli joko

käyttäjän multimedialaitteistosta Media Capture and Streams API:n avulla saadun ää-

nistriimin tai WebRTC-sovelluksen vastaanottaman äänistriimin muuttamisen Audi-

oNode-objektiksi [20]. MediaStreamTrackAudioDestinationNode-rajapinnan avulla Audi-

oNode-objekti voidaan muuttaa WebRTC:n MediaStream-objektiksi, jolloin sitä voidaan

käyttää WebRTC-sovelluksessa lähetettävänä äänistriiminä [21].

30

5 WebRTC:n signaalinkäsittelykomponenttien testaaminen

Yksinkertaisin tapa ymmärtää WebRTC:n signaalinkäsittelykomponenttien toimintaa ja

niiden toimivuutta erilaisissa sovelluksissa on ajaa erilaisia äänisignaaleja niiden läpi ja

tallentaa sekä sisään menevä että ulos tuleva signaali ja vertailla näiden eroavaisuuksia.

Koska oikeassa kaksisuuntaisessa kommunikaatiotilanteessa on useita ulkoisia tekijöitä

(esim. WebRTC:n ruuhkanhallintaominaisuus), jotka vaikuttavat vaihtelevasti vastaan-

otetun signaalin laatuun, toteutettiin signaalinkäsittelykomponenttien toiminnan testaa-

minen testiohjelman ja etukäteen muodostettujen testisignaalien avulla.

Testauksen tavoitteena oli pyrkiä muodostamaan selkeä kuva siitä, miten WebRTC:n

signaalinkäsittelykomponentit vaikuttavat ohjaajalta osallistujille lähetettävän äänen laa-

tuun. Sanoste Oy:n palveluiden äänenlaadun parantamisen kannalta tärkeintä oli selvit-

tää, miten eri signaalinkäsittelykomponentit käsittelevät puhetta, musiikkia tai näitä mo-

lempia sisältäviä signaaleja.

5.1 Testiohjelma

WebRTC:n lähdekoodi sisältää audioproc_f-testiohjelman, joka on tarkoitettu WebRTC:n

signaalinkäsittelyketjun testaamiseen. Se mahdollistaa mikrofonisignaalien ja vastaan-

otettujen signaalien simuloimisen äänitiedostojen avulla. Tällöin signaalinkäsittely-

komponenttien testaaminen voidaan suorittaa etukäteen muodostettujen testisignaalien

avulla.

WebRTC:n lähdekoodi sisältää myös signaalinkäsittelykomponenttien laadun arviointiin

(QA) tarkoitetun py_quality_assessment-ohjelmiston. py_quality_assessment-ohjel-

misto on periaatteessa Python-kääreohjelma audioproc_f-testiohjelmalle, joka tarjoaa

muutamia lisäominaisuuksia, kuten erilaisten akustisten olosuhteiden simuloimisen im-

pulssivasteiden avulla. Signaalinkäsittelykomponenttien testauksessa käytettävä tes-

tiohjelma toteutettiin tämän ohjelmiston pohjalta.

31

Koska py_quality_assessment-ohjelmisto on ensisijaisesti tarkoitettu laaturaporttien au-

tomatisoituun muodostamiseen, tuli sen toimintaan tehdä muutamia muokkauksia. Sig-

naalinkäsittelykomponenttien laadun mittaamiseen käytettävän maksullisen POLQA

(Perceptual Objective Listening Quality Analysis) -työkalun käyttö ohitettiin testiohjel-

massa täysin, koska tämä ei signaalinkäsittelykomponenttien toiminnan testaamisen

kannalta ollut oleellinen ominaisuus. Lisäksi py_quality_assessment-ohjelmisto salli ai-

noastaan yksikanavaisten wav-tiedostojen käyttöä, vaikka signaalinkäsittelykomponentit

kykenevät käsittelemään myös monikanavaista äänisignaalia. Jotta testauksessa kävisi

ilmi, vaikuttaako signaalinkäsittelykomponentti myös ulostulosignaalin kanavien mää-

rään, muokattiin py_quality_assessment-ohjelmistoa siten, että se kykeni syöttämään

signaalinkäsittelykomponenteille myös monikanavaista äänisignaalia.

5.2 Testisignaalien muodostaminen

Jotta kaikkien signaalinkäsittelykomponenttien toiminta voitiin testata riittävällä tasolla,

tuli testisignaalien muodostamisessa huomioida palvelutilanteen kaksisuuntaisuus, osal-

listujien lukumäärä sekä lähetettävien ja vastaanotettavien äänistriimien sisältö erilai-

sissa palvelutilanteissa.

Ohjaajan testisignaaleiksi muodostettiin sisällöltään kolme erilaista äänitiedostoa, joista

yksi sisälsi ainoastaan puhetta, toinen puhetta ja taustamusiikkia, ja kolmas laulua ja

taustamusiikkia. Näillä pyrittiin simuloimaan liikuntapalveluita sekä taustamusiikilla että

ilman sekä musiikkipalveluita, joissa ohjaaja laulaa säestyksen päälle. Koska myös lii-

kuntapalveluiden taustalla käytettävä musiikki sisältää usein laulua, jonka VAD-algoritmi

saattaa tulkita puheeksi, käytettiin liikuntapalveluiden taustamusiikkina musiikkikappa-

letta, joka sisältää sekä instrumentaaliosioita että laulua sisältäviä osioita.

Palveluiden kaksisuuntaisuuden huomioimiseksi testausta varten muodostettiin neljän

osallistujan äänistiimejä simuloivat äänitiedostot. Liikuntapalveluiden testaamisessa

käytettävät ääniraidat pyrittiin muodostamaan siten, että ne vastaisivat sisällöltään mah-

dollisimman hyvin osallistujien äänistriimejä oikeassa palvelutilanteessa, eli pääsääntöi-

sesti ne sisälsivät puhetta ainoastaan alku- ja lopputervehdyksen aikana, ja muutoin lä-

hinnä jumppaamisesta aiheutuvia ääniä. AEC-algoritmin DTD-komponentin testaa-

32

miseksi yksi äänitiedostoista ajoitettiin siten, että se sisältää yhtäaikaista puhetta ohjaa-

jan kanssa. Koska palvelun osallistujat ovat harvoin täysin meluttomassa tilassa, lisättiin

yhden osallistujan äänitiedostoon taustalla käytävän keskustelun ääniä. Musiikkipalve-

lun testaamista varten muodostettiin erilliset ääniraidat, jotka simuloivat yhteislaulutilan-

netta, jossa osallistujat laulavat ohjaajan esimerkin mukaisesti.

Ongelmallista kaksisuuntaisuuden testaamisessa oli, että oikeassa palvelutilanteessa

ohjaajalle saapuvat osallistujien äänistriimit on prosessoitu WebRTC:n signaalinkäsitte-

lyketjussa, jonka toimintaan puolestaan vaikuttaa ohjaajalta osallistujalle saapuva ää-

nistriimi. Jotta tätä pystyttiin simuloimaan edes jollain tasolla, ohjaajan äänitiedostot kä-

siteltiin ensin testiohjelman avulla ilman osallistujilta saapuvaa äänistriimiä, jonka jälkeen

osallistujien äänitiedostot käsiteltiin testiohjelman avulla käyttäen ohjaajan käsiteltyjä ää-

nitiedostoja osallistujalle saapuvana äänistriiminä. Näitä käsiteltyjä osallistujien äänitie-

dostoja käytettiin simuloimaan ohjaajalle saapuvaa äänistriimiä lopullisessa testauk-

sessa.

5.3 Testauksen tulokset

Koska äänenlaadun mittaamiseen ei ole olemassa mitään yksiselitteistä mittaria, arvioi-

tiin testiohjelman avulla muodostettuja ulostulosignaaleja sekä kuulonvaraisesti että ver-

tailemalla niiden aaltomuotoja alkuperäiseen sisääntulosignaaliin.

AEC

Kuulonvaraisesti arvoituna AEC onnistui poistamaan kaiun, eli ohjaajalle saapuvan ää-nistriimin, lähetetystä äänistriimistä tehokkaasti kaikista testisignaaleista. Kaikilla testi-

signaaleilla oli kuitenkin havaittavissa huomattavaa äänenlaadun heikkenemistä yhtäai-

kaisen puheen aikana. Etenkin silloin, kun testisignaali sisälsi musiikkia, ilmeni yhtäai-

kainen puhuminen lähetetyn äänistriimin pätkimisenä. Myös yhden osallistujan testisig-

naalissa esiintyvä taustalla käyty keskustelu häiritsi voimakkaasti AEC:n toimintaa.

Kuulonvaraisesti havaitut ongelmat näkyvät selvästi myös ulostulosignaalien aaltomuo-

doissa. Testisignaalissa, joka simuloi liikuntapalvelua, jossa käytetään taustamusiikkia,

voi selvästi nähdä ulostulosignaalin tason huomattavan alenemisen niissä kohdissa,

33

joissa osallistujat puhuivat samaa aikaa ohjaajan kanssa tai taustamusiikin päälle. Mu-

siikkipalvelua simuloivassa testauksessa, jossa osallistujilta ohjaajalle saapuva äänist-

riimi sisälsi osallistujien laulua, ongelma oli vielä selvemmin havaittavissa. Käytännössä

AEC lähes mykisti ohjaajan äänistriimin niissä kohdissa, joissa osallistujat lauloivat mu-

kana.

Tulosten perusteella voidaan sanoa, että AEC soveltuu heikosti käytettäväksi kaksisuun-

taisissa palveluissa, koska yhtäaikaista puhetta esiintyy vääjäämättä joko taustamelun

tai osallistujien puhumisen takia. Musiikkipalveluihin AEC ei sovellu lainkaan, sillä osal-

listujat eivät käytännössä kuule ohjaajan äänistriimiä lainkaan silloin, kun yksikin osallis-

tujista on äänessä.

NS

Pelkkää puhetta sisältävästä testisignaalista pystyi havaitsemaan, että NS-komponentti poisti hyvin ohjaajan mikrofonisignaalissa esiintyvää staattista kohinaa. Pelkkää puhetta

sisältävän testisignaalin kohdalla ei myöskään ollut havaittavissa merkittävää äänenlaa-

dun heikkenemistä.

Musiikkia sisältävien testisignaalien kohdalla oli havaittavissa musiikin tason alenemista

etenkin musiikkikappaleen instrumentaaliosioissa. Musiikkia sisältävien testisignaalien

tapauksessa merkillepantavaa oli myös ylätaajuuksien ajoittainen vaimeneminen sekä

laulun äänentason voimistuminen suhteessa taustamusiikkiin.

Vaikka äänenlaadussa ei ollut havaittavissa vakavaa heikkenemistä millään testisignaa-lilla, ei NS-komponentin käyttö ole kuitenkaan järkevää musiikkia sisältävien äänisignaa-

lien kohdalla, sillä taustamusiikin äänentason aleneminen suhteessa lauluun tai puhee-

seen ei ole useinkaan toivottua, ja vaimenemisen määrä on myös melko vaihtelevaa

musiikin sisällöstä riippuen. Pelkkää puhetta sisältäville signaaleille NS-komponentti kui-

tenkin toimi hyvin, jolloin sillä myös oli äänenlaatua parantava vaikutus.

AGC

34

AGC-komponentti vaikutti toimivan hyvin puheen äänenvoimakkuuden vaihteluiden ta-saamisessa kaikilla testisignaaleilla sekä kuulonvaraisesti että ulostulosignaalien aalto-

muotojen tarkastelun perusteella arvioutuna. Musiikkipalvelua simuloivan testisignaalin

äänenvoimakkuuteen AGC:llä oli kuitenkin melko arvaamaton vaikutus, joka ilmeni sat-

tumanvaraiselta vaikuttavana musiikin tason alenemisena.

Testisignaalilla, joka sisälsi ohjaajan puhetta ja taustamusiikkia AGC:n toiminta ei ollut

muutoin häiritsevää, mutta ulostulosignaalin loppupuolella oli kuitenkin havaittavissa

melko voimakas taustamusiikin äänentason voimistuminen sen jälkeen, kun ohjaajan oli

ollut puhumatta noin 30 sekuntia. Tämä oli myös selvästi nähtävissä ulostulosignaalin

aaltomuotoa tarkasteltaessa.

Pelkkää puhetta sisältävälle testisignaalille AGC-komponentilla oli selvästi äänenlaatua

parantava vaikutus. Musiikkia sisältävien testisignaalien kohdalla AGC:n vaikutusta ää-

nenlaatuun voidaan kuitenkin pitää heikentävänä, sillä se aiheutti musiikkiin hallitsema-

tonta äänentason vaihtelua.

35

6 Äänten miksaaminen Sanoste Oy:n sovelluksessa

Tämän työn tavoitteena oli myös selvittää mahdollisuuksia helppokäyttöisen mikseriso-

velluksen toteuttamiseen osaksi Sanoste Oy:n WebRTC-teknologiaan perustuvaa kuva-

puhelusovellusta. Mikserisovelluksen vaatimien teknologioiden ja teknisten ratkaisujen

testaamiseksi myös käytännössä työn yhteydessä toteutettiin prototyyppi mikserisovel-

luksesta, joka toteuttaa mikserisovellukselta vaaditut toiminnallisuudet.

Tässä luvussa käsitellään mikserisovellukselta vaaditut toiminnallisuudet ja niiden mah-

dolliset toteutustavat Web Audio API:n avulla. Luvun lopussa käydään läpi mikserisovel-

lukselta vaadittujen toimintojen testaaminen prototyyppisovelluksen avulla.

6.1 Mikserisovelluksen vaatimukset

Mikserisovelluksen suunnittelussa huomioon otettavista vaatimuksista tärkeimpiä oli sen

helppokäyttöisyys ja sen integroituminen palveluntuottajan kuvapuhesovellukseen. Käy-

tännössä tämä tarkoitti, että miksaamiseen liittyvien toimintojen, kuten äänentasojen hal-

linnan ja äänilähteiden reititysten, tulisi olla mahdollisimman pitkälle automatisoituja, ja

toteutuksessa käytettävien teknologioiden tulisi toimia selaimessa sekä olla integroita-

vissa WebRTC:n Media Capture and Streams API:n kanssa.

Suunnittelussa tuli lisäksi huomioida, että mikserisovellus ei saa haitata kuvapuheluso-

velluksen muuta toimintaa, eikä sen toiminta saa vaikuttaa havaittavissa olevalla tavalla

kuvan ja äänen synkronointiin. Toteutustavan tuli siis olla sellainen, että signaalinkäsit-

tely suoritetaan mahdollisuuksien mukaan näkymää päivittävän säikeen ulkopuolella. Mi-

käli signaalinkäsittely aiheuttaa mikrofonisignaaliin havaittavissa olevaa viivettä, tulisi ku-

van ja äänen olla uudelleen synkronoitavissa.

Liikuntapalveluissa, joissa käytetään taustamusiikkia, on tärkeää varmistaa puheen kuu-

luvuus musiikin yli. Tämän takia mikserisovelluksen tulisi sisältää talkover-toiminto, joka

laskee musiikin äänentasoa automaattisesti ohjaajan puhuessa. Myös äänen kierron eh-

käiseminen ja äänenlaatu tuli huomioida sekä äänimikserisovelluksessa että laitepuolen

ratkaisuissa.

36

6.2 Mikserisovelluksen teknologiat ja integrointi

Koska Sanoste Oy:n palveluntuottajan kuvapuhelusovellus toimii selaimessa, oli mikse-

risovelluksen toteuttamiseen luontevin vaihtoehto Web Audio API, sillä se on suunniteltu

toimimaan yhdessä WebRTC:n Media Capture and Streams API:n kanssa. Web Audio

API:n signaalinkäsittely tapahtuu AudioWorkerin ansiosta erillisessä säikeessä, jolloin

paljon laskenta-aikaa vaativat signaalinkäsittelyoperaatiot eivät estä näkymän päivitty-

mistä.

Signaalinkäsittelyn suorittaminen erillisessä säikeessä auttaa myös signaalinkäsittelystä

aiheutuvien viiveiden hallinnassa. Mikserisovelluksien vaatimien signaalinkäsittelyope-

raatioiden ei pitäisi aiheuttaa kovinkaan suuria viiveitä äänisignaaliin, mutta mikäli kuvan

ja äänen välille pääsee syntymään havaittavissa oleva synkronointivirhe, voidaan kuvaa

tarvittaessa puskuroida Canvas API:n avulla ja striimata viiveellä Media Capture and

Streams API:n CanvasCaptureMediaStreamTrack-rajapintaa hyödyntäen.

Jotta mikserisovellus olisi integroitavissa palveluntuottajan sovellukseen sen käyttöliitty-

män toteutustavasta riippumatta, mikserisovelluksen ei tulisi toteuttaa mitään käyttöliit-

tymäkomponentteja, vaan ainoastaan tarjota niiden toteuttamiseen vaaditut rajapinnat.

Tämän avulla voidaan varmistaa, että palveluntuottajan sovelluksen käyttöliittymän ul-

koasun muuttaminen ei vaadi muutoksia mikserisovellukseen.

Käyttöliittymäkomponenttien toteutukseen vaadittavien toimintojen mahdollistamiseksi

mikserisovelluksen tulisi tarjota rajapinnat ainakin seuraaviin toimintoihin:

• saatavilla olevien äänilähteiden listaus

• kanavan äänilähteen haku ja muokkaus

• kanavan äänentason haku ja muokkaus

• reaaliaikainen kanavan amplitudin huippu- ja RMS-arvojen haku

• kanavan signaalinkäsittelykomponenttien kytkentä päälle/pois.

Näiden avulla mahdollistetaan muun muassa seuraavat toiminnot:

• sisääntulokanavan äänilähteen valinta

• kanavan äänentason säätö

• kanavan äänentason näyttö (VU-mittari)

37

• signaalinkäsittelykomponenttien valinta.

Mikäli mikserisovelluksen toteuttamisessa ilmenee, että kuva- ja ääni täytyy synkronoida

uudelleen, voidaan synkronointi suorittaa joko mikserisovelluksessa tai palveluntuottajan

sovelluksessa. Mikäli synkronointi toteutetaan palveluntuottajan sovelluksessa, tulee

mikserisovelluksen tarjota rajapinta sen signaalinkäsittelyn aiheuttaman viiveen selvittä-

miseksi. Jos synkronointi suoritetaan mikserisovelluksessa, tulee mikserisovelluksen

sallia kuvan renderöintiin käytettävän käyttöliittymäkomponentin määrittäminen esimer-

kiksi mikserisovelluksen alustamisen yhteydessä.

6.3 Laitekokoonpanot ja signaalin esikäsittely

Koska äänimikserisovelluksen avulla pyritään pääsemään eroon monimutkaisista ja hin-

tavista laitekokoonpanoista, tulisi laitepuolen vaatimusten olla mahdollisimman kevyet.

Äänenlaadun kannalta olisi kuitenkin suotavaa, että palvelun toteuttamiseen käytetään

jotain muuta laitteistoa kuin tietokoneen sisäänrakennettua mikrofonia ja kaiutinta.

Parhaan äänenlaadun saavuttamiseksi olisi suotavaa, että palvelun ohjaaja käyttäisi

kuulokkeita ja suun lähelle sijoitettavaa mikrofonia. Kuulokkeiden käytöllä voidaan täysin

eliminoida äänen kierto ohjaajan ja osallistujien välillä, jolloin WebRTC:n AEC-kompo-

nentti voidaan huoletta kytkeä pois päältä ohjaajan osalta. Liikuntapalveluiden osalta tu-

lee ottaa huomioon, että ohjaajan tulee voida liikkua vapaasti, jolloin sisäänrakennetulla

mikrofonilla varustetut langattomat kuulokkeet ovat todennäköisesti paras vaihtoehto.

Tällöin laitteet eivät haittaa ohjaajan liikkumista ja mikrofoni sijoittuu riittävän lähelle oh-

jaajan suuta.

Palveluissa, joiden sisältö koostuu pääasiassa musiikista, saattaa olla tarpeen käyttää

kuulokkeiden sisäänrakennettua mikrofonia laadukkaampaa ja vapaammin sijoiteltavaa

mikrofonia. Tällöin esimerkiksi USB-väylään liitettävä kondensaattorimikrofoni on hyvä

vaihtoehto. Toinen vaihtoehto on käyttää pientä USB-väylään liitettävää ulkoista mikse-

riä, johon voidaan kytkeä mikrofonin lisäksi myös sähköisiä instrumentteja (esim. sähkö-

piano) tai lisämikrofoneja.

38

Mikäli palvelussa käytetään taustamusiikkia, tarvitaan jokin väylä, jota pitkin musiikkisoit-

timen (yleensä älypuhelin) ulostulosignaali voidaan siirtää tietokoneelle. Joissain tieto-

koneissa saattaa olla valmiina 3,5 mm:n sisääntuloliitäntä, johon puhelimen ulostulo voi-

daan liittää. Mikäli tällaista liitäntää tietokoneesta ei löydy, voidaan tietokoneeseen mu-

siikkisoittimen väliin hankkia ulkoinen USB-väylään liitettävä AD-muunnin. Kun musiikki

syötetään mikserisovellukseen erillisen äänilähteen kautta, voidaan kaikki WebRTC:n

signaalinkäsittelykomponentit kytkeä pois käytöstä musiikkiraidan osalta musiikin äänen-

laadun parantamiseksi.

6.4 Äänilähteet ja niiden hallinta

Koska mikserisovelluksessa ei voida luotettavasti päätellä, mitä laitetta ohjaaja käyttää

musiikkikanavan lähteenä, tulisi mikserisovelluksen kerätä laitteiden tiedot ja tarjota

käyttäjälle valikko äänilähteen valitsemiseksi. Mikrofonikanavan osalta voidaan oletus-

arvoisesti käyttää käyttäjän selaimen oletuslaitetta, mutta myös mikrofonikanavan osalta

voi olla järkevää tarjota mahdollisuus vaihtaa laitetta sen varalta, että selaimen oletus-

laite on asetettu väärin.

Käyttäjän laitteiden tiedot voidaan hakea WebRTC:n Media Capture and Streams API:n

MediaDevices-rajapinnan enumerateDevices()-metodin avulla. Metodi palauttaa listan

MediaDeviceInfo-objekteja, jotka sisältävät oleellisia tietoja käytettävissä olevista multi-

medialaitteista, kuten tiedon siitä, onko laite ääni- vai kuvalaite, sekä laitetunnisteen ja

laitteen selkokielisen nimen.

navigator.mediaDevices.enumerateDevices() .then(function(devices) { devices.forEach(function(device) { if (device.kind == "audioinput") { audioSources.push(device); } else if (device.kind == "audiooutput") { audioDestinations.push(device); } else if (device.kind == "videoinput") { videoSources.push(device); } }); }) .catch(function(err) { /* handle error */ })

Esimerkkikoodi 1. Esimerkki enumerateDevices()-metodin käytöstä mikserisovelluksen alus-tuksessa.

39

Mikserisovelluksessa MediaDevice-objektien tiedot voidaan tallentaa taulukoihin niiden

tyypin, eli kind-parametrin mukaan (ks. esimerkkikoodi 1). Tällöin käyttäjälle voidaan laa-

tia valikko saatavilla olevista äänilähteistä. Näitä tietoja myös tarvitaan myöhemmin strii-

mien alustuksen yhteydessä.

6.5 Striimien alustaminen

Jotta äänilähteiden tuottamiin striimeihin päästään käsiksi mikserisovelluksessa, tulee

niitä kutsua MediaDevices-rajapinnan getUserMedia()-metodin avulla. Tietoturvasyistä

laitteiden käytön ehtona on, että käyttäjä on sallinut laitteiden käytön kyseiselle verkko-

osoitteelle.

Multimedialaitteiden käyttöluvan kysyminen on sisäänrakennettu getUserMedia()-meto-

din toteutukseen. Metodi tarkistaa kutsun yhteydessä, onko selaimen käyttäjä sallinut

multimedialaitteiden kyseiselle verkko-osoitteelle. Mikäli käyttäjä on sallinut laitteiden

käytön, metodi palauttaa MediaStream-objektin, joka edustaa kutsutun laitteen tuotta-

maa striimiä. Mikäli käyttäjä ei salli laitteiden käyttöä, metodi palauttaa NotAllowedError-

virheen.

navigator.mediaDevices.getUserMedia(constraints) .then(function(stream) { if (audioMixer.channels[n].source) { audioMixer.channels[n].source.mediaStream.getTracks() .forEach(track => track.stop()); } audioMixer.channels[n].source = audioContext.createMediaStreamSource(stream); }) .catch(function(err) { /* handle error */ });

Esimerkkikoodi 2. Esimerkki striimin alustamisesta mikserisovelluksessa.

Striimin alustuksen yhteydessä striimistä voidaan luoda Web Audio API:n MediaStream-

SourceNode-objekteja, joita voidaan käyttää mikserisovelluksen kanavien lähteinä (ks.

esimerkkikoodi 2). Striimien alustaminen kannattaa toteuttaa dynaamisesti äänilähteen

valinnan yhteydessä tarpeettomien striimien luonnin välttämiseksi. Kun striimiä ei enää

tarvita, tulisi sen lähteenä toimiva laite vapauttaa kutsumalla striimin sisältämien Media-

StreamTrack-objektien stop()-metodia.

40

6.6 Multimedialaitteiden valinta ja asetukset

getUserMedia()-metodille voidaan antaa parametrina MediaStreamConstraints-objekti,

jossa voidaan määrittää erilaisia ehtoja MediaStream-objektin alustukselle, kuten se,

halutaanko MediaStream-objektin sisältävän vain ääni- tai kuvastriimin vai molemmat.

Lähtökohtaisesti getUserMedia()-metodi palauttaa selaimen asetuksissa määritettyjen

oletuslaitteiden striimit, mutta MediaStreamConstraints-objektissa voidaan myös viitata

tiettyyn laitteeseen enumerateDevices()-metodin palauttaman laitetunnisteen avulla.

const constraints = { audio: { deviceId: deviceId, echoCancellation: false, noiseSuppression: false, autoGainControl: false, sampleRate: 48000, sampleSize: 16, channelCount: 2 } };

Esimerkkikoodi 3. Esimerkki MediaStreamConstraints-objektin määrittelystä musiikkia sisältä-välle striimille.

MediaStreamConstraints-objektissa voidaan myös määrittää muita asetuksia, kuten

näytteenottotaajuus, sananpituus, kanavien lukumäärä ja vaadittavat signaalinkäsittely-

komponentit. Näiden avulla voidaan esimerkiksi kytkeä AEC-, NS- ja AGC-signaalinkä-

sittelykomponentit pois käytöstä musiikkia sisältävien striimien osalta (ks. esimerkkikoodi

3).

Mikrofonikanavan kohdalla ainakin AGC-komponentti kannattaa jättää päälle. Tällöin

varmistetaan, että mikrofonin signaali on koko ajan optimaalisella tasolla ja samalla eh-

käistään signaalin säröytymistä. Valitettavasti kaikki selaimet eivät tue AGC-komponen-

tin käytön määrittämistä erikseen, vaan se kytkeytyy päälle tai pois AEC-komponentin

mukana. Selaimen tukemat asetukset voidaan tarkistaa MediaDevices-rajapinnan get-

SupportedConstraints()-metodin avulla.

41

6.7 Äänentasojen analysointi ja hallinta

Mikserisovelluksen äänentasojen analysointi ja hallinta voidaan toteuttaa Web Audio

API:n AnalyserNode- ja GainNode-rajapintojen avulla. Web Audio API tarjoaa myös Dy-

namicCompressorNode-rajapinnan, jonka avulla voidaan rajoittaa signaalin dynaamiik-

kaa, eli signaalin amplitudin vaihteluita.

AnalyserNode-rajapinta mahdollistaa signaalin reaaliaikaisen amplitudi- ja taajuusinfor-

maation tarkkailun. AnalyserNode-rajapinnan getFloatTimeDomainData()-metodin

avulla saadaan haettua tarkkailtavana olevan signaalin näytteiden arvot välille -1 ja 1

normalisoituina liukulukuina, jotka edustavat näytteiden arvoja aika-alueella. Jokainen

arvo siis kuvaa signaalin amplitudia tietyllä ajanhetkellä. Signaalin amplitudin huippuarvo

on getFloatTimeDomainData()-metodin palauttamien näytteiden itseisarvojen suurin

luku. RMS-arvo voidaan selvittää ottamalla neliöjuuri näytteiden neliöiden keskiarvosta.

Signaalin amplitudiarvoja voidaan hyödyntää äänentasojen mittaroinissa tai äänenta-

sojen automatisoinnissa.

Web Audio API:n GainNode-rajapinnan avulla voidaan hallita sille syötetyn striimin ää-

nentasoa. Sen gain-parametrin voi ajatella olevan kuin liukukytkin mikserissä, jonka nol-

lataso (0 dBFS) on arvossa 1 ja minimitaso (-¥ dBFS) arvossa 0. Koska ohjattavan ka-

navan äänentason muuttaminen äkisti arvosta toiseen kuulostaisi epämiellyttävältä ja

epäluonnolliselta, tulisi kanavan äänentasoa laskea asteittain. GainNode-rajapinnan

gain-parametri toteuttaa AudioParam-rajapinnan, jonka linearRampToValueAtTime()- tai

exponentialRampToValueAtTime()-metodien avulla voidaan automatisoida GainNoden

ulostulon siirtyminen haluttuun tasoon määriteltävissä olevan ajanjakson aikana. Gain-

Node-rajapintaa voidaan käyttää äänentasojen hallintaan sekä mikserisovelluksen että

käyttöliittymän puolella.

Ulostulokanavissa signaalin huipputehon rajoittaminen voi olla tarpeen, sillä signaalien

summaaminen voi potentiaalisesti aiheuttaa kanttiaallon muodostumista, eli havaitta-

vissa olevaa äänen säröytymistä, mikäli summatun signaalin huipputeho nousee yli ar-

von 1. DynamicCompressorNode-rajapinta soveltuu hyvin tämän ehkäisemiseen, sillä

sen knee-parametrin avulla voidaan hallita signaalin vaimennuksen määrää, kun signaa-

lin amplitudi lähestyy vaimennukselle asetettua raja-arvoa. Tällöin signaalin dynaamista

42

aluetta voidaan kaventaa hallitusti asteittain sen sijaan, että signaalin huiput leikkaantui-

sivat äkisti aiheuttaen kanttiaallon muodostumista. Jotta signaalia vaimennetaan vain

lähellä dynaamisen alueen ylärajaa, tulisi vaimennuksen raja-arvo (threshold-parametri)

asettaa lähelle tasoa 0 dBFS ja vaimennuksen kerroin (ratio-parametri) mahdollisimman

korkeaksi.

6.8 Talkover-toiminto

Äänitekniikassa talkover-toiminto tarkoittaa sitä, että muiden kanavien äänentasoa las-

ketaan automaattisesti mikrofonikanavan ollessa aktiivinen. Tämän avulla varmistetaan

puheen kuuluvuus muiden äänilähteiden yli. Etenkin tilanteessa, jossa ohjaaja antaa oh-

jeita osallistujille, on tärkeää, että ohjaajan ääni kuuluu selvästi musiikin yli.

Joskus talkover-toiminto sekoitetaan sidechain-kompressointiin, jossa toisen kanavan

ulostulo ohjaa toiseen kanavaan vaikuttavaa kompressoripiiriä. Tämä kuitenkin eroaa

talkover-toiminnosta siten, että ohjaavan kanavan äänenvoimakkuus vaikuttaa ohjatta-

vana olevan kanavan dynamiikkaan. Talkover-toiminnon tarkoituksena puolestaan on

ainoastaan vaikuttaa toisten kanavien äänenvoimakkuuksiin muuttamatta näiden dyna-

miikkaa. Varsinkin musiikkia sisältävää signaalia käsiteltäessä, jonka dynaamista aluetta

on saatettu jo valmiiksi kaventaa rajusti alkuperäisen äänitteen masterointivaiheessa, on

tärkeää varmistaa, että äänistriimin dynaamista aluetta ei kavenneta entisestään, sillä

pahimmillaan tämä voi johtaa äänen säröytymiseen.

Edellä mainituista syistä johtuen mikserisovelluksen talkover-toiminnon toteutuksessa ei

kannata käyttää DynamicCompressorNode-rajapintaa, vaan se tulisi mieluummin toteut-

taa AnalyserNode- ja GainNode-rajapintoja hyödyntäen. Näiden avulla talkover-toiminto

voidaan toteuttaa siten, että mikrofonikanavan ollessa aktiivinen, muiden kanavien ää-

nentaso lasketaan tietylle tasolle ilman, että vaikutetaan signaalien dynamiikkaan.

Mikrofonikanavan aktiivisuuden tunnistamisen toteuttaminen olisi helppoa, mikäli mikse-

risovellus pääsisi käsiksi WebRTC:n VAD-algoritmin palauttamiin arvoihin. Tämä ei kui-

tenkaan ole mahdollista, sillä WebRTC ei tarjoa tällaista JavaScript-rajapintaa. Mikäli

mikrofonikanavassa on käytössä automaattinen äänentason hallinta, voidaan puheaktii-

visuuden tunnistamisessa hyödyntää tietoa siitä, että WebRTC-standardin määrittelemä

43

tavoitetaso mikrofonisignaalille on noin -22 dBFS. Puheaktiivisuuden voidaan siis tulkita

alkaneeksi, kun mikrofonikanavan amplitudi ylittää -22 dBFS:n raja-arvon, ja päätty-

neeksi, kun amplitudi laskee sen alle. Toisaalta, jos melunpoisto on käytössä, voidaan

olla melko varmoja siitä, että kun signaalin amplitudi ylittää -22 dBFS:n raja-arvon, on

kyse puheesta eikä taustakohinasta.

Koska puheen amplitudi vaihtelee paljon puheessa esiintyvien taukojen takia, voi talko-

ver-komponenttiin olla tarpeen toteuttaa jonkinlainen hystereesi, eli ominaisuus, jonka

avulla voidaan asettaa puheaktiivisuuden päättymiselle erilaiset ehdot kuin puheaktiivi-

suuden alkamiselle.

Käytännössä hystereesi voidaan toteuttaa puheaktiivisuuden tunnistamisessa saatujen

arvojen puskuroinnin avulla. Tällöin puheaktiivisuus voidaan tulkita päättyneeksi, kun pu-

heaktiivisuutta ei ole havaittu jonkin ajanjakson aikana. Tällä voidaan melko tehokkaasti

ehkäistä puheessa esiintyvien taukojen tulkitsemista puheaktiivisuuden päättymiseksi.

Puheaktiivisuuden päättymisen tunnistamiselle voidaan tarvittaessa myös määrittää al-

haisempi amplitudin raja-arvo.

Puheaktiivisuus arvojen puskuroinnin lisäksi ohjattavien kanavien äänentason palaami-

nen alkuperäiselle tasolleen kannattaa asettaa tapahtumaan riittävän hitaasti, mikä voi

myös osaltaan auttaa vähentämään havaittavissa olevia äänentason muutoksia puheen

aikana.

Jos talkover-toiminnon ohjaama kanava on esimerkiksi taustamusiikkia, voi olla jopa toi-

vottavaa, että sen äänentaso ei palaa alkuperäiselle tasolleen välittömästi puheen pää-

tyttyä. Tällöin hystereesin raja-arvot voidaan huoletta asettaa melko alhaisiksi ja pusku-

roinnin aika riittävän pitkäksi, jotta varmistutaan siitä, että puheaktiivisuus on oikeasti

päättynyt.

6.9 Striimien reitittäminen ja miksaaminen

Äänilähteiden striimien miksaaminen tapahtuu reitittämällä ne haluttuihin ulostuloihin.

Toisin sanoen mikserisovelluksen sisääntulokanavien ulostulot tulee yhdistää haluttuihin

44

ulostulokanaviin. Mikserisovelluksen käyttäjän, eli ohjaajan laitteiston valittua ulostulolai-

tetta edustaa Web Audio API:n AudioContext-rajapinnan destination-parametri, eli kaikki

sisääntulokanavat, jotka halutaan reitittää ohjaajan kuunteluun, tulee yhdistää tähän.

Sisääntulokanavien ulostulojen reitittämiseen osallistujille voidaan hyödyntää Web Au-

dio API:n MediaStreamDestinationNode-rajapintaa. MediaStreamDestinationNode-raja-

pinta toimii muuten samaan tapaan, kuin AudioDestinationNode-rajapinta, mutta sillä

erotuksella, että sen ulostulona on striimi, jota voidaan käyttää WebRTC-yhteyden ää-

nistriiminä. MediaStreamDestinationNode-objekti luodaan kutsumalla AudioContext-ra-

japinnan createMediaStreamDestination()-metodia. Liittämällä sisääntulokanavien ulos-

tulot luotuun MediaStreamDestinationNode-objektiin, voidaan eri sisääntulotulokanavat

summata yhdeksi striimiksi, joka voidaan välittää WebRTC-yhteyden yli osallistujille.

Tarvittaessa reititykset voidaan toteuttaa dynaamisesti lisäämällä käyttöliittymään si-

sääntulokanavien yhteyteen mahdollisuus valita sisääntulokanavan ulostulokanavat. Tä-

män avulla ohjaaja voi esimerkiksi valita, haluaako hän kuulla oman äänensä palvelun

aikana. Osallistujilta saapuvien äänistriimit ohjautuvat automaattisesti käyttäjän valittuun

ulostulolaitteeseen, joten niiden reitittämisestä ei tarvitse erikseen huolehtia mikseriso-

velluksessa.

6.10 Asetusten tallentaminen

Jotta käyttäjän valitsemat äänilähteet ja mahdolliset muut mikserisovelluksen asetukset

säilyisivät eri sivujen välillä navigoidessa tai sivun uudelleenlatauksen yli, tulee asetukset

tallentaa jonnekin sellaisessa muodossa, että mikserisovellus voidaan alustaa niiden

avulla siihen tilaan, jossa se oli aiemmin. Mahdollisia paikkoja asetusten tallentamiseen

ovat

• sovelluksen tietokanta

• käyttäjän istunto (cookie)

• Web Storage API (sessionStorage tai localStorage).

Asetusten tallentaminen sovelluksen tietokantaan ei todennäköisesti ole mielekästä, sillä

ensinnäkin se vaatisi tietokantaan uuden taulun, joka vaatisi muutoksia joka kerta, kun

45

mikserisovelluksen tallennettaviin asetuksiin tehdään muutoksia. Toisekseen mikseriso-

velluksen asetukset ovat hyvin pitkälti sidottu käyttäjän sen hetkiseen laitekokoonpa-

noon, joten samojen asetusten käyttö käyttäjän muissa mahdollisissa laitekokoonpa-

noissa ei ole perusteltua. Asetusten tallentaminen käyttäjän istuntoon on myös kyseen-

alaista, sillä asetukset pyyhkiytyisivät muistista heti, kun käyttäjän istunto vanhenee tai

käyttäjä kirjautuu ulos sovelluksesta. Asetusten tallentaminen tietokantaan tai käyttäjän

istuntoon edellyttäisivät myös tietojen lähettämistä taustajärjestelmään.

Edellä mainituista syistä johtuen järkevin paikka mikserisovelluksen asetusten tallenta-

miseen on selaimen oma tallennustila, eli Web Storage API:n sessionStorage tai localS-

torage. Näistä kahdesta localStorage on todennäköisesti parempi vaihtoehto, sillä ase-

tukset säilyvät tällöin muistissa, vaikka käyttäjä vahingossa sulkisi sovelluksen välileh-

den. Web Storage API:n käytön etuna on myös se, että asetusten tallentaminen voidaan

toteuttaa suoraan mikserisovellukseen, mikä tekee mikserisovelluksen integroinnista ja

jatkokehityksestä yksinkertaisempaa.

Jotta varmistetaan, että mikserisovelluksen asetukset tallentuvat esimerkiksi sivun uu-

delleenlatauksen yhteydessä, voidaan mikserisovellukseen toteuttaa asetusten auto-

maattinen tallennus window-objektin beforeunload-tapahtuman yhteydessä. Palvelin-

puolen renderöintiin perustuvassa sovelluksessa tämä todennäköisesti riittää asetusten

tallentamiseen kaikissa tilanteissa, sillä jokainen navigointitapahtuma aiheuttaa uuden

sivun lataamisen, joka puolestaan laukaisee beforeunload-tapahtuman. Asiakaspuolen

renderöintiin perustuvassa yhden sivun sovelluksessa (SPA) asia ei kuitenkaan ole ihan

näin yksinkertainen, sillä näkymien välillä navigointi ei aiheuta uuden sivun lataamista,

jolloin se ei myöskään laukaise beforeunload-tapahtumaa. Muistinkäytön hallitsemiseksi

mikserisovelluksen instanssi halutaan todennäköisesti alustaa vain niissä näkymissä,

joissa sitä tarvitaan, ja tuhota, kun näkymästä poistutaan. Tämän takia mikserisovelluk-

sen tulisi tarjota rajapinta, esimerkiksi save()-metodi, jota kutsumalla asetukset voidaan

tallentaa milloin tahansa.

"settings": { "inputs": [ { "label": "Microphone", "source": "default", "gain": 1.0, "constraints": { "echoCancellation": false, "noiseSuppression": false,

46

"autoGainControl": true, "sampleRate": 48000, "sampleSize": 16, "channelCount": 2 } }, { "label": "Music", "source": null, "gain": 1.0, "constraints": { "echoCancellation": false, "noiseSuppression": false, "autoGainControl": false, "sampleRate": 48000, "sampleSize": 16, "channelCount": 2 } } ], "outputs": [ { "label": "Main", "type": "stream", "gain": 1.0 }, { "label": "Cue", "type": "speaker", "gain": 1.0 } ], "connections": [ {"input": 0, "output": 0}, {"input": 1, "output": 0}, {"input": 1, "output": 1} ], "attenuators": [ {"source": 0, "target": 1} ] }

Esimerkkikoodi 4. Mikserisovelluksen asetusten esittäminen JSON-formaatissa.

Yksinkertaisin formaatti mikserisovelluksen asetusten tallentamiseen on JSON-for-

maatti, sillä se on helposti luettavissa ja muunnettavissa JSON-objektiksi mikserisovel-

luksessa. Jotta mikserisovellus voidaan alustaa aiempaan tilaan, tulisi asetusten sisältää

ainakin tiedot sisään- ja ulostulokanavien asetuksista, näiden välisistä reitityksistä ja

muiden komponenttien, kuten talkover-komponentin, kytkennöistä (ks. esimerkkikoodi

4).

47

6.11 Mikserisovelluksen toimintojen testaaminen

Mikserisovelluksen suunnittelun yhteydessä mikserisovelluksesta kehitettiin yksinkertai-

nen prototyyppisovellus, jonka avulla voitiin testata, että äänilähteiden miksaamiseen ja

äänentasojen automatisointiin esitetyt ratkaisut sekä niiden toteuttamisessa käytettävät

rajapinnat toimivat myös käytännössä niin kuin niiden oli ajateltu toimivan. Testauksessa

käytetty laitteisto koostui kannettavasta tietokoneesta, langallisista integroidulla mikrofo-

nilla varustetuista kuulokkeista ja USB-väylään liitettävästä kaksikanavaisesta äänikor-

tista, johon oli liitetty älypuhelin, joka toimi musiikkisoittimena.

Prototyyppisovelluksen signaalinketju koostui kahdesta sisääntulokanavasta ja kah-

desta ulostulokanavasta sekä musiikkikanavan äänenvoimakkuutta ohjaavasta talkover-

komponentista. Toinen sisääntulokanavista oli tarkoitettu mikrofonisignaalille ja toinen

taustamusiikille. WebRTC:n signaalinkäsittelykomponenttien testauksessa saatujen tu-

losten perusteella, kaikki signaalinkäsittelykomponentit kytkettiin pois päältä musiikkika-

navan osalta. Mikrofonikanavan kohdalla kokeiltiin kaikkien signaalinkäsittelykompo-

nenttien toimintaa, mutta paras äänenlaatu saavutettiin, kun päälle jätettiin ainoastaan

AGC-komponentti. Toinen ulostulokanavista reititettiin ohjaajan kuulokkeisiin AudioDes-

tinationNode-rajapinnan avulla. Toinen puolestaan muunnettiin MediaStreamDestinati-

onNode-rajapinnan avulla osallistujille lähetettäväksi äänistriimiksi. Sovellukseen toteu-

tettiin myös rajapinta ulostuloäänistriimin saamiseksi, jonka avulla sen toimintaa kyettiin

testaamaan Sanoste Oy:n ohjaajan kuvapuhelusovelluksessa. Samalla tuli myös var-

mistettua, että ohjaajan kuvapuhelusovelluksessa käytetty OpenTok-kirjasto tarjoaa ra-

japinnan, joka mahdollistaa istunnossa käytettävän äänistriimin asettamisen.

Sovellukseen toteutettiin myös yksinkertainen käyttöliittymä, joka sisälsi vain testauksen

kannalta oleellisimmat käyttöliittymäkomponentit, eli mikrofoni- ja musiikkikanavien ää-

nilähteiden valitsimet ja äänentasomittarit molemmille ulostulokanaville. Lisäksi proto-

tyyppiin toteutettiin rajapinnat käyttöliittymäkomponenttien renderöintiä varten, jotta ne

saatiin näkyviin ohjaajan kuvapuhelusovelluksessa testattaessa. Sovellukseen toteutet-

tiin myös mikserin asetusten tallentaminen JSON-formaatissa selaimen localStorage-

tallennustilaan sekä mikserin alustaminen tallennettujen tietojen perusteella. Tällöin

mikseriasetukset voitiin asettaa ohjaajan kuvapuhelusovelluksen esikatselunäkymässä

ja lukea ne muistista mikserisovelluksen alustuksen yhteydessä varsinaiseen palvelun-

toteutusnäkymään siirryttäessä.

48

Talkover-toiminnon testaamiseksi prototyyppisovellukseen toteutettiin yksikertainen al-

goritmi, joka sääteli musiikkikanavan ulostuloa edustavan GainNode-objektin gain-para-

metrin arvoa puheaktiivisuuden, eli mikrofonikanavaan kytketyn AnalyserNode-objektin

puskurista laskettujen RMS-arvojen perusteella. Algoritmi tulkitsi puheaktiivisuuden al-

kaneeksi silloin, kun mikrofonisignaalin RMS-arvo ylitti -22 dBFS:ää. Puheaktiivisuuden

algoritmi tulkitsi päättyneeksi vasta, kun mikrofonisignaalin RMS-arvo oli pysynyt -28

dBFS:n alapuolella 500 millisekunnin ajan. Talkover-toiminnon testauksessa kokeiltiin

myös muita raja-arvoja, mutta edellä mainitut arvot vaikuttivat toimivan parhaiten silloin,

kun WebRTC:n AGC-komponentti oli kytketty päälle mikrofonikanavan osalta.

Puheaktiivisuuden aikana talkover-komponentin musiikkikanavaan kohdistaman vai-

mennuksen taso asetettiin -6 dBFS:ään, joka vaikutti olevan riittävä vaimennuksen taso

silloin, kun musiikkikanavan taso oli ennalta asetettu siten, että se oli korvakuulolta arvi-

oituna yhtä lujalla kuin puhe. Puheaktiivisuuden alkaessa musiikkikanavan gain-para-

metrin taso automatisoitiin laskemaan tavoitetasolle AudioParam-rajapinnan linear-

RampToValueAtTime()-funktion avulla 20 millisekunnin aikana. Tason palautuminen

aiemmalle tasolle puheaktiivisuuden päätyttyä asetettiin tapahtumaan huomattavasti hi-

taammin. Tämän avulla minimoitiin äänentason tarpeeton huojunta virkkeiden välissä

esiintyvien taukojen aikana.

Prototyyppisovellus osoittautui sen verran toimivaksi, että hyvin pienillä jatkokehitystoi-

menpiteillä siitä voidaan saada jalostettua tuotantokäyttöön soveltuva mikserisovellus.

Tarvittavia jatkokehitystoimenpiteet liittyvät lähinnä sovelluksen käyttöliittymään ja sen

toteuttamiseen vaadittavien rajapintojen toteuttamiseen. Varsinaiseen äänen miksaami-

seen liittyvä toiminnallisuus oli prototyyppisovelluksessa jo hyvällä tasolla.

49

7 Yhteenveto

Työn tuloksena syntyi selkeä näkemys siitä, miten eri WebRTC-signaalinkäsittelykompo-

nenttien toiminta vaikuttaa erilaisiin äänisignaaleihin, sekä siitä, minkä takia AEC-kom-

ponentti soveltuu heikosti Sanoste Oy:n palveluissa käytettäväksi. Tämän lisäksi tehdyn

tutkimustyön avulla opittiin, että WebRTC:n ruuhkanhallintaominaisuuden takia äänisig-

naalin käsittelyllä voi olla vaikutusta myös kuvan laatuun, mikäli signaalinkäsittely rasit-

taa ohjaajan tietokoneen toimintaa liiaksi. Sanoste Oy:n tapauksessa ruuhkanhallinta-

ominaisuuden vaikutus on onneksi pienempi TokBoxin Scalable Video -ominaisuuden

ansiosta.

Tehtyjen tutkimusten sekä työssä toteutetun mikserisovelluksen prototyypin perusteella

voidaan todeta, että eri äänilähteistä saatavia äänisignaaleja summaavan mikserisovel-

luksen toteuttaminen ja sen integrointi Sanoste Oy:n palveluntuottajan sovellukseen on

mahdollista. Sen lisäksi, että se on mahdollista, on se myös melko yksinkertaista nykyis-

ten Web API:en avulla.

Työssä toteutetun mikserisovelluksen prototyypin kaltaisella ratkaisulla voidaan myös

mahdollistaa vaikeakäyttöisten ja hintavien ulkoisten äänilaitteiden käytöstä luopuminen,

sillä kaikki ulkoisten miksereiden tarjoama toiminnallisuus voidaan toteuttaa ohjelmalli-

sesti mikserisovelluksessa.

Jatkokehitystoimenpiteinä voidaan mainita mikserisovelluksen prototyypin kehittäminen

tuotantokelpoiseksi. Tämä ei todennäköisesti vaadi kovin suurta työtä, sillä prototyypissä

toteutettu äänen miksaamiseen vaadittava toiminnallisuus toimi testauksissa todella hy-

vin. Vain käyttöliittymä ja sen toteuttamiseen vaadittavat rajapinnat vaativat lisätyötä.

Tulevaisuudessa voi myös olla tarpeen testata mikserisovelluksen toimivuutta eri se-

laimissa, sillä prototyyppisovelluksen toimintaa testattiin ainoastaan Google Chrome -

selaimessa, koska se on tällä hetkellä ainoa palveluiden toteutukseen suositeltu selain.

50

Lähteet

1 Overview: Real Time Protocols for Browser-based Applications - draft-ietf-rtcweb-overview-19. 2017. Verkkoaineisto. IETF. <https://tools.ietf.org/html/draft-ietf-rtcweb-overview-19>. Luettu 6.4.2019.

2 Architecture. Verkkoaineisto. <https://webrtc.org/architecture/> WebRTC. Luettu 6.4.2019.

3 WebRTC 1.0: Real-time Communication Between Browsers - W3C Candidate Recommendation. 2018. Verkkoaineisto. W3C. <https://www.w3.org/TR/webrtc/>. Luettu 19.8.2019.

4 Media Capture and Streams - W3C Candidate Recommendation. 2019. Verkko-aineisto. W3C. <https://www.w3.org/TR/mediacapture-streams/>. Luettu 19.8.2019.

5 SDP: Session Description Protocol - RFC 4566. 2006. Verkkoaineisto. IETF. <https://tools.ietf.org/html/rfc4566>. Luettu 19.8.2019.

6 Datagram Transport Layer Security Version 1.2. 2012. Verkkoaineisto. IETF. <https://tools.ietf.org/html/rfc6347>. Luettu 19.8.2019.

7 WebRTC Audio Codec and Processing Requirements. 2016. Verkkoaineisto. IETF. <https://tools.ietf.org/html/rfc7874>. Luettu 6.4.2019.

8 OpenTok Basics - The OpenTok platform. 2019. Verkkoaineisto. <https://tok-box.com/developer/guides/basics/#opentok-platform>. Luettu 19.8.2019.

9 OpenTok.js - Overview. 2019. Verkkoaineisto. TokBox Developers - Client SDKs. <https://tokbox.com/developer/sdks/js/#overview>. Luettu 19.8.2019.

10 OpenTok Basics - Events. 2019. Verkkoaineisto. TokBox Developers - Guides. <https://tokbox.com/developer/guides/basics/#events>. Luettu 19.8.2019.

11 OpenTok Basics - Connection. 2019. Verkkoaineisto. TokBox Developers - Guides. <https://tokbox.com/developer/guides/basics/#connection>. Luettu 19.8.2019.

12 Video Codecs. 2019. Verkkoaineisto. TokBox Developers - Guides. <https://tok-box.com/developer/guides/codecs/>. Luettu 19.8.2019.

13 RTP Payload Format for the Opus Speech and Audio Codec. 2015. Verkkoai-neisto. IETF. <https://tools.ietf.org/html/rfc7587>. Luettu 19.8.2019.

51

14 Yousef O. Sharrab and Nabil J. Sarhan. 2012. Detailed Comparative Analysis of VP8 and H.264. Electrical and Computer Engineering Department & Wayne State Media Research Lab Wayne State University, Detroit. Conference paper.

15 Md Jahangir Alam, Patrick Kenny, Pierre Ouellet, Themos Stafylakis, Pierre Du-mouchel. 2014. Supervised/Unsupervised Voice Activity Detectors for Text- de-pendent Speaker Recognition on the RSR2015 Corpus. Centre de recherche in-formatique de Montréal, Montréal, Canada. <https://www.crim.ca/perso/pat-rick.kenny/Alam_odyssey2014.pdf>

16 Jens Schröder, Jörn Anemüller, Stefan Goetze. 2016. Performance Comparison of GMM, HMM and DNN Based Approaches for Acoustic Event Detection Within Task 3 of The DCASE 2016 Challenge. <https://www.cs.tut.fi/sgn/arg/dcase2016/documents/workshop/Schroeder-DCASE2016workshop.pdf>

17 Umar Iqbal Choudhry, JongWon Kim and Hong Kook Kim. A Highly Adaptive Acoustic Echo Cancellation Solution for VoIP Conferencing Systems. Conference paper.

18 RNNoise: Learning Noise Suppression. 2017. Verkkoaineisto. Mozilla and Xiph.Org. <https://people.xiph.org/~jm/demo/rnnoise/>. Luettu 19.8.2019.

19 Web Audio API - W3C Candidate Recommendation. 2018. Verkkoaineisto. W3C. <https://www.w3.org/TR/webaudio/>. Luettu 19.8.2019.

20 MediaStreamAudioSourceNode. 2019. Verkkoaineisto. Mozilla Developer Net-work. <https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamAudi-oSourceNode>. Luettu 19.8.2019.

21 MediaStreamAudioDestinationNode. 2019. Verkkoaineisto. Mozilla Developer Network. < https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamAudi-oDestinationNode>. Luettu 19.8.2019.