Hi Pauli, On Thu, Feb 6, 2025 at 12:13 PM Pauli Virtanen <pav@xxxxxx> wrote: > AFAICS, for synchronization (only) guidance in the specification is > (Version 6.0 | Vol 6, Part G Page 3709) > > """When an HCI ISO Data packet sent by the Host does not contain a > Time_Stamp or the Time_Stamp value is not based on the Controller's > clock, the Controller should determine the isochronous event to be used > to transmit the SDU contained in that packet based on the time of > arrival of that packet.""" > > which I'm interpreting that Host should queue synchronized packets for > different CIS to HCI at the same time. But since this seems > implementation-defined, I don't really know what Intel firmware is > expecting the Host to do, so maybe pull on completion works (at least > until user app misses a wakeup). Yeah, I think this lack the clarity on how the Controller determine what packet got the what event, in theory the buffer count acts as the queue, the queue is then used as jitter meaning there will be some latency but I think that is sort of unavoidable with the way packets are transmitted over HCI. With this in mind I think one of the problems is that when we have multiple connections we probably need to load balances the usage of the controller buffers, each connection needs at least 2 buffers since with just 1 it is possible to miss events due to the transport/bus not being fast enough to notify number of packets complete event and then the stack to react in time to send the next packet, so we need to have at least 1 packet queued ahead of time. Once we can notify the TX complete we can perhaps use it as a trigger to send the next packet, instead of trying to do it time based like bluetoothctl is doing nowadays, which imo is simpler and should result in a better utilization of the controller buffers. -- Luiz Augusto von Dentz
