Re: AW: gstreamer and sbcdec problem

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

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

On Wednesday 16 December 2009, Marian Harbach wrote:
> Hey thanks for the reply. To clarify:
>
> I use gstreamer to run a 16kHz PCM wav file through one sbc encoder/decoder
> step and save the results back to a 16kHz PCM wav file. When I examine the
> original file and the result file in a tool like Audacity, there is an
> offset between the two files of about 0.0125 secs. If I delay one file
> accordingly, the waveforms in the remaining parts fit.

Yes, this is something to be expected unless I'm mistaken. You can google
for "SBC algorithmic delay" or something like this.

> Yet, the first couple of samples of the original waveform have no
> resamblances with the resulting waveform.

This may actually need a bit of tweaking. When starting encoding, we don't
have a preceding history, but older nonexisting samples are still needed as
input for the polyphase filter. The encoder from bluez currently treats those
missing samples as zero. Having a quick look at A2DP spec again, I don't see
any special explanations about how the encoding process should start.
Experimenting a bit with the reference binary encoder and trying to guess
how it deals with the initial samples may help.

> If that delay mentioned above was actually a fixed value, I'd have no
> problem in my application.

It should be a fixed value, which only depends on encoding parameters.

> But the delay depends on input filesize 

This is strange. The encoder/decoder works with the stream of data and is not
even supposed to know how big is the input file.

Either your tool is not very precise at measuring this delay, or there could
be some bugs in sbc or in the gstreamer layer.

I suggest you to experiment with standalone sbcenc/sbcdec comand line tools
and check if the same behavior is also reproduced there.

> and also increases when running the result file through an sbcenc/sbcdec
> pair again. At least that is the pattern that I see for now.

Sure, there is a constant delay introduced on each encode/decode operation.
Repeating it multiple times will result in this delay accumulating.

-- 
Best regards,
Siarhei Siamashka

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