On Thu, Jun 14, 2018 at 8:27 AM, Tanu Kaskinen <tanuk@xxxxxx> wrote: > On Thu, 2018-06-14 at 08:05 -0700, João Paulo Rechi Vita wrote: >> > > I also had to disable module-card-restore, otherwise it tries to >> > > switch to the saved a2dp_sink profile right when the card is created, >> > > which also makes the device abort the AVDTP connection for some >> > > reason. >> > >> > This is without increasing the timeout, right, so the problem is that >> > module-card-restore is trying to restore a2dp_sink before it's >> > available? module-card-restore has been fixed to not to try to restore >> > unavailable profiles: >> > https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=d65974d8501052bafb03e65f5df954511e9949a2 >> > >> >> No, this is in addition to increasing the timeout. To have things >> working I need to increase the timeout AND disable >> module-card-restore. Sorry for not being clear about it before. >> >> I will try the commit you pointed, but I don't think it will help >> since, if I'm following this right, the transport is already marked as >> available at this point (I need to double-check on this point though >> -- sorry, too many moving parts). > > If you confirm that module-card-restore indeed has to be disabled even > with the increased timeout, then it would be very interesting to know > what effect module-card-restore has in the card initialization. To me > it seems that it should make no difference, because the a2dp profile is > the default anyway, and all the module does is to choose the initial > profile. > Ok, I have done more testing focusing on this specific point and confirmed we indeed don't need to disable module-card-restore. With the 60s timeout the headset was able to connect successfully 6 times in a row. So for now the only open point is if there is any better fix for these headsets than increasing the timeout. -- João Paulo Rechi Vita http://about.me/jprvita -- 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
