Fix Buffer Overflow when device numchannel changes

[necoaudio]

macOS can change a device numchannel during use. This can be observed, for example, in the situation where a phone call is answered in macOS. When this situation occurs, it is likely that the number of channels in the capture device is increased, causing an increase in the buffer size and consequently a buffer overflow when the buffer is copied from bufferLists.

The fix is just a proposal on how to try to work around the problem without losing data. More tests need to be performed to see which of the channels should be copied (in situations where a larger number of channels are generated). Another solution would be to avoid overflow and put RtAudio in some error state (requesting device updates).

[luzpaz]

Any traction here ?

[garyscavone]

I find it hard to believe that any OS would allow the number of channels for a device to be changed while the device is in use. If that can happen, it would surely break almost everyone's code. In any event, this is only a proposed fix and it would be good to know if has been tested for use. I would hate to have to stop / abort a running stream if this happens but at the same time, we would need to know which channels to use if the stream is to keep running properly.

[necoaudio]

It is quite simple to reproduce the problem on macOS (my test was done on a mac book pro on the default 1 channel capture device). Simply start a capture (perform in full duplex -- playing silence on the output device) and a phone call is answered on macOS (using face time). When this occurs, the capture device that had 1 channel now has 3, causing buffer overflow when copying to RtAudio's internal buffers.