Speex dev - Apr 2007 - 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

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
>