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@xxxxxxxxx>:
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@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
