This common setting was ignored by the PulseAudio driver.
It doesn't change the synthesis buffer size, which is still
the number of frames specified by audio.period-size, but
the number of periods may be raised to request a higher latency
amount, unless audio.pulseaudio.adjust-latency is 1 (the
default). In turn, PulseAudio will grant or not this latency
request. See: [PulseAudio Latency
Control](https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/LatencyControl/).
Context: https://github.com/FluidSynth/fluidsynth/discussions/931
There is a new settings "audio.oboe.error-recovery-mode" which has
string value of "Reconnect" (default) or "Stop".
Under `Reconnect` mode, it automatically recreate AudioStream for the
same audio device ID (which is the default = valid device, unless a
specific ID is specified). The behavior is the same as OpenSLES.
In the future Fluidsynth might want to provide consistent error handling
mode for audio device unplugged state, but so far this change makes apps
behave not too weird.
The 2 seconds timeout was chosen for consistency, but the reason to increase the initialization timeout is that one of my test devices (Asus T101HA, Windows 10) fails to initialize the wasapi driver with a timeout error most of the times.
The jack driver has a potential side-effect of starting
a new server. ALSA does not have such side-effects
and therefore makes a better default audio driver.
It seems that the addition of multichannel output has broken the WaveOut driver.
If you try to run FluidSynth with -a waveout, you will get this message:
fluidsynth: audio.periods 8 exceeds internal limit 4
Actually, the default value for period is set to 8, so it will never work unless you change that value before opening the driver. Rather than lowering the default period value or rising the limit of the number of buffers, in my opinion it would be better to free the driver from this limitation, by allocating the needed amount of memory for WAVEHDR too.
Attached patch fixes this bug.
