Hi Loic, > HCI H5 protocol is based on timeout to retransmit dropped packets. > According to the specification, this timeout should be calculated > based on the baudrate and the maximum packet size. > > In the current implementation, this timeout is set to 250ms. > Moreover this timer is re-triggered for 250ms at each packet transmission > without taking care of the previous non acked packet timeout. > So, in the worst case, the delay before retransmission of a packet is > tx_win*250ms. Common H5 tx_win is 4. > > These delays are not acceptable in case of "real time". > Despite buffering, It may lead to audio cuts with A2DP profile. > > Rather than decreasing timeout with a magic value, I propose to implement > a fast retransmit mechanism: > If a sender receives a specified number of invalid acks (basically, duplicate > ACKs), the sender can be reasonably confident that its oldest non-acknowledged > H5 packet was dropped. > > This mechanism is out of the H5 specification. > However, without breaking compatibility, it gives good results in practical > tests. what do you want me to do with this patch. I do not have a device to verify this and so far nobody else has spoken up to ACK or NAK it. In general I am fine with such an approach. However you might want to add nice comments in the code for what we are doing and why. I wonder if this feature is so much out-of-scape of H5 that adding an extra flag for it to enable it might be a good idea? Of is it just that this is something we should be doing anyway since it makes sense? Regards Marcel -- 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
