Multimedia Communications
Multimedia Communications: Broadcasting and Video-on-Demand

Departament d’Enginyeria Telemàtica (ENTEL)

Juanjo Alins
Jorge Mata
Oscar Esparza
Jose L. Muñoz

Capítol 1  Ràdio IP

1.1  Introducció

Internet i la distribució de continguts multimèdia són dos conceptes que estan associats. Des de que la xarxa i els equips permeten l’intercanvi de grans volums d’informació a alta velocitat, la quantitat de continguts audiovisuals que circulen per la xarxa no ha parat de créixer any rere any. Amb la millora de les condicions de la xarxa i de l’equipament informàtic, va sorgir una tècnica de transmissió de continguts multimèdia innovadora en aquell moment: l’streaming. Aquesta tècnica permet reproduir un contingut sense haver-se’l de baixar totalment abans de reproduir-lo, fet que possibilita poder escoltar i veure continguts generats en directe al moment (sumant-hi un retard). Usant streaming, es generen les primeres ràdios per Internet, essent unes ràdios que en un inici emetien un àudio típicament de baixa qualitat però que amb els anys han millorat la qualitat fins a assolir unes taxes de transmissió amb qualitats d’àudio properes a la del CD.

De ràdios IP en trobem bàsicament de dos tipus: les ràdios FM convencionals que ofereixen els continguts que emeten per aire per Internet o bé les ràdios que només emeten continguts per Internet. Les primeres, es diu que les emissores ofereixen un servei de webcasting, oferint en directe els continguts que emeten per aire. No s’ha de confondre amb el servei de podcasting, ja que aquest servei és un sistema d’àudio sobre demanda, mentre que el webcasting és un servei a temps real. Actualment es calcula que en el món hi ha 52 milions d’oients de ràdios per Internet, fet que demostra que és un servei utilitzat àmpliament per la població mundial i que es troba consolidat a dins de l’oferta de serveis IP a temps real.

Com es dissenya i es configura una ràdio IP? Aquesta és la principal qüestió d’aquests exercicis. Treballant els propers exercicis es mostra com funciona el procés de disseny d’una ràdio IP. Al llarg del recorregut es treballen els conceptes clau d’una ràdio. Cada exercici consisteix en configurar un model de ràdio IP més o menys evolucionat. La sofisticació de les ràdios IP seguirà un curs ascendent a cada exercici, assolint, al final, un model de ràdio IP amb una funcionalitat que es vol equiparar a la d’una ràdio convencional.

1.2  Ràdios IP. Visió general

Les ràdios IP són emissores de ràdio que distribueixen el seu contingut a través de xarxes IP. La distribució del contingut es fa a través d’un servidor d’àudio i el seu funcionament es basa en la tècnica d’streaming. Normalment són fluxos que no són interactius pel receptor, ja que les ràdios IP emeten contínuament, a temps real i sense cap retroacció disponible.

Les ràdios IP estan formades pels següents components:

Per a poder escoltar el contingut de la ràdio a través del servidor, l’oient de la ràdio IP haurà d’utilitzar un reproductor d’àudio que utilitzi descodificadors compatibles amb el flux del servidor.


Figura 1.1: Esquema d’una ràdio IP

En general, les ràdios es basen en la tècnica d’streaming. L’streaming és la tècnica de reproducció d’un material audiovisual en temps real, sense la necessitat d’haver-se d’esperar per descarregar tota la informació per tal d’accedir al contingut que es desitja veure o escoltar. Aquesta tècnica es desenvolupa entre dues màquines: una s’anomena servidor i l’altra client. El client és la màquina que demana rebre la informació, mentre que el servidor és la màquina que facilita tal informació. En l’inici del procés el client demana la informació que desitja al servidor i, si no hi ha cap inconvenient, el servidor envia la informació demanada al client.

En aquest servei hi ha un element clau que s’anomena buffer. El buffer és una quantitat de memòria de reserva que s’omple en el client amb l’informació que li arriba del servidor. Aquesta quantitat d’informació emmagatzemada permet al client aïllar la reproducció del contingut de la variabilitat en la velocitat de recepció de la informació des la xarxa.

1.2.1  Protocols usats en l’streaming

Protocols de transport

A nivell de transport, servidor i client es poden enviar les dades seguint diferents protocols. La tria d’un o altre protocol dependrà de les prestacions que es vulgui adjudicar al sistema d’streaming. En streaming hi ha dos conceptes a tenir en compte: la pèrdua de paquets i la latència. El sistema d’streaming ideal serà aquell que sigui més proper a una latència zero i una nul·la pèrdua de paquets.

Usar UDP, tot i ser un protocol que abaixa la latència, suposa exposar-se a pèrdues irrevocables de paquets ja que no disposa de mecanismes de correcció d’errors.

Usant TCP s’aconsegueixen connexions robustes i que evitan les pèrdues de paquets entre servidor i client, tot usant els mecanismes que manquen a UDP. Aquestes prestacions però, s’aconsegueixen en perjudici de la latència, ja que en una situació de pèrdua de paquets, es produiràn retransmissions entre el client i servidor, amb el conseqüent retard d’entrega dels paquets.

Protocols a nivell d’aplicació

Un dels protocols més utilitzats en aplicacions que usen streaming és el Real-time Transport Protocol (RTP). Va ser concebut per transferències extrem a extrem en temps real de fluxos de dades. Permet la compensació del jitter (variació del retard dels paquets), la detecció de paquets desordenats i permet fer enviaments multicast. RTP és un estàndard que defineix un protocol de transferència de dades (RTP) i un protocol de control de la transferència de dades anomenat Real-time Transport Control Protocol (RTCP). Mentre RTP s’encarrega del transport de les dades entre servidor i client, RTCP treballa per aconseguir una Qualitat de Servei especificada (QoS) i una sincronització entre fluxos multimèdia. RTP és implementat en UDP en comptes de TCP, degut a què en UDP, al contrari que TCP, prima la baixa latència davant de la fiabilitat.

El Real Time Streaming Protocol (RTSP) és un protocol de control que s’usa per establir i mantenir sessions multimèdia entre dos extrems. RTSP conté unes seqüències de control per tal de comprovar l’estat de la connexió. RSTP pot ser usat en aplicacions que usen RTP.

A diferència de RTP, l’Hypertext Transport Protocol (HTTP) s’utilitzat per a la transferència de dades. No va ser concebut per ser utilitzat usant la tècnica d’streaming i per tant, no està optimitzat per aquesta tasca. Tot i així s’usa en molts casos, ja sigui sense modificar o modificat. Un exemple d’ús d’HTTP modificat es dona en el protocol utilitzat pels servidors Icecast. Es tracta d’un protocol que, per exemple, usa la funció GET pròpia d’HTTP i que alhora té una funció anomenada SOURCE de nova creació.

1.2.2  Servidors

Hi ha un nombre important de programes per a configurar un servidor d’àudio. L’elecció, d’un programa o altre, dependrà dels protocols d’aplicació que es vulguin usar, del tipus de fluxos que es vulguin gestionar, de les fonts de servidor que es vulguin utilitzar, del preu del programari i del sistema operatiu de la màquina que farà córrer el servidor.

A continuació hi ha una representació dels programes per a servidors de música presents al mercat:

ShoutCast

És un programa de servidor que només gestiona fluxos d’àudio. Permet gestionar fluxos MPEG1-Layer 3 (mp3) i HE-AAC (MPEG4). Utilitza el protocol ICY. A finals de l’any 2010 hi havia 30000 ràdios IP que l’usaven com a servidor. És un programa gratuït i compatible amb tots els sistemes operatius.

Icecast

Gestiona tan fluxos d’àudio com de vídeo: fluxos ogg (vorbis i theora), MPEG1-Layer 3 (mp3), MPEG2 (AAC), NSV (NullSoft Video). Utilitza el protocol ICY i un protocol HTTP modificat propi. És un software gratuït i compatible amb tots els sistemes operatius exceptuant Mac.

Wowza Media Server

Programa servidor propietari ($65/mes) que permet distribuir àudio i vídeo, en directe i sota demanda, i aplicacions enriquides d’Internet. Pel què fa a protocols, utilitza RTSP/RTP i pot utilitzar ICY o HTTP Live Streaming Protocol per comunicar-se amb servidors Icecast i Shoutcast. Permet ser executat en múltiples plataformes i dispositius i els seus fluxos poden ser reproduïts per múltiples programes.

1.2.3  Fonts de servidor

Les fonts de servidor han de ser escollides segons el tipus de servidor que alimenten i segons els tipus de fluxos que el servidor pot distribuir.

A continuació hi ha una mostra de fonts de servidor presents al mercat:

Ices

És la font de servidor que forma part del projecte Icecast (codi lliure i gratuït). Té dues variants: una usa fluxos ogg vorbis i l’altra utilitza fluxos MPEG1-Layer 3 i pot alimentar servidors ShoutCast i Icecast.

Darkice

És una font de servidor per servidors Icecast, Shoutcast i Darwin. Pot generar fluxos MPEG1-Layer 3, MPEG2 (AAC) i MPEG4 (HE-AAC). És un programa gratuït i de codi lliure.

Liquidsoap

Llenguatge i intèrpret que permeten generar fluxos ogg i MPEG1-Layer 3. Molt versàtil, permet fer mescles d’àudio i diverses funcions de processat. Pot generar fluxos MPEG1-Layer 3 i ogg vorbis per alimentar servidors Icecast.

1.3  El servidor d’streaming Icecast

L’Icecast és un programa (de codi lliure) per a servidors dedicats a la distribució de continguts multimèdia. Forma part del projecte Icecast de la fundació Xiph.org per a la generació d’eines per l’streaming lliure de continguts multimèdia. Un servidor que utilitza l’Icecast permet distribuir fluxos mp3, ogg vorbis, AAC, ogg speex, ogg flac, ogg theora o NSV. Per tant, pot distribuir tant àudio com vídeo.


Figura 1.2: Pàgina d’administració de l’Icecast

1.3.1  Funcionament

L’Icecast, al ser només un servidor, necessita rebre el flux multimèdia provinent d’una font de servidor per cobrir la demanda de continguts dels clients. Pel correcte funcionament de l’Icecast, s’ha de configurar adequadament el fitxer icecast.xml o qualsevol altre fitxer de configuració en format *.xml.

Pel què fa a protocols, l’Icecast usa un protocol HTTP modificat per a la distribució de fluxos OGG. Aquest protocol l’han de saber interpretar les fonts de servidor que alimentin qualsevol servidor Icecast. A més, el servidor Icecast entén el protocol ICY. Aquest protocol és utilitzat a l’hora de distribuir fluxos NSV (NullSoft Video) i pels fluxos provinents de servidors ShoutCast.

1.3.2  Fitxer de configuració

El fitxer de configuració icecast.xml es troba a la carpeta /etc/icecast2 del sistema de fitxers del servidor. Partint de la versió creada amb la instal·lació, es faran certs retocs segons convingui. Mitjançant aquest fitxer, l’administrador del servidor pot ajustar els següents paràmetres:

Límits

Entre les etiquetes <limits>...</limits> l’administrador decideix:

Identificació

Entre les etiquetes <authentication>...</authentication> hi ha els ajustos d’identificació i de seguretat:

Altres opcions del servidor

El següent text correspon a un exemple del fitxer /etc/icecast/icecast2.xml:

 <icecast>
    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <threadpool>5</threadpool>
        <queue-size>10000</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>1000</burst-size>
    </limits>

    <authentication>
        <source-password>xxxx</source-password>
        <relay-password>xxxx</relay-password>
        <admin-user>admin</admin-user>
        <admin-password>xxxx</admin-password>
    </authentication>

    <!-- This is the hostname other people will use to connect to your server.
    It affects mainly the urls generated by Icecast for playlists and yp
    listings. -->
    <hostname>localhost</hostname>
    <listen-socket>
        <port>8000</port>
    </listen-socket>
     ...
    <paths>
        <logdir>/var/log/icecast2</logdir>
        <webroot>/usr/share/icecast2/web</webroot>
        <adminroot>/usr/share/icecast2/admin</adminroot>
        ...
    </paths>
    ...
    <security>
        ....
    </security>
</icecast>

1.4  L’Ices

L’Ices és una font que alimenta servidors Icecast amb un flux d’àudio en format ogg o mp3. Aquest programa pertany, juntament amb el programa per a servidors, al projecte Icecast de la fundació Xiph.org.

1.4.1  Funcionament

L’execució de la font del servidor està subordinada a un fitxer de configuració (escrit en xml) que en determina el mode de funcionament. La font pot actuar en dos modes: en mode de llista de reproducció (playlist) o bé en mode de reproducció d’entrada d’àudio (live). Depenent de les versions del programa, la font genera fluxos ogg o mp3: mentre que les versions 2.x del programa transmeten fluxos ogg, les versions 0.x treballen amb fluxos mp3. L’Ices hi desarà els events de funcionament en un fitxer de registre que és ubicat a la carpeta /var/log/ices al sistema de fitxers on resideix la font

Es comunica amb els servidors Icecast utilitzant el protocol HTTP modificat d’Icecast.

Mode Playlist

Directoris

Tot i tenir l’Ices instal·lat, es crea el directori /etc/ices2 al sistema de fitxers de les màquines virtuals. En aquest directori hi haurà d’haver:


Figura 1.3: Carpeta ices2 en el sistema de fitxers de les màquines virtuals

Música i llista de reproducció

La font usa una carpeta de música i la llista de reproducció per tal d’emetre el flux d’àudio. La carpeta i la llista es poden anomenar de qualsevol manera, ja que per utilitzar el directori de música i la llista de reproducció es fan servir les rutes. Per exemple, si una font ha d’emetre dues cançons anomenades pista1.ogg i pista2.ogg i estan a la carpeta /etc/ices2/music, el fitxer playlist.txt2 és:

/etc/ices2/music/pista1.ogg /etc/ices2/music/pista2.ogg
Fitxer de configuració

A continuació, s’expliquen els paràmetres del fitxer de configuració:

Capçalera
Metadades
Entrada d’àudio
Configuracions del flux d’àudio

El següent codi correspon al fitxer de configuració de l’ices2 (ices_playlist.xml):

<?xml version="1.0"?>
<ices>
    <!-- run in background -->
    <background>1</background>
    <!-- where logs, etc go. -->
    <logpath>/var/log/ices</logpath>
    <logfile>ices.log</logfile>
    <!-- 1=error,2=warn,3=info,4=debug -->
    <loglevel>4</loglevel>
    <!-- set this to 1 to log to the console instead of to the file above -->
    <consolelog>0</consolelog>

    <!-- optional filename to write process id to -->
    <!-- <pidfile>/home/ices/ices.pid</pidfile> -->

    <stream>
        <!-- metadata used for stream listing (not currently used) -->
        <metadata>
            <name>Radio MFS</name>
            <genre>Rock</genre>
            <description>Emissions en proves</description>
        </metadata>

        <!-- input module

            The module used here is the playlist module - it has 
            'submodules' for different types of playlist. There are
            two currently implemented, 'basic', which is a simple
            file-based playlist, and 'script' which invokes a command
            to returns a filename to start playing. -->

        <input>
            <module>playlist</module>
            <param name="type">basic</param>
            <param name="file">/etc/ices2/playlist.txt</param>
            <!-- random play -->
            <param name="random">0</param>
            <!-- if the playlist get updated that start at the beginning -->
            <param name="restart-after-reread">1</param>
            <!-- if set to 1 , plays once through, then exits. -->
            <param name="once">0</param>
        </input>

        <!-- Stream instance
            You may have one or more instances here. This allows you to 
            send the same input data to one or more servers (or to different
            mountpoints on the same server). Each of them can have different
            parameters. This is primarily useful for a) relaying to multiple
            independent servers, and b) encoding/reencoding to multiple
            bitrates.
            If one instance fails (for example, the associated server goes
            down, etc), the others will continue to function correctly.
            This example defines two instances as two mountpoints on the
            same server.  -->
        
        <instance>
        
            <!-- Server details:
                You define hostname and port for the server here, along with
                the source password and mountpoint.  -->
            
            <hostname>192.168.0.2</hostname>
            <port>8000</port>
            <password>xxxx</password>
            <mount>/radio.ogg</mount>

            <!-- Reconnect parameters:
                When something goes wrong (e.g. the server crashes, or the
                network drops) and ices disconnects from the server, these
                control how often it tries to reconnect, and how many times
                it tries to reconnect. Delay is in seconds.
                If you set reconnectattempts to -1, it will continue 
                indefinately. Suggest setting reconnectdelay to a large value
                if you do this. -->
                
            <reconnectdelay>2</reconnectdelay>
            <reconnectattempts>5</reconnectattempts> 

            <!-- maxqueuelength:
                This describes how long the internal data queues may be. This
                basically lets you control how much data gets buffered before
                ices decides it can't send to the server fast enough, and 
                either shuts down or flushes the queue (dropping the data)
                and continues. 
                For advanced users only. -->
            
            <maxqueuelength>80</maxqueuelength>
            
            <encode>  
                <!-- bps. e.g. 64000 for 64 kbps -->
                <nominal-bitrate>64000</nominal-bitrate> 
                <samplerate>44100</samplerate>
                <channels>2</channels>
            </encode>
        </instance>

        </stream>
</ices> 

Mode Live

El fitxer de configuració té molts punts en comú amb els de les fonts en mode de llista de reproducció. Les principals diferències es troben en els directoris i en el mode d’entrada.

Directoris

Al no utilitzar una llista de reproducció de fitxers de música, no és necessari tenir un fitxer de llista de reproducció (playlist.txt) ni tenir una carpeta amb la música a reproduir.

Configuració

Per les fonts que funcionen en mode live, s’utilitzarà el mode alsa en l’entrada d’àudio i, a més, es modificaran els següents paràmetres:

1.5  Intèrpret i llenguatge Liquidsoap

1.5.1  Definició

El liquidsoap és un llenguatge de programació d’àudio pensat per crear fluxos d’àudio i vídeo per alimentar servidors Icecast creat per The Savonet Team. Pot funcionar, com altres eines que tenen la mateixa funció, a partir d’ordres que es passen per consola o utilitzant scripts i passant-los a un intèrpret.


Figura 1.4: Exemple d’script i logo de liquidsoap. Es tracta d’una ràdio que mescla dos fluxos i els hi afegeix senyals horaris

1.5.2  Funcionament

Usant liquidsoap és molt senzill expressar una font que utilitza diversos recursos alhora per tal de fabricar un flux pel servidor. Aquesta senzillesa, juntament amb un conjunt de funcions molt útils per tractar els fluxos, fan del llenguatge liquidsoap una eina molt poderosa per l’streaming d’àudio.

En liquidsoap, els fluxos provinents dels recursos s’expressen en variables que no estan tipificades. A més, el flux resultant és robust als errors degut al control de fal·libilitat al que s’ha de sotmetre abans de ser transmès. El control de fal·libilitat consisteix en comprovar que el fitxer i el contingut del dispositiu que es vol transmetre existeix i es troba accessible per part de l’intèrpret.

Aquest llenguatge també permet la inclusió d’un servidor telnet a la font. El servidor, el qual pot rebre ordres per part de l’administrador de la font, serveix per controlar la font en tot moment sense haver de parar el bombeig i modificar l’script de la font.

1.5.3  Exemples

Un script escrit en liquidsoap que sigui de la següent manera:

#! /usr/bin/liquidsoap set("server.telnet",true) flux = playlist.safe("/etc/liquidsoap/cancons.pls") output.icecast.vorbis(host = "192.168.1.56", port = 8000, mount = "/radio.ogg", \ name = "Radio", description = "Musica 24h", genre = "Mix", password = "xxxx", flux)

Crea un flux d’àudio a partir de la llista de reproducció cancons.pls i l’envia al port 8000 d’un servidor Icecast a 192.168.1.56. El flux inclou metadades pel nom, per una descripció i pel gènere. El punt de muntatge és /radio.ogg i s’habilita el servidor telnet a la font.

Un script escrit en liquidsoap que sigui de la següent manera:

#! /usr/bin/liquidsoap set("server.telnet",true) cancons = playlist.safe("/etc/liquidsoap/cancons.pls") jingles = playlist.safe("/etc/liquidsoap/jingles.pls") flux = rotate(weights=[4,1],[cancons,jingles]) output.icecast.vorbis(host = "192.168.1.56", port = 8000, mount = "/radio.ogg", \ name = "Radio", description = "Musica 24h", genre = "Mix", password = "xxxx", flux)

Envia un flux d’àudio al mateix servidor que en el cas anterior, però aquest flux és el resultat de combinar una llista de reproducció anomenada cancons i una llista de jingles que s’anomena jingles. Al flux hi haurà quatre vegades més cançons pertanyents a la llista de reproducció cancons que no pas cançons pertanyents a la llista de reproducció jingles. La funció rotate és la que permet combinar cançons de diverses llistes de reproducció.

Com es pot observar en els exemples donats, la compactació de les ordres que necessita l’intèrpret de liquidosap es contraposa amb la longitud d’un fitxer de configuració d’una font Ices. A continuació, s’adjunta una relació de funcions i utilitats en liquidsoap.

FuncióDescripció
var = playlist(“playlist.pls”)var conté un flux a partir d’una llista de reproducció
var = single(“song.ogg”)var conté un flux (infinit) a partir d’una cançó
var = once(“song.ogg”)var conté un flux (es reprodueix un cop) a partir d’una cançó
var = in()var conté un flux a partir del so provinent del dispositiu d’entrada de so per defecte
var = add([flux1,flux2])var és la mescla 50%-50% de dos fluxos
var = fallback([flux1,flux2])var és el primer flux que està disponible quan l’altre falla
output.icecast.vorbis(flux1...)Envia el flux flux1 al servidor Icecast

1.6  Exercici 1

Aquest exercici consisteix en la correcta configuració d’una ràdio IP que reprodueix una llista de reproducció. Es parteix d’un escenari on s’han de configurar cadascun dels elements que formen part de la ràdio IP i aconseguir que la ràdio funcioni de manera correcta. Al final del exercici es podrà sentir el fil musical.

1.6.1  Objectius

Es pretén que un cop acabada l’exercici s’hagin assimilat els següents conceptes:

1.6.2  Eines

1.6.3  Escenari

Esquema

L’escenari net representa la configuració més senzilla per una ràdio IP. Consta de dues màquines virtuals configurades, una com a servidor i l’altra com a font del servidor. El host es comunica amb les dues màquines a través d’una xarxa que la connecta amb el servidor i d’un enllaç amb la xarxa que uneix el servidor i la font.

Tal i com mostra la següent figura, l’escenari té dues xarxes: Net 1, que enllaça el host i el servidor i Net 0, que enllaça a les dues màquines virtuals amb el host. L’enllaç redundant entre la màquina host i les màquines virtuals es deu a la voluntat de capturar el tràfic de paquets entre les tres màquines.


Figura 1.5: Esquema de l’escenari Net

Amb aquesta configuració, tindrem les funcions de servidor i de font de servidor virtualitzades, mentre que la màquina host s’encarregarà d’executar el client d’àudio per captar el corrent que distribuirà el servidor.

Apunts sobre les màquines de l’escenari

Màquina source

La font del servidor, source, és una font que reprodueix una llista de reproducció anomenada playlist.txt i ubicada, juntament, amb el fitxer de configuració de la font (ices-playlist.xml) i la carpeta de música de la llista, al següent directori:

source:~# /etc/ices2/

El fitxer de registre de funcionament de la font del servidor és el següent:

source:~# /var/log/ices/ices.log

Màquina server

El servidor executa automàticament un script a l’inici que carrega el fitxer de configuració predeterminat. Podeu trobar el fitxer de configuració i els registres de funcionament i error de l’Icecast als següents directoris:

# Fitxer de configuracio server:~# /etc/icecast2/icecast.xml # Registres de funcionament i d'error server:~# /var/log/icecast2/error.log server:~# /var/log/icecast2/access.log

El servidor distribueix el contingut des del port 8000.

1.6.4  Desenvolupament

Inici de l’escenari

Utilitzem l’script simctl per a virtualitzar el servidor i la seva font. L’script, basat en VNUML, s’encarrega de configurar les interfícies de xarxa de les màquines virtualitzades (VM) i les xarxes que les uneixen. Per iniciar l’escenari, passem com a argument el nom de l’escenari al simctl:

root@Laptop:~# simctl net start

Un cop el simctl ha acabat la inicialització, podrem accedir a les màquines virtuals a través d’uns pseudo-terminals screen, usant l’etiqueta get del simctl:

root@Laptop:~# simctl net get source root@Laptop:~# simctl net get server

Aquests pseudo-terminals es poden tancar sense perill de perdre la informació. Es poden obtenir de nou els pseudo-terminals tornant a invocar l’ordre get.


Figura 1.6: Terminals de les màquines source i server

El programa Icecast ha de ser iniciat manualment des de la màquina server.

# Arrancar o rearrancar el servidor server:~# /etc/init.d/icecast2 restart # Verificar que el servidor a arrancat server:~# ps aux | grep icecast

Com s’ha dit, el servidor icecast s’executa en el port 8000 de la màquina server, o sigui que la l’adreça URL concreta on podem accedir a l’Icecast en aquest escenari és: http://192.168.0.2:8000.

Posteriorment, el bombeig també sera iniciat manualment des de la màquina source quan s’hagi verificat el correcte funcionament del servidor icecast i estigui preparada la captura de paquets amb el programari wireshark.

S’ha de verificar que efectivament, les interfícies de xarxa de la màquina source i de la màquina server estan correctament configurades tot utilitzant la comanda ifconfig.

A la banda del host, heu de configurar correctament les interfícies de xarxa “tap0” i “tap1” per poder portar a terme les comunicacions desitjades. Utilitzeu la comanda ping per enviar paquets des del host fins al servidor per comprovar l’enllaç entre les dues màquines.

Un cop configurat el host, useu el Mozilla Firefox per a connectar-vos a l’adreça del servidor i obtindreu una plana web com la mostrada a la figura ??. Recordeu que podeu accedir amb usuari:admin i password:xxxx al icecast2 mitjançant l’enllaç Administration de la plana web.


Figura 1.7: Servidor Icecast present al port 8000 de la màquina server

Màquina Source I

Un cop configurades les interfícies de xarxa, s’ha de configurar correctament l’ices2 a la font. En els propers passos haureu d’editar fitxers de configuració. Si heu d’editar el fitxer de configuració de la font, assegureu-vos de què heu matat abans el procés de bombeig. Podeu utilitzar comandes com la killall:

# Matar el bombeig de la font Ices source:~# killall ices2

Per a modificar fitxers del sistema de fitxers de les màquines virtuals, podeu usar la comanda vi.

source:~# vi fitxer

La comanda vi crida a un editor de consola. Al llarg del present i següents exercicis, haureu de tenir en compte la següent taula de funcionament de l’editor vi:

Mode editorTecla Insert
Sortir del mode editorTecla Esc
Desar els canvis:w i tecla Enter, fora del mode editor
Sortir del vi:q i tecla Enter, fora del mode editor
Sortir del vi desant:wq i tecla Enter, fora del mode editor

També es pot fer servir la comanda pico amb el menu incorporat.

Editeu el fitxer de configuració de l’ices2 (/etc/ices2/ices-playlist.xml) a la màquina source, i doneu els valors adequats als paràmetres. Fixeu-vos especialment en la contrasenya per accedir al servidor, l’adresa IP i el port del servidor i el fitxer de playlist que heu de configurar.

Inicieu l’analitzador de paquets wireshark i analitzeu els paquets de la interfície que es troba a la xarxa 10.34.0.0/24.

Inicieu el bombeig d’informació d’àudio al servidor usant el fitxer /etc/ices2/ices-playlist.xml. El fitxer de configuració de la font estipula que el flux d’àudio que passa al servidor estarà disponible a través del punt de muntatge /radio.ogg.

Utilitzeu el Mozilla Firefox per captar el flux que distribueix el servidor:

#terminal de la host root@Laptop:~# wireshark #terminal de la source source:~# ices2 /etc/ices2/ices-playlist.xml # terminal de la host root@Laptop:~# firefox http://192.168.0.2:8000/radio.ogg

També podeu accedir directament fent servir el mediaplayer: mplayer o ffplay

#terminal de la host root@Laptop:~# mplayer http://192.168.0.2:8000/radio.ogg # terminal de la host root@Laptop:~# ffplay http://192.168.0.2:8000/radio.ogg

Si tot està ben configurat, heu de veure el flux de dades des de la font cap al servidor.


Figura 1.8: Intercanvi de paquets en l’associació font-servidor

Observeu les captures realitzades pel wireshark. Identifiqueu quina màquina fa les funcions de client TCP i quina les funcions de servidor TCP. Identifiqueu les adreces IP i els ports TCP del client i del servidor.

Fen servir el filtre de “display” del wireshark seleccioneu els paquets TCP que van des de la font d’audio cap al servidor d’audio (tcp.dstport == 8000) i seleccionant l’opció summary → statistics del menú del wireshark, esbrineu la taxa mitja de transmissió (en kbps) de la cançó actual. Compareu aquesta taxa amb la taxa de codificació de la cançó, tot identificant la cançó que s’està transmetent (mireu el fitxer de registre del ices2) i utilitzant la comanda ogginfo sobre el fitxer en format ogg de la cançó.

Protocol Icecast I

L’Icecast es comunica amb les fonts o amb altres servidors usant un protocol molt senzill derivat d’HTTP. En versions anteriors, l’Icecast emprava els protocols icy o xaudiocast. A la versió 2.3.2, la versió utilitzada en aquests exercicis, també admet el protocol ICY per comunicar-se amb fonts o servidors ShoutCast.

En l’inici de l’associació entre una font i un servidor Icecast, es produeix un handshake mitjançant el qual la font transmet les metadades del seu flux i la clau d’autorització al servidor i, el servidor, aprova o no l’associació amb la font segons les dades transmeses (veure figura ??).

Torneu a iniciar la captura de paquets i reinicieu el bombeig de la font. Analitzeu els paràmetres intercanviats amb l’opció Follow TCP stream pels nous paquets capturats.

Màquina Source II

Amb el reiniciat del bombeig, verifiqueu que apareix el flux d’àudio al servidor. Si s’escau feu servir el fitxer de registre de la font Ices (/var/log/ices/ices.log) per a obtenir informació respecte al funcionament de la bomba (ices2). Recordeu que una font Ices2 només pot tractar amb fluxos d’àudio OGG i AAC.

Si el sistema està funcionant correctament, visiteu la pàgina del servidor i obtindreu una plana web com mostrada a la figura ??.


Figura 1.9: Servidor amb el flux d’àudio corresponent


Ara que ja teniu el servidor i la font correctament configurats, podeu sentir el flux d’àudio del servidor mitjançant el vlc:

root@Laptop:~# vlc http://192.168.0.2:8000/radio.ogg

Usar el VLC us pot reportar problemes en els canvis de cançó. Si sentiu que la reproducció es para al finalitzar una cançó, reinicieu la reproducció amb els botons STOP i PLAY.

Finalment, teniu la possibilitat de fer servir el banshee per escoltar la radio. Observeu l’evolució del bufer d’aquesta aplicació. Feu proves aturant i reestablint la recepció de la Radio IP.

1.7  Exercici 2

En segon exercici es configura una ràdio IP que disposa de dos canals temàtics: un canal dedicat a la música folk i l’altre dedicat a música de tots els gèneres. Assumint que s’han assimilat correctament els conceptes treballats al primer exercici, es treballa en un entorn on hi ha presents dos servidors i dues fonts. L’objectiu final serà aconseguir, de manera guiada, un servidor amb diversos canals temàtics (punts de muntatge), i per tan, aconseguir una ràdio IP amb dos canals temàtics.

1.7.1  Objectius

Durant el transcurs d’aquest exercici es treballaran els següents conceptes:

1.7.2  Eines

1.7.3  Escenari

Esquema

L’escenari tree mostra una ràdio IP que disposa de dues fonts de servidor que poden alimentar de diverses maneres dos servidors. Seria un escenari útil per una ràdio IP que ofereix diversos canals alhora als seus clients. Un exemple, salvant les distàncies, seria el servei que ofereix la BBC radio via IP: la corporació britànica ofereix 11 canals temàtics més els serveis de broadcast internacional via Internet.

Tal i com podeu veure més avall, en l’escenari, la màquina host es connecta als servidors utilitzant dues interfícies (tap0 i tap1). Pel què fa a les fonts dels servidors i als servidors, source1 i server1 tenen la seva xarxa privada (Net 3), mentre que source2 i server2 comparteixen la seva xarxa amb la font source1 (Net 2). Aquesta última connexió permet que server2 i source1 estiguin connectades sense haver de dependre de source2.


Figura 1.10: Esquema de l’escenari tree

Apunts sobre les màquines virtuals

Fitxers de registre Les dues fonts de servidor de l’escenari tenen el següent fitxer de registre:

sourceN:~# /var/log/ices/ices.log

On N és el número de la font.

Els servidors de l’escenari tenen els següents fitxers de registre del servidor Icecast:

serverN:~# /var/log/icecast2/acces.log serverN:~# /var/log/icecast2/error.log

On N és el número del servidor.

Màquina source1

És la font que subministrarà un flux de música de diversos gèneres. Subministrarà el flux a ambdós servidors al llarg de l’exercici. Utilitzarà el fitxer de configuració ices-playlist-mix.xml i la llista de reproducció playlist.txt. Ambdós fitxers es troben al directori /etc/ices2.

Màquina source2

Aquesta font subministrarà un flux de música folk a server2. Utilitzarà el fitxer de configuració ices-playlist-folk.xml i la llista de reproducció playlist-folk.txt. Ambdós fitxers es troben al directori /etc/ices2.

Màquina server1

La màquina server1 distribuirà el flux que rep de la màquina source1. En la part final de l’exercici, entrega els seus punts de muntatge a server2 en una configuració “master-slave”.

Màquina server2

Aquest servidor sempre rebrà el flux de música folk provinent de source2 i farà d’esclau de server1 en la configuració “master-slave” del final de l’exercici. Acabarà essent el servidor des del qual accedirem a tots els punts de muntatge.

1.7.4  Desenvolupament

Inici de l’escenari

Per iniciar l’escenari tree amb el simctl, executeu la següent comanda:

root@Laptop:~# simctl tree start

Al final de la càrrega podreu accedir a les quatre màquines virtuals usant l’etiqueta get del simctl:

root@Laptop:~# simctl tree get source1 root@Laptop:~# simctl tree get source2 root@Laptop:~# simctl tree get server1 root@Laptop:~# simctl tree get server2

Figura 1.11: Les quatre màquines virtuals de l’escenari

Recordeu que usant el simctl es creen les interfícies que connecten la màquina host amb les màquines guest, tot i que NO se les hi assigna cap adreça de xarxa.

Configureu les interfícies tap de la màquina host tal i com indica l’esquema. Comproveu que heu configurat correctament les interfícies de xarxa de la màquina host usant l’ordre ping per enviar paquets des de la màquina host fins als servidors.

Un cop hàgiu fet validat l’escenari, heu de reiniciar el servidor icecast usant:

# Arrancar o rearrancar el servidor server:~# /etc/init.d/icecast2 restart # Verificar que el servidor a arrancat server:~# ps aux | grep icecast

Una font per cada servidor

Configureu adequadament el fitxers de configuració de l’ices2 a les dues màquines que fan de bomba d’àudio. Per la màquina source1 utilitzeu el fitxer de configuració ices-playlist-mix.xml, per la màquina source2, utilitzeu el fitxer ices-playlist-folk.xml, ambdós es troben al directori /etc/ices2 del sistema de fitxers de les màquines virtuals. Inicieu el bombeig de les fonts. Comproveu, utilitzant el Mozilla Firefox, si els fluxos de les fonts arriben als servidors. Recordeu que els servidors s’executen al port 8000 de les màquines server1 i server2. Si els fluxos no arriben, analitzeu els fitxers de registre (/var/log/ices/ices.log) per intentar esbrinar el problema i reconfigureu adequadament per solucionar el problema.

Recordeu que per veure els resultats dels canvis fets en els fitxers de configuració, cal reiniciar el programa servidor o el programa de la font del servidor, en cap cas és necessari reiniciar el simctl.


Figura 1.12: Flux mix a la server1


Figura 1.13: Flux folk a la server2

Dues fonts per un servidor

Un servidor Icecast permet tenir connectades un nombre determinat (especificat en el fitxer de configuració de l’Icecast com a <sources>...</sources>) de fonts i de servidors master. Cada flux queda muntat en un punt de muntatge diferent, així, des del port on s’executa el servidor, es pot accedir als diferents fluxos que arriben al servidor.

Modifiqueu les fonts de tal manera que les dues alimentin al servidor server2. Recordeu-vos de parar, abans de tot, els programes ices a les màquines font. Utilitzeu l’ordre :

# Matar el bombeig de la font Ices source:~# killall ices2

Figura 1.14: Server2 amb els dos fluxos

Relaying

Els servidors Icecast poden ser alimentats per punts de muntatge d’altres servidors Icecast. Aquest comportament s’anomena relaying. Amb aquest mètode, fluxos d’àudio presents en un servidor master, passen a ser enllaçats en un servidor slave. L’Icecast permet subministrar tots els punts de muntatge d’un servidor a un altre (tècnica “master-slave”), o bé només subministrar-ne un de concret (tècnica “single-broadcast”). En ambdues tècniques, només s’ha de configurar el servidor que fa el relay, en cap cas s’ha de configurar el servidor que conté el flux que serà emmirallat.

master-slave

Amb aquesta tècnica un servidor esclau (slave), integra tots els fluxos presents a un servidor subministrador (master). Per configurar un servidor slave, s’ha d’editar el fitxer de configuració del servidor configurant-ne correctament els següents camps:

single-broadcast

Utilitzant aquesta tècnica, el servidor slave capta tan sols un dels fluxos que emet el servidor master. Es configura el servidor slave perquè utilitzi aquesta tècnica en els següents camps:

El següent esquema mostra els dos servidors de l’escenari treballant en mode “master-slave”. Indiqueu quin d’ells és el master i quin d’ells és l’slave. A continuació, configureu les màquines de l’escenari per tal d’obtenir la configuració “master-slave” tal i com mostra l’esquema.


Figura 1.15: Esquema “master-slave”

Un cop hàgiu fet els canvis necessaris al fitxer de configuració de l’Icecast, heu de reiniciar el servidor usant un dels mètodes següents:

# reiniciat directe del servidor server2:~# /etc/init.d/icecast2 restart # parant el servidor i tornant-lo a encendre server2:~# /etc/init.d/icecast2 stop server2:~# /etc/init.d/icecast2 start

D’aquesta manera es reiniciarà l’Icecast amb els nous paràmetres de configuració.

Protocol icecast

En l’exercici anterior ja vam veure en què consistia el protocol Icecast en una connexió font-servidor, ara veureu en què consisteix el protocol Icecast en una connexió entre dos servidors Icecast quan un és esclau de l’altre.

Connexió servidor-servidor

Amb el wireshark capturant a la interfície correcta, reinicieu el servidor master i captureu el handshake que es produeix entre els dos servidors. Com podreu comprovar, en aquest cas si que es fa servir una funció d’HTTP (GET). Es fa servir perquè el servidor esclau pugui obtenir el llistat de fluxos que té el servidor master. En el cas que el servidor master hagi servit correctament la llista al servidor esclau, respon amb HTTP/1.0 200 OK.

1.8  Exercici 3

Fins ara, s’han generat models de ràdios que només permetien la distribució de música provinent de llistes de reproducció. Però, què és una ràdio sense la capacitat de captar el so provinent d’almenys un micròfon? En aquest tercer execici hi trobareu diferents maneres per captar l’àudio provinent del micròfon i enviar-lo al servidor i com fer mescles d’àudio, ja sigui una mescla locutor-música com una mescla música-música.

Objectius

L’objectiu principal d’aquest exercici és el de dissenyar una ràdio que posi música ambient a sota del locutor de la ràdio. Fins a arribar a aquest objectiu, es treballaran els següents conceptes:

1.8.1  Eines

1.8.2  Escenari

Esquema

L’escenari utilitzat en aquest exercici és el més senzill de tots. De màquines virtualitzades només se’n necessita una, ja que la font de servidor s’ha d’executar des del host ja que aquesta, ha d’obtenir dades del maquinari de so.

En aquest escenari, tot i que només hi ha una màquina virtual i una de física, hi ha dos xarxes. Això es deu a que una xarxa(Net 0) serà l’enllaç que durà el tràfic de pujada de dades cap al servidor, mentre que l’altra(Net 1), concentrarà el tràfic de dades del servidor cap a la màquina host.


Figura 1.16: Esquema de l’exercici

Apunts sobre la màquina server

Com ja va essent habitual, els fitxers de registre de la màquina server es troben als següents directoris:

server:~# /var/log/icecast2/acces.log server:~# /var/log/icecast2/error.log

El servidor s’executa en el port 8000 i s’escoltarà a través de la interfície que té a la xarxa Net 0.

Apunts sobre les fonts de servidor

Font Ices El fitxer de registre de funcionament de la font Ices, tindrà que està situat en el següent directori accesible com ara:

root@Laptop:~# $HOME/log/ices

El fitxer de configuració de l’Ices, s’anomena ices-alsa.xml i es troba en el següent directori:

root@Laptop:~# /usr/share/vnuml/scenarios/files/live/local/ices2

Font liquidsoap El fitxer de registre de funcionament de la font liquidsoap, té que està situat en el directori:

root@Laptop:~# $HOME/log/liquidosap

Arxius de música La carpeta de música mix es troba en el següent directori:

root@Laptop:~# /usr/share/vnuml/scenarios/files/live/local/liquisoap/mix

A dins hi ha fitxers ogg de música clàssica i d’altres gèneres.

1.8.3  Desenvolupament

Inici de l’escenari

Per tal d’iniciar l’escenari, passeu el nom de l’escenari live al simctl:

root@Laptop:~# simctl live start

Aquest escenari genera una sola màquina virtual que tindrà la funció de servidor. A continuació, configureu correctament les interfícies de xarxa. Comproveu que ho heu fet correctament visitant el servidor mitjançant el Mozilla Firefox.

Ràdio amb locutor

Com s’explica a la introducció, aquesta sessió tracta sobre com dissenyar una ràdio IP muntada en un servidor Icecast i que pugui combinar directe(locutor provinent de les connexions d’entrada de la targeta de so de la màquina host) i una llista de reproducció de música.

En aquest apartat, veureu com crear ràdios IP que gestionen un corrent de veu. Ho fareu utilitzant dos tipus de fonts: una font Ices i una font liquidsoap. Aquestes fonts no poden ser virtualitzades, ja que han de treballar conjuntament amb el servidor de so del sistema host, i per tant, amb el hardware instal·lat a la màquina host. Per això l’escenari live és tan minimalista.

L’Ices2, la font “oficial” de l’Icecast, permet codificar en diversos formats i té una funcionalitat força senzilla, però té un problema, i es que només pot treballar amb un recurs per generar un flux per enviar al servidor. Altres fonts són molt més versàtils i, com les fonts liquidsoap, permeten crear un flux per enviar-lo al servidor a partir de la combinació de diversos recursos.

CaracterísticaIces2Liquidsoap
Format d’àudio d’entradaOGG, AACOGG, AAC, MP3
Número de recursos d’entrada11 o més
Funcions de mesclatNo
Programació horàriaNo
Funció aleatòriaNo
Submostreig
Metadades
Canvis en calentNo

Comprovació del maquinari

Si es considera que el sistema operatiu usa l’arquitectura de so ALSA (Advanced Linux Sound Architecture), l’arquitectura de so és la part del nucli Linux que gestiona els dispositius d’àudio i els unifica en un sol sistema de control. Sobre ALSA hi corre un servidor de so de sistema com PulseAudio.

Comproveu que el sistema té una targeta de so correctament instal·lada. Per fer-ho, utilitzeu l’ordre alsamixer:

root@Laptop:~# alsamixer

Al terminal hi veureu els nivells de volum d’entrada i sortida dels dispositius de la targeta de so.


Figura 1.17: Mesclador gràfic d’àudio d’ALSA

Prement F4, veureu els nivells dels dispositius d’entrada i prement F6 accedireu als menús d’informació del sistema. Mireu els diferents menús i comproveu que hi ha una configuració de so correcta. Comproveu que hi sigui present el dispositiu de so d’entrada amb un valor de volum correcte.

Endolleu el micròfon a l’entrada de micròfon de la targeta de so. A continuació, graveu sons de prova per confirmar que el maquinari està configurat correctament. Per iniciar una gravació utilitzeu l’ordre rec:

root@Laptop:~# rec prova.ogg

Parleu pel micròfon i observeu si el programa detecta activitat d’entrada(sabreu que hi ha activitat si veieu caràcters que es mouen al costat del tamany del fitxer resultant). En acabar la gravació(CRTL+c) escolteu el fitxer resultant utilitzant, per exemple, l’ordre play:

root@Laptop:~# play prova.ogg

Figura 1.18: Programa rec captant l’àudio del micròfon

Ices2 L’Ices2, tot i no poder utilitzar diversos recursos alhora, permet captar la senyal del micròfon per tractar-la i, posteriorment, enviar-la al servidor. Fins ara, només havíeu treballat amb fonts configurades en mode “playlist”. El mode “playlist” consistia en assenyalar a la font on podia trobar la música, mitjançant una llista de reproducció, i aquesta música era codificada i enviada pertinentment al servidor configurat. El mode “live” en certa manera funciona de la mateixa manera, només canvia que, en comptes de donar una llista de reproducció a la font, se li dóna l’arquitectura d’àudio que utilitza el sistema operatiu i el dispositiu de so que vol ser transmès.

Creeu un directori de treball i copiu el fitxer de referència per editar-lo:

root@Laptop:~# mkdir live root@Laptop:~# cp /usr/share/vnuml/scenarios/files/local/ices2/ices-alsa.xml ./live

Obriu el fitxer de configuració de la font i observeu els camps. Heu de configurar la font amb els següents paràmetres:

Modifiqueu els paràmetres per tal d’aconseguir que la font s’adeqüi als paràmetres anteriors.

Reinicieu el servidor icecast:

# parant el servidor i tornant-lo a encendre server2:~# /etc/init.d/icecast2 stop server2:~# /etc/init.d/icecast2 start

Modificats els paràmetres, inicieu el bombeig cap al servidor.

root@Laptop:~# cd live root@Laptop:~# ices2 ices-alsa.xml

Figura 1.19: Flux generat per l’Ices vist a la pàgina del servidor

A partir d’aquest exercici utilitzareu el programa ffplay per sentir els fluxos del servidor.

# terminal de la host root@Laptop:~# ffplay http://10.34.0.254:8000/radio.ogg

Posseu en marxa el ffplay, parleu pel micròfon i escolteu el flux provinent del servidor. Observeu quina magnitud té el retard del so.

Liquidsoap Liquidsoap és un llenguatge de programació desenvolupat amb l’objectiu de produir fluxos d’àudio i de vídeo per alimentar servidors Icecast. Mentre la majoria de fonts de servidor funcionen a partir d’un fitxer de configuració, el liquidsoap funciona a partir d’scripts, usant un llenguatge funcional, que és interpretat.

Pel què fa a funcionalitats, és de les fonts de servidor més completes del mercat: permet barreja de recursos, canvis de recursos, amplificació del so, downsampling etc. A més, incorpora un servidor telnet per tal que l’administrador de la font pugui interactuar amb ella mentre funciona, sense la necessitat de parar-la i modificar l’script que usa.


Figura 1.20: Esquema de funcionament del liquidsoap

Funcions interessants del liquidsoap

Com es veu en l’esquema anterior, s’ha de generar un script en format .liq, que contingui els fluxos i les funcions que els combinen i modifiquen. Qualsevol script escrit per liquidsoap, ha de començar amb el següent shebang:

#!/usr/bin/liquidsoap
Llista de reproducció

Creeu una llista de reproducció de format PLS amb els fitxer presents a la carpeta /usr/share/vnuml/scenarios/files/local/liquidsoap/mix. Teniu les especificacions del format PLS al següent enllaç: http://en.wikipedia.org/wiki/PLS_(file_format). Podeu comprovar que l’heu configurat correctament si l’executeu amb un programa de reproducció de música i es reprodueix el contingut especificat a la llista.

Quan hagueu enllestit la llista de reproducció, creeu un script anomenat radio1.liq que generi un flux a partir de la llista de reproducció creada i l’enviï al servidor Icecast. Aquest flux s’ha d’anomenar /radio1.ogg.

Per iniciar el bombeig del flux creat, assegureu-vos que teniu privilegis d’execució sobre l’script generat (usant l’ordre ls -l al directori on heu creat l’script) i executeu-lo:

root@Laptop:~# ./radio1.liq

Observeu algun error?

La funció output.icecast.vorbis ha de transmetre sempre un flux infal·lible. Un flux infal·lible és aquell que, abans de ser transmès, s’ha comprovat que conté la informació que ha de dur. Per exemple, si un flux d’àudio prové d’una llista de reproducció present a un directori, es comprova que la música que es necessita per reproduir a la llista és present a la ruta especificada.

L’error que mostra el terminal és degut a que la llista de reproducció que s’envia no ha estat verificada abans d’emetre-la. Per tan, el liquidsoap decideix no emetre’l. Per sol·lucionar aquesta situació hi ha diverses vies possibles:

Els tres mètodes anteriors tenen en comú que generen silenci quan no són capaços de reproduir els arxius especificats.

En qualsevol moment, podeu aturar el bombeig utilitzant al combinació de tecles CTRL+c.

Inicieu l’script radio1.liq, comproveu que sona correctament amb ffplay.


Figura 1.21: Fluxos radio.ogg i radio1.ogg presents al servidor

Dues llistes de reproducció

Amb liquidsoap podeu reproduir dos recursos musicals mesclats. Per aconseguir-ho, es poden mesclar dues llistes de reproducció, dues cançons o una llista de reproducció i una cançó. En el nostre cas, veureu com es poden mesclar dues llistes de reproducció de tal manera com ho faria una taula de mescles.

Modifiqueu la llista anterior de tal manera que contingui només dues pistes de música de la carpeta mix. Creeu una llista de reproducció que contingui la resta de les cançons.

Repasseu les anotacions sobre liquidsoap que s’han fet més amunt i genereu un flux que sigui la mescla de dos fluxos, un generat a través de la llista de música clàssica i l’altre generat a partir de la llista de música restant. Anomeneu el flux d’àudio /radio2.ogg.

Executeu l’script i confirmeu, usant el ffplay, que efectivament el flux que distribueix el servidor és resultat de mesclar les dues llistes de reproducció.

Usant el paràmetre weights a dins de la funció add. Per exemple, si es vol donar 4 vegades més intensitat al flux1 que al flux2 es fa de la següent manera: var = add(weights = [ 4,1 ], [ flux1,flux2 ]). Modifiqueu l’script radio2.liq de tal manera que el flux de música clàssica predomini a la mescla.

Veu

A continuació, creeu un script anomenat radio3.liq. Aquest script ha d’aconseguir transmetre el contingut del micròfon al servidor. Canvieu el nom del punt de muntatge i assigneu-li el nom /radio3.ogg. Assegureu-vos que heu matat el procés de bombeig de l’Ices2 abans d’escoltar el flux que envia el liquidsoap a través de l’script radio3.liq. Per què creieu que si envieu dos fluxos provinents de la mateixa font, hi ha un error?

Llista de reproducció + locutor

Per acabar, creeu un nou script que sigui el resultat de mesclar un flux provinent del micròfon amb el flux que genera la llista de reproducció de música clàssica. Configureu-ho de tal manera que la el locutor predomini en la mescla, deixant la música en un pla secundari.


1
Quantitat de bytes que s’envia al client al moment de l’establiment de la connexió
2
En el fitxer de configuració s’haurà d’indicar que es vol utilitzar el fitxer playlist.txt a l’etiqueta <param name=“file”>.
3
hw:0,0 és el dispositiu d’entrada d’àudio per defecte. És l’utilitzat en totes les configuracions en mode directe

Ce document a été traduit de LATEX par HEVEA