lv2 workers not always scheduling about qtractor

[rncbc]

Got the test_work.lv2 plugin running here,... However I really don't know whether what or when it ever fails: I do see "worker N called!" messages and I think the respective "response N called" afterwards. I do activate/deactivate the plugin in quick succession to let it spawn 10 of those each time. Unfortunately I cannot say it ever failed. Maybe I'm doing it wrong or not looking in the right direction.

Care to explain or demonstrate what am I supposed to see when it is said to "fail" ?

Thanks in advance.

[jmage619]

Thanks for looking!

So here's a sample output of a normal run:

plugin activated!
worker 0 scheduled!
worker 1 scheduled!
worker 2 scheduled!
worker 3 scheduled!
worker 4 scheduled!
worker 5 scheduled!
worker 6 scheduled!
worker 7 scheduled!
worker 8 scheduled!
worker 9 scheduled!
worker 0 called! sleeping 0 seconds..
worker 1 called! sleeping 0 seconds..
worker 2 called! sleeping 0 seconds..
worker 3 called! sleeping 0 seconds..
worker 4 called! sleeping 0 seconds..
worker 5 called! sleeping 0 seconds..
worker 6 called! sleeping 0 seconds..
worker 7 called! sleeping 0 seconds..
worker 8 called! sleeping 0 seconds..
worker 9 called! sleeping 0 seconds..
response 0 called!
response 1 called!
response 2 called!
response 3 called!
response 4 called!
response 5 called!
response 6 called!
response 7 called!
response 8 called!
response 9 called!

but after retrying a few times I get the failed version, note I only get the running message and response from worker 0, and no more:

plugin activated!
worker 0 scheduled!
worker 1 scheduled!
worker 2 scheduled!
worker 3 scheduled!
worker 4 scheduled!
worker 5 scheduled!
worker 6 scheduled!
worker 7 scheduled!
worker 8 scheduled!
worker 9 scheduled!
worker 0 called! sleeping 0 seconds..
response 0 called!

Oddly if I deactivate, then reactivate agan, the previous workers finally do run eventually, along with the 10 new workers. But they never ran when they were supposed to.

[jmage619]

Ok I figured out how to trigger the bug every time, just like my sampler code. I pass a char array containing the path in the data field of the work callback. I have it set to 256 chars long. Now it always fails on the third worker, consistently, just like my sampler does in qtractor.

I have pushed the update here if you'd like to pull / retry
https://github.com/jmage619/test_work.lv2

[rncbc]

Now that explains it: the qtractor ring-buffer capacity for each plugin instance is fixed to 1KB, so that it will only accommodate at least 3 of those 256B+ worker schedules on each run--all else will get dropped and lost into oblivion, sorry.

ps. just to compare on other lv2 hosts: jalv does 4KB fixed; ardour is 4x current jack-buffer-size in frames x 4Bytes; or 4x 8KB if using the alsa backend (=32KB).

pps. hopefully fixed on git head master 9502a07

[jmage619]

Ah ok, so just to be sure I'm understanding, my jack frames / period is 128, period is 3, so buf size is 384. For ardour this would give 4 x 384 x4 = 6k

I'd like to support O(100) wavs being loaded at any given time. Even in ardour with those settings I won't be able to schedule more than 24 workers.

Based on what I'm observing is it true that lv2 workers don't run concurrently? only one can run at a time anyway? Perhaps I can change my scheduling to just schedule the next wav loading worker after the previous finishes from its response callback without too much of a performance hit?

Also, I think you've explained the main problem I reported, but I'm not convinced it's related to the random freezing of workers I observed when the data size was sizeof (int) when I was only passing the worker id.

Let me know your thoughts, and thanks again for taking the time out to help me get to the bottom of this! I'll try your updated master later this weekend.

[rncbc]

maybe you can try passing just the pointers (8bytes) as payload to the schedule/response messages? instead of copies of the complete path and/or file-name as you suggest (256byte+)?

there's not really a problem as the whole happens under the same process address-space, just over separate threads, one of them being the real-time one (the one that issues the schedule() calls, which you want to offload from non-realtime processing, like opening and actually read/loading the sample files from disk (the worker thread that issues the response calls), right?

[jmage619]

I retested with the latest master, and it looks like both the issues with not enough ring buffer space, and also the earlier random failures are no longer happening.

Also I took your suggestion and came up with a way to pass pointers rather than the char arrays, that seems to do the trick!