[ubuntu-studio-devel] Ubuntu Studio 19.10 and Xubuntu 19.04 and dual quad core Xeon E5335 CPUs

[Len Ovens]

On Wed, 2 Oct 2019, Mike Squires wrote:

> The short answer here is that if I can use a generic kernel then Ubuntu 
> Studio works across all of the PCs on which I need to run it; the low latency 
> kernel, however, makes using versions 18 and 19 too slow for my needs.

The real question is what you wish to achieve with your system. The goals 
of lowlatency and throughput are not the same. In fact high throughput in 
general probably makes for poor lowlatency performance. If low latency is 
not a hard requirement for your use, then install a generic kernel and be 
happy. Yes it will be faster in some cases with some systems. Or to put it 
another way, the lowlatency kernel will always be at least a little bit 
slower than the generic kernel... on some systems it will be much more 
noticable.

So, end of story? No not really. On a single core atom processor running 
at 0.8Ghz (800 Mhz) the speed difference between generic and lowlatency is 
really not noticable. It can only deal with rather small packets anyway 
with only 2G Ram and a smaller data bus etc. One of the ways that a high 
powered server cpu with lots of cores can be "faster" or have greater 
throughput (how speed is normally measured) is to use really large packets 
and more the whole packet at once... however, if you have a high priority 
audio process that is stopping that file transfer every 128 samples so it 
can do a very small file transfer before that big transfer starts agian, 
then that large packet is effectively broken down into a large number of 
small packets being transfered. Each of those small packet portions may 
take as long as several packet portions would _if_ they were all sent as 
one packet because of the overhead of context change etc.

"Oh but I wasn't doing audio at the same time as the file transfer". Is 
that true? is Jack running silently? Even if no client is hooked to jack, 
if it is running and the packet size is 128 samples, then the device irq 
is firing every 128 samples without fail anyway. So one way to test this 
is to A) shut jack off while doing high speed file transfers (does that 
make it faster?) B) set jack to 1024 sample buffers or higher when it is 
only being used for listening to youtube. You will notice if you play with 
it much that hdmi audio has very large buffers as a minimum size. They 
will not accept 256 sample buffers, they are too small. That is he reason 
computers are not designed for audio... esspecially lowlatency audio. I 
have read some of the Intel specs for latency. In those specs "low 
latency" is 30ms... normal latency is higher. making a PC do low latency 
audio is hard and in some cases it is not really possible with some 
hardware. Having many cores should in theory help, but in the end does not 
as they all have to access the same memory. In a file transfer situation, 
it is main memory use that counts. Audio too uses that main memory and it 
has to access it on schedule whithin the time limits the buffersize puts 
on it.

Having said that... thankyou for reminding me... my machine was feeling 
slow and I am realizing I have the buffer size set quite slow when I don't 
need it to be.

I have been far too long winded on this, but this is not a bug that I can 
see. I do suspect there are ways of doing things better for high memory, 
high core count machines but I am not well versed with them. I know 
setting aside a core or two just for Audio is one of them. I am even aware 
that some people run a generic kernel on most of their system with a 
second real time kernel on a few cores. I have never done this and don't 
know where to look for it.

--
Len Ovens
www.ovenwerks.net