Hi people,
I found that I cannot set A2DP bitpool to anything more than 53 in my
~/.asoundrc file. The bluetooth driver reports an error and keeps
reporting it (becomes useless) until it is restarted.
Bitpool values as high as 128 are possible on Windows Mobile devices
(including mine), which means they are possible in A2DP. Such a high
value is necessary for some genres of current music, which are highly
compressed (the problem was once discussed in one of Xiph Foundation's
articles). SBC is unable to encode such material properly if it
doesn't have enough bandwidth.
I don't understand Bluetooth. So I'm asking you for an advice:
1. Is it actually possible to set SBC bitpool in linux' A2DP to more than 53?
2. If it is, can I ask for a short success story in order to reproduce it?
2. If not, where should I start (in bluez source code) in order to fix
this problem?
Regards
--
Sebastian
On Mon, Oct 10, 2011 at 10:10 PM, [email protected] <[email protected]> wrote:
> 2011/10/10 Siarhei Siamashka <[email protected]>:
>> On Mon, Oct 10, 2011 at 1:40 PM, [email protected] <[email protected]> wrote:
>> Could you please provide a link to the Xiph Foundation's article you
>> have mentioned? Also what does "SBC is unable to encode such material
>> properly" mean?
>
> I remember it was their "About" article, but it seems either they
> shortened it (removing fragments irrelevant to their mission) or it
> has never been there and I've seen it somewhere else. Anyway, the
> whole phenomena is called "Loudness war". CD's are recorded with
> dynamics compression, so their sound has distortions introduced in
> production and high energy in all subbands at the same time. Thus, SBC
> must encode distortions as well as higher energy in all subbands.
Still I would suggest you to try the attached patch just for a test.
It reduces audio volume as part of the sbc encoding process and should
eliminate most of the possible clipping cases on the decoding side.
Some people on Hydrogenaudio forums have investigated the impact of
clipping on the perceived audio quality and found it at least audible:
http://www.hydrogenaudio.org/forums/index.php?showtopic=82112
http://en.wikipedia.org/wiki/Clipping_(audio)
>> The SBC decoder seems to be clamping the out-of-range values [...]
>> not doing any clamping is a lot worse and letting the samples
>> overflow results in really bad audible clicks.
>
> Maybe sin() would help, who knows? Obviously in the decoder, which
> usually cannot be reprogrammed, but future /bluez devices/ could
> benefit from this.
The headset is free to do whatever it likes with the samples falling
out of [-0x8000, 0x7FFF] range, like clipping them or adjusting the
volume or anything else. It does not have to produce files with 16-bit
audio samples but just needs to play some sound in the speakers.
>> What kind of A2DP headset are you using yourself?
>
> Nokia BT-503. Its quality is enough to notice an obvious difference
> between 'computer' bitpool (<=53) and that coming from Windows Mobile
> (128 does not cause skipping yet). In presence of dynamics
> compression, even two guitars with a vocal can be distinguished only
> with higher bitpool. Another example is a symphony - I can hear
> individual instruments from WinMo, and a "movie soundtrack" from
> Bluez. I don't know how the device deals with clicks, but I never
> heard them. Usual (and also annoying) distortion is a 'chirp' in some
> bands.
OK, thanks for the information. It looks like this is not the same
issue as I observed with Logitech FreePulse headset. In any case, I'm
glad that you are interested in A2DP audio quality and would
definitely appreciate any feedback and test results. As I see it,
there are two things to take care:
1. make higher sbc bitpool settings usable in bluez with your headset
2. make sure that sbc codec itself is well behaved and providing
the best results for any available bitpool
But I myself can only comment on the latter.
Using bitpool 128 is kind of weird for SBC codec, because the encoded
data stream has about the same size as the the original data and this
defeats the whole purpose of having any lossy compression at all. It
is also worth mentioning that bluez sbc encoder implementation uses a
bit lower precision analysis filter by default which allows SIMD
optimizations and this should be fine at normal encoding settings. But
uncommenting SBC_HIGH_PRECISION define may be important for getting
better audio quality at higher bitpool settings. Also trying to
enable/disable joint stereo, testing 4 vs. 8 subbands and snr vs.
loudness allocation method may probably have some impact on audio
quality for your use case. I still recommend you to try sbcenc/sbcdec
tools for the experiments with audio quality. They use a somewhat less
common big endian http://en.wikipedia.org/wiki/Au_file_format but you
can get your audio files converted to it using
http://sox.sourceforge.net/ command line tool. Also here I have some
ruby script, which can simplify sbc encoding/decoding testing:
http://cgit.freedesktop.org/~siamashka/bluez/log/?h=sbc-tests
When doing the evaluation of encoding/decoding audio quality with
sbcenc/sbcdec, please keep in mind that the current bluez sbc
*decoder* implementation has some issues. Partially motivated by your
posts, I decided to finally attempt to bring the bluez sbc decoder
into a better shape and already sent one patch to the mailing list for
review. The rest of the fixes are available here and they improve sbc
decoder audio quality:
http://cgit.freedesktop.org/~siamashka/bluez/log/?h=sbc-decoder-fixes
But the synthesis filter still needs to be converted to fixed point
and optimized for performance before really using it in bluez. I'll
try to do this work as time permits and will submit the patches later.
But quality-wise, it should be already possible to use my
'sbc-decoder-fixes' git branch for testing.
--
Best regards,
Siarhei Siamashka
Hi,
2011/10/10 Luiz Augusto von Dentz <[email protected]>:
> It can be 2 things, either a bug or the device maximum bitpool is
> actually 53 so we cannot negotiate it.
My headset indeed reports bitpool range up to 53. WinMo seems to
either override it, or present some features that cause the Nokia BT
chip to report a wider range. Unfortunately I don't know how to
disable encryption in Windows Mobile to capture its bluetooth session
(and how to capture it with Bluez). Can 'hcidump' do this?
> PulseAudio uses 64 as bitpool maximum and it seems to work fine
Yes, wIth movies, games etc. the quality is excellent.
2011/10/10 Siarhei Siamashka <[email protected]>:
> On Mon, Oct 10, 2011 at 1:40 PM, [email protected] <[email protected]> wrote:
> Could you please provide a link to the Xiph Foundation's article you
> have mentioned? Also what does "SBC is unable to encode such material
> properly" mean?
I remember it was their "About" article, but it seems either they
shortened it (removing fragments irrelevant to their mission) or it
has never been there and I've seen it somewhere else. Anyway, the
whole phenomena is called "Loudness war". CD's are recorded with
dynamics compression, so their sound has distortions introduced in
production and high energy in all subbands at the same time. Thus, SBC
must encode distortions as well as higher energy in all subbands.
> The SBC decoder seems to be clamping the out-of-range values [...]
> not doing any clamping is a lot worse and letting the samples
> overflow results in really bad audible clicks.
Maybe sin() would help, who knows? Obviously in the decoder, which
usually cannot be reprogrammed, but future /bluez devices/ could
benefit from this.
> What kind of A2DP headset are you using yourself?
Nokia BT-503. Its quality is enough to notice an obvious difference
between 'computer' bitpool (<=53) and that coming from Windows Mobile
(128 does not cause skipping yet). In presence of dynamics
compression, even two guitars with a vocal can be distinguished only
with higher bitpool. Another example is a symphony - I can hear
individual instruments from WinMo, and a "movie soundtrack" from
Bluez. I don't know how the device deals with clicks, but I never
heard them. Usual (and also annoying) distortion is a 'chirp' in some
bands.
Regards
--
Sebastian Olter
On Mon, Oct 10, 2011 at 1:40 PM, [email protected] <[email protected]> wrote:
> Hi people,
>
> I found that I cannot set A2DP bitpool to anything more than 53 in my
> ~/.asoundrc file. The bluetooth driver reports an error and keeps
> reporting it (becomes useless) until it is restarted.
>
> Bitpool values as high as 128 are possible on Windows Mobile devices
> (including mine), which means they are possible in A2DP.
The SBC codec itself supports bitpool values higher 53, and
sbcenc/sbcdec command line tools can be used to experiment with
encoding/decoding audio data.
> Such a high value is necessary for some genres of current music, which are highly
> compressed (the problem was once discussed in one of Xiph Foundation's
> articles). SBC is unable to encode such material properly if it
> doesn't have enough bandwidth.
Could you please provide a link to the Xiph Foundation's article you
have mentioned? Also what does "SBC is unable to encode such material
properly" mean?
My understanding is that the highly compressed sources are mostly a
problem not for SBC encoder, but actually for decoder:
http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=3df7c3e66042f266dadace88488e532de92d4da9
When the original audio signal is using full range, then going to the
frequency domain, doing lossy compression, and going back to the time
domain may easily result in some sample values exceeding the valid
range. The reference binary SBC decoder seems to be simply clamping
the out-of-range values to bring them into valid range (based on the
output it produces). And since some time ago, bluez SBC decoder also
does the same. This not a perfect solution, because the shape of the
decoded signal abruptly changes to "flat" part at the top or bottom.
But not doing any clamping is a lot worse and letting the samples
overflow results in really bad audible clicks. However it's hard to
say how each particular A2DP headset deals with the out-of-range
samples. Most of them are apparently also doing clamping and the audio
sounds ok. But unfortunately sometimes this is not the case. I happen
to be an owner of Logitech FreePulse A2DP headset, and the
out-of-range samples can be clearly heard as clicking artifacts (in
the worst cases resembling 'frying pan' type of sound). I myself used
a hack by patching bluez SBC to also reduce audio volume as the part
of the encoding process so that the badly compressed audio sources are
less likely to have any out of range samples in the SBC encoded data
stream.
I guess that increasing bitpool would result in a less lossy encoding
with a better approximation of the original audio data. Hence less
likely to differ from the original data too much and go out of range.
But I don't think that it's a "proper" solution for the problem.
Normally, even low bitpool values should be still quite usable.
What kind of A2DP headset are you using yourself?
--
Best regards,
Siarhei Siamashka
Hi,
On Mon, Oct 10, 2011 at 1:40 PM, [email protected] <[email protected]> wrote:
> Hi people,
>
> I found that I cannot set A2DP bitpool to anything more than 53 in my
> ~/.asoundrc file. The bluetooth driver reports an error and keeps
> reporting it (becomes useless) until it is restarted.
It can be 2 things, either a bug or the device maximum bitpool is
actually 53 so we cannot negotiate it.
> Bitpool values as high as 128 are possible on Windows Mobile devices
> (including mine), which means they are possible in A2DP. Such a high
> value is necessary for some genres of current music, which are highly
> compressed (the problem was once discussed in one of Xiph Foundation's
> articles). SBC is unable to encode such material properly if it
> doesn't have enough bandwidth.
PulseAudio uses 64 as bitpool maximum and it seems to work fine, but
that depends on available bandwidth, in fact PA reduces the bitpool if
it detects the audio is skipping.
> I don't understand Bluetooth. So I'm asking you for an advice:
> 1. Is it actually possible to set SBC bitpool in linux' A2DP to more than 53?
> 2. If it is, can I ask for a short success story in order to reproduce it?
> 2. If not, where should I start (in bluez source code) in order to fix
> this problem?
Take a look a PulseAudio or BlueZ source tree (audio/pcm_bluetooth.c)
--
Luiz Augusto von Dentz
On Wed, Mar 14, 2012 at 2:53 PM, qduaty <[email protected]> wrote:
> 2012/3/13 Siarhei Siamashka <[email protected]>:
>> Are you now comparing streaming of A2DP audio from your phone to your
>> PC (using bluez A2DP sink) and to your bluetooth headset?
>
> I assume that the phone streams data to the headset (whose session is
> hard to dump on Windows mobile) with bitpool = 112, ie. the same it
> fails to set in Bluez and I'm saying it gives good results in terms of
> perceiveable quality, from which Bluez cannot take advantage due to
> its inherent bitpool=53 limitation.
>
> Anyway, I did some additional listening tests (by listening to Bluez
> SBC on an A2DP headset). SBC_HIGH_PRECISION alone (without your hack)
> only slightly improves quality. Also I finally managed to force higher
> bitpool in ALSA (patch attached). This makes further improvement in
> quality, at least on headsets that do not choke on higher bitpools.
Do you have a hcidump log before and after patching bluez for the part
where A2DP settings are negotiated? For normal bluez 4.99, this is
what I get with Logitech FreePulse headset:
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 25]
AVDTP(s): Discover rsp: transaction 11 nsp 0x00
ACP SEID 1 - Audio Sink
ACP SEID 2 - Audio Sink
ACP SEID 3 - Audio Sink
< ACL data: handle 11 flags 0x00 dlen 7
L2CAP(d): cid 0x0200 len 3 [psm 25]
AVDTP(s): Capabilities cmd: transaction 12 nsp 0x00
ACP SEID 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 1
> ACL data: handle 11 flags 0x02 dlen 20
L2CAP(d): cid 0x0040 len 16 [psm 25]
AVDTP(s): Capabilities rsp: transaction 12 nsp 0x00
Media Transport
Media Codec - SBC
16kHz 32kHz 44.1kHz 48kHz
Mono DualChannel Stereo JointStereo
8 12 16 Blocks
4 8 Subbands
SNR Loudness
Bitpool Range 2-64
Content Protection
02 00
< ACL data: handle 11 flags 0x00 dlen 7
L2CAP(d): cid 0x0200 len 3 [psm 25]
AVDTP(s): Capabilities cmd: transaction 13 nsp 0x00
ACP SEID 2
> ACL data: handle 11 flags 0x02 dlen 20
L2CAP(d): cid 0x0040 len 16 [psm 25]
AVDTP(s): Capabilities rsp: transaction 13 nsp 0x00
Media Transport
Media Codec - SBC
16kHz 32kHz 44.1kHz 48kHz
Mono DualChannel Stereo JointStereo
4 Blocks
4 8 Subbands
SNR Loudness
Bitpool Range 2-32
Content Protection
02 00
< ACL data: handle 11 flags 0x00 dlen 7
L2CAP(d): cid 0x0200 len 3 [psm 25]
AVDTP(s): Capabilities cmd: transaction 14 nsp 0x00
ACP SEID 3
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 24
L2CAP(d): cid 0x0040 len 20 [psm 25]
AVDTP(s): Capabilities rsp: transaction 14 nsp 0x00
Media Transport
Media Codec - non-A2DP
27 00 00 00 01 00 F7 77 02 56 00 FA
< ACL data: handle 11 flags 0x00 dlen 18
L2CAP(d): cid 0x0200 len 14 [psm 25]
AVDTP(s): Set config cmd: transaction 15 nsp 0x00
ACP SEID 1 - INT SEID 1
Media Transport
Media Codec - SBC
44.1kHz
JointStereo
16 Blocks
8 Subbands
Loudness
Bitpool Range 2-53
The headset reports 2-64 bitpool capabilities, but bluez sets bitpool
to 53 because it does not use anything higher than suggested by
'default_bitpool' function (actually in two places):
"max_bitpool = MIN(default_bitpool(cap->frequency,
cap->channel_mode), supported->max_bitpool);"
If I change this code, bitpool 64 can be used, however my ears are not
trained enough to hear any differences between 53 and 64. By the way,
high bitpool settings are causing problems for some users, so not
everything is so clear:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/424215
Would it be a good idea if you come up with a clean patch, making
bitpool selection strategy tunable via a configuration file? Or
implement some kind of heuristics based on whether EDR is supported or
not?
--
Best regards,
Siarhei Siamashka
Hello,
I found that floating point processing eliminates all the quality
issues that were mentioned here. So I added a floating point mode to
SBC, which can be enabled with an #ifdef in sbc_tables.h, along with a
code for minimizing quantization errors. It reduces noise by several
dB and greatly improves the reproduction of higher bands.
There is room for further improvements, such as adaptive clipping
prevention and high resolution input format, but with current code
base, they are somewhat hard to implement.
The attached patch may cause some trouble because of one part being
rejected. I hope this will not prevent those who are interested, from
applying it and testing.
--
Sebastian Olter
2012/3/13 Siarhei Siamashka <[email protected]>:
> Are you now comparing streaming of A2DP audio from your phone to your
> PC (using bluez A2DP sink) and to your bluetooth headset?
I assume that the phone streams data to the headset (whose session is
hard to dump on Windows mobile) with bitpool = 112, ie. the same it
fails to set in Bluez and I'm saying it gives good results in terms of
perceiveable quality, from which Bluez cannot take advantage due to
its inherent bitpool=53 limitation.
Anyway, I did some additional listening tests (by listening to Bluez
SBC on an A2DP headset). SBC_HIGH_PRECISION alone (without your hack)
only slightly improves quality. Also I finally managed to force higher
bitpool in ALSA (patch attached). This makes further improvement in
quality, at least on headsets that do not choke on higher bitpools.
Regards
--
Sebastian Olter
On Tue, Mar 13, 2012 at 2:45 PM, qduaty <[email protected]> wrote:
> 2012/3/13 Siarhei Siamashka <[email protected]>:
>> On Tue, Mar 13, 2012 at 3:48 AM, qduaty <[email protected]> wrote:
>>> 2011/10/18 Siarhei Siamashka <[email protected]>:
>> Thanks for testing! One more experiment would be very much welcome. I
>> wonder if just defining SBC_HIGH_PRECISION without doing anything else
>> would have any noticeable effect on audio quality in listening tests.
>
> Well, before I move on, there is one thing that makes me sad:
>
> < ACL data: handle 1 flags 0x02 dlen 7
> L2CAP(d): cid 0x006d len 3 [psm 25]
> AVDTP(s): Capabilities cmd: transaction 10 nsp 0x00
> ACP SEID 1
>> HCI Event: Number of Completed Packets (0x13) plen 5
> handle 1 packets 1
>> ACL data: handle 1 flags 0x02 dlen 16
> L2CAP(d): cid 0x0040 len 12 [psm 25]
> AVDTP(s): Capabilities rsp: transaction 10 nsp 0x00
> Media Transport
> Media Codec - SBC
> 44.1kHz
> Stereo
> 16 Blocks
> 8 Subbands
> Loudness
> Bitpool Range 112-128
> < ACL data: handle 1 flags 0x02 dlen 18
> L2CAP(d): cid 0x006d len 14 [psm 25]
> AVDTP(s): Set config cmd: transaction 11 nsp 0x00
> ACP SEID 1 - INT SEID 2
> Media Transport
> Media Codec - SBC
> 44.1kHz
> Stereo
> 16 Blocks
> 8 Subbands
> Loudness
> Bitpool Range 112-53
>> HCI Event: Number of Completed Packets (0x13) plen 5
> handle 1 packets 1
>> ACL data: handle 1 flags 0x02 dlen 8
> L2CAP(d): cid 0x0040 len 4 [psm 25]
> AVDTP(s): Set config rej: transaction 11 nsp 0x00
> Media Codec
> Error code 204
I'm only familiar with SBC codec in bluez, but not much with A2DP
protocol. Maybe somebody else could comment.
> The other device that tries to communicate at bitpool=112 and gives
> up, is my phone. Now I'm listening to it with the headset and the
> sound is perfectly clear, with no sign of that "analog" distortion I
> mentioned earlier.
Are you now comparing streaming of A2DP audio from your phone to your
PC (using bluez A2DP sink) and to your bluetooth headset?
> Bluez has MAX_BITPOOL=53 or 64 stored everywhere and who knows, maybe
> it's even able to recover these magic numbers from bitrate. Should I
> look for bitrate constant, like 320 or so?
Maybe. If there is some problem negotiating optimal bitpool setting,
then it is better to be fixed.
>> audio quality in the current bluez sbc decoder is
>> far from perfect and the synthesis filter needs to be replaced first.
>
> I'm not sure what you expect from sbcenc-sbcdec tests. Even if they
> prove the encoding/decoding within Bluez has a reasonably good
> quality, what then? Will it propagate among different devices,
> bluetooth stacks?
sbcenc-sbcdec tests are useful for testing bluez SBC codec. For any
given bitpool value, encoding/decoding roundtrip should preserve as
much audio quality as possible. And trying different possible
combinations of encoder/decoder (bluez / reference sbc codec /
bluetooth headset) should help to provide the answers to the questions
you are asking.
--
Best regards,
Siarhei Siamashka
2012/3/13 Siarhei Siamashka <[email protected]>:
> On Tue, Mar 13, 2012 at 3:48 AM, qduaty <[email protected]> wrote:
>> 2011/10/18 Siarhei Siamashka <[email protected]>:
> Thanks for testing! One more experiment would be very much welcome. I
> wonder if just defining SBC_HIGH_PRECISION without doing anything else
> would have any noticeable effect on audio quality in listening tests.
Well, before I move on, there is one thing that makes me sad:
< ACL data: handle 1 flags 0x02 dlen 7
L2CAP(d): cid 0x006d len 3 [psm 25]
AVDTP(s): Capabilities cmd: transaction 10 nsp 0x00
ACP SEID 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 1 packets 1
> ACL data: handle 1 flags 0x02 dlen 16
L2CAP(d): cid 0x0040 len 12 [psm 25]
AVDTP(s): Capabilities rsp: transaction 10 nsp 0x00
Media Transport
Media Codec - SBC
44.1kHz
Stereo
16 Blocks
8 Subbands
Loudness
Bitpool Range 112-128
< ACL data: handle 1 flags 0x02 dlen 18
L2CAP(d): cid 0x006d len 14 [psm 25]
AVDTP(s): Set config cmd: transaction 11 nsp 0x00
ACP SEID 1 - INT SEID 2
Media Transport
Media Codec - SBC
44.1kHz
Stereo
16 Blocks
8 Subbands
Loudness
Bitpool Range 112-53
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 1 packets 1
> ACL data: handle 1 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 25]
AVDTP(s): Set config rej: transaction 11 nsp 0x00
Media Codec
Error code 204
The other device that tries to communicate at bitpool=112 and gives
up, is my phone. Now I'm listening to it with the headset and the
sound is perfectly clear, with no sign of that "analog" distortion I
mentioned earlier.
Bluez has MAX_BITPOOL=53 or 64 stored everywhere and who knows, maybe
it's even able to recover these magic numbers from bitrate. Should I
look for bitrate constant, like 320 or so?
> audio quality in the current bluez sbc decoder is
> far from perfect and the synthesis filter needs to be replaced first.
I'm not sure what you expect from sbcenc-sbcdec tests. Even if they
prove the encoding/decoding within Bluez has a reasonably good
quality, what then? Will it propagate among different devices,
bluetooth stacks?
Regards
--
Sebastian Olter
On Tue, Mar 13, 2012 at 3:48 AM, qduaty <[email protected]> wrote:
> 2011/10/18 Siarhei Siamashka <[email protected]>:
>> Still I would suggest you to try the attached patch just for a test.
>> It reduces audio volume as part of the sbc encoding process and should
>> eliminate most of the possible clipping cases on the decoding side.
>
> Sorry for responding after a half year :) but I finally tested your
> encoder patch applied to libbluetooth version 4.96, using AIMP3 and
> pulseaudio. Unpatched encoder produces a "digital" distortion (which
> is rather annoying) and sounds much like BlueSoleil on Windows. After
> patching, music is slightly quieter (which can be expected if you
> decreased its volume) and has an "analog overdrive" like through a
> cheap FM radio. Anyway, the annoying "digital" distortion that was
> present in unpatched encoder, is now gone.
Thanks for testing! One more experiment would be very much welcome. I
wonder if just defining SBC_HIGH_PRECISION without doing anything else
would have any noticeable effect on audio quality in listening tests.
> Some fluctuations can be heard in higher bands in classical music, and
> (as expected) instruments are indistinguishable, but it's acceptable
> given the low bitpool.
>
> For the "analog overdrive" I hear, it may also come from the device
> itself (its proper name is Nokia BH-503). Considering its glue sealed
> case, it might have been designed as a budget solution and its price
> was "adjusted" due to no competition.
>
>> Using bitpool 128 is kind of weird for SBC codec, because the encoded
>> data stream has about the same size as the the original data and this
>> defeats the whole purpose of having any lossy compression at all.
>
> Yes, but who needs a lossy compression in an endpoint? SBC and MP3
> were introduced to overcome the low throughput problem of the
> bluetooth link, which is no longer the case since 2.0+EDR has plenty
> of unused bits.
>
>> I still recommend you to try sbcenc/sbcdec tools for the experiments with audio quality.
>
> I tried them some time ago, but I believe ALSA backend may serve for
> the same purpose (and is much easier to use). 8 blocks seems to sound
> slightly better than 16 for classical music, full stereo eliminates
> the floating of virtual sound sources, 48 kHz also seems to increase
> quality a bit when compared to 44.1.
sbcenc/sbcdec tools can do file-to-file encoding/decoding and
eliminate the need to use any bluetooth device (which could
potentially be the source of some audio quality issues). However, as I
mentioned before, audio quality in the current bluez sbc decoder is
far from perfect and the synthesis filter needs to be replaced first.
--
Best regards,
Siarhei Siamashka
2011/10/18 Siarhei Siamashka <[email protected]>:
> Still I would suggest you to try the attached patch just for a test.
> It reduces audio volume as part of the sbc encoding process and should
> eliminate most of the possible clipping cases on the decoding side.
Sorry for responding after a half year :) but I finally tested your
encoder patch applied to libbluetooth version 4.96, using AIMP3 and
pulseaudio. Unpatched encoder produces a "digital" distortion (which
is rather annoying) and sounds much like BlueSoleil on Windows. After
patching, music is slightly quieter (which can be expected if you
decreased its volume) and has an "analog overdrive" like through a
cheap FM radio. Anyway, the annoying "digital" distortion that was
present in unpatched encoder, is now gone.
Some fluctuations can be heard in higher bands in classical music, and
(as expected) instruments are indistinguishable, but it's acceptable
given the low bitpool.
For the "analog overdrive" I hear, it may also come from the device
itself (its proper name is Nokia BH-503). Considering its glue sealed
case, it might have been designed as a budget solution and its price
was "adjusted" due to no competition.
> Using bitpool 128 is kind of weird for SBC codec, because the encoded
> data stream has about the same size as the the original data and this
> defeats the whole purpose of having any lossy compression at all.
Yes, but who needs a lossy compression in an endpoint? SBC and MP3
were introduced to overcome the low throughput problem of the
bluetooth link, which is no longer the case since 2.0+EDR has plenty
of unused bits.
> I still recommend you to try sbcenc/sbcdec tools for the experiments with audio quality.
I tried them some time ago, but I believe ALSA backend may serve for
the same purpose (and is much easier to use). 8 blocks seems to sound
slightly better than 16 for classical music, full stereo eliminates
the floating of virtual sound sources, 48 kHz also seems to increase
quality a bit when compared to 44.1.
Regards
--
Sebastian Olter