[pulseaudio-discuss] Virtual audio cable - high cpu usage
rghia at tixeo.com
Fri Feb 5 09:12:18 UTC 2021
Our application is pulseaudio only.
So in this case I suppose that Jack must be interconnected with pulseaudio.
Do you think that even interconnected, I wouldn't have cpu usage problems ?
Concerning the remap module, without remap the virtual device is not
visible by our application...
Thanks a lot for your time.
Le ven. 5 févr. 2021 à 02:15, Sean Greenslade <sean at seangreenslade.com> a
> On Thu, Feb 04, 2021 at 06:29:47PM +0100, Renaud GHIA wrote:
> > >> Thank you for the tip.
> > >> Now I am sure that resampling does not apply (see below).
> > >> But unfortunately pulseaudio always consumes 30% of one CPU core!
> > >>
> > >
> > > The reason is that you are using module-loopback. Due to a potential
> > > difference between the clocks on the null sink and on the real sound
> > > (even though both report 44100 Hz), it always has to resample in order
> > > correct for the clock skew. If you don't understand, here is an
> > > you have two mechanical watches. Even though both claim that their hour
> > > hand makes one full circle every 12 hours, in fact, if left unattended,
> > > they will diverge over time. There is no way to avoid that, except by
> > > moving to Jack or PipeWire which simply don't introduce a null sink
> with an
> > > independent clock.
> > >
> > > If you decide to stay on PulseAudio, you can tweak the resampling
> > > The default, speex-float-1, is light on the CPU resources and should
> > > produce no distortions detectable by human ear on typical speech and
> > > It does produce easily detectable distortions on specifically crafted
> > > signals. If you want to make sure that the resampler is transparent no
> > > matter what is thrown at it, use speex-float-5. There is no point in
> > > higher than that.
> > Thanks for your response.
> > I understand the problem of clock drift when we have several audio
> > devices (with different qwartz).
> > But here, it's a pity that the null video driver has an independent
> > Concerning pipewire, for now it doesn't work with our particular
> > application (no sound), but it seems to evolve quickly.
> > I haven't tried jack for now, but if it depends on pulseaudio, won't I
> > the same problem?
> Jack doesn't depend on pulseaudio, it's an independent sound server.
> Though there are ways to make the two interconnect.
> As far as I know, jack solves this problem by only allowing one hardware
> sound device and locking all clocks to that. See:
> One thing that just occured to me was to ask whether you acutally need
> to use the remap module at all. I just did a quick test on a very weak
> machine of mine: a null sink, a music player outputting to that sink,
> and ffmpeg recording the null sink's monitor-source, all with matching
> 44.1 kHz sample rates. This resulted in no resamplers in the chain, and
> only 9% CPU usage on a 2010 Atom CPU.
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss