Capture and Playback Needs to be "Primed" on Startup

[Eecornwell]

I have been experimenting with your library using playback and capture for audio conferencing, thank you for your awesome work! I have my application to a point where I can consistently receive playback and also send microphone output to meeting api on Windows. One thing I have observed is that on startup of the audio, the user's audio will sound "choppy" until a long sound is processed using capture. Once the long sound (approx. 5 seconds) finishes, the audio quality greatly improves and there is no choppy audio unless a new session is started. I have a hunch that this is a buffer issue, but I wanted to check here first to get input. Here are some details:

• Windows WASAPI
• Single Channel Capture/Single Channel Playback
• Both have sample rate of 48000
• Using only PCM data
• Using ma_device_type_duplex to keep both capture and playback in same callback/frequency
• The frequency that the meeting api picks up a sample is 10ms
• The frequency that the callback uses is periodSizeInMilliseconds = 10
• Currently, I am using a uint16_t pointer to directly transfer the data from the callback to the meeting api

Any comments/ideas?

[mackron]

I'm not entire sure on the best way to avoid this to be honest. miniaudio is a fairly thin wrapper around the low level API. It just fires the data callback whenever the backend needs more data. It doesn't do any priming or anything.

That said, it could just be a buggy duplex implementation on the part of miniaudio. Not entirely sure off the top of my head what would be causing it though.

Sorry I can't be of more help with this one. All of your settings look totally fine.

[Eecornwell]

Ok, let me try to decouple the mic and playback callbacks. I was only using duplex for diagnostics and ease of use. One thing I remember seeing in the miniaudio fprint log was that 3*480 buffers were going to be used under the hood. The output and input frames of 480 equal the number of frames the meeting is expecting. I am using these to hold my data/frames:
uint16_t* pData_in = new uint16_t[480];
uint16_t* pData_out = new uint16_t[480];

[Eecornwell]

@mackron, I believe this priming behavior might be happening due to my implementation. Is there a way to make the MA callback function work in another class similar to virtual/override? Or does the MA callback need to be global?

[mackron]

It needs to have the same signature. It could be a lambda, but the signature needs to match or else you'll get compilation errors. You can take advantage of the device's user data member and use the callback as a proxy. Set it via the config, and then access it from the ma_device object after initialization:

deviceConfig.pUserData = &myObject;

In the data callback:

my_class* pMyObject = (my_class*)pDevice->pUserData;
pMyObject->my_data_callback(...);

The pUserData member is for your use - miniaudio won't touch it.

[Eecornwell]

I believe this is exactly what I was looking for! For some reason I assumed that was an internal data member (I need to re-read your docs). I will try that, thanks!

[Eecornwell]

Although, correct me if I am wrong, but I won't be able to use pUserData for capture and playback when using the duplex scheme, right? I need to split them apart.

[mackron]

It's one pUserData pointer per ma_device object. You can just do a wrapper object:

pMyUserData->pPlaybackObject->do_something(...);
pMyUserData->pCaptureObject->do_something(...);

[Eecornwell]

Thanks @mackron, moving the code around to a proxy implementation and putting the audio on a higher thread priority solved my issue.