On Fri, 2015-12-18 at 09:10 +0100, Georg Chini wrote: > On 18.12.2015 09:07, Tanu Kaskinen wrote: > > Good that you asked, because it got me thinking about this a bit more, > > and I'm starting to think that it's not worth it after all. Adding > > another resampler would in many situations mean that the audio would > > get resampled twice (or three times, if we count the source ouput > > resampler, but that's beside the point). That doesn't seem like a good > > idea due to the extra cpu load. > > > > Something that could be considered is to have separate "nominal rate" > > and "real rate" stored in pa_sink_input, so that the small rate tweaks > > that module-loopback applies wouldn't be visible where they don't need > > to be visible, and pa_sample_rate_valid() wouldn't have to accept rates > > higher than PA_RATE_MAX. > > > > (If you anyway want to see code that does resampling, grep for > > "pa_resampler_run".) > > Wouldn't it avoid additional resampling when you set the sink_input rate > to the sink rate? Yes, but I fear that would require replicating the pa_sink_input.render_memblockq buffer and some of its rewinding logic in the loopback module to deal with stream moves. I don't think it's worth it. --Â Tanu
