Speex decodifica va male

Question

sto usando Speex per codificare alcuni dati audio e inviarlo su UDP, e decodificarlo sull'altro lato. Ho eseguito alcuni test con speex, e notato che se decodifico un pacchetto subito dopo che esso codificati, i dati decodificati è in alcun modo vicino ai dati originali. La maggior parte dei byte all'inizio del buffer sono 0. Così, quando ho decodificare l'audio inviati su UDP, tutto quello che ottiene è il rumore. Questo è come mi sto codifica l'audio:

bool AudioEncoder::encode( float *raw, char *encoded_bits )
{
    for ( size_t i = 0; i < 256; i++ )
        this->_rfdata[i] = raw[i];
    speex_bits_reset(&this->_bits);
    speex_encode(this->_state, this->_rfdata, &this->_bits);
    int bytesWritten = speex_bits_write(&this->_bits, encoded_bits, 512);
    if (bytesWritten)
        return true;
    return false;
}

questo è come sto decodifica l'audio:

float *f = new float[256];
// recvbuf is the buffer I pass to my recv function on the socket
speex_bits_read_from(&this->_bits, recvbuf, 512);
speex_decode(this->state, &this->_bits, f);

Ho il check-out la documentazione, e la maggior parte del mio codice arriva dalla codifica esempio / decodifica campione dal sito Speex. Non sono sicuro di quello che mi manca qui.

Answer 1

Ho trovato la ragione per i dati codificati era così diversa. C'è il fatto che è una compressione lossy come diceva Paolo Scardine, e anche che Speex funziona solo con 160 fotogrammi, in modo che quando il recupero dei dati da PortAudio a Speex, ha bisogno di essere da "pacchetti" di 160 fotogrammi.

Answer 2

In realtà parla introduce un ulteriore ritardo per i dati audio, ho scoperto da enginiering inversa:

narrow band : delay = 200 - framesize + lookahead = 200 - 160 +  40 =  80 samples 

wide band   : delay = 400 - framesize + lookahead = 400 - 320 + 143 = 223 samples

uwide band  : delay = 800 - framesize + lookahead = 800 - 640 + 349 = 509 samples

Dato che il lookahead viene inizializzato con zereos, si osservano i primi campioni di essere "vicino allo zero".

Per ottenere il giusto tempismo, si deve ignorare quei campioni prima di ottenere i dati audio effettivi avete alimentate nel codec. Perché vale a dire, non so. Probalby l'autore di Speex mai importato su questo dato Speex è per lo streaming, non in primo luogo per l'archiviazione e ripristino dei dati audio. Un'altra soluzione (per non sprecare spazio) è, si mangimi (framesize-delay) zeri nel codec, prima di alimentare i vostri dati audio effettivi, e quindi far cadere l'intero primo Speex-frame.

Spero che questo chiarisce tutto. Se qualcuno familiarità con Speex legge questo, sentitevi liberi di correggermi se sbaglio.

EDIT: In realtà, decoder ed encoder hanno sia un tempo di lookahead. La formula attuale per il ritardo è:

narrow band : delay = decoder_lh + encoder_lh =  40 +  40 =  80 samples 

wide band   : delay = decoder_lh + encoder_lh =  80 + 143 = 223 samples

uwide band  : delay = decoder_lh + encoder_lh = 160 + 349 = 509 samples

Answer 3

Si consiglia di dare un'occhiata qui per qualche codifica semplice / decodifica: http://www.speex.org/docs/manual/speex -Manual / node13.html # SECTION001310000000000000000

Dal momento che si sta utilizzando UDP si può anche lavorare con un jitter buffer per i pacchetti riordinare e roba.