AudioTransportSource + URL Stream for Background Streaming

Audio Plugins
1

I’m attempting to use the AudioTransportSource to read a URL stream in a background thread. I was wondering if I needed to set the Thread for the AudioTransportSource, or if not passing the Thread would still accomplish the stream buffering automatically. Example I’m using:

const juce::URL url("https://S3/my_audio_file.wav");
juce::StringPairArray responseHeaders;
int statusCode = 0;

auto streamOpts = juce::URL::InputStreamOptions(juce::URL::ParameterHandling::inAddress)
        .withConnectionTimeoutMs(1000)
        .withStatusCode(&statusCode)
        .withResponseHeaders(&responseHeaders);

auto stream = url.createInputStream(streamOpts);

juce::AudioFormatManager audioFormatManager;
audioFormatManager.registerBasicFormats();

juce::AudioFormatReader* reader =
    audioFormatManager.createReaderFor(std::move(stream));

std::unique_ptr<juce::AudioFormatReaderSource> readerSource =
    std::make_unique<juce::AudioFormatReaderSource>(reader, true);

std::unique_ptr<juce::AudioTransportSource> transportSource =
    std::make_unique<juce::AudioTransportSource>();

transportSource->prepareToPlay(samplesPerBlock, sampleRate);
transportSource->setSource(m_readerSource.get());

Is BufferingAudioSource better for this kind of thing? I see that requires a thread in its constructor, but it points to AudioTransportSource in its docs so I wasn’t too sure what’d be better in this case.

2

I did end up finding this thread: AudioFormatReader from URL InputStream has no samples?

This claims that an AudioFormatReader requires a PositionableInputStream, and a WebInputStream isn’t positionable. This leads me to believe that it could be possible to use the thread to do pre-fetching on a WebInputStream, but I’m still not 100% sure.