Dear all,
As much as I’ve been looking at the forum and having analyzed all the examples, I have no idea how to open a file, make a certain audio process and bring it to an audio output.
I understand that AudioSourcePlayer::AudioIOeviceCallback is called by AudioDeviceManager, but where I put the AudioProcessor? Where I hooked an audio processor?
The easiest way is probably to use an Audio Processor Player as your Audio IO Device callback. Then put your processor in AudioProcessorPlayer::setProcessor (AudioProcessor *processorToPlay)
If I am not wrong, the only way to play a file is by AudioSourcePlayer, isn’t it? But Audio AudioSourcePlayer has not a member to insert an AudioProcessor or a member to expose their input/output audio buffer.
Of course, there would be a way to do it, but I do not find it. Where am I wrong?
There are several ways to do that actually, depending on what you want to do next :
Put your audio source directly into your AudioProcessor. In your processBlock method, you can call the audio source getNextAudioBlock
Create a AudioSourceProcessor which only job is to play the source but has an AudioProcessor interface. Then add both your AudioSourceProcessor and your AudioProcessor to an AudioProcessorGraph
Create your own AudioIODeviceCallback which forwards the calls to AudioSourcePlayer and AudioProcessorPlayer
The 1st solution is probably the simplest, the 2nd one is probably the cleanest and the 3rd one …I never tried it but I suppose it should work ?!
I’ll go for a sort of mix of solution 1 and 2. Despite I need to use AudioSources to manage files, I think I’ll go for AudioProcessorPlayer instead of the ‘old’ AudioSourcePlayer.
So, I’ll wrap a couple of AudioSources subclasses (to read and write files) in a AudioProcessor interface and I’ll include the logic of my plugin. Everything under the ProcessBlock() method of such AudioProcessor subclass.
Because, it seems that it is better option to use AudioProcessPlayer than AudioSourceplayer, isn’t it?
In my opinion, yes, it’s better to use only AudioProcessors. Why, because they can easyly be included in an AudioProcessorGraph.
AudioSourcePlayer is designed to do really simple stuff (well…reading a source ) but if you start using AudioProcessor in an AudioProcessorGraph, you can do really complex routing, with multiple channels, processors and stuff.