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.
Regards,
Robert
Den ons 10 juni 2020 kl 01:12 skrev Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>:
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@xxxxxxxxx> 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@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
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
