I'm using speex under symbian (8000 hz, 16 bit) narrow band. The phones API only give me a buffer of 4096 bytes in recording.To reproduce audio I must fill up the buffer of the same dimension. 4096 isn't a multiple of 320. I want encode the audio in streaming. The solution that I adopt to encode is: - Divide 4096-256 bytes in 12 frames of 320 bytes. - Therefore the frame number 13 is composed only of 256 bytes. I encode every frame and I fill up the last frame (13th) with 0 to reach 160 samples. I'm not sure, but it seems a low degradation but wish to know if it is due to Speex or to the phone... i'd like to know if the zeroes-padding i use could affect the encoder in term of audio quality and, most of all, performance. Regards, maurizio PS: I compile it with FIXED_POINT 1 and ARM4_ASM
Maurizio Cembalo wrote:> I'm using speex under symbian (8000 hz, 16 bit) narrow band. > The phones API only give me a buffer of 4096 bytes in recording.To > reproduce audio I must fill up the buffer of the same dimension. 4096 > isn't a multiple of 320.What you get is rarely a multiple of 20 ms, that's what buffering is for.> I want encode the audio in streaming. > > The solution that I adopt to encode is: > - Divide 4096-256 bytes in 12 frames of 320 bytes. > - Therefore the frame number 13 is composed only of 256 bytes. > > I encode every frame and I fill up the last frame (13th) with 0 to > reach 160 samples.Ouch! I've seen creative ways of screwing up the encoding, but this is a new one :-) No, it doesn't work! If you don't have enough samples to fill up a frame, just keep them for the next time. That being said, encoding 2048 samples (4096 bytes) at a time seems like a horrible thing to do for VoIP because it will add insane amounts of latency. It's recommended to capture audio smaller bits at a time.> I'm not sure, but it seems a low degradation but wish to know if it is > due to Speex or to the phone...Definitely the phone!> i'd like to know if the zeroes-padding i use could affect the encoder > in term of audio quality and, most of all, performance.I affects quality, badly. Please fix that :-) Jean-Marc
I would consider another solution to your problem. 1) Save the 256 bytes, wait for 64 more in the next 4096 buffer and give speex a complete frame. Or... 2) Not sure on this but I believe simply dropping the 13:th frame could be an option. < 10% packetloss is barely audible with correct decoding and playback. //JT -----Ursprungligt meddelande----- Fr?n: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] F?r Maurizio Cembalo Skickat: den 13 april 2007 18:30 Till: speex-dev@xiph.org ?mne: [Speex-dev] Symbian and buffer of 4096 bytes I'm using speex under symbian (8000 hz, 16 bit) narrow band. The phones API only give me a buffer of 4096 bytes in recording.To reproduce audio I must fill up the buffer of the same dimension. 4096 isn't a multiple of 320. I want encode the audio in streaming. The solution that I adopt to encode is: - Divide 4096-256 bytes in 12 frames of 320 bytes. - Therefore the frame number 13 is composed only of 256 bytes. I encode every frame and I fill up the last frame (13th) with 0 to reach 160 samples. I'm not sure, but it seems a low degradation but wish to know if it is due to Speex or to the phone... i'd like to know if the zeroes-padding i use could affect the encoder in term of audio quality and, most of all, performance. Regards, maurizio PS: I compile it with FIXED_POINT 1 and ARM4_ASM _______________________________________________ Speex-dev mailing list Speex-dev@xiph.org http://lists.xiph.org/mailman/listinfo/speex-dev
> 2) Not sure on this but I believe simply dropping the 13:th frame could > be an option. < 10% packetloss is barely audible with correct decoding > and playback.NO, that'll sound like shit because it creates a discontinuity in the audio. It's not the same as losing a packet because there's no concealment possible for that. Jean-Marc> //JT > > > > > -----Ursprungligt meddelande----- > Fr?n: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] F?r > Maurizio Cembalo > Skickat: den 13 april 2007 18:30 > Till: speex-dev@xiph.org > ?mne: [Speex-dev] Symbian and buffer of 4096 bytes > > I'm using speex under symbian (8000 hz, 16 bit) narrow band. > The phones API only give me a buffer of 4096 bytes in recording.To > reproduce audio I must fill up the buffer of the same dimension. 4096 > isn't a multiple of 320. > > I want encode the audio in streaming. > > The solution that I adopt to encode is: > - Divide 4096-256 bytes in 12 frames of 320 bytes. > - Therefore the frame number 13 is composed only of 256 bytes. > > I encode every frame and I fill up the last frame (13th) with 0 to > reach 160 samples. > I'm not sure, but it seems a low degradation but wish to know if it is > due to Speex or to the phone... > i'd like to know if the zeroes-padding i use could affect the encoder > in term of audio quality and, most of all, performance. > > > Regards, > maurizio > > PS: I compile it with FIXED_POINT 1 and ARM4_ASM > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev > > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev >