Re: gstreamer and sbcdec problem

[Siarhei Siamashka <siarhei.siamashka@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On Tuesday 15 December 2009, Marian Harbach wrote:
> Hi,
>
> I have the same problem as described in this post:
>
> http://www.spinics.net/lists/linux-bluetooth/msg03627.html

This looks like either some completely random garbage gets there (valgrind
can probably help), or the decoder is not reinitialized properly and has
some stale data from the previous decode in some of its internal buffers.

> I found that depending on filesize, the original input is delayed by some
> bytes (180-260 for 16kHz PCM input) 

SBC introduces some delay to the audio data due to the way how it works.
Some of the trailing samples of the buffer you feed to the 'sbc_encode' 
function are actually not represented fully in the encoded data for this
frame, but are kept in the ring buffer and get processed later on
next 'sbc_encode' call.

The reference binary encoder introduces exactly the same delay.

> and additionally the first few samples 
> are overwritten when doing sbcenc followed by sbcdec.

Could you please clarify this part? In what way and where do they get
overwritten (in files, memory buffers, ...)?

> Is there a fix for this issue?

My guess is that the client application can be aware of this delay and take it
into account somehow.

Also I don't have much trust in the current bluez SBC decoder implementation.
Its quality may be not the very best. I was considering to eventually review
its code, do some refactoring and merge some of its parts with the encoder
(SBC encode and decode are quite symmetric), but did not find some spare
time for this yet. Considering that bluez got SBC sink support now, improving
the decoder may make sense.

-- 
Best regards,
Siarhei Siamashka

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]