Re: [PATCH] Re: A2DP quality (bluetooth-alsa)

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

On Tue, 31 Jul 2012 13:09:19 +0300
Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

> Hi Siarhei,
> 
> On Wed, Apr 4, 2012 at 11:12 AM, Siarhei Siamashka
> <siarhei.siamashka@gmail.com> wrote:
> > On Tue, Apr 3, 2012 at 3:56 AM, qduaty <qduaty@gmail.com> wrote:
> >> 2012/4/2 Siarhei Siamashka <siarhei.siamashka@gmail.com>:
> >>> Could you provide a short summary for this whole discussion? The
> >>> discussion has been changing from bitpool negotiation to SBC codec
> >>> improvements back and forth. And now it's becoming hard to follow
> >>> and see which problems are still relevant and need to be solved.
> >>> Also do you want to work on some code yourself or mostly trying
> >>> to escalate the problems?
> >>>
> >>> A2DP is in the list of ideas for BlueZ GSoC, so maybe that's a
> >>> good chance to get some improvements implemented:
> >>> http://www.bluez.org/development/gsoc/gsoc-ideas-list-2012/
> >>
> >> Ok. This is the summary.
> >> 1. It was found that Bluez can occasionally limit available bitpool
> >> because some devices report a narrow bitpool range that does not
> >> reflect their real capabilities. A solution was proposed by means
> >> of encoding at a higher bitpool than negotiated, and it was
> >> confirmed to both work and not break compatibility, unless it is
> >> misused. 2. It was found that Bluez audio sink has quality
> >> problems even on high bitpools. An SBC encoder fix was proposed,
> >> which (re)enables floating point processing. Tests are needed to
> >> confirm whether it improves quality in all cases.
> >> 3. It was (previously) found and now confirmed that reducing
> >> volume in SBC encoder by a factor of 0.7-0.8 improves quality by
> >> eliminating audible effects of clipping in the decoder.
> >
> > OK, thanks.
> >
> >> For myself, I'm likely to be done with it. I've already solved the
> >> problems that prevented me from using A2DP on Linux. Further work
> >> would require more time and I cannot benefit from it (but students
> >> obviously can).
> >
> > Fair enough.
> >
> >> My proposals:
> >> 1. Introduce a less restrictive input format for the audio sink,
> >> such as float32. Currently it supports only S16LE, which is not
> >> suitable for audio processing (ALSA softvol is a known example).
> >> 2. Find out what quality problems the SBC decoder has and fix them.
> >> Possibly introduce floating point output to eliminate clipping.
> >> 3. Implement proper (adaptive?) clipping prevention in the SBC
> >> encoder.

Sorry for a late reply, I have missed this one.
 
> Is there anyone working on this proposals?

These were all qduaty's ideas. If (s)he is not working on this stuff,
then I guess nobody does.

> Specially the decoder seems to need some optimization as it consumes
> quite a bit of CPU (6-8% on my i7) 

Yes, there are lots of low hanging fruits. For example, getting rid of
integer division and better bitstream reading should provide a
significant performance boost for the decoder. I might do that
eventually.

> and some people seems to notice some quality issues.

Are there some links to more information? Or to some audio quality
tests, which can be confirmed/reproduced?

The precision of fixed point calculations in the decoder is not
very good, so it definitely can be improved. But it should not be
too bad either.

The audio quality should be quite good for the encoder. Except for the
clamping problem, which may be happening on the decoder side with some
heavily compressed audio data and a poor/buggy A2DP headset. This
can be workarounded by reducing audio volume in the encoder by 20-30%.
The SBC encoder may get these extra volume adjustment settings, but the
big unresolved question is who and when is going to enable it? Would it
be some configuration file (pulseaudio/alsa/anything else)? Or would it
be some automatic heuristics kicking in for known bad headsets?

-- 
Best regards,
Siarhei Siamashka