How can I tell if my device is now playing sound?

[Mikez2015]

Hello.

How can I tell if my device is now playing sound?
To understand when the sound effect has ended.

[mackron]

When you call ma_device_start() it is continuously running and firing the data callback. Whatever you copy to the output buffer in the data callback is what will be playing. If you're not copying anything to the buffer, nothing will come out of the speakers, but the device will still be running in the background. Likewise, if you haven't yet called ma_device_start() or have called ma_device_stop(), nothing will be playing.

If you're using the engine, just use ma_sound_at_end() to know if the sound is at the end yet.

(Moving this to the Discussion section.)

[GasimGasimzada]

For the high level API, is there a way to set up a callback that gets fired when the sound stops playing? I was looking into the data callback but I could not find a way to the current sound and user data to it (there is a way to it but it is way before I create the sound).

[Mikez2015]

Thx for fast answer.

I correctly understood that if i want this, I need to use the "ma_engine", and I can’t do it using only "low level api" (there is no analogue "ma_sound_at_end()" for "low level api")?

[Mikez2015]

Thx a lot. For me, the library works perfectly.

[mafemergency]

ma_decoder_read_pcm_frames will return MA_AT_END

but how would we determine the backend has consumed the data? does ma_device_stop consume buffered data before stopping? i was looking for a convenient interface to know when playback was complete -- which is tricky because it may never complete for instance an infinite stream, or when mixing multiple streams, etc. it would still be very handy to have for the simple cases however, like in the examples:

miniaudio/examples/simple_playback.c

Line 69 in 3898fff

getchar();

getchar() wouldn't be required if we could poll or signal an event when a stream has completed playback (not decoding).

here i made an example using the wasapi backend, polling the IAudioClient's clock position to determine if playback has completed:

#define INITGUID
#define COBJMACROS
#include <windows.h>
#include <audioclient.h>

#define MA_DEBUG_OUTPUT
#define MINIAUDIO_IMPLEMENTATION
#include "miniaudio.h"

#include <stdio.h>

void on_data(ma_device *device, void *out, void const *in, ma_uint32 count) {
	(void) in;
	ma_waveform_read_pcm_frames(device->pUserData, out, count, NULL);
}

int main(void) {
	ma_device_config device_config;
	ma_device device;
	ma_waveform_config waveform_config;
	ma_waveform waveform;
	IAudioClock *clock;
	UINT64 freq, pos, qpcpos;
	double time;
	double const max_duration = 1.0;

	device_config = ma_device_config_init(ma_device_type_playback);
	device_config.playback.format = ma_format_f32;
	device_config.playback.channels = 1;
	device_config.sampleRate = 48000;
	device_config.dataCallback = on_data;
	device_config.pUserData = &waveform;
	ma_device_init(NULL, &device_config, &device);

	ma_IAudioClient_GetService(device.wasapi.pAudioClientPlayback,
				   &IID_IAudioClock, (void **) &clock);
	IAudioClock_GetFrequency(clock, &freq);

	waveform_config = ma_waveform_config_init(
		device.playback.format, device.playback.channels,
		device.sampleRate, ma_waveform_type_sine, 0.2, 220);
	ma_waveform_init(&waveform_config, &waveform);

	ma_device_start(&device);

	do {
		IAudioClock_GetPosition(clock, &pos, &qpcpos);
		time = (double) pos / (double) freq;
		printf("playback: %f / %f\n", time, max_duration);
	} while(max_duration > time);

	ma_device_stop(&device);
	ma_waveform_uninit(&waveform);
	ma_device_uninit(&device);

	return EXIT_SUCCESS;
}

this used a waveform generator for convenience and brevity, but for streaming from a vorbis file i suppose you could decode until MA_AT_END at which point you can determine total duration and then test against the clock's position.

[mackron]

There's no convenient way to do this through miniaudio. ma_device_stop() will prefer backends to pause in-place, but if that's not possible, drain instead of flush. But it's ultimately up to the backend. I wouldn't recommend using ma_device_stop() to do what you're wanting.

Off the top of my head, I think the best way might be to set a flag indicating that you want to stop, and then wait for the next data callback to get fired, and then at that point stop your device (don't stop it from inside the callback - set a variable or signal an event that is queried by your main thread). The data callback is fired when the device needs more data, so maybe you can use that to determine when the device must have physically output the sound?

[mafemergency]

The data callback is fired when the device needs more data, so maybe you can use that to determine when the device must have physically output the sound?

this could be a solution if all backends are double buffered. for an example let's say we're playing some music that's 20 minutes in duration and we have a 10 minute front and a 10 minute back buffer (extreme but it's an example):

|  10min   |  20min   |
|   buf0   |   buf1   |
^

device requests we fill buf0, to which we do, and then immediately requests we fill buf1, which again we do. MA_AT_END hasn't triggered yet at this point.

|  10min   |  20min   |  30min   |
|+++buf0+++|+++buf1+++|   buf0   |
           ^

device has consumed the first buffer and now requests we fill it again. MA_AT_END would trigger at this point but it would be erroneous to stop playback since only 10min/20min of audio has been played. so fill buf0 with some default data.

|  10min   |  20min   |  30min   |  40min   |
|+++buf0+++|+++buf1+++|+++buf0+++|   buf1   |
                      ^

another buffer consumed, and another request for more data. at this point we could trigger the device to stop.
this would appear to work if we make assumptions about how the backend requests data. fixed size double buffer is predictable. but is this guaranteed for all backends?

[mackron]

It's an annoying one. So backends will populate the playback.internalPeriods member of the ma_device object which might give you a hind, but it's not 100% consistent because some backends just don't have the notion of a period (a period in this case is your buf0/buf0/bufn in your comment above). In this case it's just set to 1. I cannot remember off the top of my head exactly which backends reliably fill this, but I think WASAPI, PulseAudio and ALSA should be accurate.

I realise this comment isn't too helpful... It's an annoying problem to get this accurate across every single backend.