[alsa-devel] [PATCH 2/2] Improve hw_params documentation

[Andrew Eikum]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alsa_period_count.c
Type: text/x-csrc
Size: 3306 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20111116/61b9f96b/attachment.c