[LAU] system configuration

Robert Jonsson spamatica at gmail.com
Fri Jun 12 13:13:34 CEST 2020

Hi Paul,

Yes, you are right, 'let the internet archive it' was mostly a joke, it
didn't really carry across.
I mainly wanted to make a post while I had it fresh in memory, so a little
trigger happy.

I agree the subject isn't simple at all and my findings may not have any
bearing outside my bubble. I did try to make it clear though where it was
more opinion than conclusion. I have not done any tests yet trying to
confirm or deny my feelings on low latency, in comparison to other systems.
Hopefully I can do some follow up tests soon.

If anyone has any links to low latency comparisons between different
operating systems, I would very much like to read them. Don't think I know
of any at the moment.


Den ons 10 juni 2020 kl 01:12 skrev Paul Davis <paul at linuxaudiosystems.com>:

> I think this is a fairly misleading post because nowhere does itt
> really make it clear that everything about these results are system
> specific.
> A line like "his configuration still leaves a bit before it is
> comparable to say a similar Macbook running OS X." ...  but you could
> try a different system configuration and get better results than macOS
> or these results ... and then another and get way, way worse and so
> on.
> Latency performance is a whole system metric, and it's not fair or
> sensible to suggest that anything about your results will have any
> bearing on anything except for an absolutely identical system.
> I'm not trying to invalidate your results - that would be stupid. I
> just think that you're aiming for "the internet to archive it" without
> using the appropriate framing of 'your results may vary dramatically".
> On Tue, Jun 9, 2020 at 2:18 PM Robert Jonsson <spamatica at gmail.com> wrote:
> >
> > Hi all,
> >
> > Just wanted to report some results and conclusions I've drawn so far
> with my renewed interest in getting a more reliable low latency
> configuration, so Internet can archive it...
> >
> > My testing mainly focused on running with 44100 and 64 and 128 frame
> buffers. Though a cool feat to run jack at 16 frames, that's not so
> important to me. My use case is mainly recording audio and midi with real
> time listening.
> >
> > I've installed the linux-xanmod-rt-edge kernel on the same type of
> laptop that rosea grammostola mentioned, Thinkpad T420, running kubuntu
> 18.04. I removed the gui login from X with
> > sudo systemctl set-default multi-user.target and instead use startx as I
> think this shaves off some overhead.
> >
> > Running governor performance, this kernel (or atleast cpufreq tools)
> lists userspace (with a set frequency) as a possible governor, as I have
> used this in the past and found it superior I tried to configure it again
> but it doesn't seem to bite... the setting is done but the frequency still
> changes freely so I reverted to performance governor.
> >
> > I made a little midi test file that I planned to use with Surge and
> Dexed synths.
> > First I used the built in soundcard but when going for 64 frames it
> really struggled to work.
> > jack can start in this configuration but neither ardour or muse could
> use it reliably, muse only output a never ending stream of xruns, ardour
> actually made some sound but it was mostly noise.
> > With Ardour going directly with alsa it didn't even pass the
> configuration step.
> >
> > Being somewhat miffed by this outcome I eventually remembered to try
> with my firewire soundcard and the behaviour was much better! I'm not
> really sure why I expected the internal soundcard to work well... in
> retrospect it is hardly part of it's expected use.
> > With the firewire interface (Presonus Firestudio project) I could
> successfully use the test song I put together in MusE with both Surge and
> Dexed without any xruns during playback.
> > I kept adding a few synths and plugins and it was pretty stable up to
> maybe 50% dsp load (as reported in muse, I believe this metric comes from
> jack though), more load than that and xruns were starting to occur a bit
> too often.
> > I didn't A/B between Ardour and MusE in this configuration yet so I
> can't say if the xruns stem from muse or another part of the system.
> > I do however have the distinct feeling that the realtimeness of this
> configuration still leaves a bit before it is comparable to say a similar
> Macbook running OS X. .. (I really should get my hands on one for
> testing..) and I would really like to understand where the bottlenecks are,
> especially if they are fixable.. In theory (as I understand it), as the dsp
> execution is done in a realtime thread, it should be able to reach close to
> a 100% utilization before xruns need to occur.
> >
> > I guess there a few hardcore things I neglected this far, disabling
> network, upping the priorty of irqs etc. Would be nice if these kinds of
> things were not necessary though..
> > Any other ideas of what I neglected are welcome.
> >
> > Regards,
> > Robert
> >
> >
> > Den sön 7 juni 2020 kl 22:40 skrev rosea.grammostola <
> rosea.grammostola at gmail.com>:
> >>
> >>
> >> On 6/7/20 9:24 PM, Len Ovens wrote:
> >> > On Sun, 7 Jun 2020, rosea.grammostola wrote:
> >> >
> >> >> Disabled the networking (devices). I can play Zynaddsubfx via usb
> >> >> midi keyboard with 0.7626 msec latency, without a single xrun now
> >> >> (testing it the last +- 30 minuts)... With this cheap usb device.
> >> >> Quite shocking... to me at least.
> >> >
> >> > It was my understanding that the USB bus has a hard limit of 1ms.
> >> >
> >> When I push the limits even further, JACK won't start and I find no way
> >> to get it running again with this usb card, even with less strict
> >> setting. I can make it work after reboot. Maybe it has something to do
> >> with it?
> >> _______________________________________________
> >> Linux-audio-user mailing list
> >> Linux-audio-user at lists.linuxaudio.org
> >> https://lists.linuxaudio.org/listinfo/linux-audio-user
> >
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user at lists.linuxaudio.org
> > https://lists.linuxaudio.org/listinfo/linux-audio-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20200612/b7969b8d/attachment.html>

More information about the Linux-audio-user mailing list