its a hack in the sense this could be coded better as an external, and thus use less resources… and as I mentioned above, Im surprised if someone has not already written an external to do it, its not that hard.
as above, you code it in C++ as externals, sorry I don’t need it at the moment, so I’m not going to do it.
yeah, thats expected… and its also partly an issue with not having multiple cores available.
this trick might still be worth trying though, the reason is your not really oversampling anything here.
what its doing is calling ‘read file’ and transfer the data at a increased frequency (the higher sample rate) BUT the thread will be blocked doing the read, due to slow IO… i.e. if you tell it do 512kHz, you wont be doing 512kHz, the thread will be blocked trying to read the USB, so your limited to the rate of the IO, not the sample rate.
now the issue are (and why its a hack)
- this is not really the intended purpose, so what does readsf do if it cant get the data fast enough as normally this is an ‘error’ i.e. imagine you are streaming at ‘play rate’, if you cant read fast enough, what does readsf give you… Id imagine (without checking the code) either zeros, or an incomplete buffer.
- thread priority is really important, if the ‘readsf’ thread has the same priority as the audio thread, then its still competing.
(and i checked the readsf code, bizarrely it doesnt set the thread attributes which means it could well be inheriting the thread priority, exactly what you do NOT want … but it is what you want if your using it for its intended priority (=streaming) )
these highlight an issue… you can get away with many things on a desktop, they have power/resources by the bucket load, unless your writing critical stuff (e.g. VSTs in a DAW that got loads of other VSTs loaded) , you’ll get away with murder.
thats just not the case on small platforms like rPI, Axoloti, Organelle … on these, efficiency is important.
BTW: this is a good idea, for sample playback (assuming no need play it at a faster than playback speed)
basically the idea, is to just give yourself a bit of a ‘head start’ , this is a bit like you will see with say youtube… have some data in hand, that allows for ‘variability’ in IO/network, but then just stream the rest at the rate you need it. also helps with not taking up too much memory.