Allora ho bisogno di un piccolo chiarimento riguardo il sistema sonoro linux e dei vari Desktop Environment.
So che ALSA e OSS ( ormai deprecato ) si occupano del livello più basso , quello a contatto con l hardware e che si sonfigura nel kernel ( quasi sempre nel caso di alsa ).
Quello che ho poco chairo riguarda i vari : ESD, ARTS ( per i DE ) e xine , gstreamer.
So che ARTS è il gestore sonoro di KDE e ESD di gnome.
Diciamo che arts serve per far funzionare l audio dei programmi di kde ....mentre anche con solo alsa posso far funzionare madplay da console...e fin qui tutto ok.
Però non capisco perchè nel centro di controllo KDE , sotto alla sez. AUDIO, oltre a AUTOMATICO si possa anche scegliere direttamente sia alsa che arts.
Se arts è il sistema sonoro di kde come fanno a funzioare i programmi come amarok e k3b dal punto di vista sonoro se scelgo alsa ( e delle volte l ho fatto e funziona perfettamente ) ?
Altro discorso e chiarimento è il seguente : xine e gstreamer ( ho sempre usato il primo ) fondamentalmente a che livello stanno rispetto ai precedenti nomi che ho fatto ?
Scusatemi se chiedo chiarimenti qui, ma googlando non dico certo di non aver trovato informazioni, ma sto cercando qualcosa che mi faccia un confronto tra tutti questi.
Grazie in anticipo a tutti
chiarimento sistema sonoro e vari demoni...
Moderatore: Staff
Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
-
useless
- Staff
- Messaggi: 3896
- Iscritto il: dom 12 ott 2003, 0:00
- Località: A place where the streets have no name
- Contatta:
in effetti la cosa è piuttosto intricata.
di per sé, un programma potrebbe usare direttamente l'API di ALSA per riprodurre suoni (OSS ormai è obsoleto, ma da questo punto di vista è equivalente ad ALSA).
il problema è che molte schede audio, le più economiche soprattutto, non hanno un mixer hardware integrato (o, in certi casi, ALSA non lo sa usare), e quindi, appena un'applicazione si mette a riprodurre suoni, le altre non riuscirebbero a fare altrettanto, dato che la scheda è "monopolizzata" dalla prima.
per ovviare a questo sono stati concepiti i demoni che citi tu, ossia arts, esound, e altri ancora. sostanzialmente, un'applicazione, invece di usare l'API di ALSA, usa quella di arts, e questo si preoccupa di mixare in software tutti i flussi audio in ingresso, e di riprodurre il risultato attraverso la scheda audio. peraltro, arts fa abbastanza pietà, ed è molto lento a fare il suo lavoro: ecco perché sui pc meno recenti, spesso l'audio risulta "laggato".
dovresti quindi avere capito perché nel centro di controllo di kde puoi scegliere un modo di output per arts: è quello che usa per accedere alla scheda audio. ed in effetti, a me non compare arts stesso nella lista dei plugin!
arts sarà abbandonato in kde4, che userà una nuova infrastruttura multimediale (che mi pare si chiami photon o qualcosa di simile), che vorrebbe essere compatibile con tutti i possibili modi di riprodurre audio, e la cosa migliore dovrebbe essere farle utilizzare gstreamer.
xine-lib è una libreria che permette di decodificare e riprodurre audio e video mediante la sua API. per come viene utilizzata, ad esempio, da amarok, puoi considerarlo alla pari di arts, anche se in realtà sta un pelo sopra, e può a sua volta utilizzare arts per effettuare l'output (forse non prevede l'opzione, ma in linea di principio potrebbe farlo). è vagamente simile a gstreamer, nell'utilizzo pratico.
gstreamer è una cosa mooooooolto più in grande, che vorrebbe unificare tutto quel che fanno i vari sw/lib citati sopra. in sostanza è composto da una serie di componenti in grado di effettuare varie operazioni: (de)muxing, decoding, encoding, output, input, ecc. esso espone poi un'API ben definita, attraverso la quale è possibile istanziare i vari componenti ed interconnetterli, creando una catena che può svolgere i compiti più disparati. in questo modo, il compito di interpretare i vari formati di file è lasciato solo a gstreamer. di conseguenza, è solo lui che definisce i vari formati supportati o meno da un programma. ad esempio, se è stato compilato col supporto xvid, qualunque player video che usa gstreamer sarà in grado di riprodurre file xvid. e quando inventeranno nuovi formati, basterà inserire il supporto a questi in gstreamer perché tutte le applicazioni, anche quelle scritte PRIMA, siano in grado di riprodurli.
questo dovrebbe anche spiegare perché le altre distro hanno un pacchetto base per gstreamer, e poi altri tipo gstreamer-mp3, gstremer-vorbis, ecc...
insomma, gstreamer è una figata. ancora un po' acerbo, ma promette assai
.
di per sé, un programma potrebbe usare direttamente l'API di ALSA per riprodurre suoni (OSS ormai è obsoleto, ma da questo punto di vista è equivalente ad ALSA).
il problema è che molte schede audio, le più economiche soprattutto, non hanno un mixer hardware integrato (o, in certi casi, ALSA non lo sa usare), e quindi, appena un'applicazione si mette a riprodurre suoni, le altre non riuscirebbero a fare altrettanto, dato che la scheda è "monopolizzata" dalla prima.
per ovviare a questo sono stati concepiti i demoni che citi tu, ossia arts, esound, e altri ancora. sostanzialmente, un'applicazione, invece di usare l'API di ALSA, usa quella di arts, e questo si preoccupa di mixare in software tutti i flussi audio in ingresso, e di riprodurre il risultato attraverso la scheda audio. peraltro, arts fa abbastanza pietà, ed è molto lento a fare il suo lavoro: ecco perché sui pc meno recenti, spesso l'audio risulta "laggato".
dovresti quindi avere capito perché nel centro di controllo di kde puoi scegliere un modo di output per arts: è quello che usa per accedere alla scheda audio. ed in effetti, a me non compare arts stesso nella lista dei plugin!
arts sarà abbandonato in kde4, che userà una nuova infrastruttura multimediale (che mi pare si chiami photon o qualcosa di simile), che vorrebbe essere compatibile con tutti i possibili modi di riprodurre audio, e la cosa migliore dovrebbe essere farle utilizzare gstreamer.
xine-lib è una libreria che permette di decodificare e riprodurre audio e video mediante la sua API. per come viene utilizzata, ad esempio, da amarok, puoi considerarlo alla pari di arts, anche se in realtà sta un pelo sopra, e può a sua volta utilizzare arts per effettuare l'output (forse non prevede l'opzione, ma in linea di principio potrebbe farlo). è vagamente simile a gstreamer, nell'utilizzo pratico.
gstreamer è una cosa mooooooolto più in grande, che vorrebbe unificare tutto quel che fanno i vari sw/lib citati sopra. in sostanza è composto da una serie di componenti in grado di effettuare varie operazioni: (de)muxing, decoding, encoding, output, input, ecc. esso espone poi un'API ben definita, attraverso la quale è possibile istanziare i vari componenti ed interconnetterli, creando una catena che può svolgere i compiti più disparati. in questo modo, il compito di interpretare i vari formati di file è lasciato solo a gstreamer. di conseguenza, è solo lui che definisce i vari formati supportati o meno da un programma. ad esempio, se è stato compilato col supporto xvid, qualunque player video che usa gstreamer sarà in grado di riprodurre file xvid. e quando inventeranno nuovi formati, basterà inserire il supporto a questi in gstreamer perché tutte le applicazioni, anche quelle scritte PRIMA, siano in grado di riprodurli.
questo dovrebbe anche spiegare perché le altre distro hanno un pacchetto base per gstreamer, e poi altri tipo gstreamer-mp3, gstremer-vorbis, ecc...
insomma, gstreamer è una figata. ancora un po' acerbo, ma promette assai
.Anzitutto grazie per il post di risposta...
In seconda istanza..
potremo dire che non esiste un unico demone che riesce a far "suonare" tutti i programmi...
es: amarok , o i suoni di k3b, se non installo arts non riuscirò a sentire niente benchè abbia installato alsa correttamente?
Altro discorso pe gaim ad esempio che ho notato che anche solo con alsa riesce a "suonare" i suoi avvisi..
Quindida quando ho capito tutto dipende dal programma che si vuole utilizzare...e allora per un desktop stile fluxbox, che non ha demoni propri, se eseguo applicazioni varie come k3b, amarok, xine-ui, gaim, skype dovrei installare comunque arts anche se non uso un DE come KDE ( e nel caso ESD se usassi programmi in gtk ) ?
In seconda istanza..
potremo dire che non esiste un unico demone che riesce a far "suonare" tutti i programmi...
es: amarok , o i suoni di k3b, se non installo arts non riuscirò a sentire niente benchè abbia installato alsa correttamente?
Altro discorso pe gaim ad esempio che ho notato che anche solo con alsa riesce a "suonare" i suoi avvisi..
Quindida quando ho capito tutto dipende dal programma che si vuole utilizzare...e allora per un desktop stile fluxbox, che non ha demoni propri, se eseguo applicazioni varie come k3b, amarok, xine-ui, gaim, skype dovrei installare comunque arts anche se non uso un DE come KDE ( e nel caso ESD se usassi programmi in gtk ) ?
questo lo so , ma con gentoo avevo avuto dei problemi proprio riguardo amarok che compilandolo con la use flag xine all avvio continuava a dirmi che non trovava motori sonori per poter funzionare..e mi dava questo messaggio in avvio chiudendosi poi da sologiberg ha scritto:Amarok può usare xine, gstreamer...
amaroK could not find any sound-engine plugins. amaroK is now updating the KDE configuration database. Please wait a couple of minutes, then restart amaroK.
If this does not help, it is likely that amaroK is installed under the wrong prefix, please fix your installation using:
$ cd /path/to/amarok/source-code/
$ su -c "make uninstall"
$ ./configure --prefix=`kde-config --prefix` && su -c "make install"
$ kbuildsycoca
$ amarok
More information can be found in the README file. For further assistance join us at #amarok on irc.freenode.net.
.