Thu Jun 21 12:02:13 CEST 2007

Thu Jun 21 12:02:13 CEST 2007 Briareos
Buondi', ho iniziato a stendere un protocollo TS-like e sto scrivendo server e client per questo protocollo. Il server è scritto in python, il client ( che per ora serve solo per testare il server ) è anche lui temporaneamente in python. Il tutto verrà rilasciato sotto GPL non appena le specifiche del progetto raggiungano uno stato "stable". Senza dilungarsi troppo, se qualcuno ha una buona esperienza di python ( server ), o di gtk+/qt (client) e trovasse il porgetto interessante mi contatti ( in priv o su jabber ). Il draft delle specifiche ( devo aggiornarlo, non temete non è tutto qui cio' che è gia stato fatto ) lo trovate a quest'url: [url:13n2n498]http://www.elgraz.net/getfile.php?name=roger_draft[/url:13n2n498] Grazie molte, sorry per l'OT ( poi mica troppo... TS lo si usa tutti no? ) e lockate pure il thread se lo ritenete oppurtuno. Saluti, Bria

Thu Jun 21 14:44:53 CEST 2007 tux [ITA]
Bash script? Se vuoi ti faccio l'installer e l'updater in bash! EDIT: Nome? I.T.A. Speak?

Thu Jun 21 15:32:25 CEST 2007 Briareos
.... leggi le specifiche Cmq il nome provvisorio del protocollo è roger, anche se dovrà essere cambiato a causa di Roger Wilco... Susu, uomini del sw libero so che siete la fuori !

Thu Jun 21 16:44:11 CEST 2007 jdoe@gentoo-it
in bocca al lupo avessi il tempo mi piacerebbe darti una mano ma altrimenti faccio come con slux e il sito che non gli ho più detto nulla a che punto siete?

Fri Jun 22 00:06:25 CEST 2007 Slux
Ottimo! purtroppo so veramente poco di python... @jdow: non ti preoccupare!

Sun Jun 24 07:11:51 CEST 2007 peoro
Ho gia' provato una volta con zukka e codernem a fare un progetto simile... Il difficile in questo caso non e' stendere il protocollo o pianificarne il funzionamento, il difficile, o meglio, le difficolta' che avevamo trovato noi, sono state altre: non abbiamo trovato molte librerie audio decenti (che usino alsa, che siano multipiattaforma, che siano semplici da usare e, in questo caso, che abbiano bindings per python), lo stesso vale per i codecs audio (ci sono quelli che distruggono qualsiasi processore, quelli che consumano troppa banda, quelli che non ti fanno capire niente di cio' che viene detto e quelli che lavorano su chunks troppo grossi da aggiungere un delay di 25 minuti...). Poi arrivano i problemi legati alla manipolazione dei chunks audio (come trovare ed eliminare i fruscii e l'eco, come zittire del tutto i giocatori quando sono zitti, come limitare il volume massimo, come mixare piu' tracce audio offsettando i volumi o i tempi), quindi problemi legati alla trasmissione dell'audio (in una stanza con 10 persone, dove tutti parlano e dove alcuni hanno scelto di non sentire altri o di abbassarne/alzarne la voce, come inoltri i dati? mandi a tutti tutte le tracce audio separate per farle poi mixare al client? richiede troppa banda e aggiunge qualche problema di sincronizzazione per le tracce. per ogni presente mixi la traccia audio fatta apposta per lui e la mandi? richiede troppa cpu e fa diminuire la versatilita' dell'applicazione. una via di mezzo dove mixi le tracce audio a gruppi di due o tre e quindi le inoltri? richiede algoritmi troppo complessi per la mia povera mente ubriaca ed importa tutti gli svantaggi dei due sistemi che mischia)... Quando poi, alla ricerca di qualche libreria in nostro soccorso, abbiamo trovato vari progetti opensource simili, molto piu' grossi e fondati del nostro, morti a causa dei problemi sopraelencati, abbiamo abbandonato del tutto l'idea... Comunque se sei davvero interessato perche' non apri un bel progetto su sourceforge o savannah e provi a cercare collaboratori anche esterni al forum della community italiana di tremulous? [img:j8zg7siy]http://www.marmotta.ch/faccine/stordita.gif[/img:j8zg7siy]

Sun Jun 24 10:52:17 CEST 2007 CoderNeM
Io avevo fatto un sistema del genere (in java :F) sia client che server. Il problema grosso, come fatto notare da peoro, e' lato server e sul codec scelto: il mixing delle tracce deve essere velocissimo e bisogna gestire ottimamente le ottimizzazioni in termini di concorrenza e banda usata.. Purtroppo non ho molto tempo, e di c++/python non so nulla, altrimenti comunque avrei partecipato volentieri. Ad ogni modo tienici aggiornati!

Sun Jun 24 11:34:08 CEST 2007 whitenoise[ITA]
Non per rovinarti l'entusiasmo, ma non sarebbe meglio partire da qualcosa che già esiste? Tempo fa Arbiter aveva trovato questo progettino, simile a TS e funzionante con ALSA: http://mumble.sourceforge.net/ Non l'abbiamo mai provato (io sono allergico alla compilazione) quindi non sappiamo come funziona... ciao Luca

Sun Jun 24 20:04:58 CEST 2007 Luk
sei allergico a tutte le cose intelligenti...come usare Debian! Briaeros forse ho la soluzione che fa per te visita http://www.hackerforum.devil.it chiedi di Wicker o The Wanderer scrivono in phyton inoltre hanno formato un forum apposito phyton italia.

Mon Jun 25 13:39:37 CEST 2007 Arbiter
I cloni di teamspeak già ci sono e farne un altro, sopratutto in python non credo che sia una grande idea e una soluzione ottimale. Per questo tipo di applicazioni vedo molto meglio C/C++ che un linguaggio di scripting (si ok, si possono fare moduli in C per le porzioni critiche del progetto ma a questo punto si fa prima e meglio - imho - a scrivere tutto in C/C++). Inoltre ci sono altri cloni di TS già ad un avanzato stadio di sviluppo, riscrivere l'ennesimo software ex-novo non credo che sia molto saggio, specialmente se si prefigge le medesime finalità dei suddetti cloni (se poi è solo per scopo didattico ben venga). Secondo me è più conveniente vedere di collaborare ad uno di quesi progetti piuttosto che cominciarne un altro da zero.

Tue Jun 26 14:33:38 CEST 2007 Briareos
Ok, calma e gesso e rispondo a tutti @peoro: come formato per la voce speex è maturo, è specifamente pensato per la voce eper risparmiare banda è open e parte di vorbis... Il mixing è necessario farlo lato server, e sarà il job più pesante ( anche l'unico cpu-bound ) del server. @arbiter: si, è vero ci sono altri progetti... ce ne fosse uno affermato open non mi sarei posto il problema, avrei usato quello, ma visto che ancora non c'e volevo provare a progettarne uno per conto mio, magari va bene, magari scopro che è un cagata... chissa'... Riguardo al linguaggio, python non è prestazionalmente potente, ma per il mix, ad esempio, i moduli ritengo possano essere una misura sufficente ( ci lavoro da un anno su un proxy di content filtering, ti assicuro che rende ). Stendere l'intero progetto in C/C++ porterebbe a un FORTE rallentamento dello sviluppo e un probabile nuovo progetto fantasma che non raggiungerà mai una stato usabile. Le risorse di tempo e numero di sviluppatori sono poche ed è preferibile un sw completo leggermente meno performante di una perenne alfa. Oltre queste considerazioni il vero scopo è "ludico" senza pretese di sorta, quindi il ero interessato a qualcuno che potesse divertirsi nello sviluppare un progetto simile. Python è un linguaggio che si impara in un pomeriggio, quindi chiunque abbia delle solide basi di programmazione e fosse interessato al progetto puo' partecipare. Alternativamente vi farò sapere qualcosa appena avrò il tempo di portarlo fuori da questo stato embrionale, magari per un po di beta testing ... Seeya

Tue Jun 26 16:04:33 CEST 2007 Arbiter
beh, non mi resta che augurarti buona fortuna anche se continuo a non approvare la scelta di python per una applicazione di questo tipo

Tue Jun 26 17:01:04 CEST 2007 peoro
E' quello che abbiamo usato anche noi, ma non va affatto bene... Per encodare con speex un chunk di meno di 640 bytes, con qualita' 6 ciuccia circa il 20% della mia CPU (un athlon 2400+) al secondo. Ok, ad un server con due CPU recenti ciuccera' forse anche meno del 5% del totale, ma e' sempre troppo troppo: come hai 10 persone in una stanza devi decodificare 10 messaggi, fare un casino di mixamenti (che anche questi, beh, non sono troppo leggeri: usando l'algoritmo piu' banale che c'e' devi fare 100 mixate ogni frame e i frames al secondo devon essere come minimo una ventina, se vuoi stare sotto i 100ms di delay embedded) e poi ricodificare tutti i chunks mixati. Sui server pubblici e gratuiti di teamspeak di NGI ci sono costantemente circa un paio di centinaia di persone, in stanze di anche 50 persone l'una...

Wed Jun 27 10:45:34 CEST 2007 Briareos
@Arbiter: chi virà vedrà Sono daccordo con te per tutte le motivazioni che mi hai dato, ma veramente questo è l'unico modo in cui ho una speranza di fare qualcosa... @peoro: Ummh... beh a dire il vero l'encoding delle strem è demandato al client, il server deve occuparsi solo del mixing ( sarà per questo motivo che ts lagga sempre? ) quindi il job di encoding è da contare single-user, mentre per il mix devi considerare la totalità degli utenti connessi... cmq dammi un po di tempo per fare qualche prova ( appena lo trovo il tempo, tra esami e lavoro.... ) e ti farò sapere le mie impressioni, intanto grazie della dritta.. btw speex lo usano in parecchi... ( ts in primis ) quindi una via deve esserci.....

Wed Jun 27 13:54:21 CEST 2007 zukka
mmmh... non credo si possano mixare stream encodati senza prima decodificarli... no ? il server per mixare deve decodificare gli stream, mixarli e codificarli... o esitono codec isomorfi per il mix ?? ahh una nota... con peoro siamo anche riusciti a parlarci usando il nostro embrione di programma e la qualita' non era male

Fri Jun 29 10:52:26 CEST 2007 Briareos
right zucca, tucciai ragggione e il lavoro è enorme visto che dovresti prevedere una linea di mix per ogni utente ( o al max per ogni stanza ) ... Leggendo ingiro per la rete molti alla fine ripiegano sul forward di tutti gli strem cosi' come arrivano al server... anche se la cosa non mi aggrada per nulla. Mah vediamo appena arrivo al punto, sono senza rete a casa e sviluppare senza documentazione online è un incubo

Fri Jun 29 14:34:23 CEST 2007 zukka
eheh purtroppo io e il peoro ci siamo gia' schiantati su sti problemi... una linea di mix per utente e' l'unca strada percorribile... non si puo' fare per stanza perche' altrimenti ognuno avrebbe indietro il proprio stream audio >,<. La seconda soluzione risparmia cpu ma la banda cresce linearmente per i client e n*(n-1)mente per il server :O comunque mi candido come beta tester

Sun Jul 01 19:50:49 CEST 2007 CoderNeM
Io ti posso passare il mio server prototipo fatto in java, con due engine di mixing: certo, e' java, e' LENTO (e butta, direbbe la peora) pero' a livello architetturale la soluzione progettata non e' malaccio.. Se ti puo' essere di aiuto come starting point, fai un UP

Mon Jul 02 10:37:57 CEST 2007 CoD
Butto qui un'idea per non aprire un nuovo thread... se non vi piace ignoratela. Leggendo dell'European Exhibition Tournament mi e' venuto in mente un mod carino che potrebbe essere interessante: una sorta di bot che specti la partita e trasmetta le immagini in streaming. Cosi' gli spettatori potrebbero assistere alle partite senza doversi connettere la server... ... ok e' assurdo eh?

Mon Jul 02 21:26:27 CEST 2007 jackal@slack
woa no anzi! Nessun timore quindi di accettare spettatori Caspita e' un'ideona!

Tue Jul 03 08:03:17 CEST 2007 CoD
Si', peccato che io non vi sappia aiutare.... mi chiedo pero' se la banda non andrebbe troppo giu' costringendo il server che ospita il match a trasmettere in streaming le immagini. Forse si potrebbe fare un bot lato client, in questo modo il server gestirebbe solo un altro giocatore e sarebbe il pc del client a sobbarcarsi lo streaming verso gli spettatori esterni.

Tue Jul 03 14:18:06 CEST 2007 jackal@slack
si parlava gia' di un bot no? Intanto che mi arrovello, cosa intendi per io non vi SO aiutare? Credevo fossi un ottimo programmatore!

Wed Jul 04 09:43:52 CEST 2007 CoD
Me la cavo benino... ma nel mio ramo: PHP, programmi lato server, sistemi multilingua e accessibili.... con il C sono una frana

Wed Jul 04 16:14:39 CEST 2007 Briareos
Umhh, l'idea non è male, pero' sarebbe da delocalizzare il bot e il frontedn web. Facendo spedire al bot le immagini a una seconda macchina di forntend, la q.ta di traffico necessaria per il server è predicibile e gli spect caricano la macchina di frontend e non il server di game. Per il bot servirebbe modificare un po l'engine di q3 facendogli fare una sorta di rander_to_texture, grabbase i frame e stremmarli ( si puo' fare con ffmpeg ) a una seconda macchina se serve lo strem. Il bot poi lo si controlla da console con i vari follow. Boh le mie idee le ho lancite... maledetti ladri di threads bb

Thu Jul 05 08:20:08 CEST 2007 CoD
Io vedo due possibilita' (ma forse sono strabico ): 1) si fa un bot autonomo come dice Briareos e magari gli si insegna a spostarsi random seguendo i player (che so 20 sec per ciascuno) e prediligendo quelli che stanno combattendo (qui pero' sono 'azzi: se e' un client non puo' sapere cosa succede nel resto della mappa) 2) si fa un sistema che si possa usare da dentro al proprio client, in questo modo possiamo lasciare l'onere di "viaggiare" per la mappa ad un essere umano che non solo e' di sicuro piu' intelligente e puo' prevedere dove ci sara' battaglia, ma puo' fare inquadrature esterne e diventare un vero e proprio REGISTA! Con questo secondo sistema introduciamo un elemento personale e artistico nella trasmissione. Se la cosa funziona potrebbe essere la prima "trem tv" del mondo