higher than expected usage for reverb with multiple DSP threads

[tehn]

with a single-core engine like TestSine the reverb only uses one core.

when loading SoftCut or other multi-core engine, reverb jumps to using all cores.

then reloading TestSine, reverb still uses multiple cores. until crone is stopped/started.

@catfact suggests this may be a bug

[catfact]

study1 without reverb

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND      
32343 we       -91   0  182552 116140  95484 S  3.9 11.6   0:57.15 DSP Thread 0 

study1 with reverb

32343 we       -91   0  182552 116140  95484 R 41.3 11.6   1:02.22 DSP Thread 0 

awake with reverb:

31550 we       -91   0  182552 116176  95528 S 24.3 11.6   0:34.03 DSP Thread 0 
31551 we       -91   0  182552 116176  95528 S 23.4 11.6   0:13.82 DSP Thread 1 
31552 we       -91   0  182552 116176  95528 S 23.0 11.6   0:13.70 DSP Thread 2 
31553 we       -91   0  182552 116176  95528 S 23.0 11.6   0:13.62 DSP Thread 3 

awake without reverb:

32343 we       -91   0  182552 116140  95484 S  6.9 11.6   1:24.55 DSP Thread 0 
32344 we       -91   0  182552 116140  95484 S  4.9 11.6   0:04.14 DSP Thread 1 
32345 we       -91   0  182552 116140  95484 S  4.6 11.6   0:04.10 DSP Thread 2 
32346 we       -91   0  182552 116140  95484 S  4.6 11.6   0:04.06 DSP Thread 3 

[catfact]

was hoping this was an artifact of usage metering. DSP work units have to spinlock for audio bus access, and they are at a high priority.

but, the reverb contribution to workload seems to remain the same when more work units are added:

earthsea, 32 voices, with reverb

20897 we       -91   0  182420 115864  95472 S 58.4 11.6   0:26.66 DSP Thread 3 
20896 we       -91   0  182420 115864  95472 S 58.4 11.6   0:26.80 DSP Thread 2 
20895 we       -91   0  182420 115864  95472 S 58.8 11.6   0:26.87 DSP Thread 1 
20894 we       -91   0  182420 115864  95472 S 61.7 11.6   0:31.81 DSP Thread 0 

earthsea, 32 voices, without reverb

20897 we       -91   0  182420 115864  95472 S 36.8 11.6   1:04.87 DSP Thread 3 
20896 we       -91   0  182420 115864  95472 S 37.2 11.6   1:05.18 DSP Thread 2 
20895 we       -91   0  182420 115864  95472 S 37.2 11.6   1:05.26 DSP Thread 1 
20894 we       -91   0  182420 115864  95472 S 39.8 11.6   1:12.47 DSP Thread 0 

[catfact]

i can't really account for why the reverb CPU usage would be spread between DSP threads in the first place. the reverb is a monolithic UGen exported by Faust. AFAICT, when supernova constructs a DSP work graph, each work unit is the perform() method for an entire synth object. (if anyone can correct this reading, please do so!)

one thing is that the reverb definitely isn't using the nova SIMD operations. (neither are the GVerb or FreeVerb implementations in supercollider though - again, to my best knowledge.)

[tehn]

as a test i switched the reverb to GVerb. same behavior observed re: multi-core spreading.

[catfact]

well i'm just not sure this is something to worry about. it could well be a sampling artifact: we are seeing a pretty coarse-grained average of how often a given thread/core is occupied. and the computation of the reverb could be (evidently, is) handed off to a different thread on each tick of the scheduler.

really the useful point of comparison would be: does supernova outperform scsynth on a single thread.

[tehn]

mlr (softcut) all four tracks playing, with heavy reverb. grid plugged in, REC screen. wifi on, attached to network for diagnostics.

scsynth

• CPU 16% (54-59% single core, others negligible (1-3% each)
• TEMP 45c
• POWER (battery) -600ma

supernova

• CPU 51% (49-55% all four cores)
• TEMP 60c
• POWER (battery) -800ma

[catfact]

ok, temperature and current draw is pretty unarguable. spinlocks on bus access still seems like a likely culprit (?), probably not adequately tested on ARM. dang.

supernova source is pretty dense and i don't think we have the bandwidth to tackle a fix for this ourselves. we can try for a more isolated test and file an issue upstream, who knows.

i guess it's time to take a more serious look at the alternative of multiple scsynth processes connected by jack.

[catfact]

i'm closing this since there doesn't seem to be a lot we can do about it. issue #630 discusses dual scsynth approach.