Replies: 9 comments 12 replies
-
|
Sequence number increment: Solution 1 In this solution, the host will just naively increment the sequence number once per SDU interval using a timer. This is a very simple solution and requires little to no thought. The side effect of this, is that if the application attempts to send 2 SDUs in a single SDU interval on a single stream, they will get the same package sequence number (unless we choose to reject the send request), and when sent to the controller won't be sent on air. Since the controller cannot reject it, it is best if the host rejects it if the application sends two SDUs in a single SDU interval on a single stream. The application will not be able to enqueue multiple packets in the controller at the same time |
Beta Was this translation helpful? Give feedback.
-
|
Sequence number increment: Solution 2 In this solution, the host will increment the sequence number once per SDU interval using a timer, but also once per send request from the application. The application will be able to enqueue multiple packets in the controller (with different sequence numbers). The implementation will be slightly more complex than #43317 (comment) since we need to figure out when to increment the sequence from the timer and when we need to increment it from application requesting a send. |
Beta Was this translation helpful? Give feedback.
-
|
Sequence number increment: Solution 3 In this solution we simply offload the sequence number to the application. Add another field in the This solution is however also the most flexible, as it will allow an application to schedule ISO SDUs in the future (e.g. sending a SDU with a sequence number 10 above the current sequence number will schedule it 10 * SDU interval in the future. The application will however require that the TS of the last sent message is also known to the application. |
Beta Was this translation helpful? Give feedback.
-
I do not think the specification needs to state this - if the application do not generate exactly one SDU every SDU interval then you have gaps in your audio stream or buffer overflow over time - hence a broken system :-)
I think I would do it as a guard timer starting when the stream is enabled. It could be one or two SDU intervals (kconfig value). The timer is reset for each SDU written by the application hence if it fires it is because a SDU was not written in time and the host stack could increment based on this. Actually we do not need a timer if we just store a timestamp for each SDU send - then if there is a gap above a certain threshold when a new SDU is send we can increment the sequence number accordingly - the timer is only needed if we want to transmit empty PDU's to indicate missing data.
It will not be very accurate but yes over a long period it could be used.
No it should not. If the host do not apply a timestamp in the SDU's to be send the controller is responsible to schedule transmission based on when in time the SDU was received - which is why I doubt any controller implementation will use the sequence number for anything but aligning data between multiple CIS'es. and maybe in case of a gap of one skip a CIS event:
Over air there are two types of "empty" packets. A NULL packet (NPI bit set) indicates there is no data - hence the receiving controller will not see this as a PDU and will require use of retransmissions for this missing PDU and you will start to congest retransmissions until you reach the flush point - and then when data is actually to be sent you will be in retransmission congested state with only a few retransmissions left (I have a few slides of this in case you want a call for me to explain). If however empty packets are sent in replacement of missing data you will keep the system in normal state - having all buffers at the correct level for retransmission to be used for real data. It is not important if these empty PDU's are sent to the host on the sink side (but they should to kick in the PLC) the important part is the the buffer level in the controller are kept "intact". |
Beta Was this translation helpful? Give feedback.
-
The host/application can generate multiple SDUs in a single interval with increasing packet sequence number to enqueue them in the controller, e.g. in a 10ms (example SDU interval) it could generate SDU_1 (SN 1), SDU_2 (SN 2), SDU_3 (SN 3), etc. and enqueue all of them in the controller in a burst and the controller will then send them 1 by 1. In the case that the controller supports e.g. 10 packets, the host/app can enqueue 10 packets within a 10ms time frame, have a pause for 90-100ms and enqueue 10 more.
If the host/app needs to increment the sequence number once per SDU interval, I don't really see any way to avoid a timer, unless we want to call the
I think @cvinayak is more suited to answer this one.
My understanding is that only SDUs are sent to the host. An empty PDU which is not caused by the remote host (it can't really), should not reach the local host. Generally I think there's still a lot of confusion regarding the sequence numbers and how they should be used (the spec is also not being clear on this). |
Beta Was this translation helpful? Give feedback.
-
True, that is why I added "over time" :-) so in average you would need one SDU every SDU interval - for audio. The system also needs to handle BN>1.
True good point - but the buffering and synchronization issue still applies unless FT=1 and you do not care about power consumption.
I disagree. The HCI packet description have information in the header to allow a host to drive a codec with PLC (for example data received with error) - if the controller do not issue ISO data events for every SDU interval then it overcomplicates the audio processing and a host is forced to implement quite a large buffer to do timer based handling of this (again the different time domains forces handling of jitter) - hence adding to the overall latency.
Why do you say "it can't really" - I do not see any statement that ISO_SDU_Length cannot be 0 (section 5.4.5 HCI ISO Data packets).
How about doing the empty packet approach and use the number of complete packets events to drive the correct sequence number update. So as @asbjornsabo suggested let the data write from an application drive the sequence number increment when there is a steady flow of data. The host knows how many buffers are in use in the controller - and when this runs below a certain threshold the host stack will start injecting empty packets every time it receives a number of complete packet event and the buffer level in the controller is still below the threshold - when the application have provided new data the buffer level will not be below the threshold. |
Beta Was this translation helpful? Give feedback.
-
ISO (specifically CIS) have some features that are interesting to explore for non-periodic data, e.g. to handle very low intervals (less than the minimum 7.5ms ACL interval), as well as establishing multiple CIS towards a single device to send data on e.g. 4 streams in a single interval. While I agree that this perhaps is misusing the intention of ISO, there are certainly use cases where misusing ISO/CIS can provide functionality not previously possible with BT. Since the core spec does not prohibit such behavior, I'd rather avoid the ISO API to only support strictly periodic data.
That is true. It isn't written clearly in any sentence, but consider this part:
that are sent by the remote host, should not be sent to the local host.
Interesting approach, and could indeed "fix" the incremental of the sequence number without using a timer. It will, however, send unnecessary many empty SDUs to the remote host (assuming that it doesn't get empty SDUs if the host doesn't send), which may or may not be good. In the case of a ISO stream with "breaks" in the e.g. audio (e.g. a walkie talkie implementation), the constant receive of SDUs will need to wake up the host processor (in multi-processor builds) with empty SDUs, just for the host to possibly ignore or discard them. I'm not strictly against this proposal (in fact I'll add it as a solution proposal now), but it will have side effects not found in the others, although waking the host processor to increment a value by a timer is roughly the same. |
Beta Was this translation helpful? Give feedback.
-
|
The walkie talkie example is a good example as you have frequent silence periods. In case empty PDU's are not sent while silence the controller will need to service every single CIS sub-event - this means toggling on/off the BT receiver and transmitter throughout the entire CIS event exchanging nothing but NULL packets as well as forcing the radio CPU to stay awake for the entire CIS event. IMO this requires significantly more power than transferring a single empty PDU when there is no audio data to indicate it is OK for the central to close the CIS event early and allow the radio controller to go to sleep until the next CIS event. But it surely depends on the CIG configuration (NSE) and the cost of waking the host CPU - but unless we are talking a mobile phone or a PC with a big OS I doubt it is more expensive. Whether or not a controller allows a vendor specific command to disable empty ISO data events is implementation specific - but it should be a core-spec feature if you ask me. Note that over air a NULL packet and an empty SDU have the exact same length - the only difference is if the NPI bit is set or not. All the header content the host sees (sequence number timestamp etc.) is stripped away before transmission and recreated on the receiver side based on CIS timing. On an ACL you have a more data bit to indicate when to stop a connection event but on a CIS you use the knowledge about the number of expected PDU's to be received in each CIS event to determine when you can close the event. I agree the controller should not generate the empty SDU's, but I'm just stating that it could to save power if the host do not provide a steady flow of SDU's. |
Beta Was this translation helpful? Give feedback.
-
|
TX Sync Solution 1 To sync the timestamp and sequence number, the In this solution, the application is responsible for calling a function that sends this command to the controller, and then the resulting event can then be used for the host or application (depending on the Sequence number solution) to correct any out-of-sync sequence numbers. It is thus up to to the application to derive when it makes sense to call this, and how often. |
Beta Was this translation helpful? Give feedback.
-
|
I do not see much value in this command on systems that do not have access to actually read the controller timestamp. I think the data transmitted events provide better timing accuracy (the flush timeout + a few ms) as you will get these events as soon as a SDU is transmitted where as the host would need to periodically send this HCI command hence you will have timing inaccuracies of twice the flush timeout - or the flush timeout + the periodic sample interval which ever is lowest. The only case I can see where you would need to use this command is after a period of silence where you want to start off with the correct sequence number on your SDUs and have not implemented what you suggest above. If you have access to the local BT controller timing you could use the command to determine clock drift between central and peripheral which have a lot of value to do adaptive sample rate conversion - but if you already have access to the Bluetooth timing I would assume there are better ways to read the clock drift that this command.. I think TX sync across multiple CISes are more important - ensuring the same audio frame is send across all CISes in a group - but I assume the controller will handle this if the host ensures they are tagged with the correct sequence number. |
Beta Was this translation helpful? Give feedback.
-
In the case the host/app timer (or whatever triggers a
This is important as well. I guess the worse case scenario is where you have 2 (or more) CIS, and the host/app (possibly due to drift) first sends an SDU on CIS_1 to the controller 1ms (or less) before the next SDU interval, and the next (given that we cannot do it in parallel) sends the SDU on CIS_2 to the controller 1ms (or less) after the SDU interval, causing a SDU send on both streams to be sent in two different SDU intervals. However, I can only imagine this being an extremely rare occurrence, and if there's drift it will unlikely more than once in a row. |
Beta Was this translation helpful? Give feedback.
-
Actually I have tested this on a system that ignores the sequence number - and it happens quite often if the first PDU is sent to the controller close to the ISO event as you mention - then I experience left/right sync shift back and forth one audio frame every 10-20 second. If however the first PDU is send with a reasonable distance to the anchor point it could play for minutes before it happened. |
Beta Was this translation helpful? Give feedback.
-
|
TX Sync Solution 2 To sync the timestamp and sequence number, the In this solution, the host will send this command to the controller periodically. This can either by configured by a KConfig in e.g. MS (e.g. send every 10000ms/10s), or relative to the SDU interval, e.g. send it every 100 SDU intervals. This solution can work together with #43317 (comment), i.e. having the host call this periodically, as well as allowing the application to call it manually. |
Beta Was this translation helpful? Give feedback.
-
|
For a correct supply of audio data from host to controller, the host must anyway send (at least on average) exactly one SDU per SDU interval. So "naively incrementing" should be fine. That will fulfill the spec requirement of incrementing once per SDU interval. So, I think the question is not so much about the numbering as it is about knowing when to send SDUs, i.e. keeping track of how many SDU intervals have elapsed and when send SDUs to the controller. For a "live" system, that should be given by the flow of data from the A/D converter (which must exist somewhere). For stored data (less common?) a timer is required, I believe. |
Beta Was this translation helpful? Give feedback.
-
|
The naively incrementing won't work in case that the application doesn't send every SDU interval (which it isn't required to do). The numbering is indeed not important, but rather sending the correct number to the controller. Please keep in mind that we are discussing ISO data here, and not audio, and that any ISO data source may not provide data every SDU interval. For audio data, there may also be skips in time. E.g. a chat application (teams, discord, etc.) where there's a "Push to talk" (similar to walkie talkie), where you may not want to disconnect the iso/audio stream between each "session". In those cases, I don't think it would make to expect the application to send empty SDUs (empty in the sense that there is no audio data). |
Beta Was this translation helpful? Give feedback.
-
|
Sequence number increment: Solution 4 In this solution the host will continuously send ISO packets to the controller, and use the command complete to increment the sequence number, rather than using a timer, when a specific ISO channel is considered "idle". This should ensure correctness for the sequence number, assuming that we can enqueue enough packets to never miss an interval. The side effects of this is that the controller will continuously send SDUs instead of empty PDUs, causing the remote host to receive empty SDUs continuously (which arguably is the intention of the ISO feature). A negative side effect is that the host will need to reserve at least 1 but more like 1-2 ISO TX buffers to implement this feature. |
Beta Was this translation helpful? Give feedback.
-
|
It seems that the conclusion (based on numerous discussions) is that TX Sync Solution 1 together with Sequence number increment: Solution 3 is the solution. In this case, we basically offload everything to the application, and add the packet sequence number to the So basically we are going to change int bt_iso_chan_send(struct bt_iso_chan *chan, struct net_buf *buf);to int bt_iso_chan_send(struct bt_iso_chan *chan, struct net_buf *buf, uint16_t sn, uint32_t ts);For Audio data (sent via @Casper-Bonde-Bose Does this seem good to you? |
Beta Was this translation helpful? Give feedback.
-
|
#43859 will be worked on soon. |
Beta Was this translation helpful? Give feedback.
-
|
Closed as issue has been fixed |
Beta Was this translation helpful? Give feedback.
-
The current implementation (as of SHA 0e8f556) is that the sequence number is just naively incremented per SDU send from the application/host to the controller for the specific ISO stream.
The core spec (Version 5.3, Vol 6, Part G, Section 2 ISOAL Features) mandates that the sequence number is incremented once per SDU interval, which is current not the case.
So we need to increment the SDU interval via a timer in the host, started when the ISO channel is connected. This applies for both unicast and broadcast. This change is pretty trivial, and won't require much discussion (if any).
Furthermore, to keep the timer in sync with the timer in the controller, as well as the sequence number, we need to use the
LE Read ISO TX SyncHCI command. This will need to be called periodically either by the application, or by the host.There is no way for the controller to indicate to the host that the timestamps/sequences numbers are out of sync.
Below will be a few discussion points in comments, with different ways of implementing this sync between the host and the controller.
Beta Was this translation helpful? Give feedback.
All reactions