Hi Luiz, pe, 2025-02-07 kello 12:34 -0500, Luiz Augusto von Dentz kirjoitti: > 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. Another thing to consider is that it's probably more or less guaranteed userspace can miss the deadlines sometimes, and packets for some of the CIS are late. (Maybe kernel can also miss deadlines, I don't know if there's any guaranteed wakeup for the the HCI worker tasks.) The scheduling should somehow guarantee that underrun only produces temporary audio glitch, and not persistent stream desynchronization. So maybe it is still necessary to wait for completion for all synchronized CIS, and send new packet for all of them at once? Or, maybe controllers now implement LE Read ISO TX Sync, and it can be used to figure out the timestamping. IIUC, not straightforward either, you'd need to deal with syncing packet sequence numbers with ISOAL and clock drift... -- Pauli Virtanen
