Settantasettesimo articolo dedicato alle web radio.

Cominciamo le guide avanzate dedicate ad icecast su linux, studiando i file XML di esempio che vengono forniti a corredo con ices2.

E’ chiaro che il server icecast può non essere utilizzato necessariamente con ices2, ma in questo caso, risulta secondariamente necessario alla trasmissione (quantomeno per passare da un livello amatoriale ad uno semi-professionale) conoscere e sapere manipolare i file di configurazione, che in questo caso sono del tipo Extensive Markup Language.

Il primo di questi file che considereremo è quello dedicato allo streaming da ALSA. Alsa sta per Advanced Linux Sound Architecture e contraddistingue in questo caso una modalità di streaming improntata sul live o sull’ingresso della scheda audio, ad esempio un banale simulcasting.

Andiamo quindi a considerare le parti di questo file, che è meglio ricordare, si trova in /usr/share/doc/ices2/examples

La prima parte del file è questa:

Il tag background va settato ad 1 se si vuole porre ices in background.

Il tag logpath identifica una directory che può essere scritta dall’utente che ices2 sta identificando. Può essere piazzata ovunque, ma chiaramente devono essere abilitati i permessi di scrittura.

Il tag logfile identifica il nome del file di log. Alla riapertura del log file l’esistente viene rinominato come “logfile”.1

Il tag logsize indica la massima grandezza del file di log prima di andare in modalità ciclica di scrittura.

Il tag loglevel Indica un numero che rappresenta il livello di logging prescelto.
1 – Loggati solo i messaggi d’errore
2 – Come il punto uno, ma anche i Warnings verranno loggati
3 – Come il punto due, ma anche i messaggi informativi verranno loggati.
4 – Come il punto tre, ma anche i messaggi di debug verranno loggati.

Il tag consolelog, se impostato ad 1 causa l’apparizione dei messaggi loggati in console, piuttosto che in un log file.

Nelle applicazioni più sensibili al ritardo (tra cui OVVIAMENTE una radio), è sconsigliato avere logging in console. E’ un opzione utile in fase di studio del software.

Il tag pidfile consente di creare un file in cui è scritto il ProcessID del processo ices2 corrente.

Veniamo adesso alla sezione stream.

La sezione stream è composta da tre sottoparti, chiamate metadata, input e instance.

Esaminiamole tutte e tre nel dettaglio.

Metadata intuitivamente si capisce già su cosa abbia influenza, ovvero si occupa di trasmettere tutti i dati a corredo della trasmissione stessa.

Le sue sottoparti sono nome, genere, descrizione e url, esattamente gli stessi campi che si trovano in generale nei server shoutcast, ma in realtà praticamente in tutti.

Input invece tratta la parte hardware della trasmissione, vediamo come.

Module, ci indica di scegliere quale modulo hardware stiamo trattando, qui si parla di alsa, per cui scriviamo alsa.

I successivi parametri sono rate, channels, device e i metadata.

Rate indica la frequenza di campionamento del segnale analogico di partenza. E’ normalmente settata a 44100 hertz, se non sapete come mai, vi invito caldamente a leggere il teorema divino.

Channels indica se vogliamo una trasmissione mono o stereo.

Device indica la posizione della scheda audio nell’elenco delle periferiche del nostro sistema.

Metadata e metadatafilename rappresentano uno switch di scrittura e un nome file dove vengono scritti i metadati.

Istance rappresenta la generica istanza di trasmissione. Dico “generica” in quanto, se conoscete il software di cui stiamo parlando, o avete letto altri articoli (non per forza di questo blog) su ices2, saprete che è un source multi-instanziabile, ovvero ha la possibilità di trasmettere, a differenza di molti software per shoutcast ad esempio, lo stesso stream a più server contemporaneamente.

hostname indica l’indirizzo ip del server da contattare, può essere sia un ipv4 che ipv6.

port indica la porta del processo sul server da contattare, vi ricordo che si comunica in tcp.

password non necessità spiegazioni

mount, identifica il cosidetto mountpoint, ovvero un particolare stream in un singolo server icecast, che può trasmettere più stream contemporaneamente.

yp è uno switch che abilita o disabilita la visione pubblica dell’emittente.

La sezione Encode indica i parametri di codifica dello stream, che devono matchare chiaramente quelli impostati in hardware nella sezione precedente.

Il tag downmix è uno switch che indica se, in caso di necessità, si preferisce diminuire il numero di canali da due ad uno, ovvero passare da stereo a mono.

La sezione Resample definisce la frequenza in hertz a cui passare in caso ad esempio di problemi di rete. Tipicamente si preferisce passare ad un valore pari alla metà della frequenza di partenza. Ricordatevi sempre che sempre per il teorema divino, se volete ricostruire senza aliasing un segnale che ha banda N hertz, avete bisogno di una frequenza di campionamento NON INFERIORE a 2N hertz. Quindi avere 22050 hertz di frequenza di campionamento, consente di sentire discretamente una banda di 10000 hertz. Sufficiente per il parlato ma non certo per la marcia turca di mozart.

Con questa sezione finisce la parte alsa, vedremo nei prossimi articoli di considerare anche le altre opzioni possibili, ovvero OSS e una playlist.

Settantaseiesimo articolo dedicato alle web radio

Carissimi internauti vi ricordate di questo articolo?

In quell’articolo si parlava di Icecast, un server di streaming rilasciato con licenza GPL e che permette lo streaming audio/video dei file Ogg, sia Vorbis che Theora. Lo abbiamo introdotto in ambiente windows, adesso, vedremo di parlarne anche in ambiente linux.

Cominceremo dall’inizio, ovvero dall’installazione dei componenti fino all’effettiva messa in onda della radio. Successivamente, in una guida avanzata, procederemo a vagliare e valutare tutte le possibili opzioni. Per adesso, mettiamo in moto la nostra radiolina linuxiana.

Supponiamo di lavorare su una debian-based

Una volta installati i due programmi, effettuiamo una modifica al file /etc/default/icecast2 tramite un qualsiasi editor di testo modificando il parametro ENABLE, da false a true. Ciò permetterà di potere effettuare la prossima operazione.

Facciamo partire il nostro server icecast2 tramite il comando:

Potremo quindi trovare l’interfaccia web, comprensiva di pannello di amministrazione, all’indirizzo http://localhost:8000
Studieremo successivamente le peculiarità web di questo server di streaming,

In questo momento abbiamo il nostro server di streaming funzionante (almeno in locale) e possiamo cominciare a lavorare su ICES2.

Ices2 è:

usato per fornire a server audio streaming Icecast2 flussi
audio Ogg Vorbis. Supporta sia input audio live dalla scheda audio, sia la
ricodifica di file Ogg Vorbis da una scaletta.

Creiamo tre cartelle da terminale:

La prima servirà a contenere i log, la seconda servirà invece a contenere i file di configurazione mentre la terza conterrà i file musicali.

All’interno della cartella /usr/share/doc/ices2/examples/ si trovano tre files:

I tre files corrispondono alle tre modalità di streaming, ovvero tramite ALSA (Advanced Linux Sound Architecture) oppure OSS (Open sound system) oppure tramite una playlist di file OGG, che è il caso che tratteremo in questa guida basilare.

Copiamo il file ices-playlist.xml all’interno della cartella /etc/ices2 ad esempio con il comando

a questo punto dobbiamo verificare che vi sia matching perfetto tra la password impostata su ices2 e quella del server icecast, come del resto avviene per qualsiasi accoppiata, encoder/server.

La password del server di streaming icecast2 si trova nel file /etc/icecast2/icecast.xml alla sezione AUTHENTICATION.
La password da impostare in ices2, che deve chiaramente essere uguale a quella (per adesso di default) del server icecast2, è nella sezione INSTANCE del file ices-playlist.xml.

Penseremo a tutti i parametri opzionali (tra cui anche la modifica delle password) nella guida avanzata. Per adesso il nostro unico obiettivo è quello di mettere (almeno localmente) la radio in trasmissione.

Dopo avere controllato la corrispondenza tra le password passiamo al riempimento della cartella music, precedentemente impostata con i file ogg vorbis che ci interessa trasmettere.

Una volta riempita la cartella music, creiamo il file playlist.txt all’interno della cartella /etc/ices2 e scriviamo una riga per ciascun file OGG che dobbiamo trasmettere, con tanto di PATH completo.

Una volta creato il file, startiamo ices2 con il seguente comando:

In questo modo il server icecast avrà come mountpoint il flusso creato da ices2.

Settantacinquesimo articolo dedicato alle web radio

Questo articolo potrebbe risultare leggermente fantascientifico, ma in realtà non risulterà esserlo affatto.
Cominciamo a discutere e valutare la possibilità, di idealizzare, cercare e perchè no creare un parser audio, o quantomeno, di andarci molto vicini.

Secondo Wikipedia:

Il parsing o analisi sintattica è il processo atto ad analizzare uno stream continuo in input (letto per esempio da un file o una tastiera) in modo da determinare la sua struttura grammaticale grazie ad una data grammatica formale. Un parser è un programma che esegue questo compito.

Considereremo vari casi nella studio del parsing audio applicato alle web radio, cominceremo dividendo dicotomicamente il problema di studio:

Vedremo che le cose non sono poi cosi diverse, ma vanno valutate separatamente.

Un file audio digitalizzato non compresso è composto, come abbiamo già visto tempo addietro da una frequenza di campionamento, una risoluzione ed un numero di canali.

Possiamo quindi esprimere in sintassi XML un file audio in un primo modo:

<brano>
<titolo>Titolo Brano</titolo>
<infoAggiuntive>Informazioni Aggiuntive</infoAggiuntive>
<canale>
<campione>
<id>ID</id>
<risoluzione>Risoluzione</risoluzione>
</campione>
</canale>
</brano>

In questo modo è rispettata una struttura gerarchica che riproduce esattamente il contenuto di un file audio.

Un file audio, normalmente, ovvero per la maggior parte dei generi musicali, ha una struttura LOGICA di questo tipo:

<brano>
<intro>introduzione</intro>
<strofa>strofa</strofa>
<refrain>refrain</refrain>
<strofa>strofa</strofa>
<outro>Outro</outro>
</brano>

Tale struttura divide il file in parti, ovvero l’introduzione, il ritornello, le strofe e l’uscita.

Combinando le due rappresentazioni è possibile effettivamente creare una struttura gerarchica suscettibile al parsing ad opera di un parser, che potrebbe quindi strutturare un file audio dato in input.

Passando dai file alle web radio, il discorso non cambia molto.

Si potrebbe benissimo considerare una web radio alla stregua di un brano, ottenendo ad esempio:

<flusso>
<brano>NomeBrano</brano>
<Vocal>InterventoVocale</vocal>
<brano>NomeBrano</brano>
</flusso>

Oppure la stessa programmazione:

<webradio>
<Day>
<hour>
<programma>Nomeprogramma</programma>
</hour>
</day>
</webradio>

e così via…

Abbiamo già parlato di un programma che segmentava l’input di una web radio in parti in base a dei pattern, tale programma si chiama streamripper.

In quel caso il discrimen è dato dal volume, che può essere preso come delimitatore di sezione all’interno del secondo modello di parsing.
Si può passare dal campo intro al campo strofa in base ad un superamento di soglia di volume prefissata, oppure esattamente all’inizio della parte vocale, quindi in base ad un controllo del timbro o delle frequenze in gioco.

La trasposizione in linguaggio XML di un brano non è un puro esercizio matematico fine a se stesso.

Alcune sue applicazioni, oltre allo stesso streamripper, possono essere Tunatic e Midomi, di cui parleremo in prossimi articoli.

Il primo programma riconosce titolo e autore di un brano semplicemente ascoltandolo, mentre il secondo tenta di riconoscere i dettagli di un brano, quando viene cantato. Sono per lo più applicazioni da cellulare, per chi non riesce a trovare un titolo di un brano sentito alla radio.

Tuttavia queste applicazioni, applicate a stream digitali quali ad esempio le web radio o le radio fm stesse, consentono di controllare in modo proporzionale alla precisione dell’algoritmo di riconoscimento dei brani, se una radio ha difformità tra i tracciati cartacei e il flusso, ad esempio nella reportistica siae.

Ho effettuato un controllo a tappeto della web radio che ascolto più spesso (radio mela) e della radio in fm in cui ho lavorato più recentemente (dabliuradio)

In entrambi i casi i risultati sono stati soddisfacenti ma non perfetti. Spesso la mia memoria ha vinto su tunatic, ma altrettanto spesso è accaduto il contrario.]]> http://www.fabriziomondo.com/blog/2009/12/28/parsing-audio/feed/ 0 http://www.fabriziomondo.com/blog/2009/10/02/studio-di-un-mixer/ http://www.fabriziomondo.com/blog/2009/10/02/studio-di-un-mixer/#comments Fri, 02 Oct 2009 10:37:22 +0000 Fabrizio Mondo http://www.fabriziomondo.com/blog/?p=493

Settantaquattresimo articolo dedicato alle web radio

Continuiamo il nostro excursus attraverso l’hardware necessario per strutturare degnamente una web radio, argomento di questo articolo sono i mixer.

Un mixer è un apparecchiatura che di base effettua una miscelazione, ovvero una emissione contemporanea di due o più strumenti musicali (intesi in senso lato, teoricamente qualsiasi attrezzo che sia in grado di generare onde sonore).

Tale strumento, fondamentale per una radio che effettui interventi vocali o strumentali live, è rappresentabile in questa immagine:

Le sorgenti etichettate con S, possono essere rappresentative di tutto, dai microfoni, a strumenti musicali qualsiasi, come precedentemente detto. L’anello di congiunzione tra le sorgenti e il mixer stesso è detto connettore, e ne abbiamo già parlato.

Tra i tre connettori di cui abbiamo parlato è sempre meglio optare per XLR in quanto bilanciato, ma il bilanciamento non è esattamente argomento di questo articolo, e la sua trattazione è rinviata ai commenti, o ad un altro articolo.

Approfondiamo allora il processo di percorso di un segnale (che in generale è una qualsiasi funzione dipendente dal tempo) all’interno di un mixer, e per farlo, approfitto a piene mani di chi ne sa qualcosina meglio di me, in fatto di mixer e attrezzature audio.

Tra gli stadi di ingresso abbiamo:

Il primo stadio, chiamato (1) in figura, è un amplificatore operazionale e rappresenta il primo stato in assoluto di qualsiasi mixer, generalmente il primo con guadagno o amplificazione significativi.

Il secondo stadio, chiamato (2) in figura, è un equalizzatore e per questo si rimanda alla pagina di wikipedia apposita, io posso anticiparvi che è principalmente uno strumento che consente di incrementare o decrementare l’ampiezza di componenti in frequenza desiderata di un segnale.

Il terzo stadio, chiamato (3) in figura, è un fader, collegato ad un LED picco di canale, rappresentanti uno dei migliori strumenti per il controllo di guadagno di un canale.

Tra gli stadi della sezione master abbiamo:

Il primo stadio, chiamato (4) in figura, è il mixaggio vero e proprio, composto da un sommatore di segnale, che mixa, appunto, tutti i segnali dei vari canali, qualunque cosa essi rappresentino.

Il secondo stadio, chiamato (5) in figura, è invece un altro fader, chiamato fader master, antecedente l’output del mixer.

Per tutto quello che riguarda l’ottimizzazione dell’audio e il miglioramento dell’output del mixer, consiglio la lettura del manuale da cui questo articolo è nato, ovvero questo.

Continuiamo invece trattando un caso specifico, ovvero vediamo cosa sono i vari componenti e le varie parti di un mixer, il mixer MG16/6FX.

Esaminiamolo parte per parte:

La prima manopola rappresenta il cosiddetto GAIN, o guadagno e regola il livello del segnale di ingresso.

Il rilevatore PEAK si accende quando il livello del segnale sale fino ad essere 3dB inferiore al livello di saturazione del segnale. E’ un potenziale campanello d’allarme.

Il pulsante 80 attiva il filtro passa alto con frequenza di taglio pari ad 80 hertz.

Questa fila di manopole rappresenta invece l’equalizzatore. Consentono di regolare l’ampiezza della porzione di frequenze interessate dalla manopola. Sono divise in alti (frequenza base 10 Khz), medi (frequenza base regolabile da 250 a 5000 Hz) e bassi (sotto i 250 Hz).

Le due manopole AUX regolano il segnale che viene inviato ai canali ausiliari. Il tasto PRE permette di scegliere se inviare al canale ausiliare 2 il segnale in pre o post fading.

La manopola EFFECT regola il livello del segnale inviato al bus effetti.

La manopola PAN|PAN/BAL|BAL regola il posizionamento del canale sui canali gruppo o bilancia il segnale nel caso in cui ci si occupasse di un ingresso stereo in un canale stereo.

Abilita il canale al missaggio.

Il PreFader Listen button serve ad abilitare il monitoraggio (effettuato tramite output ai jack phones e c-r out). Il segnale viene trasmesso pre-fading.

I pulsantini 1-2 e 3-4 abilitano il canale alla trasmissione ai bus group corrispondenti, che avviene A PRESCINDERE dallo stato del tasto ST.
Il fader invece serve per regolare il livello generale di segnale del canale.

Settantatreesimo articolo dedicato alle web radio, quarto articolo dedicato alle web tv.

Questo è un articolo che ricapitola un pò tutto quello che abbiamo fatto, per mezzo di un immagine. Sono graditi consigli su argomenti da trattare, inerenti comunque il campo dello streaming. Visto che vorrei fosse argomento della mia tesi di laurea, qualche aiuto, non fa certo male…

Settantaduesimo articolo dedicato alle web radio

Una delle tantissime critiche che gli amici che mi seguono nella creazione dei miei articoli mi fanno, è quella di dedicarmi ed essermi dedicato pochissimo all’hardware.

Nel cercare di colmare questa lacuna, cominciamo parlando della cosidetta “cavetteria” ossia i connettori.

I connettori più usati in ambito audio, e che troviamo praticamente sempre in qualsiasi web radio più complessa di un semplice winamp + dsp + server shoutcast, sono questi:

• Connettore RCA
• Connettore JACK
• Connetore XLR

Il connettore RCA è uno dei connettori più usati per audio semiprofessionale. Il connettore RCA è mono, viene cablato su cavo coassiale e può trasportare un solo canale alla volta.

Nel caso più comune, il cavo è di tipo maschio/maschio, con una spina a ogni estremità. Un eventuale cavo di prolunga è di tipo maschio/femmina, con presa volante su un’estremità del cavo.

Il connettore è composto da una protuberanza centrale (maschio) o da un foro (femmina), circondati da un anello, separati da un isolante di plastica o ceramica. Il bloccaggio della connessione non è meccanico, ma avviene a pressione, sfruttando la piccola differenza di diametro dell’anello esterno.

Da notare che, a differenza di connettori professionali come il tipo XLR, il polo centrale viene in contatto con l’altro connettore prima della massa, per cui accade spesso che durante la connessione si verifichino ronzii o soffi se questa avviene ad apparecchiature accese.
Connettori audio RCA.

Nel cablaggio di apparati audio, questo connettore si trova frequentemente in configurazioni a Jack-Doppio RCA, che permette di collegare un lettore CD o un PC ad un Mixer; in questo caso i connettori RCA sono colorati in modo diverso, per distinguere il canale destro dal sinistro, il destro è solitamente rosso, mentre il sinistro può essere sia bianco che nero.

(Fonte: Wikipedia)

Il connettore jack è senza alcun dubbio il connettore più usato per la connettività delle piccole apparecchiature audio. Si distinguono abitualmente tre tipi di connettori jack secondo il diametro :

* Jack 2.5 mm: il più piccolo jack,
* Jack 3.5 mm: il jack classico, corrispondente alla presa cuffia,
* Jack 6.35 mm: il jack usato per la sonorizzazione semi-professionale per collegare gli altoparlanti, gli amplificatori o i microfoni.

Ognuno di questi jack si declina in due versioni :

* jack mono, per le trasmissioni di un suono monofonico. Questo tipo di jack possiede due contatti : una referenza, sul corpo della fiche, e il segnale sulla punta.
* jack stereo, per la trasmissione di un suono stereofonico. Questo tipo di jack possiede tre contatti, cioè gli stessi contatti che il connettore jack nonché un anello supplementare che permette la trasmissione di un altro canale audio.

Questo connettore dispone di tre contatti e quindi può realizzare connessioni audio sbilanciate con 2 canali (sinistro e destro) e connessioni audio bilanciate ad 1 canale.

Il connettore JACK offre un buon contatto elettrico, una buona resistenza meccanica e una pessima resistenza alla trazione.

(Fonti: Dreamvideo, kioskea)

Il connettore XLR fu prodotto per la prima volta negli Stati Uniti dalla Cannon Electric, la sigla XLR deriva dal nome originale Cannon X , a cui furono aggiunte prima un blocco (Latch) di sicurezza, e poi un isolante di gomma (Rubber) attorno ai poli. La sigla XLR è a volte interpretata come “eXtra Long Run”. Un connettore XLR può avere diversi schemi di piedinatura, i tipi più comuni sono a tre, quattro e cinque poli.

Nella sua versione a tre poli, il connettore XLR viene usato normalmente per la terminazione di linee audio bilanciate, ma spesso viene usato anche per segnali sbilanciati creando un corto circuito tra il polo di massa e quello freddo. È praticamente l’unico tipo di connettore impiegato per il collegamento di microfoni, mentre per i segnali a livello di linea è più comunemente usato il jack stereo.

Bisogna fare attenzione alle apparecchiature che usano il polo 3 come caldo, perché può capitare facilmente di invertire la polarità del segnale audio.

Sempre la versione tripolare viene usata per le connessioni audio di tipo digitale: in questo caso il sistema di modulazione usato non pone problemi nel caso di connessioni in controfase.

(Fonte: Wikipedia)

Settantunesimo articolo dedicato alle web radio.

Uno dei problemi più comuni nella creazione di stazioni web radiofoniche ma anche che trasmettono in modulazione di frequenza, è la cosidetta fault tolerance.

La tolleranza ai guasti è un parametro che permette di quantificare in modo molto preciso la professionalità di una radio, in quanto permette di capire quanto il servizio è affidabile, nelle ventiquattro ore della giornata.

Esaminiamo uno schema possibile di web radio, in cui il controllo è dato ad una regia e che lavora con UN SINGOLO computer, partendo dalla periferia e arrivando al centro.

A sinistra troveremo le apprecchiature di INPUT, che sono microfoni e lettori.

Nel caso in cui essi si guastassero, è sufficiente la loro riparazione o, ancora meglio, la loro sostituzione, e cosi per tutte le periferiche di input.

A destra troviamo le periferiche di OUTPUT audio, ovvero l’amplificatore per cuffia e le cuffie. Anche in questo caso, nel caso in cui si guastasse qualcosa è sufficiente la sua sostituzione, perchè tutti componenti NON VITALI per la trasmissione, e che possono essere cambiati anche a run time e piuttosto facilmente.

I problemi più seri, si verificano in altri casi, ovvero quando si hanno:

1) Problemi hardware al computer di regia
2) Problemi software al computer di regia
3) Problemi di connettività
4) Problemi di corrente elettrica
5) Problemi generici ai server esterni

Cominciamo considerando i vari punti, concentrandoci in questo momento però più sul secondo.

I problemi hardware possono succedere in qualsiasi momento e hanno cause più varie. Possono coinvolgere schede madri, ram, alimentatori e quanto altro e possono essere dannosi. Sicuramente un guasto hardware non può essere curato se non tramite la sostituzione del o dei componenti danneggiati, ma nella maggior parte dei casi questo comporta un interruzione del servizio, dovuto appunto allo spegnimento del pc.

In tal caso si deve procedere al MIRRORING.

E’ necessario un computer che funzioni in situazioni di emergenza, che possa trasmettere quando il pc PRINCIPALE è fuori uso. Purtroppo la disconnessione avviene necessariamente, ma è chiaramente più breve se si ha un immediato intervento umano. Del resto, è molto semplice modificare la sorgente di un server di streaming esterno, in modo che l’interruzione sia limitata nel tempo, senza per questo dovere cambiare NESSUN dato sul sito internet.

Il mirroring dovrebbe essere praticamente totale, sia nei files che nella regia, che dovrebbe essere la stessa chiaramente del computer principale.

Un modo per evitare totalmente la disconnessione è quello di cambiare l’impostazione generale e fare veicolare tutto l’audio non più dal computer di regia, ma dal mixer, che poi invierà il flusso audio ad uno (o ad N) computer che si occuperanno della messa in onda, ma questo è argomento di un secondo articolo.

I problemi software possono essere circoscritti a problemi d’applicazione, nel caso in cui l’applicazione della regia si blocca, spesso si finisce di trasmettere, stoppando anche il suono. Il silenzio si può verificare a maggior ragione in controllo mixer, anzi, è ancora più utile effettuare tale tipo di controllo, in quanto in quel caso, potrebbe anche capitare che qualche regista dimentichi abbassati i volumi del canale dedicato alla regia.

Ragion per cui, studieremo adesso un programma, chiamato Pira CZ Silence Detector che svolge proprio la funzione di fare notare quando c’è un pò troppo silenzio.

Scarichiamo il programma da qui: http://www.pira.cz/eng/piraside.zip e scompattiamolo in una qualsiasi cartella del vostro pc. Trovermo alcuni files, tra cui un file htm contenente la guida in linea e l’applicazione, piraside.exe

Apriamola, ci comparirà questa schermata:

Tale schermata ha un level meter a sinistra e dei pulsanti a destra.

Il level meter misura il livello audio, e questo era abbastanza scontato. Vediamo a cosa servono i pulsanti a destra partendo da mixer.

Mixer visualizza il controllo registrazione della vostra scheda audio, dove potrete settare quale sia la periferica del quale input è importante valutare la presenza costante.

Setup invece fa apparire una finestra con delle impostazioni settabili. Il primo tab è Alarm Activation che consente di settare le condizioni per il quale dovrebbero scattare gli allarmi.

L’allarme può scattare se ci sono N secondi di silenzio (settabili) nel canale sinistro, destro, entrambi, o uno dei due. Tale vincolo è settabile, ma non rimovibile. In più, si può aggiungere un controllo sull’orario (dentro o fuori un settabile intervallo) e/o sul giorno.

Inoltre, è possibile fare un controllo opzionale sulla presenza o non presenza di un particolare applicativo aperto. Per fare ciò clicchiamo sul tasto FIND (dopo avere spuntato il flag a sinistra)

e comparirà la seguente schermata:

da qui potremo scegliere la finestra sulla quale ci interessa lavorare.

In basso troviamo invece impostazioni per riportare tutto per com’era. Le due impostazioni settabili sono il numero di secondi sufficienti a fare staccare l’allarme e se bloccare o meno la coda di esecuzione tasks in caso di ricomparsa del suono, chiaramente, la scelta è libera.

Passiamo adesso ad ALARM TASKS:

Questo tab rappresenta l’elenco delle attività che dovrà svolgere il programma (in esatta sequenza) una volta che si è verificata una condizione di allarme.

Le attività possibili sono:

*Send Email: consente di inviare una mail ad un indirizzo qualsiasi a patto di avere i dati di accesso smtp. Consente di inviare anche un file in allegato.

*Save Screenshot: Salva un immagine ritraente il desktop e può anche allegarla ad una mail, inoltre può disattivare lo screen saver

*Open/play 1: Tre campi per potere avviare un programma in condizioni d’allarme, sono settabili anche i parametri.

*Open/play 2: Altri tre campi per potere avviare un programma in condizioni d’allarme, sono settabili anche i parametri.

*Reboot system: consente di spegnere o riavviare il pc

*Kill application: E’ possibile killare una qualsiasi applicazione, compreso il silence detector stesso.

*Switch port pin: E’ possibile switchare il pin di una porta com, da negativo a positivo per un numero di secondi o il piu a lungo possibile.

*Delay: Applica un ritardo alle operazioni

*Send HTTP query: Invia una query http ad un sito internet

*Speak: Fa dire una frase ad un bot.

Una volta decise le attività che il programam deve eseguire, basta cliccare su ADD su UP, DOWN e DELETE, per ordinare una coda.

Nel Tab RETURN TASKS il procedimento è molto simile, semplicemente questa coda gestirà gli eventi da eseguire una volta che tutto sarà ritornato alla normalità.

Le operazioni fattibili sono un sottoinsieme di quelle del tab precedente.

L’ultimo tab riguarda impostazioni generali, si può settare la priorità dell’applicazione, la possibilità di bloccare il level meter (che permette di settare il punto minimo di allarme, la cosidetta soglia), scegliere se usare i font di sistema, usare filtri, loggare gli eventi e utilizzare o meno un programma interno al silence detector per suonare mp3.

Si può infine anche settare la periferica di acquisizione dell’audio, rinominare il programma e i canali e scegliere le modalità di start-up del programma stesso.

Gli altri tipi di problemi possibili per una stazione web radiofonica, sono risolvibili in altro modo.

Gli scatti di tensione elettrica e di connettività si risolvono utilizzando un gruppo di continuità e una connessione a banda garantita, che ha come caratteristica quella della continuità del servizio.

I server di streaming vanno gestiti tramite le interfacce web dei cosidetti applicativi di cast control, ai quali presto dedicherò un articolo.

Settantesimo articolo dedicato alle web radio

Uno dei fenomeni che in Italia ha preso maggiormente piede, si chiama Facebook. Non c’è bisogno che sia io a dirvi cosa sia e cosa rappresenti, anche se una minima discussione me la permetterete.

Facebook è un social network creato da Mark Zuckerberg, che presto è diventato il social network per eccellenza, con iscritti nell’ordine dei milioni. Facebook consente di contattare amici e parenti che magari non si sentivano da molto tempo e crearsi una rete più o meno virtuale di rapporti, di gruppi accomunati da interessi comuni e manie condivise.

Tecnicamente, ogni utente di facebook ha una sua pagina divisa in tab. I principali sono info e bacheca.

Nel tab info compaiono le informazioni personali del contatto, che possono essere, a scelta, più o meno complete. Nel tab bacheca compaiono pensieri, attività, foto e movimenti del profilo dell’usuario, mentre, a lato, compaiono i widget.

I widget sono delle parti, delle porzioni modulari di facebook, che possono essere inserite e tolte a scelta. E’ proprio l’inserimento di un widget in bacheca, l’oggetto del settantesimo articolo.

Facciamo login su facebook e dirigiamoci verso la nostra bacheca.

Cerchiamo, tramite il campo ricerca che si trova in alto a destra, l’applicazione MP3 PLAYER.

Compariranno una serie di opzioni, noi sceglieremo la prima, l’applicazione che ha nel logo, un cane.

Per sceglierla, è sufficiente cliccare su MOSTRA APPLICAZIONE.

Siamo arrivati alla schermata di presentazione dell’applicazione. Clicchiamo su VAI ALL’APPLICAZIONE e potremo così operare concretamente sulle configurazioni del player, affinché ci possa permettere di ascoltare la nostra radiolina.

Consentiamo l’accesso ai nostri dati e procediamo.

La prima schermata che comparirà sarà una schermata con 4 opzioni:

Choice 1:
Single-Song Player (Upload)
Choice 2:
Single-Song Player (Link)
Choice 3:
Multiple-Songs Player (Link)
Choice 4:
Single-Songs Multiple-Players (Link)

Il player può fare molto, streammare canzoni, uploadarne limitatamente altre e, che poi è il nostro campo di interesse, fare ascoltare web radio, o meglio, detto tecnicamente, shoutcast’s streams.

Scegliamo di conseguenza la SECONDA opzione e andiamo avanti con submit.

A questo punto comparirà quest’altra schermata:

In Url inseriamo l’indirizzo della nostra web radio in questa forma:

http://ipserver:porta/;stream.nsv

Si utilizza il link fittizio ;stream.nsv anche se NON si tratta ovviamente di un flusso Nullsoft Shoutcast Video. Ricordatevelo bene.

Settate anche Artist e Title come meglio preferite. Una volta fatto tutto questo, cliccate su UPDATE YOUR PROFILE e vi troverete con il player in bacheca.

Qualora il player non si trovasse in bacheca, potete controllare se non sia finito nei RIQUADRI, in quanto potete scegliere di piazzarlo in entrambi i posti.

Sarà sufficiente a questo punto, cliccare sul tasto play per fare partire il flusso, che NON può partire in automatico e che si interrompe ogni volta che si cambia pagina su facebook.

Sessantanovesimo articolo dedicato alle web radio.

Ci eravamo lasciati con una panoramica delle funzioni della classe shoutcast. Adesso andiamo a vedere con maggiore precisione come realizzare una pagina php che utilizzi tale classe.

Esaminiamo il file demo.php, a corredo con il pacchetto shoutcast che stiamo utilizzando e che abbiamo trovato al sito phpclasses.org

Il file comincia naturalmente in questo modo:

include(“shoutcast.class.php”);

Questi comandi aprono una pagina php e includono all’interno il file shoutcast.class.php.

Esaminiamo adesso la funzione convertseconds, e vediamo cosa fa:

function ConvertSeconds($seconds) {
$tmpseconds = substr(“00″.$seconds % 60, -2);
if ($seconds > 59) {
if ($seconds > 3599) {
$tmphours = substr(“0″.intval($seconds / 3600), -2);
$tmpminutes = substr(“0″.intval($seconds / 60 – (60 * $tmphours)), -2);

return ($tmphours.”:”.$tmpminutes.”:”.$tmpseconds);
} else {
return (“00:”.substr(“0″.intval($seconds / 60), -2).”:”.$tmpseconds);
}
} else {
return (“00:00:”.$tmpseconds);
}
}

La funzione ConvertSeconds accetta la variabile seconds come unico parametro.

Pone in un altra variabile, chiamata $tmpseconds, una stringa composta da due zeri iniziali e il modulo 60 dei secondi contati dalla variabile seconds, rimuovendo le ultime due cifre (che sono probabilmente i centesimi di secondo).

Se $seconds é maggiore di 59, e contemporaneamente anche maggiore di 3599, allora va settata una variabile $tmphours che conterrá una stringa con il numero di ore calcolate a partire dai secondi e una variabile $tmpminutes, che conterrá una stringa con il numero dei minuti.

Se $seconds é solo maggiore di 59, allora il procedimento per le ore non é piú necessario e quindi si effettua solo il calcolo dei minuti.

Se $seconds non é magiore di 59, si riporta il numero di secondi esattamente come sono.

Passiamo adesso alle dichiarazioni:

$shoutcast = new ShoutCast();
$shoutcast->host = “localhost”;
$shoutcast->port = 8000;
$shoutcast->passwd = “YOURPASSWORDGOESHERE”;

La variabile $shoutcast contiene un nuovo oggetto di tipo shoutcast (poca fantasia, ma meglio non confondere le idee).
Settiamo l’host, la porta e la password del server, che chiaramente, sono dati che voi DOVETE avere a disposizione.

Esaminiamo adesso l’ultima funzione della pagina, la piú importante.

La prima operazione é quella di aprire le statistiche dell’oggetto creato, se l’apertura ha successo, recuperiamo l’xml, e quindi, andiamo a fare operazioni di echo (scrittura) dove decidiamo quando e come visualizzare le informazioni a nostra disposizione. Tutti gli echo, ma chiaramente anche gli altri comandi, sono modificabili a vostro piacimento, in base a come vorrete posizionare le informazioni nella pagina. Le variabili history e listeners sono da considerarsi come possibili array, e quindi é necessario un controllo con la funzione is_array

if ($shoutcast->openstats()) {
// We got the XML, gogogo!..
if ($shoutcast->GetStreamStatus()) {
echo ““.$shoutcast->GetServerTitle().” (“.$shoutcast->GetCurrentListenersCount().” of “.$shoutcast->GetMaxListenersCount().” listeners, peak: “.$shoutcast->GetPeakListenersCount().”)\n\n”;

echo “<table border=”0″ cellspacing=”0″ cellpadding=”0″>\n”;
echo ”
<tbody>
<tr>
<td width=”180″><strong>Server Genre: </strong></td>
<td>”.$shoutcast->GetServerGenre().”</td>
</tr>
\n”;
echo ”
<tr>
<td><strong>Server URL: </strong></td>
<td><a href=”\”>GetServerURL().”\”>”.$shoutcast->GetServerURL().”</a></td>
</tr>
\n”;
echo ”
<tr>
<td><strong>Server Title: </strong></td>
<td>”.$shoutcast->GetServerTitle().”</td>
</tr>
<tr>
<td colspan=”2″></td>
</tr>
\n”;