[ubuntu-studio-devel] Studio 19.04 vs XUBUNTU 19.04 vs dual quad Xeon

Len Ovens len at ovenwerks.net
Wed Jul 10 14:59:52 UTC 2019

On Mon, 8 Jul 2019, Mike Squires wrote:

> My desktop is a Supermicro X7DAE dual quad core Xeon (2Ghz), with a 1TB 
> RAID 1 boot device and a single 4 TB archive device running off a 3ware 
> 9750 PCI-E card.  A second RAID 5 array running off an older 3ware 9550 
> PCI-X card is currently off line (drives pulled).  Video is a ATI/AMD 
> 5500 PCI-E card.
> History:
> Ubuntu Studio (using "Studio) afterwards) 16 ran fine; v 18 was 
> extremely slow once installed, taking many minutes to complete simple 
> tasks.  I ran 19.04 but although faster than 18 it was still much slower 
> than 16.
> I have since switched to XUBUNTU 19 on the same hardware, speed is OK.

I do not know the Xeons well. I do know that much of the RT patches that 
have been added to main line kernel were developed on the Xeon as well as 
i3-7 processors. And the lowlatency kernel is only slightly different from 
generic. Still, I would at least try running the generic kernel. Note that 
the way GRUB works in Studio is the latest lowlatency kernel is listed 
first followed by the latest kernel (which may be the same lowlatency 
kernel above it) the only way to ensure the generic kernel is selected is 
to use the third option which gives a sub menu of all the kernels to 
choose from. This is a packaging oddity but does insure the lowlatency 
kernel is default.

The other package I would look at is rtirq which may be raising the 
priority of your mouse and keyboard above your storage system. The 
settings in rtirq should always be set for the system the package is used 
with the default tries to be reasonable but I certainly have to change 
things for no xruns at low latency even with PCI audio cards. With USB 
audio I need to specify that the physical port the audio device uses has 
higher priority than any other USB ports. So try disabling 
/etc/init.d/rtirq by:
sudo mv /etc/rc5.d/S01rtirq /etc/rc5.d/K01rtirq

Should this prove to be the problem, it should be possible use the same 
tool to raise the priority of the storage bits to just below the audio 
device. There is work to replace or suplement rtirq with a more dynamic 

Our default-settings has been split up in the last cycle so that 
performance type settings have there own package... I don't know what the 
package is called but perhaps not using that will also help.

The first packages added tend to be installer and controls. Installer only 
runs when the user runs it. Controls does have a daemon (autojack) that 
runs from session start to end, but it doesn't ever show in top and 
normally sits in a wait state until some DBUS event tells it to do 
something. Jackdbus does use some cpu if it is running and certainly more 
with lowlatency setting, with latency set to 1024 I see .3%cpu for jack 
which means about .6% for pulse if it is bridged.

I certainly will be interested in your findings.

Len Ovens

More information about the ubuntu-studio-devel mailing list