programmino per tesi..

[giorget1]

devo fare la tesi di ing. informatica e mi sono scelto un progetto abbastanza simpatico Imho.. quello che devo fare e' catturare il segnale in entrata dal microfono di un palmare (applicazione client) comprimerlo e trasferirlo via wi-fi ad un server che si occupera' di riprodurlo...

utilizzero' vb embedded sul palmare e .net per il lato server... ora se per le winsock non ci sono problemi, ho gia' programmato una chat da palmare via wireless, i problemi sono per il microfono, qualcuno se ci sono funzioni che permettono di gestirlo?? inoltre.. sapete di problematiche riguardanti il wi-fi in tal lato??

[cionci]

Sei sicuro su VB ? Visual Basic quando si tratta di lavorare sui bit è una vera ciofeca....
Perchè non VC++ Embedded ?

[giorget1]

beh sparavo, la comodita' era quella di non dover implementare da capo, potrei recuperare la parte winsock dall'altro programma, la vedi cosi' ostica?

[cionci]

VB Embedded non è .Net... Quindi la parte di Winsock è diversa...
Diciamo solo che VB non è l'ideale... Mentre i socket in C++ sono praticamente identici fra la versione per CE e quella desktop...

[alexmaz]

Dico un eresia...

ma usare .Net Compact Framework sul palmare? :fagiano:

[cionci]

Ma è uscito ? E funziona su CE 3.0 ?
Altrimenti potrebbe essere una soluzione...

[cionci]

Infatti:
"The Microsoft .NET Compact Framework is supported on Pocket PC 2000, Pocket PC 2002, Windows Mobile 2003-based Pocket PCs and embedded systems running Windows CE .NET 4.1 and later"

[alexmaz]

Ah lui usa CE 3? Ops :fagiano:

[giorget1]

eh gia'... la comodita' e' che l'embedded era abbastanza comodo col suo simulatore, l'altro .net mai usato

[giorget1]

oggi mettevo giu la struttura.......



mic-->compressione->buffer->scocket invio x il client

contrario lato server piu' altre varie ottimizzazioni


ora il problema si pone sulla compressione (come e che codec posso usare??

[giorget1]

p.s. problemi relativi al alla trasmissione su wi.fi ??

[cionci]

Dipende dalla banda che hai a disposizione... Se non sbaglio 10 Mbs...
Direi di entrare nel limite di 1/10 o 1/20 della banda a disposizione....quindi sotto ai 500 o 1000 Kbps...
Devi partire da una acquisizione, direi, a 22 Khz, 16 bit, stereo... 22000*16 bit/campione * 2 canali = 704000 bps = 687,5 Kbps... In teoria ci saresti già dentro...
Allora potrebbe bastarti una codifica di Huffman ad alfebeto dinamico...

Se non conosci la codifica di Huffman su Google trovi molta roba...
La codifica dinamica, rispetto all'algoritmo standard, non fa altro che generare dinamicamente (ad ogni K passi, con metodi statistici) un alfabeto diverso...

Chiamando C il campione letto...
A[n] dipenderà da {A[n-1], C[(n-1)K + i]} per i = 0..K-1
A[n] servirà per codificare i campioni C[nK + i] per i = 0..K-1

Io direi di crearti A[0] in base ad una statistica su un'oretta di parlato (metti il microfono davanti alla TV)... Le varie componenti di A[0] saranno la frequenza di ricorrenza dei valori da 0 a 255 all'interno di ogni byte letto dal microfono (normalizzato alla fine per il numero di byte letti)...
Facendo il grafico dei vari valori di A dovrebbe essere non livellato, ma con notevoli sali e scendi... Se è livellato allora non è adatta la codifica di Huffman...
Anzi direi che sarebbe meglio aumentare l'alfabeto a 16 bit (cioè pari al campione)... In modo da contare i valori dei vari campioni e sicuramente avrai una compressione migliore...
La codifica di Huffman è loss-less (e velocissima)... I livelli di compressione probabilmente andranno nell'ordine del 2:1 (poco, ma sufficiente)... Senza contare che ti permette, in un certo senso, anche di criptare il canale...
Potresti anche inserire un ulteriore livello di compressione (ma con perdita) raggruppando in una sola codifica valori contigui con probabilità bassa di presentarsi... In questo modo avrai notevoli miglioramenti (i simboli con probabilità + bassa corrispondono a codifiche + lunghe)...


Poi se dal server volessi spedire la lettura del microfono tramite internet potresti usare decine di protocolli già pronti... Come ad esempio la stessa codifica GSM...

[giorget1]

allora, oggi sono andato a riparlare col docente, l'applicazione e' da svilupparsi in visual c# o c++, posso lasciar stare il lato palmare che verra' poi ripreso da loro in futuro, il problema e' che se in vb me la cavo abbastanza e di java ci capisco un po', di c++ e c# so davvero poco soprattutto in ambiente visual, in normale un po' ci mastico... dunque premesse queste basi la vedete ostica realizzare un'applicazione del genere in circa 3 mesi??

[cionci]

No...ma come fate a sviluppare l'applicazione palmare dopo ?!?!? E le specifiche dell'algoritmo di compressione chi te le da ?

[giorget1]

boooh per ora quello che gli serve e' questo.... per la compressione posso usare algo gia' esistenti

[cionci]

Allora cerca l'agloritmo del GSM ;)

[giorget1]

ma per ipotesi (ho deciso di farlo in c#) e' possibile tramite directx acquisire direttamente in formato compresso appongiandosi a qualche codec??

[cionci]

Mmmmm...sinceramente... BOH

Potrai sicuramente sfruttando il registratore multimediale... Comunque quando hai il codice dell'algoritmo di compressione fai anche presto ad adattarlo al tuo audio... Lo impacchetti e lo spedisci ;) Oppure se l'algoritmo lo permette, basta lasciare un canale aperto e sincronizzarsi...

[giorget1]

ecco hai toccato un'altro tasto bastardo... ho trovato molte info su come registrare su disco ma non su come "spedire" su un ip... ha idee??

[giorget1]

ecco hai toccato un'altro tasto bastardo... ho trovato molte info su come registrare su disco ma non su come "spedire" su un ip... hai idee??

[cionci]

Una semplice connessione TCP è pù che sufficiente...anche se solitamente per applicazioni realtime si usa UDP...

[giorget1]

no, intendo a comandi..... non ho proprio idea di come far "scrivere" i dati che apprendo via directsound sulla porta tcp/udp

[cionci]

Con C# proprio non posso aiutarti...