On Wed, Nov 16, 2011 at 10:20:07PM +0100, Clemens Ladisch wrote:
Andrew Eikum wrote:
+++ b/include/pcm.h @@ -44,8 +44,20 @@ extern "C" {
/** PCM generic info container */ typedef struct _snd_pcm_info snd_pcm_info_t; -/** PCM hardware configuration space container */
+/** PCM hardware configuration space container
- snd_pcm_hw_params_t is an opaque structure which contains a set of possible
- PCM hardware configurations. For example, a given instance might include a
- range of buffer sizes, a range of period sizes, and a set of several sample
- formats. Some subset of all possible combinations these sets may be valid,
- but not necessarily any combination will be valid.
- No validation is done by the various snd_pcm_hw_params_set* functions.
These functions do validate the value that the application is trying to set and adjust all other dependent limits.
I didn't find that to be the case in my testing, at least between periods, period_size, and buffer_size. I've attached a test program here. It sets periods to 10, period_size to 1024, and buffer_size_max to be the same as the return from get_buffer_size_min (in my case, 80). The first call to fail is snd_pcm_hw_params(). If what you said is true, I would expect the set_buffer_size_max() call to fail.
$ gcc -I /usr/include/alsa -lasound -o alsa_period_count alsa_period_count.c $ ./alsa_period_count min_buffer_frames: 80 set max buffer size: 80 snd_pcm_hw_params: -12 $
Andrew