You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Change the way pipeline TX handles the order of framebuffers. Track
per-frame sequence numbers so transport can dequeue the newest converted
frame instead of always taking the next one, needed as otherwise
we cannot drop frames, as they will not be in order.
(This also makes it easier for multi threaded applications to use
the api should improve performance with multiple threads from the api
only).
Add a new flag to the TX pipeline to enable droping frames when we jump
over epoch. Mostly will aid with user control pacing.
Implemented in a way that only drops one frame in a scenario where late
is detected. This creates limitation for extreamly high drops The stream
will still not adjust immidiately instead doing
send frame | drop frame | send frame | drop frame ...
until we catch up.
(Done mostly as big jumps over more than 2 frames could be undesirable
and if you have that big of a drop ... well this is the least of your
troubles).
Due to lack of consumer and producer print stats of the queue via
reporting the framebuffers statuses (removed the ACCURATE_FRAMEBUFF) as
it became redundant.
Reverts: 772621d
All above done in pipeline as the purpose of the api pipeline is to
smoothe the library tight timing requirements from the user
applications.
Fix the st20p wrong user timestamp reporting in frames snapped to
the next frame.
if times given by the application looks as follows
----|--frame-1--|--frame-2--|--frame-3--|--frame-4--|-...
epoch-1--|--epoch-2--|--epoch-3--|--epoch-4--|...
This causes frames to snap to the next epoch, resulting in incorrect
timestamp reporting where every frame appears to have a "wrong user
timestamp" due to the forward snapping behavior.
Fixes: 88c3566
Fix the usdt for st40p tx (only to add the spurn event).
Fixes: 921fa0d
The ST40 pipeline helpers (used by `RxSt40PipelineSample`, `TxSt40PipelineSample`, or any app built on `st40_pipeline_api.h`) expose their own provider to focus on frame-level callbacks rather than mbuf activity. Today only the RX side wires USDT probes (TX helpers reuse the regular logging path):
739
+
The ST40 pipeline helpers (used by `RxSt40PipelineSample`, `TxSt40PipelineSample`, or any app built on `st40_pipeline_api.h`) expose their own provider to focus on frame-level callbacks across both TX and RX paths:
740
740
741
741
```c
742
742
provider st40p {
743
+
/* tx */
744
+
probe tx_frame_get(int idx, int f_idx, void* va);
745
+
probe tx_frame_put(int idx, int f_idx, void* va);
746
+
probe tx_frame_next(int idx, int f_idx);
747
+
probe tx_frame_done(int idx, int f_idx, uint32_t tmstamp);
748
+
probe tx_frame_drop(int idx, int f_idx, uint32_t tmstamp);
743
749
/* rx */
744
750
probe rx_frame_available(int idx, int f_idx, uint32_t meta_num);
745
751
probe rx_frame_get(int idx, int f_idx, uint32_t meta_num);
@@ -749,6 +755,19 @@ provider st40p {
749
755
}
750
756
```
751
757
758
+
To watch for ancillary frames that arrive too late to flush, hook the TX drop probe (customize the process name for your setup):
Usage: This utility is designed to capture and store audio frames transmitted over the network. Attaching to this hook initiates the process, which continues to dump frames to a local file until detachment occurs.
1546
1613
@@ -1568,7 +1635,7 @@ Then use ffmpeg tools to convert ram PCM file to a wav, customize the format as
Usage: Similar to tx_frame_dump hook, this utility is designed to capture and store audio frames received over the network. Attaching to this hook initiates the process, which continues to dump frames to a local file until detachment occurs.
0 commit comments