Hi Siarhei, On Wed, Apr 4, 2012 at 11:12 AM, Siarhei Siamashka <siarhei.siamashka@xxxxxxxxx> wrote: > On Tue, Apr 3, 2012 at 3:56 AM, qduaty <qduaty@xxxxxxxxx> wrote: >> 2012/4/2 Siarhei Siamashka <siarhei.siamashka@xxxxxxxxx>: >>> 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. Is there anyone working on this proposals? Specially the decoder seems to need some optimization as it consumes quite a bit of CPU (6-8% on my i7) and some people seems to notice some quality issues. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
