Perform probing for supported & best period size
As was mentioned in !330 (comment 719378), DACs and ADCs are finicky about period sizes (and buffer sizes, with number of periods too): some support almost anything while other may be limited to a single arbitrary value (recently I've read a report about some "professional" model that was limited only to 256 but can't find it for now). But not only we should know supported sizes, we should select most optimal one which is the lowest one, usually 128 or below. However, unlike JACK that value should not be propagated for the whole software pipeline.
I recommend probing every unknown DAC & ADC device for supported value, starting with the list of 8192/4096/2048/1024/512/256/128/64/32/16/8/4/2. Then it can try using 3 values as pointers for selecting most optimal smallest value: default.clock.quantum, PCIe Payload size (128 by default but can be a power-of-2 value up to 4096 per PCIe port, including PCIe port of a used USB controller) and sample rate (do we want nice, 1ms-divisible numbers ? probably not). Period size does not actually have to be a power-of-2 value but some devices may only support that. Generally, any value divisible by 16 or 64 should suffice which is why I find 48 to be a good choice.
I also recommend to use 3 periods per buffer instead of 2 just to give more leeway with scheduling preemption of the OS, similarly how GPU frames are handled. JACK recommends that for only USB DACs but USB is not as important of a factor as just sometimes missing too strict of a timing (which is why thread that feeds hardware should have highest available priority). More periods can be used but values beyond 8 aren't really practical and even with >4 it would be easier for CPU to just increase period size.
Naturally, highest supported bitrate should always be used and sample rates in range of 48-192khz. It might be theoretically beneficial to feed delta-sigma DSD DACs higher rates by default for their internal upsampler that is a part of PCM->DSD converter block, when DSD is not fed directly. Otherwise higher rates than 48khz only make sense on software filtering nodes that are susceptible to them, such as limiter or time-strecher.
For now period can be set in api.alsa.period-size
in /etc/pipewire/media-session.d/alsa-monitor.conf due to 87292432