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:
signature.asc
Description: This is a digitally signed message part.
