Anything less seemingly triggers a bug in the ALSA PulseAudio
plugin when used against PipeWire (audio just never starts playing).
It would be nice to generally have less latency here, but with the
current design based on large resampling queues, this isn't going
to be what causes it.
die_on_error("snd_pcm_hw_params_set_rate()", snd_pcm_hw_params_set_rate(pcm_handle, hw_params, sample_rate, 0));
die_on_error("snd_pcm_hw_params_set_channels", snd_pcm_hw_params_set_channels(pcm_handle, hw_params, num_channels));
die_on_error("snd_pcm_hw_params_set_rate()", snd_pcm_hw_params_set_rate(pcm_handle, hw_params, sample_rate, 0));
die_on_error("snd_pcm_hw_params_set_channels", snd_pcm_hw_params_set_channels(pcm_handle, hw_params, num_channels));
- // Fragment size of 512 samples. (A frame at 60 fps/48 kHz is 800 samples.)
- // We ask for 16 such periods (~170 ms buffer).
- unsigned int num_periods = 16;
+ // Fragment size of 2048 samples. (A frame at 60 fps/48 kHz is 800 samples.)
+ // We ask for 4 such periods (~170 ms buffer).
+ unsigned int num_periods = 4;
int dir = 0;
die_on_error("snd_pcm_hw_params_set_periods_near()", snd_pcm_hw_params_set_periods_near(pcm_handle, hw_params, &num_periods, &dir));
int dir = 0;
die_on_error("snd_pcm_hw_params_set_periods_near()", snd_pcm_hw_params_set_periods_near(pcm_handle, hw_params, &num_periods, &dir));
dir = 0;
die_on_error("snd_pcm_hw_params_set_period_size_near()", snd_pcm_hw_params_set_period_size_near(pcm_handle, hw_params, &period_size, &dir));
die_on_error("snd_pcm_hw_params()", snd_pcm_hw_params(pcm_handle, hw_params));
dir = 0;
die_on_error("snd_pcm_hw_params_set_period_size_near()", snd_pcm_hw_params_set_period_size_near(pcm_handle, hw_params, &period_size, &dir));
die_on_error("snd_pcm_hw_params()", snd_pcm_hw_params(pcm_handle, hw_params));