Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: David Henningsson <david.henningsson@canonical.com>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	clemens@ladisch.de, Tanu Kaskinen <tanu.kaskinen@linux.intel.com>,
	Arun Raghavan <arun@accosted.net>,
	Raymond Yau <superquad.vortex2@gmail.com>
Subject: Re: PulseAudio and SNDRV_PCM_INFO_BATCH
Date: Fri, 19 Jun 2015 13:32:26 +0200	[thread overview]
Message-ID: <s5hmvzw9bn9.wl-tiwai@suse.de> (raw)
In-Reply-To: <55818DB5.6050007@canonical.com>

At Wed, 17 Jun 2015 17:09:41 +0200,
David Henningsson wrote:
> 
> 
> 
> On 2015-06-17 11:19, Takashi Iwai wrote:
> > Well, USB-audio has another problem.  USB-audio uses the intermediate
> > audio ring buffer, and the samples are copied to each URB buffer.  At
> > each packet complete, the driver copies the rest of sample chunk
> > again, and advances the hwptr when the packets.  So, the hwptr of
> > USB-audio is in advance of the actual sample position.  But we provide
> > the runtime delay information for user-space to correct to the more
> > accurate sample position.  So far, so good.
> >
> > A missing piece in this picture is, however, the position of the
> > not-yet-queued samples in ring buffer.  Basically you can rewrite /
> > rewind the sample at most this point, but not farther -- such
> > in-flight samples can't be modified any longer.  This can be seen a
> > kind of hardware fifo with a pretty big and non-continuously variable
> > size during operation.
> >
> > In that sense, get_fifo() looks like a candidate for giving such
> > information, indeed.  But reviving the old (and rather bad working)
> > API appears dangerous to me.  I'd prefer creating a new API function
> > instead, if any.
> >
> > BTW, because of its design like above, a large (or no) period size
> > doesn't help for saving power at all with USB-audio.  This should be
> > considered before the further discussion...
> 
> Hmm...I was trying to understand this power save argument. I tried to 
> figure out a "typical" URB size by just plugging my headset in, and I 
> saw wMaxPacketSize being 96 and/or 192 bytes.
> Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this 
> is just a headset).
> 
> Can this be correct? Does it mean that we are getting interrupts every 
> 192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)?

The driver can build up a URB containing multiple packets, so the
wakeups can be reduced in some level.  But, then the hwptr update also
suffers, and more badly, the in-flight size also increases -- both are
bad for sample mixing, obviously.


Takashi

  parent reply	other threads:[~2015-06-19 11:32 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12 12:29 PulseAudio and SNDRV_PCM_INFO_BATCH Arun Raghavan
2015-06-12 12:32 ` Arun Raghavan
2015-06-12 13:43   ` Alexander E. Patrakov
2015-06-12 13:57     ` Alexander E. Patrakov
2015-06-17  3:04     ` Raymond Yau
2015-06-17  3:38       ` Alexander E. Patrakov
2015-06-15  3:42   ` Raymond Yau
2015-06-15  8:03 ` Lars-Peter Clausen
2015-06-15 11:39   ` Raymond Yau
2015-06-15 12:01     ` Lars-Peter Clausen
2015-06-15 13:34       ` Raymond Yau
2015-06-15 14:16         ` Lars-Peter Clausen
2015-06-16  2:33           ` Raymond Yau
2015-06-17  8:27             ` Lars-Peter Clausen
2015-06-17  9:19               ` Takashi Iwai
2015-06-17 15:09                 ` David Henningsson
2015-06-17 16:48                   ` Alexander E. Patrakov
2015-06-18  3:15                     ` Raymond Yau
2015-06-19 11:19                       ` Alexander E. Patrakov
2015-06-19  1:17                   ` Raymond Yau
2015-06-19 11:32                   ` Takashi Iwai [this message]
2015-06-20  3:24                     ` Raymond Yau
2015-06-20  6:17                     ` Raymond Yau
2015-06-22  2:35           ` Raymond Yau
2015-06-22  6:43             ` Lars-Peter Clausen
2015-06-22  7:49               ` Raymond Yau
2015-06-22  9:41               ` Clemens Ladisch
2015-06-22 11:54                 ` Raymond Yau
2015-06-22 12:10                   ` Alexander E. Patrakov
2015-06-22 12:34                     ` Raymond Yau
2015-06-22 12:49                       ` Alexander E. Patrakov
2015-06-22 15:50                         ` Raymond Yau
2015-06-22 16:28                           ` Alexander E. Patrakov
2015-06-24  5:51                             ` Raymond Yau
2015-06-22 22:52                     ` Takashi Sakamoto
2015-06-27 15:28   ` Alexander E. Patrakov
2015-06-27 17:15     ` Clemens Ladisch
2015-06-27 17:58       ` Alexander E. Patrakov
2015-06-28  2:09         ` 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=s5hmvzw9bn9.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=arun@accosted.net \
    --cc=clemens@ladisch.de \
    --cc=david.henningsson@canonical.com \
    --cc=lars@metafoo.de \
    --cc=superquad.vortex2@gmail.com \
    --cc=tanu.kaskinen@linux.intel.com \
    /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