The branch is up at https://github.com/mkbosmans/pulseaudio/compare/master...rate-adjustment ready for merging, as far a I am concerned. I'm still not entirely sure whether the change of https://github.com/mkbosmans/pulseaudio/commit/72b90ea8ac53e23862284991a2ce355de250f585 is correct, but it seems to avoid unnecessary rewinds for me. I've tested module-loopback by playing to a null-sink and looping its monitor to the real alsa sink. This showed good behaviour, but may be the algorithm I used for module-rtp-recv should also be used here. Does anyone has a better suggestion for a setup to test module-loopback? null-sink and alsa have very stable latencies, so its no good test for module-loopback. Maarten 2011/1/15 Maarten Bosmans <mkbosmans at gmail.com>: > 2011/1/15 Colin Guthrie <gmane at colin.guthr.ie>: >> Hi, >> >> I know people (i.e. Maarten) are discussing and proposing various rate >> adjustment patches just now. Not quite got a grasp on whether any of >> them are ready for merging so if/when they are, please just poke me. >> >> Col > > The patches I sent to the list were mainly to illustrate the ideas I > was discussing. I am trying to make a coherent set out of them. Things > remaining are: > ?- smoothing of the estimated (real) sample rate in module-rtp-recv. > I'm tryng to find a balance between very good runtime behaviour and > keeping the algorithm not too complicated. > ?- module-loopback. I just need to setup a loopback and start some testing. > > I would have expected that module-tunnel also needs sample rate > adjustments, but it appears it does not. Is that correct? > > module-echo-cancel also seems to do sample rate adjustments. But it > seems that it is not completely implemented yet (there are commented > lines), so unless the author of that module explains what de desired > behaviour is, I'll just leave that. > > I'll try to make a patch set and send them to the list for (hopefully) > final review. > > Maarten >
