Adjusting the sample rate is done in the IO thread, which can cause
interruptions in the audio if the adjustment requires heavy computation. The
trivial resampler is guaranteed to be light on the cpu.
It would be better to adjust the sample rate in some other thread (FWIW,
module-combine uses the
On Thu, Mar 24, 2011 at 8:16 AM, Tanu Kaskinen tanu.kaski...@digia.com wrote:
Adjusting the sample rate is done in the IO thread, which can cause
interruptions in the audio if the adjustment requires heavy computation. The
trivial resampler is guaranteed to be light on the cpu.
It would be
On Thu, 2011-03-24 at 15:31 +0200, pl bossart wrote:
On Thu, Mar 24, 2011 at 8:16 AM, Tanu Kaskinen tanu.kaski...@digia.com
wrote:
Adjusting the sample rate is done in the IO thread, which can cause
interruptions in the audio if the adjustment requires heavy computation. The
trivial
The sink may be running in a low-latency mode even if the loopback
stream doesn't have any latency requirements - there may be other
streams active at the same time with stricter timing requirements.
FWIW, the practical case here was a very simple test of looping null
sink's monitor to a hw
On Thu, 2011-03-24 at 09:09 -0500, pl bossart wrote:
The sink may be running in a low-latency mode even if the loopback
stream doesn't have any latency requirements - there may be other
streams active at the same time with stricter timing requirements.
FWIW, the practical case here was a
It might be that you have misunderstood the reason for the patch. Now
that I read the patch description again, it indeed isn't entirely clear:
the problem that I'm having is that the periodic (every 10 seconds)
reinitialization of the resampler takes too much CPU time. The
resampling itself
