[arch-proaudio] lmms not working with rt jack; vst and midi
Hi, I'm experiecing problems using lmms. I didn't use it before so it might be related to wrong settings. 1. lmms doesn't run with rt mode enabled in jack. The terminal says: "cannot lock down memory for RT thread (Nicht genügend Hauptspeicher verfügbar)" This is strange as the computer has 20GB of Ram and only 2GB are used upon startup. My /etc/security/limits.conf says: @orm - memlock unlimited @orm - rtprio 99 lmms is running with the "orm" userid. 2. Using a VST plugin (The Demo version of the Legend by Synapse) creates nasty audio dropouts when sending pitchbend or other continuous data while playing (with both, the ALSA or JACK non-rt output). The dropouts are clearly related to the incoming Midi (which is using the ALSA Sequencer interface). The cpu load is around 38% when playing and doesn't change if continous data is received. If it was hardware you'd suspect that midi in and audio are sharing the same interrupt... I know this might be a problem of VST with wine in general or something related to the way the synth is programmed but with these clicks the plugin is basically unusable with controllers and maybe someone knows ways to circumvent this problem. The VST plugin seems to be executed by this process: /usr/lib/lmms/RemoteVstPlugin.exe.so \ /tmp/{3e7dc1eb-ba62-4900-9b5f-ec04d555ec23} xembed BTW (regarding versions): My arch system is up to date. -- Orm
On Sat, 12 Jan 2019 21:15:58 +0100 Orm wrote:
My /etc/security/limits.conf says:
@orm - memlock unlimited @orm - rtprio 99
lmms is running with the "orm" userid.
those settings are normally set for the 'audio' group, not a single user - most conventionally JACK and all jack programs should be run by a user of the 'audio' group; though on arch i think that is now the 'realtime' group
Hi, Am Samstag, den 12. Januar 2019 um 17:17:14 Uhr (-0500) schrieb bill-auger:
On Sat, 12 Jan 2019 21:15:58 +0100 Orm wrote:
My /etc/security/limits.conf says:
@orm - memlock unlimited @orm - rtprio 99
lmms is running with the "orm" userid.
those settings are normally set for the 'audio' group, not a single user - most conventionally JACK and all jack programs should be run by a user of the 'audio' group; though on arch i think that is now the 'realtime' group
Well the audio group also has the same settings in limits.conf and orm is member of the audio group. Shouldn't that suffice? there is no realtime group on my system. Would it help to add it? -- Orm
the 'realtime-privileges' packages handles that; though you can also install the 'pro-audio' package group which includes it
On Sat, 12 Jan 2019 23:22:46 +0100
Orm Finnendahl
@orm - memlock unlimited @orm - rtprio 99
lmms is running with the "orm" userid.
In this context "@orm" means user group orm, use "orm" to specify a user. Though like mentioned, on archlinux install the realtime-privileges package and add your user to the realtime group (needs a fresh login to take effect). -- Joakim
Am Samstag, den 12. Januar 2019 um 20:00:09 Uhr (-0500) schrieb bill-auger:
the 'realtime-privileges' packages handles that; though you can also install the 'pro-audio' package group which includes it
they were both installed on my system, but the realtime group doesn't exist and lmms can't lock down RT memory... Is there anybody on the list using lmms with jack RT or should I file a report to the lmms maintainer? David, are you reading on this list? -- Orm
On Sun, 13 Jan 2019 14:45:53 +0100, Orm Finnendahl wrote:
Am Samstag, den 12. Januar 2019 schrieb bill-auger:
the 'realtime-privileges' packages handles that; though you can also install the 'pro-audio' package group which includes it
they were both installed on my system, but the realtime group doesn't exist and lmms can't lock down RT memory...
If everything is installed, the group must exist. As already mentioned by Joakim, you still need to add your user to the group. The limits.conf file should be located in /etc/security/limits.d/99-realtime-privileges.conf . However, it unlikely would solve the issue, since you already enabled the required privileges by the group of the user.
Is there anybody on the list using lmms with jack RT or should I file a report to the lmms maintainer?
LMMS is not the kind of software I ever used. -- pacman -Q linux{,-rt{-cornflower,,-securityink,-pussytoes}}|cut -d\ -f2 4.20.arch1-1 4.19.13_rt10-0 4.19.10_rt8-0 4.19.8_rt6-0 4.18.16_rt9-1
Hi Orm! On 2019-01-12 21:15:58 (+0100), Orm Finnendahl wrote:
I'm experiecing problems using lmms. I didn't use it before so it might be related to wrong settings.
1. lmms doesn't run with rt mode enabled in jack.
The terminal says:
"cannot lock down memory for RT thread (Nicht genügend Hauptspeicher verfügbar)" This is coming from the jackd log output or when starting lmms in a terminal? How are you starting jack currently?
When I start jackd, it gives me this: ``` Jan 13 17:45:47 dvzrv jackd[14075]: JACK server starting in realtime mode with priority 80 ``` When I start lmms in a terminal I only get some some VST sync support messages and some sample rate related ones, but none indicating the above problem.
This is strange as the computer has 20GB of Ram and only 2GB are used upon startup.
My /etc/security/limits.conf says:
@orm - memlock unlimited @orm - rtprio 99
lmms is running with the "orm" userid. My user is in the 'realtime' group, which takes care of rtprio/memlock now. I assume your user is also in the 'orm' group, yes? Can you check what `ulimit -a` gives you?
FWIW: The 'audio' group is largely irrelevant on Arch these days it seems (as access to audio devices is taken care of by udev).
2. Using a VST plugin (The Demo version of the Legend by Synapse) creates nasty audio dropouts when sending pitchbend or other continuous data while playing (with both, the ALSA or JACK non-rt output). The dropouts are clearly related to the incoming Midi (which is using the ALSA Sequencer interface). The cpu load is around 38% when playing and doesn't change if continous data is received. If it was hardware you'd suspect that midi in and audio are sharing the same interrupt...
I know this might be a problem of VST with wine in general or something related to the way the synth is programmed but with these clicks the plugin is basically unusable with controllers and maybe someone knows ways to circumvent this problem. The VST plugin seems to be executed by this process:
/usr/lib/lmms/RemoteVstPlugin.exe.so \ /tmp/{3e7dc1eb-ba62-4900-9b5f-ec04d555ec23} xembed I don't really use VSTs (nor wine for audio), so others might be of better help regarding this. That being said, there seem to be quite a few bugs in lmms regarding VST: https://github.com/LMMS/lmms/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+vst
Aside from that: I also get xruns on just adding instruments or LADSPA plugins in that application, etc. so I guess the host might be not too realtime safe. It's fairly possible, that you're encountering a bug in lmms. Best, David -- https://sleepmap.de
Hi David, thanks, your mail brought me to the right solution: The problem was that I had installed jack and should have had jack2 installed. It's really a pain with jack vs jack2 vs jack2-dbus. I would prefer to have either the version 1 jack lib removed altogether or at least get a warning when installing lmms and other pro audio apps that the wrong lib is installed. -- Orm Am Sonntag, den 13. Januar 2019 um 18:01:52 Uhr (+0100) schrieb David Runge:
Hi Orm!
On 2019-01-12 21:15:58 (+0100), Orm Finnendahl wrote:
I'm experiecing problems using lmms. I didn't use it before so it might be related to wrong settings.
1. lmms doesn't run with rt mode enabled in jack.
The terminal says:
"cannot lock down memory for RT thread (Nicht genügend Hauptspeicher verfügbar)" This is coming from the jackd log output or when starting lmms in a terminal? How are you starting jack currently?
When I start jackd, it gives me this:
``` Jan 13 17:45:47 dvzrv jackd[14075]: JACK server starting in realtime mode with priority 80 ```
When I start lmms in a terminal I only get some some VST sync support messages and some sample rate related ones, but none indicating the above problem.
This is strange as the computer has 20GB of Ram and only 2GB are used upon startup.
My /etc/security/limits.conf says:
@orm - memlock unlimited @orm - rtprio 99
lmms is running with the "orm" userid. My user is in the 'realtime' group, which takes care of rtprio/memlock now. I assume your user is also in the 'orm' group, yes? Can you check what `ulimit -a` gives you?
FWIW: The 'audio' group is largely irrelevant on Arch these days it seems (as access to audio devices is taken care of by udev).
2. Using a VST plugin (The Demo version of the Legend by Synapse) creates nasty audio dropouts when sending pitchbend or other continuous data while playing (with both, the ALSA or JACK non-rt output). The dropouts are clearly related to the incoming Midi (which is using the ALSA Sequencer interface). The cpu load is around 38% when playing and doesn't change if continous data is received. If it was hardware you'd suspect that midi in and audio are sharing the same interrupt...
I know this might be a problem of VST with wine in general or something related to the way the synth is programmed but with these clicks the plugin is basically unusable with controllers and maybe someone knows ways to circumvent this problem. The VST plugin seems to be executed by this process:
/usr/lib/lmms/RemoteVstPlugin.exe.so \ /tmp/{3e7dc1eb-ba62-4900-9b5f-ec04d555ec23} xembed I don't really use VSTs (nor wine for audio), so others might be of better help regarding this. That being said, there seem to be quite a few bugs in lmms regarding VST: https://github.com/LMMS/lmms/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+vst
Aside from that: I also get xruns on just adding instruments or LADSPA plugins in that application, etc. so I guess the host might be not too realtime safe. It's fairly possible, that you're encountering a bug in lmms.
Best, David
On 2019-01-13 19:35:21 (+0100), Orm Finnendahl wrote:
Hi David,
thanks, your mail brought me to the right solution:
The problem was that I had installed jack and should have had jack2 installed. It's really a pain with jack vs jack2 vs jack2-dbus. I would prefer to have either the version 1 jack lib removed altogether or at least get a warning when installing lmms and other pro audio apps that the wrong lib is installed. I know that the jack/jack2 schizm is not ideal (upstream is currently working towards changing that AFAIK). The only relevant difference in the implementation should be, that jack2 doesn't have access to ALSA midi (which can be gotten around with by using a2jmidid). Other than that, they should operate in the same way.
What exactly leads you to believe, that jack offers "a wrong lib"? All of the pro-audio applications were actually compiled against jack (as it's still the default). Do you have logs to provide some more insight? This might be very relevant for upstream. Best, David P.S.: In any case, I'm glad this worked out for you! -- https://sleepmap.de
Hi David, Am Sonntag, den 13. Januar 2019 um 21:29:02 Uhr (+0100) schrieb David Runge:
What exactly leads you to believe, that jack offers "a wrong lib"? All of the pro-audio applications were actually compiled against jack (as it's still the default). Do you have logs to provide some more insight? This might be very relevant for upstream.
For whatever reason when jackd (with jack version 1) starts up, it says it can't lock shared memory because a link/file is missing in /dev/shm/jack-1000/default/... (which is true). Jack works but obviously the locked shared memory isn't working/used (as the lmms error also indicates). You can probably try this yourself by replacing jack2 with jack, tell it to use locked memory and start it up. The file layout with jack2 is different: There is no directory tree named /dev/shm/jack-1000/default/ anymore, but all files are created directly in /dev/shm/ called jack_default_1000_0, jack-1000-0, ... -- Orm
On 2019-01-13 21:52:06 (+0100), Orm Finnendahl wrote:
For whatever reason when jackd (with jack version 1) starts up, it says it can't lock shared memory because a link/file is missing in /dev/shm/jack-1000/default/... (which is true). I have now tried to reproduce a failing lock of shared memory (an exact error message and the exact flags given to jackd would have been very helpful here). What exact file is missing? How do you start jackd? Which terminal emulator, which DE? What does `prlimit` in the same terminal tell you? It should be somehow similar to:
RESOURCE DESCRIPTION SOFT HARD UNITS AS address space limit unlimited unlimited bytes CORE max core file size unlimited unlimited bytes CPU CPU time unlimited unlimited seconds DATA max data size unlimited unlimited bytes FSIZE max file size unlimited unlimited bytes LOCKS max number of file locks held unlimited unlimited locks MEMLOCK max locked-in-memory address space unlimited unlimited bytes MSGQUEUE max bytes in POSIX mqueues 819200 819200 bytes NICE max nice prio allowed to raise 0 0 NOFILE max number of open files 1024 4096 files NPROC max number of processes 128186 128186 processes RSS max resident set size unlimited unlimited bytes RTPRIO max real-time priority 98 98 RTTIME timeout for real-time tasks unlimited unlimited microsecs SIGPENDING max number of pending signals 128186 128186 signals STACK max stack size 8388608 unlimited bytes I really recommend using the realtime-privileges package and the realtime group for configuring this.
Jack works but obviously the locked shared memory isn't working/used (as the lmms error also indicates). You can probably try this yourself by replacing jack2 with jack, tell it to use locked memory and start it up. When you are writing 'locked shared memory isn't working/used', do you refer to using the '-u' flag to jackd or the memory required for the implied '-R' flag? I tried this and without it, but neither jack nor lmms gives me that error (I ran it verbosely with my internal card, similar to this, with and without '-u' flag):
/usr/bin/jackd -P80 -p 512 -u -v -d alsa -d hw:PCH,0 -n 2 -p 1024 -r 44100
The file layout with jack2 is different: There is no directory tree named /dev/shm/jack-1000/default/ anymore, but all files are created directly in /dev/shm/ called jack_default_1000_0, jack-1000-0, ... Yes, that's correct.
Is your issue maybe related to incomplete limits configuration? I can not reproduce this... sorry. Best, David -- https://sleepmap.de
participants (5)
-
bill-auger
-
David Runge
-
Joakim Hernberg
-
Orm Finnendahl
-
Ralf Mardorf