Hi,
On 12/9/2010 10:25 PM, Nick Pelly wrote:
On Thu, Dec 9, 2010 at 2:37 AM, Andrei Emeltchenko
<andrei.emeltchenko.news@xxxxxxxxx> wrote:
Hi All,
On Wed, Jun 16, 2010 at 5:15 PM, Nick Pelly<npelly@xxxxxxxxxx> wrote:
On Wed, Jun 16, 2010 at 4:40 AM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
Hi,
On Tue, Mar 9, 2010 at 11:45 PM, Marcel Holtmann<marcel@xxxxxxxxxxxx> wrote:
Hi Nick,
Right now Bluez always requests flushable ACL packets (but does not
set a flush timeout, so effectively they are non-flushable):
However it is desirable to use an ACL flush timeout on A2DP packets so
that if the ACL packets block for some reason then the LM can flush
them to make room for newer packets.
Is it reasonable for Bluez to use the 0x00 ACL packet boundary flag by
default (non-flushable packet), and let userspace request flushable
packets on A2DP L2CAP sockets with the socket option
L2CAP_LM_RELIABLE.
the reliable option has a different meaning. It comes back from the old
Bluetooth 1.1 qualification days where we had to tests on L2CAP that had
to confirm that we can detect malformed packets and report them. These
days it is just fine to drop them.
Got it, how about introducing
#define L2CAP_LM_FLUSHABLE 0x0040
that l2cap_sock_setsockopt_old() sets this didn't give you a hint that
we might wanna deprecate this socket options ;)
I need to read up on the flushable stuff, but in the end it deserves its
own socket option. Also an ioctl() to actually trigger Enhanced flush
might be needed.
struct l2cap_pinfo {
...
__u8 flushable;
}
Sure. In the long run we need to turn this into a bitmask. We are just
wasting memory here.
Attached is an updated patch, that checks the LMP features bitmask
before using the new non-flushable packet type.
I am still using L2CAP_LM_FLUSHABLE socket option in
l2cap_sock_setsockopt_old(), which I don't think you are happy with.
So how about a new option:
SOL_L2CAP, L2CAP_ACL_FLUSH
which has a default value of 0, and can be set to 1 to make the ACL
data sent by this L2CAP socket flushable.
In a later commit we would then add
SOL_ACL, ACL_FLUSH_TIMEOUT
That is used to set an automatic flush timeout for the ACL link on a
L2CAP socket. Note that SOL_ACL is new.
But maybe this is not what you had in mind, so I'm looking for your
advice before I implement this.
Attached an updated patch for 2.6.32 kernel. We've been using this
patch successfully on production devices.
can see anything wrong with that patch. However we need to use
SOL_BLUETOOTH for it of course. So we need to come up with something to
make this simple.
Nick are you going to take Marcel comments? Otherwise I could take
care about the patch as it seems that it might help in some
situations.
I'm not actively working on this patch.
An additional change I like to see is to use flags for booleans like
flushable in the structures. Can you work on changing that.
Also do we have decoding support for this in hcidump. It might be nice
to include some really simple examples in the commit message.
At least wireshark which I use understands those packets.
I would like to play a little bit with this, so is there any missing updates?
Nope, that is our most recent version.
Nick, do you know headset which could help to hear the real
difference? I was trying to use Sony DR-BT22 headset which has some
issues with A2DP but the solution did not help much.
It becomes essential in non-ideal radio bandwidth conditions such as
single antenna wifi co-existence. We also had some headsets that
exacerbated the problem (presumably they had less logic to 'catch-up'
through late packets) but I can't remember off hand.
I think you should be able to reproduce the same issue using any A2DP
headset.
Use a CSR dongle as local controller and start streaming A2DP data.
Parallel to that initiate an FTP connection to another device.
Take the headset out of range, or keep it in a shield box.
You should be able to see that the FTP link also stalls as the A2DP
packets are stalled in controller without getting flushed.
Nick
--
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
Regards
Suraj
--
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
