Hi Marcel, On Fri, Dec 18, 2009, Marcel Holtmann wrote: > > > are you expecting to change this frequently and from different parts of > > > the code during the lifetime of a socket. I just don't see that > > > happening at all actually. Either you create a "flushable" socket or you > > > don't. Fill me in on how you wanna actually use this feature. > > > > My use case is just for A2DP. I turn on flushing with a timeout of say > > 160ms just before starting streaming of A2DP data, and turn it off > > when I finish. This is not a problem with either API proposal. > > I count this as creating socket, setting flushable and then using it. > Then closing it. And especially in A2DP case where the media socket is > brought up and taken down a lot that is a proper usage. However I do > expect that each socket should not change from flushable to > non-flushable in mid term usage. While potentially possible it don't see > its usage at all. I hope you remember that the A2DP media transport socket is kept open much longer periods than e.g. the SCO socket in HFP/HSP since suspending an A2DP stream only means stopping sending data but still keeping the media socket open. Only when the configured codec parameters aren't suitable for the audio data would you close, reconfigure and recreate the media socket. So is it ok to keep the flushable setting even while the A2DP stream is suspended? Johan -- 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
