<div dir="ltr"><div>Hi Nicolas<br><br></div><div>Thx for taking the time<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 27, 2022 at 8:12 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Somewhat your pipeline is live, or can be made live. One way to reach this<br>
effect, could be to place clocksync element after your parser (since you need<br>
timeinformation). This will make you pipeline live, and then you can control the<br>
amount of jitter you allow with the processing-deadline properly for the "real<br>
sink", and ts-offset on the clocksync (or something along these line).<br></blockquote><div><br></div><div>Ok so clocksync adds timestamp and we can wait start until first sample. I thought audiorate also did this?<br></div><div>And is it still the case that fdsrc do-timestamp=true" does not actually add a timestamp?</div><div><br></div><div>Ok so now we have timestamped bytestream (audio or not does not matter) andwe can add a ts offset, even negative if needed.</div><div><br></div><div>But how does the processing dead-line work. If we set that to lets say 100ms, does it mean that the sink (lets use alsasink as a case study), does start process and output the first sample until after 100ms and subsequently on average, any sample received after that can be up to 100ms delayed accoding to a prefect stream thus in effect have a jitterbuffer of 100ms. Is that what you mean and how it works?<br><br></div><div>Thanks for taking the time.</div><div><br></div><div>Peter Maersk-Moller<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Thanks in advance.<br>
> Peter Maersk-Moller<br>
> <br>
>  <br>
<br>
</blockquote></div></div>