From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSmSj-0006Np-7c for qemu-devel@nongnu.org; Fri, 21 Aug 2015 09:34:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSmSf-0002zG-0v for qemu-devel@nongnu.org; Fri, 21 Aug 2015 09:34:29 -0400 Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:38337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSmSe-0002yC-H9 for qemu-devel@nongnu.org; Fri, 21 Aug 2015 09:34:24 -0400 Received: by wicja10 with SMTP id ja10so16321684wic.1 for ; Fri, 21 Aug 2015 06:34:23 -0700 (PDT) From: "=?UTF-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?=" References: Message-ID: <55D728E6.9020504@gmail.com> Date: Fri, 21 Aug 2015 15:34:30 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 21/25] audio: common rate control code for timer based outputs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= Cc: QEMU , Gerd Hoffmann Hi, 2015-08-21 00:37 keltezéssel, Marc-André Lureau írta: > Hi > > On Thu, Aug 6, 2015 at 8:28 PM, Kővágó, Zoltán wrote: >> >> - decr = rate_get_samples(&hw->info, &out->rate); >> - decr = audio_MIN(out->fsize - out->fpos, decr); >> - >> - *size = decr << 2; >> + *size = audio_rate_get_bytes(&hw->info, &out->rate, >> + (out->fsize - out->fpos) << 2); >> return out->frame + out->fpos; >> } > > I am not familiar with this "rate" thing, but you are changing the way > it works for Spice without explaining why, and that worries me a > little. > > The rate->bytes_sent is not updated the same way, the result is not > always << 2.. > > I really don't get what this is really doing tbh, some kind of clever > buffer limit :) > The old code pretty much ignored if the buffer overflow (which shouldn't happen normally), while the new one doesn't. The problem is that with this new get_buffer/put_buffer thing if we reach the end of the circular buffer, it will produce have the same effect as a buffer overflow, but we need to handle it more gracefully as it will now happen every now and then. But probably I'll change << 2 to info.shift, to handle more gracefully if the spice stream format changes. Zoltan