Frames left in buffer after stopping playback

[yanostulens]

Hi, back with another question.

In my application I've built a simple audio-player class which is supposed to play, pause and stop files. I've noticed something strange however. If I call my method AudioPlayer::playFile("file1") "file1" will start playing, then I call the AudioPlayer::unInit() which will essentially stop the ma_device and uninit the data source in the ma_resource_manager. Finally I call AudioPlayer::playFile("file2") again in order to start playing "file2". But just before "file2" starts playing, some samples of "file1" are audible.

Furthermore I noticed that the deviceConfig.periodSizeInMilliseconds-attribute has an influence on how many samples of the previous file are still audible. So it seems to me that when the device is stopped, there are still some frames left in some kind of buffer.
I was thinking about using a onStopCallback which could then clear the buffer when a file is stopped. But I have no idea which buffer to clear of what function to call.

Thanks you advance for the help!
I'm testing the application on Ubuntu 20.04.4 using ALSA as the back-end.
Here is my code:

#define MINIAUDIO_IMPLEMENTATION
#include "audioplayer.h"

#define MA_ENABLE_ONLY_SPECIFIC_BACKENDS
#define MA_ENABLE_ALSA
#define MA_NO_ENCODING
#define MA_NO_GENERATION

AudioPlayer::AudioPlayer()
{
    ma_result result;
    /**- Initialize a miniaudio-device */
    deviceConfig = ma_device_config_init(ma_device_type_playback);
    deviceConfig.dataCallback = data_callback;
    deviceConfig.pUserData = &dataSource;
    
    /** Decode and send frames to the soundcard in chunks of 100ms of data */
    deviceConfig.periodSizeInMilliseconds = 100;
    result = ma_device_init(NULL, &deviceConfig, &device);
    if(result != MA_SUCCESS)
    {
        std::string res(ma_result_description(result));
        LOG(LogType::ERROR, "Failed to initialize device:" + res);
    }

    /** - Initialize a miniaudio resourceManager */
    resourceManagerConfig =  ma_resource_manager_config_init();
    resourceManagerConfig.decodedFormat =  device.playback.format;
    resourceManagerConfig.decodedChannels =  device.playback.channels;
    resourceManagerConfig.decodedSampleRate =  device.sampleRate;

    result = ma_resource_manager_init(&resourceManagerConfig, &resourceManager);
    if(result != MA_SUCCESS)
    {
        ma_device_uninit(&device);
        std::string res(ma_result_description(result));
        LOG(LogType::ERROR, "Failed to initialize the resource manager: " + res);
    }
}

/** This method simply stops the playback of a single dataSource */
vf_result_e AudioPlayer::unInit()
{
    /** Stop the device: stop playback */
    ma_device_stop(&device);

    /** Kill the dataSource if it wasnt dead already */
    if(dataSource.alive)
    {
        auto result = ma_resource_manager_data_source_uninit(&(dataSource.source));
        if(result != MA_SUCCESS)
        {
            std::string res(ma_result_description(result));
            LOG(LogType::ERROR, "Failed to uninit data source: " + res);
            return vf_ma_error;
        }
        dataSource.alive = false;
    }
    this->readyForPlayback = true;
    return vf_success;
}

void AudioPlayer::data_callback(ma_device *pDevice, void *pOutput, const void *pInput, ma_uint32 frameCount)
{
    /** - decode and read some PCM frames from the dataSource */
    ma_result result = ma_data_source_read_pcm_frames((ma_data_source *) pDevice->pUserData, pOutput,
                                                      frameCount, NULL);

    /** - if the file is at the end we stop playback, signal AudioPlayer::ready_for_playback_cv */
    if(result == MA_AT_END)
    {
        std::unique_lock<std::mutex> playLock(readyForPlayback_m);
        readyForPlayback = true;
        playLock.unlock();
        readyForPlayback_cv.notify_all();
        LOG(LogType::MESSAGE, "Reached the end");
    }
    (void) pInput;
}

vf_result_e AudioPlayer::playFile(playback_info_t toPlay)
{
    /** - Checks if the file to play is stil a valid audio file */
    if(!FileHandler::isValidAudioFile(toPlay.filePath))
    {
        LOG(LogType::MESSAGE, "File to play is invalid");
        return vf_invalid_input;
    }

    ma_result result;

    /** - Initialize the Miniaudio resource manager */
    result           = ma_resource_manager_data_source_init(&resourceManager, toPlay.filePath.c_str(),
                                                  MA_RESOURCE_MANAGER_DATA_SOURCE_FLAG_ASYNC |
                                                    MA_RESOURCE_MANAGER_DATA_SOURCE_FLAG_STREAM,
                                                  NULL, &(dataSource.source));
    dataSource.alive = true;

    if(result != MA_SUCCESS)
    {
        std::string res(ma_result_description(result));
        LOG(LogType::ERROR, "Failed to load sound: " + toPlay.filePath + " error: " + res);
        return vf_ma_error;
    }

    /** - Start the device (this also starts playback) */
    result                    = ma_device_start(&device);
    if(result != MA_SUCCESS)
    {
        ma_device_uninit(&device);
        std::string res(ma_result_description(result));
        LOG(LogType::ERROR, "Failed to start device: " + res);
        return vf_ma_error;
    }

    return vf_success;
}

[mackron]

It'll be because the backend hasn't yet processed the data from the last data callback. When the device is resumed, that leftover data is pushed through to the speakers. That said, the ALSA backend is support to drop any pending audio so I'm not entirely sure what's going on there.

Is it possible to try the PulseAudio backend to see if you're getting the same results?

[yanostulens]

@mackron

Thank you for the quick response! I just did a test using PulseAudio, so using these flags:

#define MA_ENABLE_ONLY_SPECIFIC_BACKENDS
#define MA_ENABLE_PULSE

But unfortunately I got the exact same result.

[yanostulens]

@mackron
I've been looking for the bug for over a day now and thought I could share my finding so far.

First of all I noticed that even though I use the #define MA_ENABLE_ONLY_SPECIFIC_BACKENDS and #define MA_ENABLE_ALSA the application will still use PulseAudio. I checked this by adding a print in both the ma_device_start__alsa and ma_device_start__pulse and noticed that the latter would be called (while using the defines specified above). ALSA would only work if I manually stop the PulseAudio service on my system.

So then I had a look at the ma_device_stop__alsa and ma_device_stop__pulse functions. I saw that in the ma_device_stop__alsa function, you properly drop the ALSA buffer and prepare it such that it could be restarted. Nevertheless, when playing a second file some samples of the previous file are still audible first.

In the ma_device_stop__pulse however I saw that due to potential problems no functions are called to drain the pulse device (the following code is a copy from miniaudio.h):

static ma_result ma_device_stop__pulse(ma_device* pDevice)
{
    ma_result result;

    MA_ASSERT(pDevice != NULL);

    if (pDevice->type == ma_device_type_capture || pDevice->type == ma_device_type_duplex) {
        result = ma_device__cork_stream__pulse(pDevice, ma_device_type_capture, 1);
        if (result != MA_SUCCESS) {
            return result;
        }
    }

    if (pDevice->type == ma_device_type_playback || pDevice->type == ma_device_type_duplex) {
        ((ma_pa_stream_drain_proc)pDevice->pContext->pulse.pa_stream_drain);
        /*
        Ideally we would drain the device here, but there's been cases where PulseAudio seems to be
        broken on some systems to the point where no audio processing seems to happen. When this
        happens, draining never completes and we get stuck here. For now I'm disabling draining of
        the device so we don't just freeze the application.
        */
    #if 0
        ma_pa_operation* pOP = ((ma_pa_stream_drain_proc)pDevice->pContext->pulse.pa_stream_drain)((ma_pa_stream*)pDevice->pulse.pStreamPlayback, ma_pulse_operation_complete_callback, &wasSuccessful);
        ma_wait_for_operation_and_unref__pulse(pDevice->pContext, pDevice->pulse.pMainLoop, pOP);
    #endif

        result = ma_device__cork_stream__pulse(pDevice, ma_device_type_playback, 1);
        if (result != MA_SUCCESS) {
            return result;
        }
    }

    return MA_SUCCESS;
}

So naturally I tried adding a call to pa_stream_drain hoping it would work on my system, and luckily it did, now only if I wait long enough between playback of different songs, no samples are still audible from the previous track.

But unfortunately I really need to use ALSA for my embedded application. So I'm still digging for a way to fix this.

If you have an idea about what could go wrong or where I could look, please let me know! Also, is there any internal buffer that is made and maintained by miniaudio itself that might be causing the problem?

Kind regards!

[mackron]

Enable MA_DEBUG_OUTPUT and post the results here. Might give us some feedback on what's going on:

#define MA_DEBUG_OUTPUT
#include "miniaudio.h"

[yanostulens]

@mackron
The first problem seemed to be fixed, totally my bad. I defined #define MA_ENABLE_ALSA after I included miniaudio.h. Doing it the other way, ALSA is working now. Even when Pulse is also running on my machine.

I tried enabling MA_DEBUG_OUPUT, I'm doing the following in my .cpp file:

#define MINIAUDIO_IMPLEMENTATION
#define MA_DEBUG_OUPUT
#define MA_ENABLE_ONLY_SPECIFIC_BACKENDS
#define MA_ENABLE_ALSA
#define MA_NO_ENCODING
#define MA_NO_GENERATION

#include "audioplayer.h" /** <-- audioplayer.h includes miniaudio.h */

But when running the program, no miniaudio logs show (the only things you see are the commands I type in):

Could I be that just nothing goes wrong, so no logs show?

[mackron]

Well the comment there in ma_device_stop__pulse() explains what's going on there. With PulseAudio, stopping of the device does not result in a drain. I think that explains it. I'm not sure how I'd work around it, given that comment. Does it work with ALSA?

Regarding the printing problem, it's probably due to miniaudio not detecting the presence of snprintf() properly and skipping it. I've seen it before with C++ builds.

[yanostulens]

@mackron thank you for the answer. When using ALSA there are also still some samples audible, which is very strange since you correctly call the snd_pcm_drain() function from libasound.

I am currently solving the problem by re-initializing the ma_device() every time I want to play a new song. Not ideal, but is does the trick.