Hi folks,
I've got either a bug or a misunderstanding in how ALSA handles ioplugs that provide hw_params restrictions. My understanding is that the snd_pcm_ioplug_set_param_* functions are supposed to restrict which hw_params settings a client may set. This seems to work for at least access and format. But I noticed that it's broken for buffer_bytes and periods at least.
Attached is two source files demonstrating the problem. alsa-example.c is a dead-simple ioplug module. It sets some hw_params restrictions, and does basically nothing else. The important thing to notice is that it sets /only one/ allowable period size, period count, and buffer size, all of which are compatible with each other (256 byte period * 8 periods == 2048 byte buffer size).
There is also test client, alsa-test.c, which attempts to violate those hw_params restrictions, and succeeds! The eventual call to the ioplug's example_hw_params() callback gets an invalid buffer_size parameter (it happens to be 512).
Here is the output when run on my Arch Linux with alsa-lib 1.0.25:
[aeikum@aeikum ioplug_buffer_bytes]$ ./alsa-test ALSA-example: Opening bytes: 512 ALSA-example: hw_params: 512 TEST FAILURE: buffer_size != 8812: 512 ALSA-example: stop ALSA-example: close [aeikum@aeikum ioplug_buffer_bytes]$
Am I misunderstanding the snd_pcm_ioplug_set_param_* methods, or is this a bug? I am seeing this behavior in the wild with a pulseaudio client that ignores my hw_params restrictions.
Thanks for any insight, Andrew