All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Eikum <aeikum@codeweavers.com>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Andrew Eikum <aeikum@codeweavers.com>,
	alsa-devel <alsa-devel@alsa-project.org>
Subject: Re: [PATCH 2/2] Improve hw_params documentation
Date: Thu, 17 Nov 2011 08:02:43 -0600	[thread overview]
Message-ID: <20111117140243.GK30602@foghorn.codeweavers.com> (raw)
In-Reply-To: <4EC43465.5060901@ladisch.de>

On Wed, Nov 16, 2011 at 11:08:37PM +0100, Clemens Ladisch wrote:
> On 11/16/2011 10:31 PM, Andrew Eikum wrote:
> > 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.
> 
> I can reproduce this.
> 
> Try running the program with LIBASOUND_DEBUG=1; it appears that there is
> a bug in the rate plugin.  (Normal programs actually set their rate ...)

This doesn't change the output in any way. I checked the Arch Linux
alsa-lib build script[1] and it doesn't seem to disable debugging in
any obvious way. Do I have to explicitly enable debugging output and
rebuild?

$ LIBASOUND_DEBUG=1 ./alsa_period_count 
min_buffer_frames: 80
set max buffer size: 80
snd_pcm_hw_params: -12
$ 

[1] http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/alsa-lib

Andrew

  reply	other threads:[~2011-11-17 14:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16 19:56 [PATCH 2/2] Improve hw_params documentation Andrew Eikum
2011-11-16 21:20 ` Clemens Ladisch
2011-11-16 21:31   ` Andrew Eikum
2011-11-16 22:08     ` Clemens Ladisch
2011-11-17 14:02       ` Andrew Eikum [this message]
2011-11-21 22:31         ` Raymond Yau
2011-11-22 13:41           ` Andrew Eikum
2011-11-22 23:57             ` Raymond Yau
2011-11-17  0:45     ` Raymond Yau
2011-11-17 13:27       ` Clemens Ladisch
2011-11-19  1:28         ` Raymond Yau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111117140243.GK30602@foghorn.codeweavers.com \
    --to=aeikum@codeweavers.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.