as can be reproduced rather easily using pyalsaaudio's pcm.dumpinfo(), snd_pcm_hw_params_current() seems to always return zero for periods and buffer_time, at least for playback streams (i didn't test capture).
the sequence is basically this:
snd_pcm_hw_params_any(...);
...
unsigned periods = 4;
snd_pcm_hw_params_set_periods_near(..., &periods, ...);
// periods is still fine here
snd_pcm_hw_params(...);
snd_pcm_hw_params_current(...);
snd_pcm_hw_params_get_periods(..., &periods, ...);
// nope, zero periods
i tested this with two completely different setups on two different machines (one a raw driver, another one with pipewire), so it doesn't appear related to the driver.
from the other returned parameters it can be inferred that the period count is actually fine.
one thing i noticed is that snd_pcm_hw_params_current() uses snd_interval_copy() instead of snd_interval_set_value() for exactly these two parameters. but min & max are both zero. i wasn't able to trace it down so far; both the library and the kernel code look fine.
as can be reproduced rather easily using pyalsaaudio's pcm.dumpinfo(), snd_pcm_hw_params_current() seems to always return zero for periods and buffer_time, at least for playback streams (i didn't test capture).
the sequence is basically this:
i tested this with two completely different setups on two different machines (one a raw driver, another one with pipewire), so it doesn't appear related to the driver.
from the other returned parameters it can be inferred that the period count is actually fine.
one thing i noticed is that snd_pcm_hw_params_current() uses snd_interval_copy() instead of snd_interval_set_value() for exactly these two parameters. but min & max are both zero. i wasn't able to trace it down so far; both the library and the kernel code look fine.