Behavior of Pa_GetDeviceInfo() and PaAsio_GetAvailableBufferSizes() - pyaudio

Question

I'm building a simple application using portaudio, but there is something I can't quite explain when it comes to ASIO drivers, and to the behavior of Pa_GetDeviceInfo() and PaAsio_GetAvailableBufferSizes()
Let's say I use an external application to record audio from my ASIO device at 48 kHz.
At this point if I run the "pa_devs" example that ships with portaudio, I get the below:
[ Default ASIO Input, Default ASIO Output ]
Name = xxx
Host API = ASIO
Max inputs = 8, Max outputs = 8
Default low input latency = 0.0196
Default low output latency = 0.0196
Default high input latency = 0.0196
Default high output latency = 0.0196
ASIO minimum buffer size = 864
ASIO maximum buffer size = 864
ASIO preferred buffer size = 864
ASIO buffer granularity = 0
Default sample rate = 44100.00
Now if I make a second recording at 192 kHz, and subsequently run "pa_devs" again, I get this:
[ Default ASIO Input, Default ASIO Output ]
Name = xxx
Host API = ASIO
Max inputs = 8, Max outputs = 8
Default low input latency = 0.0784
Default low output latency = 0.0784
Default high input latency = 0.0784
Default high output latency = 0.0784
ASIO minimum buffer size = 3456
ASIO maximum buffer size = 3456
ASIO preferred buffer size = 3456
ASIO buffer granularity = 0
Default sample rate = 44100.00
So what seems to be happening is that the buffer size is automatically adjusted based on the sample rate, to maintain a fixed latency in absolute terms:
864/48000 = 3456/192000 = 18 ms
Now here is the real question. As opposed to "pa_devs", my own application doesn't start and stop between recordings, but is constantly running on the side.
However, if between recordings my app calls Pa_GetDeviceInfo() and PaAsio_GetAvailableBufferSizes() then I invariably get the same latencies and the same ASIO buffer sizes. Basically it doesn't seem to see that the external recording application has changed the sample rate between successive calls. Any ideas what can be causing that ?
[edit]: using pyaudio builds from here (with ASIO support) as a different observation mechanism, I find that executing pyaudio.PyAudio().get_device_info_by_index(N) also invariably returns the same answer, even though the sample rate has been changed (which I can also monitor on the ASIO control panel)
Yet as a different observation mechanism, I have an Audio Precision box. On the ASIO connector settings, it instantly reflects any changes of sample rate and changes of buffer sizes as soon as recording starts on the external application. How come pyaudio and my own app do not get notified of changes too ?

Answer 1

At least now I think I understand the root cause of the problem. I'm not too sure if that's a bug or a design intent.
When the parameters of devices get changed externally (e.g. current sample rate or default sample rate), portaudio won't reflect these changes (in terms of sample rate but also in terms of buffer sizes and latencies) as long as all previous calls to Pa_Initialize() have not been closed by a Pa_Terminate() and that Pa_Initialize() is eventually called again.
So if an app calls Pa_Initialize() at startup, it will get the same replies from all subsequent calls to Pa_GetDeviceInfo() and PaAsio_GetAvailableBufferSizes(), even if devices properties are changed externally in the meantime.
Rather, it seems an app should always call Pa_Initialize() and Pa_Terminate() in pairs every time it wants to do anything, be it as simple as Pa_GetDeviceInfo(). It seems to raise further questions:
what about pyaudio ? it exposes terminate() but doesn't expose initialize(). I haven't found a way to force an update of devices properties. Even reload(pyaudio) doesn't do the trick.
What about apps that are concurrently running and that load the same shared portaudio library ? If they make interleaved calls to Pa_Initialize() and Pa_Terminate(), they presumably won't get correct values ?