New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load samples asynchronously in a separate thread #21
Conversation
Hmm, I just came across a sample that causes Dirt to segfault, so let me check and test a bit more, just in case. |
80a766c
to
cd7371b
Compare
Whenever Dirt needs to load up a new sample from disk, it now creates a thread for reading and loading sound data into cache. Meanwhile the main thread continues playing, solving the problem with large sample files blocking the main execution thread. To keep it simple, there can only be one thread for file reading (no queue), and to enforce that, there is a boolean variable (and its corresponding mutex) that determines if there is actually one running.
cd7371b
to
9a5b7b2
Compare
OK, there was a small bug, I think it's fixed :) |
Load samples asynchronously in a separate thread
Thanks for this E.g. if I run this:
then this:
the first time round the bass drum isn't played. It'd be much better if it was late by a few samples in that case. I guess part of the problem is when it starts loading the sample. It should do that as soon as the OSC message comes in.. I'll have a look into it. |
Sorry I reverted it again, this change of behaviour won't work out in many situations. I'm surprised this doesn't work out better, there's 0.04 seconds of latency in which dirt can load its samples, and as far as I can tell dirt is using it. I think what we need though is a way that sample triggers are still queued even if samples aren't loaded yet, and only get dequeued when they are. |
I see what you mean... For small samples, it should take little time and could play them as soon as it's loaded. Do you think preloading as soon as Dirt receives the OSC message would solve this problem in most cases?
If I understood correctly, you're saying that when |
Yes, not sure whether it needs a special queue for this, I guess that would be the ideal situation.. |
👍 I'll try to solve this and let you know. Thanks! |
@yaxu OK, I've been working on this and I think I managed to solve the issue you mentioned... Basically Dirt now calls I also added a command-line option to enable or disable late triggering, just in case someone doesn't want late triggers. I left it enabled as default so it behaves as always. Because, actually, most of the time Dirt plays samples really fast :) Especially if you keep them normalized to skip samplerate conversion, for instance. I'll keep testing it a bit more before submitting a new PR, but you can have a look here if you want. |
Load samples asynchronously in a separate thread
Load samples asynchronously in a separate thread
Whenever Dirt needs to load up a new sample from disk, it now creates a thread for reading and loading sound data into cache. Meanwhile the main thread continues playing, solving the problem with large sample files blocking the main execution thread.
To keep it simple, I made it so that there can only be one thread for file reading (that is, there are no queues), and to enforce that, there is a boolean variable (and its corresponding mutex) that determines if there is actually one running. If there is, skip file loading.
This changeset has a (nice) side effect that makes Dirt play a sample at a specific time only if it's already loaded in the samples cache, meaning that the first time you try to play an unloaded sample, it will not actually play until the next "tick" after it's been loaded in the cache. I think this is actually better than the old behavior, because now it will always play a sample in the right moment, even if it's delayed a bit more than before (because it used to play just after loading it).