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