ASIO: add PaAsio_GetSampleRate() function

[Spacechild1]

PaAsio_GetSampleRate() returns the current sample rate of the specified device at the time of library initialization.
(If the current sample rate is unknown, a sample rate of 0 will be returned.)

For example, this is useful for people who want to use the current sample rate as the default sample rate (which PA's ASIO implementation does not do.)

Actually, I would rather prefer the solution proposed in #970, but if this is not desired, this PR would be an acceptable workaround.

However, the function would still be useful for other purposes, e.g. to select the "current" sample rate - instead of the "default" sample rate - in a UI dialog.

[RossBencina]

Phil and I discussed this PR at length today. I think that an argument can be made for providing a way to query the current ASIO device sample rate irrespective of whether it's the optimal fix for #970. We already have PaAsio_SetStreamSampleRate.

A problem with this PR in its current form is that it does not actually query the current device sample rate. It just returns the cached value retrieved at Pa_Initialize time. Thus if the sample rate is changed asynchronously (e.g a change to a front panel switch, or incoming wordclock) the proposed implementation will return an incorrect value. Thus this PR is not really a perfect fix for #970.

Of course querying the current device sample rate is actually a massive pain (see PaAsio_ShowControlPanel for the implementation and limitations) which comes with its own caveats; and we have used the cached approach for other query functions (e.g, PaAsio_GetInputChannelName). So I am hesitant to request a rewrite to this patch.

[Spacechild1]

Thus this PR is not really a perfect fix for #970.

I agree. In the PR description I actually say that I'd prefer to add a flag to Pa_OpenStream and you seemed to agree: #970 (comment). Do you want me to implement that?

[dyfer]

@RossBencina would you consider @Spacechild1 's offer to add a flag to Pa_OpenStream? This would be very much a welcome addition to the ASIO backend.

[dyfer]

@RossBencina ping

[RossBencina]

I'm not going to approve a patch that I havn't seen, but yes, a host-api-specific flag (i.e. a flag in the host-api-specific parameters structure) to open the stream at the current ASIO device sample rate would be a reasonable candidate for a host-API-specific extension and I can't right now think of any reason that would cause problems. If the patch is written in such a way that it is very clear that there is no change in behavior when the flag is not set, that will make it easier to make the merge decision.

[Spacechild1]

Thanks for the answer! Just wanted to check if you agree with the basic idea before I make a PR.

I'm not going to approve a patch that I havn't seen

Nobody asked for that :)