This has to be handled in two places, in ARDOUR_UI::do_audio_midi_setup and in
the dialogs response handler and in as the window can also be triggered via the
window action manager.
Without a session loaded this makes the message dialog appear in front of the
AudioSetup dialog instead of randomly up in the top left somewhere. This does
mean though that if the AudioSetup dialog is not visible the error message
popup will appear randomly up in the top left(at least on windows, it seems
fine on linux) but I will fix that shortly.
Unfortunately it seems that in zita-alsa-pcmi doesn't set state() correctly in
some cases. Setting an invalid SR doesn't display the correct error message,
first guess would be that set_hwpar is failing and state() is not
representative of the actual error.
Having error codes defined in PortaudioIO means it is not dependent on the
ErrorCodes in AudioBackend but it doesn't really make sense to have another
set, so just use the PA ones until they become insufficient.
If a backend is not returning AudioBackend::ErrorCode values to indicate the
type of error then the default string will be returned which is the same as
what was previously displayed.
This will allow backends to return a more meaningful error message. Eventually
an error code could be returned by AudioEngine::start and the GUI can then use
AudioBackend::get_error_string to convert the error into a translated error
message directly, or it may be desirable to define its own error messages.
The reasons for not doing that right now is that this is a workable solution
with the least change required.
We can't check for Session::actively_recording() because punch out may have disabled that. Rather
than add logic to check if a flush is needed (which is not much different than the code that runs
as part of the flush to disk), just do a flush anyway.
