Couldn't set realtime scheduling priority 1: Operation not permitted

Questions
1

Hello,

I came across an oddity in Ubuuntu while working on the following PR:

When doing the following steps, I got an error in Linux terminal:

  1. Create an empty file in SuperCollider IDE or an editor that can evaluate sclang.
  2. Write the following code:
    thisProcess.nowExecutingPath
  3. Save it as fileMain.scd in the account home folder.
  4. Run fileMain.scd in terminal with the following command:
    sclang '/home/_AccountFolder_/fileMain.scd'
  5. Result
    compiling class library...
qt.webenginecontext: 

GL Type: desktop
Surface Type: OpenGL
Surface Profile: CompatibilityProfile
Surface Version: 4.0
QSG RHI Backend: OpenGL
Using Supported QSG Backend: yes
Using Software Dynamic GL: no
Using Multithreaded OpenGL: yes

Init Parameters:
  *  application-name SuperCollider 
  *  browser-subprocess-path /usr/lib/qt6/libexec/QtWebEngineProcess 
  *  create-default-gl-context  
  *  disable-features ConsolidatedMovementXY,InstalledApp,BackgroundFetch,WebOTP,WebPayments,WebUSB,PictureInPicture 
  *  disable-setuid-sandbox  
  *  disable-speech-api  
  *  enable-features NetworkServiceInProcess,TracingServiceInProcess 
  *  enable-threaded-compositing  
  *  in-process-gpu  
  *  use-gl desktop 

	Found 868 primitives.
	Compiling directory '/usr/local/share/SuperCollider/SCClassLibrary'
	Compiling directory '/usr/local/share/SuperCollider/Extensions'
	Compiling directory '/home/parallels/.local/share/SuperCollider/Extensions'
	numentries = 846541 / 12695528 = 0.067
	5578 method selectors, 2276 classes
	method table size 13505824 bytes, big table size 101564224
	Number of Symbols 12665
	Byte Code Size 388334
	compiled 329 files in 0.24 seconds

Info: 4 methods are currently overwritten by extensions. To see which, execute:
MethodOverride.printAll

compile done
localhost : setting clientID to 0.
internal : setting clientID to 0.
Couldn't set realtime scheduling priority 1: Operation not permitted
Class tree inited in 0.01 seconds


*** Welcome to SuperCollider 3.14.0-dev. *** For help type ctrl-c ctrl-h (Emacs) or :SChelp (vim).
Couldn't set realtime scheduling priority 1: Operation not permitted

On macOS and on Windows, the last two lines of the terminal are as follows:

  • On macOS:

    *** Welcome to SuperCollider 3.14.0-dev. *** For help type cmd-d. 
/Users/_YourAccountFolder_/fileMain.scd

  • On Windows:

    *** Welcome to SuperCollider 3.14.0-dev. *** For help press F1. 
C:\Users_YourAccountFolder_\fileMain.scd

Why does the last line in Linux not return the path of thisProcess.nowExecutingPath?

Thank you in advance!

2

Probably the user needs to be added to the ā€œaudioā€ group, to acquire real-time permission.

hjh

2 Likes
3

PS I tried this:

$ echo "thisProcess.nowExecutingPath.postln; 0.exit" >tmp/test.scd
$ sclang tmp/test.scd
... snip...
*** Welcome to SuperCollider 3.13.0. *** For help type ctrl-c ctrl-h (Emacs) or :SChelp (vim) or ctrl-U (sced/gedit).
tmp/test.scd
cleaning up OSC

So at least the path is there.

Also, I had a quick look at the execution path when sclang is given a file to execute. This seems to go into SC_LanguageClient::executeFile() (C++) side, which prepares a statement thisProcess.interpreter.executeFile("your-pathname-here") and runs that.

In the SC classlib, Interpreter:executeFile returns the codeā€™s result but doesnā€™t print it.

  • Interpreter:executeFile: no postln
  • SC_LanguageClient::executeFile: no printf()
  • SC_TerminalClient (which calls the C++ executeFile): also no printf()

So I canā€™t figure out why Mac and Win are posting the value automatically, while Linux requires an explicit postln. I donā€™t see any platform differences in the sourceā€¦ unexplained magic.

So this may be another one of those where thereā€™s an optimistic assumption that all platforms should err on the side of more convenience to the user.

In this case, I always took the opposite assumption. Consider:

fork { thisProcess.nowExecutingPath }

This doesnā€™t print the path, because the Routine isnā€™t under control of interpretPrintCmdLine. In Terminal, when doing sclang some-path.scd, this is also not under control of interpretPrintCmdLine, so I always assumed that anything I wanted to post, I should post it myself. Iā€™m genuinely surprised to see that Mac and Win seem to be doing extra work that I havenā€™t been able to find the source code.

hjh

1 Like
4

Thank you for your kind and detailed reply.

Probably the user needs to be added to the ā€œaudioā€ group, to acquire real-time permission.

I followed your advice and was able to resolve the issue. I sincerely appreciate your guidance.

So I canā€™t figure out why Mac and Win are posting the value automatically, while Linux requires an explicit postln. I donā€™t see any platform differences in the sourceā€¦ unexplained magic.

Oh, I would like to clarify that there was no mysterious behaviour involved - it was entirely my oversight. When copying, pasting and editing the same code, I accidentally left out the .postln on Linux and mixed up the SCD files between MacOS and Windows. I apologise for any time wasted due to this error. I never noticed/thought I was missing the .postln on Linux.

I have also found that the process of copying, pasting and editing code is very similar to composing a minimalist piece of music, where every detail matters. I realise that I need to focus even more on each element to avoid such mistakes in the future.

Thank you again for your invaluable support and understanding.