01.02.2015 03:43, Georg Chini wrote: > This is the final version of my patch for module-loopback. It is on top of the > patch I sent about an hour ago and contains a lot more changes than the previous > versions: > > - Honor specified latency if possible, if not adjust to the lowest possible value > - Smooth switching from fixed latency to dynamic latency source or sink and vice versa > - good rate and latency stability, no rate oscillation > - adjusts latency as good as your setup allows > - fast regulation of latency offsets, adjusts 100 ms offset within 22 seconds (adjust > time=1) to 60 seconds (adjust_time=10) > - usable latency range 4 - 30000 ms > - Avoid rewinds and "cannot peek into queue" messages during startup and switching > - works with rates between 200 and 190000 Hz > - maximum latency offset after source/sink switch or at startup around is 200 ms > > I also introduced a new parameter, buffer_latency_msec which can be used together > with latency_msec. If buffer_latency_msec is specified, the resulting latency > will be latency_msec + buffer_latency_msec. Latency_msec then refers only to > the source/sink latency while buffer_latency_msec specifies the buffer part. > This can be used to save a lot of CPU at low latencies, running 10 ms latency > with latency_msec=6 buffer_latency_msec=4 gives 8% CPU on my system compared to > 12% when I only specify latency_msec=10. Is there any more detailed profiling data for it? E.g., have you tried running perf record / perf report? I am not quoting the patch, but my opinion is that it needs either comments or some text in the commit message on the following topics: Why does it use hand-crafted heuristics instead of a PID-controller? Or, is this "Low pass filtered difference between expectation value and observed latency" a PI controller in disguise? How was the lowpass filter tuned? -- Alexander E. Patrakov
