When I run tracktion engine as a plugin I can set sample rate and block size when calling engine’s audioInterface prepare to play (https://github.com/Tracktion/tracktion_engine/blob/381e3220571419d726be759f305576bba2df46cc/examples/EngineInPluginDemo.h#L239). I guessed the plugin host would pass correct sample rate/blocksize here, but my host does not seem to pass the values I configure it with (maybe a problem of the host). then my question is, what does tracktion engine do with these values? what happens if these are different from sample rate/blocksize of the host?
Sample rate and block size are two different things.
If the sample rates are different you’ll get a pitch shifted playback.
If the block size is larger than the prepared one, it will probably crash. If you ask for more samples than you’ve prepared for, you’re violating a contract so all bets are off.
If you ask for less samples, things will probably work.
It sounds to me like this is a purely host problem though. If you ask your host for a sample rate and block size and it can’t oblige, the least it should do is actually prepare plugins with the sample rate and block size it is currently running at.
Thanks @dave96,
My host is ELK’s sushi host, for low latency audio in the ELK boards. It is using a buffer size of 64 samples and configured to 48kHz. However when I run my tracktion engine demo plugin, the engine prints on screen that it is using 44.1kHz and 512 block size. So here I assume sushi is doing something wrong. Using this configuration audio plays nicely, but playback is shifted as you mention. I can manually force the sample rate and block size in the engine plugin and then I get no shifted playback. As per the blocksize it seems to work fine with any values (did not try values lower than 64). So all seems to work as you indicate. I’m not sure however if there are performance issues here. I imagine that a plugin is regularly asked for X samples, therefore if tracktion engine is configured to 512 block size but sushi only asks for the first 64, when sushi asks for the next 64 tracktion won’t recompute them again. I’ll talk to ELK guys to clarify these issues, but I guess it makes sense.
Thanks!
I think you might need to step through the Elk preparing code to see what’s happening.
At the top level what is the buffer size/ sample rate and does this change at any point as it gets to Tracktion Engine’s DeviceManager?
What to you mean at the top level? In plugin’s processor prepareToPlay, if I print the received block size and sample rate, I get 44.1kHz and 512 (which I think is some sort of default?). I think this is an ELK thing really.
If you put a break point in there so execution stops, you should be able to look at the stack trace at each calling function and the block size it is passing down.
I’m wondering if this is actually changing at some point or if Elk just isn’t respecting your device settings request.
ah I see, I’ll have a look, thanks for the suggestion
Hi, I think I was assessing the problem wrong. My problem was that there is the sample rate and block size that is passed to prepareToPlay, and then there is the sample rate and block size of the tracktion engine. I was printing the sample rate and block size of the engine (the HostedAudioDeviceInterface) instead of the sample rate and block size received in prepareToPlay. Now I configured engine properly and I could assess that ELK host was already properly passing sample rate and block size to plugin. Thanks anyway! Just for the records, here’s how sample rate and block size can be configured for tracktion engine as a plugin:
te::HostedAudioDeviceInterface::Parameters p;
p.sampleRate = 48000;
p.blockSize = 64;
audioInterface.initialise (p);
You may also want to set fixedBlockSize to true if ELK pases you a fixed block size. That will remove one block of latency from the engine.
1 Like
Nice, thanks for the suggestion!