Crackling with pulseaudio, but no xruns showing up

[lilith]

I made a strange observation. Currently I'm on Ubuntustudio and everything works pretty good. I'm using Studiocontrols with Jack and the pulse audio bridge. When I have a Reaper (or e.g. Bitwig) project open which uses a lot of CPU already (let's say 70%) and at the same time I listen to something through the browser via pluseaudio surfing or moving the Thunar windows around causes crackles and stutters. I see CPU spikes of almost 100% when I do this. This is best observed when playing a sine tone in Firefox and muting Reaper (so Reaper is just increasing CPU usage). However these crackles don't show up as xruns. The same does not happen when I play a sine tone in Bitwig and have the Reaper project running at the same time. No crackling at all.

Now I changed the pulse parameters to

high-priority = yes
nice-level = 0
realtime-scheduling = no
realtime-priority = 5

Again I get crackles but these most of the time now correlate with xruns. Sometimes I'm having still crackles without xruns though.

Is this related to the realtime priority of pulse audio somehow? If pulse is not running with RT priorities can this cause crackles and xruns don't show up?
It's not a problem, but I find it irritating that there are crackles without xruns. On the other hand it affects only pulse audio.

[asbak]

My system isn't remotely like yours because it just uses qjackctl, module-jack-sink and scripts to handle pulse via jack audio configurations but you shouldn't be hearing crackles or stutters when playing pulse via jack.

You shouldn't be seeing xruns and CPU spikes either for that matter.

There are also much better & faster browsers out there than Firefox, another thing to consider.

[lilith]

My system isn't remotely like yours because it just uses qjackctl, module-jack-sink and scripts to handle pulse via jack audio configurations but you shouldn't be hearing crackles or stutters when playing pulse via jack.

You shouldn't be seeing xruns and CPU spikes either for that matter.

There are also much better & faster browsers out there than Firefox, another thing to consider.

If I see xruns or not seems to depend on the priority with which pulse is running. Crackling I get in both cases. When the CPU usage is low there are no crackles in pulse. Can you recommend a browser? In Chromium it´s even worse I have the feeling.

[asbak]

I use Brave now, it's a chrome derivative but quite optimised and fast. Things at FF seems to be going backward. Can't comment on whether or not pulseaudio works better with Brave through jack vs FF, since on my end there aren't crackles or xruns when using browser audio.

This is all I have in my pulse daemon.conf, it probably doesn't address your particular problems but here it is

default-sample-format = float32le
default-sample-rate = 48000
#default-sample-rate = 44100
realtime-scheduling = yes
exit-idle-time = -1
resample-method = speex-float-1


By the way, I think you're on Ubuntu? There are often "enhancements" and services on Ubuntu which may or may not contribute to poor audio performance. When I run jack I stop unnecessary services via script automation with qjackctl and restart them once qjackctl exists.

Having things like snapd installed probably won't help audio performance either, I think that's a standard feature with Ubuntu?

There are a couple of thread on performance tuning and bug-hunting where many of these topics are covered so those would definitely be worth reading and comparing to your current setup.

[lilith]

Thanks. Just booted into the UbuntuStudio live system and get the same behaviour. I think it's not worth to look more into it. Seems to be more or less normal... it only is an issue while listening to music through the browser while the CPU is under heavy load.

[lilith]

Hmmm... now that's interesting: It does not crackle when I use Spotify which also uses Pulse. Only with Firefox and Chromium.

[asbak]

it only is an issue while listening to music through the browser while the CPU is under heavy load.

I could be mistaken but to me that looks like the clue right there.

Performance on this system appears to be somewhat marginal and this shows up when it is put under load. On the other hand, one should also define what does "heavy load" mean? No system is going to run smoothly if it is being driven beyond its capabilities with resource hungry plugins or other tasks.

What the underlying causes for the xruns are can be difficult to determine whether it be hardware related, configuration related or a combination of both.

It should be possible to have jack & pulse running with a couple of plugins (obviously not the really system intensive ones) running in a sequencer & host and some applications like Guitarix running and so on while also browsing or playing back browser audio without getting xruns.

If this fails either the computer is hopelessly inadequate or there could be chipset related handicaps with the computer & soundcard, or jack is set up with sub-optimal settings for the hardware being used (*this is extremely common), or a sub-optimal kernel is being used, or some configuration settings are sub-optimal, or a combination of these factors.



Examples
*PCI type cards - set jack to 2x128 or 2x256, at least initially, it shouldn't be xrunning at these settings. The lower the settings the sooner it will xrun.
USB cards - set jack to somewhere in the region of 3x128 initially, it shouldn't be xrunning at these settings. The lower the settings (3x64 and lower) the sooner it will xrun.
As an alternative to jack raq or seq MIDI, try turning these off and use a2jmidid instead.
Some cards like the RME 9652 xruns under jack when using its own MIDI ports, it's probably a driver bug.
Some Thunderbolt chipsets are known to be buggy with soundcards connected via an adaptor to USB.


The only way I know of to fix xrun issues is via tedious process of elimination, getting rid of potentially problem services and looking at process activity and disk i/o activity to gain more clues. It also assumes having a base configuration that's more or less in-line with what (presumably) people use who don't experience many issues.

My own system isn't configured exactly like Ted's but this is a good starting point imo. Obviously some of the settings can be adjusted for one's particular circumstances.

http://www.tedfelix.com/linux/linux-midi.html

[lilith]

Sorry, I think I was not clear enough. When Using Reaper or Bitwig I can bring my system to the limit without getting xruns.
My question was how I can get crackling while I don't see any xruns. This happens when I keep a Reaper project playing in the backgroud (~60% DSP load shown in Reaper) and I listen to music from the Brower. Opening new Firefox tabs or changing the playhead position in Reaper causes CPU spikes and when this happes I get crackling noises, but no xruns. When however I give Pulse RT priorities I also get xruns at the same time (most of the time).

Thanks for the link...will go through and check my settings.

[tapenade]

Many years ago, there was an article and a whole forum subsection on how certain laptop computer manufacturers had made certain models where the built-in wifi and networking ALWAYS messed with the audio and couldn't be fixed in software nor firmware. It was an entire super-long forum article and responses about how to dodge those computers.

But that was way back in like the year 2010 or something like that.

It was a reason to be VERY careful when buying a computer.

As for Firefox, in the about:config URL, you could set these: (type "connections" into the search bar)

network.http.max-connections (default is like "900"; you could set it safely down to 3 or 4; 8 isn't bad)
do the same with the websocket one.

If you only browse one site at a time, and only do one thing at a time and don't need massive CPU heavy browsing features, this literally cuts the maximum number of internetworked connections down to whatever you like.

This about:config editing technique is also good for setting "privacy.tracking" to true (turns OFF several ad systems)
You can also turn down maximum number of cookies "1" is nice, and turn of "prefetch" and "fetch" functions. Fetch looks for info you have NOT yet clicked on. It can always be turned off. It's a WINDOWS kind of annoyance.