Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: Takashi Iwai <tiwai@suse.de>,
	Clemens Ladisch <clemens@ladisch.de>,
	General PulseAudio Discussion
	<pulseaudio-discuss@lists.freedesktop.org>
Subject: SNDRV_PCM_INFO_BATCH
Date: Tue, 04 Mar 2014 15:20:08 +0100	[thread overview]
Message-ID: <5315E118.7060809@canonical.com> (raw)

So, PulseAudio removed timer scheduling for drivers with
SNDRV_PCM_INFO_BATCH, and released 5.0. Meanwhile, USB drivers still
have SNDRV_PCM_INFO_BATCH, so this leads to performance regressions for
USB sound cards.

The question remains - what does SNDRV_PCM_INFO_BATCH really mean?

In the documentation, we have this:
"int snd_pcm_hw_params_is_batch (const snd_pcm_hw_params_t *params) 	
Check, if hardware does double buffering for data transfers for given
configuration."

What PulseAudio was looking for was more something like "what accuracy
does the pointer callback give us". When we asked this question at the
latest audio meeting, SNDRV_PCM_INFO_BATCH was given as the answer, i e,
if this flag is set, pointer callback have no more accuracy than period
boundaries. At least that's how I understood it.

So, either the documentation for snd_pcm_hw_params_is_batch is correct,
in which case PulseAudio should revert the tsched patch. Or the answer
given at the audio meeting was correct, in which case we need to fix the
USB driver to stop sending the SNDRV_PCM_INFO_BATCH flag.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

             reply	other threads:[~2014-03-04 14:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-04 14:20 David Henningsson [this message]
2014-03-04 14:34 ` SNDRV_PCM_INFO_BATCH Takashi Iwai
2014-03-04 14:50 ` SNDRV_PCM_INFO_BATCH Clemens Ladisch

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=5315E118.7060809@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=pulseaudio-discuss@lists.freedesktop.org \
    --cc=tiwai@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox