ASIO: Handle buffer size changes

[npostavs]

This fixes #472. I don't know if it's the best approach.

When kAsioBufferSizeChange or kAsioResetRequest is received, remember
it and update the buffer sizes the next time
PaAsio_GetAvailableBufferSizes() is called.  Add callbacks for those
messages so that the library user can be aware of them.

[RossBencina]

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.

[npostavs]

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.

[philburk]

Thanks for contributing.

[npostavs]

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.

[npostavs]

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.

[RossBencina]

@npostavs do you think #519 would supersede this?

[npostavs]

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

[RossBencina]

@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.

[npostavs]

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.

[RossBencina]

Closing as superseded by #519.