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
next prev 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