All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lennart Poettering <mznyfn@0pointer.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: Tony Vroon <tony@linx.net>,
	alsa-devel@alsa-project.org,
	Sophie Hamilton <sophie-alsa@theblob.org>
Subject: Re: Problems with safe API and snd-cs46xx
Date: Tue, 8 Sep 2009 00:47:00 +0200	[thread overview]
Message-ID: <20090907224659.GA5917@tango.0pointer.de> (raw)
In-Reply-To: <s5hbplmssrg.wl%tiwai@suse.de>

On Mon, 07.09.09 17:01, Takashi Iwai (tiwai@suse.de) wrote:

> Maybe a bit "safer" option would be to check the period min size and
> raise to a sane value as a workaround.
> 
> Or, if the period size doesn't matter much but rather the buffer size
> is more important, you can first limit the buffer size as max.  Then
> call snd_pcm_hw_params().  Without this, the PCM core determines the
> period size first, then the buffer size.

Hmm, I wonder what this means for PulseAudio. In the past we had
various problems with the functions for setting the buffer metrics and
the order in which we called them. 

For a short while we used to call
snd_pcm_hw_params_set_buffer_size_near() first, then
snd_pcm_hw_params_set_periods_near() and then snd_pcm_hw_params().

This turned out to cause a couple of issues with some drivers (i think
CS46xx is one of them, ice1712 another, I lack the hw in question, so
i never tried to track this down further). Basically on those drivers
both _set_buffer_size_near() and _set_periods_near() would fail with
EINVAL for some reason and then causing snd_pcm_hw_params() to return
ENOENT. Removing the two calls and calling snd_pcm_hw_params() would
however work. Changing the order of the first two calls, i.e. doing
first _set_periods_near() and then _set_buffer_size_near() would make
both calls succeed and the snd_pcm_hw_params(), too.

It would be good if the ALSA docs would actually mention in which
order those functions need to be called, if the order matters, which
it apparently does.

(Hmm, and while we are at it. Ssome other driver I don't posess,
ens1371 has some issues with the buffer size: if you ask it for 65536
bytes in the playback buffer it will only agree to 65532. If the next
time you ask for 65532 right-away it will only agree to 65528, and so on...)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

  parent reply	other threads:[~2009-09-07 22:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-05 12:24 Problems with safe API and snd-cs46xx Sophie Hamilton
2009-09-07 12:32 ` Takashi Iwai
2009-09-07 13:29   ` Tony Vroon
2009-09-07 14:18     ` Raymond Yau
2009-09-07 14:25     ` Error with custom driver: playback drain error (DMA or IRQ trouble?) Stefan Schoenleitner
2009-09-07 15:01     ` Problems with safe API and snd-cs46xx Takashi Iwai
2009-09-07 15:07       ` Raymond Yau
2009-09-07 15:15         ` Takashi Iwai
2009-09-07 22:47       ` Lennart Poettering [this message]
2009-09-07 23:10         ` Sophie Hamilton
2009-09-08  6:29         ` Takashi Iwai
2009-09-08  7:46           ` Sophie Hamilton
2009-09-08  8:53             ` Takashi Iwai
2009-09-09 11:04               ` Takashi Iwai
2009-09-09 12:29                 ` Sophie Hamilton
2009-09-09 12:35                   ` Takashi Iwai
2009-09-09 14:07                     ` Lennart Poettering
2009-09-09 14:14                       ` Takashi Iwai
2009-09-09 14:27                         ` Lennart Poettering
2009-09-09 14:37                           ` Takashi Iwai
2009-09-10  8:47                             ` Raymond Yau
2009-09-08 13:38           ` Lennart Poettering
2009-09-08 14:42             ` Takashi Iwai
2009-09-09  2:18               ` Raymond Yau
2009-09-07 15:02   ` Sophie Hamilton
2009-09-07 17:04     ` Sophie Hamilton
2009-09-07 17:27       ` Takashi Iwai
2009-09-07 19:06         ` Sophie Hamilton
2009-09-08  6:38           ` Takashi Iwai
2009-09-08  8:19             ` Sophie Hamilton
2009-09-08  9:03               ` Takashi Iwai
2009-09-08 13:18               ` Raymond Yau
2009-09-08 13:21                 ` Takashi Iwai

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=20090907224659.GA5917@tango.0pointer.de \
    --to=mznyfn@0pointer.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=sophie-alsa@theblob.org \
    --cc=tiwai@suse.de \
    --cc=tony@linx.net \
    /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.