On 05.02.2015 16:59, Alexander E. Patrakov wrote: > 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? > No, I haven't - I just compared CPU for the current module and my patched version. I did not change the way audio is processed so I would not expect large differences to the current version as long as you only use latency_msec. CPU usage mainly depends on the latency set for sink and source and splitting the latency into buffer and source/sink latency aims at that. I can provide figures if you would like to see them, but I do not know how to use the tools you mention above. Is there a HowTo somewhere? > 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: > Mh, I thought I already put a lot of comments in ... > 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? > What do you mean by "handcrafted heuristics"? It's basic math - how many samples do I need for the requested latency. The equation new_rate = base_rate * (1 + latency_difference / adjust_time) is a simple P-regulator without I or D part, rate difference is proportional to latency difference. There were two options - either to get the latency right as quickly as possible - that would be base_rate * (1 + latency_difference / (adjust_time + latency)) - or to get the fastest convergence to the latency at the expected rate. I choose the second option. I experimented with adding I- or D-parts but did not see any significant improvement (maybe because of incorrect parameter values). There are however two additional restrictions: 1) Do not deviate too much (I choose 0.75%) from the base rate 2) Do the adjustment in small amounts at a time The first restriction was solved by introducing min_cycles, which makes sure the rate cannot deviate more than 0.75% from the base rate. It also produces some dampening of the P-regulator and smooths out the steps produced by the second restriction (at least when you are approaching the base rate). For 2) I just copied what was already in the current code. And then I was looking for the right criterion when to stop regulation. When is the latency "good enough"? Using some percentage of the latency will not work well when you have a latency range of 4 - 30000 ms to cover (at varying rates). Just cutting off when you are a few Hz away from the base rate like the current code does is also not a good idea for the same reason (100 - 190000 Hz). The best you can get is an error of adjust_time / (2 * base_rate). But this does not work either because the latency measurement itself has some error and there is some jitter in the latency. This easily leads to instable rates or oscillation because the controller follows every tiny change. The jitter gets significant for example if you are using USB devices that are connected to a busy USB hub. The approach was then to additionally use the error of the regulation as a stop criterion. I calculate the next expected latency and compare it to the real latency I receive. When the difference between configured latency and current latency is larger than twice this error, the difference can be considered significant. Adding the "best error" from above and a bit of safety margin finally leads to the stop criterion in the patch. The low pass filter of the error is necessary to get some running average value. I have to say that finding the right stop criterion was the most difficult part. > How was the lowpass filter tuned? > Not at all - it is a very simple low pass (or you could say running average) and the values I choose initially just seemed to fit, so I did not investigate any further. Maybe you could find better values with some experimentation but my goal - cancel out rate oscillations and do not try to follow "jumping" latencies - was very efficiently reached so I did not see the point. The basic idea was to smooth the error value a bit but still react quite quickly to jumps in the latency.
