On Wed, Mar 28, 2012 at 2:28 AM, qduaty <qduaty@xxxxxxxxx> wrote: > ALSA bitpool patch is attached. > > 2012/3/27 Siarhei Siamashka <siarhei.siamashka@xxxxxxxxx>: >> The first patch adds debug prints to syslog from sbc encoder, just to >> clearly confirm the real bitpool used by the encoder. > > It obviously worked: > > Mar 27 17:49:41 machina-turbo pulseaudio[2355]: sbc_encode: bitpool set to 138 > >> The second patch removes default_bitpool() limitation, and this boosts >> bitpool from 53 to 64 for me. > > I found it was my device that prevented Bluez from using higher > bitpools. Bluez assumes that requesting a wider range of bitpools from > a device will cause an error, and indeed, my device cannot be > configured with a bitpool range wider than 2-53. So the only way to > achieve higher bitrates is to force them. I guess this depends on the headset. Your patch hacks around and allows you to use higher bitpool with your Nokia BH-503 headset. With my Logitech FreePulse headset, your patch does not seem to break audio playback, but on the other hand such radical changes are not needed (just removing default_bitpool() is enough to be able to set bitpool to 128 via ./asoundrc). For somebody else your patch might possibly even break audio playback if their headset does not like to be forced. > There is (was) a rather serious problem in the ALSA module, when it > tried to set bitpool exceding device capabilities, it ended with an > error and next tries, even with a valid bitpool, resulted in "Invalid > seid 0" in syslog and required bluetooth service to be restarted. With > my patch, bluez only uses the configured bitpool for sbc, without > sending it to the device. So, any bitpool value not exceeding true > device and adapter capabilities will work (and these can be much > higher than negotiated). Apparently this works a bit different in my case and I don't get the same "Invalid seid 0" error. In any case, what we have here is that (some?) A2DP headsets can support a lot higher SBC bitpool settings than they are normally reporting. Now the big question is how to probe for this information without violating negotiation protocol in any way and not causing any regressions. The next question is how to decide which bitpool to use by default, because in my case bitpool 128 occasionally causes some skips in music playback which did not happen with lower bitpool settings. 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/ -- Best regards, Siarhei Siamashka -- 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
