From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: PulseAudio and SNDRV_PCM_INFO_BATCH Date: Fri, 19 Jun 2015 13:32:26 +0200 Message-ID: References: <557E86DD.8020709@metafoo.de> <557EBEAA.70004@metafoo.de> <557EDE22.7080808@metafoo.de> <55812F5C.8010502@metafoo.de> <55818DB5.6050007@canonical.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 3E421260525 for ; Fri, 19 Jun 2015 13:32:27 +0200 (CEST) In-Reply-To: <55818DB5.6050007@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: David Henningsson Cc: ALSA Development Mailing List , Lars-Peter Clausen , clemens@ladisch.de, Tanu Kaskinen , Arun Raghavan , Raymond Yau List-Id: alsa-devel@alsa-project.org 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