Re: [pulseaudio-discuss] Virtual audio cable - high cpu usage
On 2/4/21 7:15 PM, Sean Greenslade wrote: 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 card (even though both report 44100 Hz), it always has to resample in order to correct for the clock skew. If you don't understand, here is an analogy: 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 method. The default, speex-float-1, is light on the CPU resources and should produce no distortions detectable by human ear on typical speech and music. 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 going higher than that. Thanks for your response. I understand the problem of clock drift when we have several audio hardware devices (with different qwartz). But here, it's a pity that the null video driver has an independent clock... 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 have 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: https://jackaudio.org/faq/multiple_devices.html 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. If you have an HDaudio device, it's quite likely that the HDaudio bus clock and your MONOTONIC_RAW time are locked already. If you use the MONOTONIC option for your timers, it'll be subject to NTP corrections but for short-enough rendering you shouldn't see a problem without resampling. My 2 cents. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] USB-connected headsets: no sound
On Thu, 4 Feb 2021, Sean Greenslade wrote: There are two places in pavucontrol where you will need to verify things. Sean, I did a lot of poking in the system. Here's the relevant lines in dmesg: # dmesg [4721657.287134] usb 1-11: new full-speed USB device number 49 using xhci_hcd [4721657.877083] usb 1-11: New USB device found, idVendor=046d, idProduct=0a56, bcdDevice= 1.03 [4721657.877086] usb 1-11: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [4721657.877088] usb 1-11: Product: Logitech H570e Stereo [4721657.877089] usb 1-11: Manufacturer: Logitech Inc [4721657.877091] usb 1-11: SerialNumber: [4721658.041812] usb 1-11: Warning! Unlikely big volume range (=4125), cval->res is probably wrong. [4721658.041816] usb 1-11: [11] FU [Sidetone Playback Volume] ch = 1, val = 0/4125/1 [4721658.180916] input: Logitech Inc Logitech H570e Stereo Consumer Control as /devices/pci:00/:00:01.3/:01:00.0/usb1/1-11/1-11:1.3/0003:046D:0A56.0014/input/input 53 [4721658.233326] input: Logitech Inc Logitech H570e Stereo as /devices/pci:00/:00:01.3/:01:00.0/usb1/1-11/1-11:1.3/0003:046D:0A56.0014/input/input 54 [4721658.233482] hid-generic 0003:046D:0A56.0014: input,hiddev96,hidraw1: USB HID v1.11 Device [Logitech Inc Logitech H570e Stereo] on usb-:01:00.0-11/input3 When I entered the Warning! in duckduckgo I found a 7-year-old thread on a red hat forum. There I learned about the 'pactl list' command. Running that here poured out a lot of output. The sections on the Logitech headset are in the attached gzipped text file. I don't understand why but I see what's probably the underlying cause. I hope that your expertise can translate it to explain what I need to do about the suspended and other non-working parts. Regards, Rich pactl-list.txt.gz Description: GNU Zip compressed data ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual audio cable - high cpu usage
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. Renaud Le ven. 5 févr. 2021 à 02:15, Sean Greenslade a écrit : > 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 > card > > > (even though both report 44100 Hz), it always has to resample in order > to > > > correct for the clock skew. If you don't understand, here is an > analogy: > > > 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 > method. > > > The default, speex-float-1, is light on the CPU resources and should > > > produce no distortions detectable by human ear on typical speech and > music. > > > 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 > going > > > higher than that. > > > > Thanks for your response. > > I understand the problem of clock drift when we have several audio > hardware > > devices (with different qwartz). > > But here, it's a pity that the null video driver has an independent > clock... > > 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 > have > > 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: > > https://jackaudio.org/faq/multiple_devices.html > > 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. > > --Sean > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
