FWIW I just hit the same problem (albeit with Mixbus) when I was trying to connect to Jack in Zorin linux. I tried launching Jack externally (i.e. using QjackCtl) but when trying to connect, MB gives me the same error:- JACK: Cannot use real-time scheduling. I’ve tried installing jackd both ways (with real-time scheduling disabled and then enabled) but I still see the error. Here’s what I see in QjackCtl’s error log:-
Tue Jul 12 10:45:11 2022: Starting jack server…
Tue Jul 12 10:45:11 2022: JACK server starting in realtime mode with priority 10
Tue Jul 12 10:45:11 2022: self-connect-mode is “Don’t restrict self connect requests”
Tue Jul 12 10:45:11 2022: ERROR: Cannot lock down 82280346 byte memory area (Cannot allocate memory)
Tue Jul 12 10:45:11 2022: Acquired audio card Audio0
Tue Jul 12 10:45:11 2022: creating alsa driver … hw:PCH|hw:PCH|1024|2|44100|0|0|nomon|swmeter|-|32bit
Tue Jul 12 10:45:11 2022: configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
Tue Jul 12 10:45:11 2022: ALSA: final selected sample format for capture: 32bit integer little-endian
Tue Jul 12 10:45:11 2022: ALSA: use 2 periods for capture
Tue Jul 12 10:45:11 2022: ALSA: final selected sample format for playback: 32bit integer little-endian
Tue Jul 12 10:45:11 2022: ALSA: use 2 periods for playback
Tue Jul 12 10:45:11 2022: ERROR: Cannot use real-time scheduling (RR/10)(1: Operation not permitted)
Tue Jul 12 10:45:11 2022: ERROR: AcquireSelfRealTime error
Note that where it says creating alsa driver there’s an implication that it’s creating a 32-bit driver (though Zorin and Mixbus are both 64-bit)
For Ardour and Mixbus, is real-time scheduling part of some config file somewhere? i.e. could I get around this by simply editing something in a config file?
Tue Jul 12 10:45:11 2022: ALSA: final selected sample format for capture: 32bit integer little-endian
I think the 32 bit refers to the above, which is the sample format and not the CPU architecture. I recently had persistent problems getting jack to use realtime scheduling on Ubuntu 20.04 LTS despite following all the usual recommended instructions (which, used to work just fine). In the end all I needed to do was a complete reboot after making the changes - previously it was enough to just log out and back in. (I now seldom use jack, but in this particular case it was essential for some plug-in test / measurement I was doing - I’ve no idea why it was a problem this time, neither did I have any inclination to investigate).
Any chance this is a User/Group issue? I thought most Ubuntu-based distributions put an ordinary user in the Audio group by default, but maybe Zorin is different?
It is a system configuration issue, not an Ardour or Mixbus issue. Ardour/Mixbus/jackd need to use realtime scheduling, but it is up to the user to configure the operating system properly to allow that.
The process to allow user realtime scheduling involves a file in /etc/security/limits.d to add permission to request realtime scheduling and lock memory for particular user groups, and then making sure your user account is part of that group. If you have to make changes you may need to log out and back in, or possibly reboot as Mike noted in another post.
Usually that setup is done for you when you install certain packages which require realtime access. On my system it was setup when I installed JACK, but assuming my distribution packagers did a good job it should also be setup if I install the pipewire-jack packages, and there is also a package named realtime-setup which sets up realtime permissions in a general way.
On Debian based systems, installing jackd asks to setup realtime permissions. You can later change this by running
sudo dpkg-reconfigure -p high jackd2
In either case you have to re-login (or reboot) for the permission change to be active.
–
On Arch Linux (and derivatives), you can install the realtime-privileges package, add your user to the “realtime” group, and re-login (see Professional audio - ArchWiki)
Thanks Robin but if I’m reading this thread correctly, Ardour & Mixbus (on Linux) won’t connect to Jack if RT scheduling is disabled? If I can’t re-enable it for some reason it’s not a huge problem - I just wanted to run a quick comparison test but it’s not important.
A major breakthrough here!! In usr/share/jackd there’s a file called audio.conf and in etc/security/limits.d there was an identical file - but called audio.conf.disabled
I renamed the 2nd file so they’re now both called audio.conf and all of a sudden it works!!
With Windows (being a non real-time OS) the averaging provides some much needed functionality. It does so without either hiding or disguising xruns and was only added after extensive testing. It’s certainly not useless, or inconsistent, or unreliable
And apart from Robin, I’ve never known anyone else to complain about it
“it works fine on average, but crashes 5% of the time”
Ardour’s internal Windows backend (WinMME, ASIO) does not average DSP load. process-time query works reliably. – Perhaps there used to be issues with Windows 95 or XP and/or jack2’s use of QueryPerformanceCounter on multi-core systems with freq scaling.
Anyway, “average load” is pretty much useless information. You might as well not display it at all.
Except it does hide xruns. Please re-read the discussion and the source-code. Perhaps that was the intention, but it’s not what happens.
perhaps re-read the discussion thead…
“DSP load is low and I do get dropouts” used to be a major support issue for Harrison Windows users. Those pretty much went away after we stopped requiring JACK (around he same time as the discussion on jack-dev). It still comes up regularly here for Linux/JACK users though.
On the upside, pipewire’s (which replaces JACK) does not follow jack2’s lead, and implements this properly (but pipewire is currently Linux only).
That’s very true - but it came about after dropping Jack and introducing the Portaudio driver!
On Windows, the main problem with Mixbus’s DSP reading is that it can be adversely affected by things which have no connection at all to Mixbus - e.g. starting and using some unrelated program can make MB’s DSP reading vary wildly. This was leading users to mistrust MB. IIRC it was Todd who asked me to come up with an averaging strategy - but it needed to be done in such a way that it didn’t “mask” genuine DSP artefacts such as xruns. One particular problem (with not averaging) is that upgrading other apps (and even upgrading MB itself) will cause an apparent degradation in MB’s DSP performance - and that factor alone has been hugely detrimental to MB sales on Windows. At one time, Windows users accounted for around 85% of MB sales but I’ll bet it’s a looong way short of that now.
Seriously Robin, I’ve no objection to changing Jack’s averaging such that it could be enabled or disabled. Maybe by default it could be disabled for a real-time OS and enabled otherwise. But removing it altogether can only make matters worse.
Timer accuracy has nothing to do with real-time OS. The latter is about reliably meeting scheduler deadlines (Ardour uses REALTIME_PRIORITY_CLASS for backend threads).
As discussed elsewhere, the issue about Windows timer accuracy in jack2’s codebase was understood, and was correctly implemented in Ardour.
evidence to the contrary.
–
As for the issue at hand:
To meaningfully compare performance, all measurements systems use the same algorithm.
Worst case performance provides this. jack2’s heuristic averaging does not.
This was also the motivation to directly add measurement into libardour, independent of the backend. Window > Performance Meters is probably the best way to compare systems.
Sorry Robin but when you and (Tim?) implemented the Portaudio driver you based it on a previous driver written by some guys at Waves. Their driver had some excellent features. e.g. it would work without needing ASIO - which Jack on Windows rarely seems to support - but its big drawback was that it was inefficient. The Waves code would produce xruns when the DSP usage was only around the mid 50’s. And of course averaging made that all appear hugely worse. xruns would occur when the apparent reading was barely in the mid 20’s. By comparison, xruns on Jack were tending to happen way up in the 80’s and 90’s. Todd made a decision to disable averaging if any reading was higher than 95%. And with hindsight that should probably have been 85%.
But averaging itself was never the problem. The problem was simply very poor xrun performance in the Waves driver.
You’re right about the Performance Meters though… they’re surely a much better way to be measuring stuff like this.
But of course the much bigger problem is that having the DSP reading zipping up and down all over the place has been a ginormous turn-off for Win users
Yes. I wrote the initial proof-of-concept based on waves code, and that had issues like you’ve mentioned. Tim Mayberry then did the actual implementation (early 2015) and that works reliably and outperforms JACK (fewer context switches).
While it improved performance for Ardour, it decreased performance for Mixbus at that time. The reason for that were mutexes in the harrison channelstrip DSP which also caused context switches. Those are also meanwhile gone and there was a significant performance improvement then (Mixbus 5 → 6).
And yes, I do recall the conversation we had with Todd, I have just looked it up and read it again to remind myself of the details.
Yes you’ve worked hard (and successfully) over the years to improve your Portaudio driver and it offers many improvements over Jack - but please, please don’t lose sight of the real problem here:-
Now that your Portaudio driver has shed its initial problems, maybe now’s the time to reinstate its averaging feature?
And I don’t mean that in any negative way… Mixbus really does need to look as though it’s not being affected by unrelated apps. I remember we once discussed a ‘traffic light’ system rather than having the percentage reading. Maybe that’d be the way to go if you’re still averse to averaging?
That just feels completely wrong to me. That is assuming my understanding is correct, and on Windows Mixbus/Ardour really is affected by unrelated apps. As a user I need to know if other applications are affecting my audio work so I can know to avoid that during critical times (e.g. recording, real-time export, live use, etc.). If the application is hiding what is really happening in terms of system headroom to complete the audio processing within the alloted time that would give me a false sense of security which would eventually cause problems when I acted on that false understanding.
why is the DSP showing a MORE accurate reading a problem? If I’m tracking in MB and the DSP is wavering between 28% and 34%, I have a a better idea of what’s going on than a green light or yellow light. If I’m trying to tweak my system to maximize performance, I would rather know if the system went from 28% down to 20% after changes, than simply seeing green light before and green light after. I’m very confused as to what the issue is here.
