Scsynth underperforming compared to other Jack clients

[eckel]

@amindfv

Right, my question wasn’t about running with ParGroups/on multiple cores, it was about having something very similar to scsynth to test with. It would be quite interesting, for example, if the same sclang code performed very differently on one core with supernova than it did with scsynth - pointing to an issue with scsynth, instead of likely elsewhere.

Yes, this is a very good idea. I tried but failed with:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Server 'localhost' exited with exit code 0.

when running the code below with sclang test-supernova.scd 2000. It works with 1000.

(
var arg1, num;

arg1 = thisProcess.argv[0];
arg1.isNil().if({
	num = 200;
}, {
	num = arg1.asInteger();
});

Server.supernova;

Server.default.quit();
Server.default.options.maxNodes = 8192;
Server.default.options.memSize = 32768;

Server.default.waitForBoot({
	var group;

	group = ParGroup.new();
	num.do({ {
		SinOsc.ar([200, 202], 0, num.reciprocal());
	}.play(target: group, addAction: \addToHead) });
});

)

[lucas]

That GUI processing causes xruns and that small buffer sizes like 64 causes lots of xruns with a good sound card, that works fine in other systems, are all Linux problems, I’m quite sure about it by experience. On the internet, I see recipes and advice and people saying they achieved it or not but no real results. Is it a distro problem? Is it the kernel scheduling model? Is it the drivers? Is it Jack? Is it sunday? I don’t know.

@eckel An idea, can you test the very same with other os/distro in the same machine? That could give you some other clues and a bigger picture. But it requires some work, e.g. I wouldn’t do it myself (there are two things I dislike about electroacoustic music: cables and system configuration).

[lucas]

I also guess that in every system it will be a point of instability, then the problem may be that you want an extreme setup with variables you can’t control. This is my advice to you, most people set things up so they work fine for most cases. Nonetheless, I like these threads because they are very informative and something can always arise.

[eckel]

@lucas

That GUI processing causes xruns and that small buffer sizes like 64 causes lots of xruns with a good sound card, that works fine in other systems, are all Linux problems, I’m quite sure about it by experience. On the internet, I see recipes and advice and people saying they achieved it or not but no real results. Is it a distro problem? Is it the kernel scheduling model? Is it the drivers? Is it Jack? Is it sunday? I don’t know.

Not any GUI processing does and not any real time process reacts with xruns. When I run this naive Pd test patch, I can print to the Pd post window 100 times a second and have the audio thread load the CPU with 80% without causing a single xrun. Pd runs with Jack at a blocksize of 64 at 44.1 kHz and a delay setting of 1ms.

[jamshark70]

@eckel

Pd runs with Jack at a blocksize of 64

This is not the same as a JACK buffer size of 64. The JACK buffer size is independent of the size of a Pd control period.

hjh

[eckel]

@jamshark70

This is not the same as a JACK buffer size of 64. The JACK buffer size is independent of the size of a Pd control period.

I meant the Jack blocksize. Both the Pd blocksize and the Jack buffersize are 64.

[jamshark70]

@eckel

Both the Pd blocksize and the Jack buffersize are 64.

Ok, thanks for clarifying that. It isn’t necessarily obvious that they are separate.

It may be that Qt is more CPU expensive than Tcl/Tk. (One thing that annoys me to no end in Pd is its antique pixelated appearance in Linux and Windows – c’mon, it’s 2021 – but, if Tcl/Tk doesn’t antialias and Qt does, then Qt is doing more work. But why that work has to be high priority enough to bomb an audio thread, I don’t know.)

hjh

[MarcinP]

Just a quick note - the std::bad_alloc error is reported here: supernova: silence/crash when starting many synths · Issue #1840 · supercollider/supercollider · GitHub
TL;DR this happens on supernova when it runs out of realtime memory with many nodes. Increasing server.options.memSize “fixes” it.

[jamshark70]

Ah, I see that I misread the post – I should have grouped “Pd, with Jack at a blocksize” together, rather than reading it as “Pd, with Jack, at a [Pd] blocksize…”

Over the years, I’ve seen a lot of confusion in both SC and Pd forums over control blocks vs audio buffers (I misunderstood some aspects myself, for a long time) and I saw the term “block” through that lens… which was not right in this case. I’m sorry about that.

May I suggest one other benchmark? To run the test in command-line sclang, but also open a server status window with Server.default.makeGui – this will also trigger Qt string drawing, but in sclang rather than IDE. Maybe there’s a difference (in thread priority?). Sclang forces all GUI operations onto a lower priority thread… if you can get more juice with a 64-sample buffer and sclang GUI work vs the IDE, that might tell us something.

hjh

[clfest]

Now I run Ubuntu Studio 20.04, I experience occasional xruns running 128x2. That speed was rock solid last distribution with the wifi off. I assumed it was something wrong with the distribution, or
at any case something I now need to ‘adjust’. My machine is a grand old Latitude E6500.

[eckel]

@jamshark70

May I suggest one other benchmark? To run the test in command-line sclang, but also open a server status window with Server.default.makeGui – this will also trigger Qt string drawing, but in sclang rather than IDE. Maybe there’s a difference (in thread priority?). Sclang forces all GUI operations onto a lower priority thread… if you can get more juice with a 64-sample buffer and sclang GUI work vs the IDE, that might tell us something.

Thank you for your suggestion. I thought about this at some point earlier in the whole process, but then lost track of it, among all the other ideas to analyse the problem. It indeed allows me to run much more with this test code:

(
var num, options, server;

num = 2900;
options = ServerOptions.new();
options.maxNodes = 4096;
options.memSize = 16384;
server = Server.new("test", NetAddr.new("localhost", 57115), options);
server.waitForBoot({
	num.do({ { SinOsc.ar([200, 202], 0, num.reciprocal()) }.play(server) });
	server.makeGui();
});
)

That’s the kind of performance I can sustain at a buffersize of 64/2 without an xrun for at least one minute:

[eckel]

@MarcinP

Just a quick note - the std::bad_alloc error is reported here: supernova: silence/crash when starting many synths · Issue #1840 · supercollider/supercollider · GitHub
TL;DR this happens on supernova when it runs out of realtime memory with many nodes. Increasing server.options.memSize “fixes” it.

Thank you! I though I had given it enough memSize, but it needed more. This is what I can achieve with supernova under the same conditions as the lasts tests performed for this discussion.

And this is the code, run as sclang test-supernova.scd 2000 from the terminal:

( // file: test-supernova.scd
var num;

num = thisProcess.argv[0].asInteger();

Server.supernova();
Server.killAll();

Server.default.options.maxNodes = 1024 * 16;
Server.default.options.memSize = 8192 * 16;

Server.default.waitForBoot({
	var group;

	group = ParGroup.new();
	num.do({ {
		SinOsc.ar([200, 202], 0, num.reciprocal());
	}.play(target: group, addAction: \addToHead) });
});
)

[jamshark70]

@eckel

That’s the kind of performance I can sustain at a buffersize of 64/2 without an xrun for at least one minute:

Aha… So there is a concrete difference between two parts of the SC suite. This perhaps can’t be entirely blamed on Qt.

That would be a valid question to raise on github: why does string drawing in sclang StaticText objects not break server performance, while string drawing for the IDE’s status bar does break it?

hjh

[jamshark70]

FWIW, I’ve just logged a bug report:

[linux] IDE server status bar may cause xruns at low-latency audio settings

@eckel I believe I’ve summarized the findings accurately and fairly… if I missed anything, feel free to comment on the github issue.

hjh

[eckel]

Hi James,

sorry for the long silence. I have been busy with other projects.

Thank you very much for filing the bug report. I think your summary is perfect and a great help, as I am not experienced in filing these reports.

Did the developers take notice of it?

Best regards,

Gerhard

[jamshark70]

@eckel

Did the developers take notice of it?

No action yet, though it’s been only a couple of weeks and developer hours are limited.

hjh