I'm not sure whether it is the best approach but it is not bad. bufferSizeOutdated needs to be atomic.

I wonder whether a single generic callback would be better than individual callbacks for each event type.

bufferSizeOutdated needs to be atomic.

Ah, it's been a while since I've had to think about threads. Do you mean std::atomic?

I wonder whether a single generic callback would be better than individual callbacks for each event type.

Hmm, probably yes. I started out thinking that just kAsioBufferSizeChange would give me the all the info I wanted. But then it turns out my device sends kAsioResetRequest when I change the buffer size (I assume this is typical). And I end up ignoring the newBufferSize parameter in the code anyway.

bufferSizeOutdated needs to be atomic.

Ah, it's been a while since I've had to think about threads. Do you mean std::atomic?

According to https://github.com/PortAudio/portaudio/wiki/ImplementationStyleGuidelines, C++ code should be C++98 so std::atomic wouldn't be available. But perhaps the guidelines are out of date?

I'm also unsure about the thread safety of ASIOGetBufferSize.

I'm thinking perhaps it would be simpler to just drop all the attempts at updating the buffer size, leaving just the callbacks. The library user would be responsible for calling Pa_Terminate() and Pa_Initialize() to get updated info.

This would push all the threading trouble onto the caller. And there can be changes other than buffer size anyway.

@npostavs do you think #519 would supersede this?

As I mentioned there, #519 doesn't seem to cover the case of messages sent before a stream is opened.

@npostavs I don't think it is possible to receive callbacks before the stream is opened. Your code does not handle that either: the callbacks asioCallbacks_ are set during OpenStream.

I don't think it is possible to receive callbacks before the stream is opened.

Oh, you're right. I managed to confuse myself into thinking it could work (possibly I got a bit mixed up between opening vs starting the stream). I believe #519 supersedes this one then.

Closing as superseded by #519.