From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] audio streaming from usb devices Date: Wed, 10 Feb 2010 13:28:13 -0600 Message-ID: <4B7308CD.30507@codemonkey.ws> References: <4B699B13.60802@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm-devel To: "David S. Ahern" Return-path: Received: from mail-iw0-f185.google.com ([209.85.223.185]:36328 "EHLO mail-iw0-f185.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754008Ab0BJT23 (ORCPT ); Wed, 10 Feb 2010 14:28:29 -0500 Received: by iwn15 with SMTP id 15so403697iwn.19 for ; Wed, 10 Feb 2010 11:28:28 -0800 (PST) In-Reply-To: <4B699B13.60802@cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/03/2010 09:49 AM, David S. Ahern wrote: > I have streaming audio devices working within qemu-kvm. This is a port > of the changes to qemu. > > Streaming audio generates a series of isochronous requests that are > repetitive and time sensitive. The URBs need to be submitted in > consecutive USB frames and responses need to be handled in a timely manner. > > Summary of the changes for isochronous requests: > > 1. The initial 'valid' value is increased to 32. It needs to be higher > than its current value of 10 since the host adds a 10 frame delay to the > scheduling of the first request; if valid is set to 10 the first > isochronous request times out and qemu cancels it. 32 was chosen as a > nice round number, and it is used in the path where a TD-async pairing > already exists. > > 2. The token field in the TD is *not* unique for isochronous requests, > so it is not a good choice for finding a matching async request. The > buffer (where to write the guest data) is unique, so use that value instead. > > 3. TD's for isochronous request need to be completed in the async > completion handler so that data is pushed to the guest as soon as it is > available. The uhci code currently attempts to process complete > isochronous TDs the next time the UHCI frame with the request is > processed. The results in lost data since the async requests will have > long since timed out based on the valid parameter. Increasing the valid > value is not acceptable as it introduces a 1+ second delay in the data > getting pushed to the guest. > > 4. The frame timer needs to be run on 1 msec intervals. Currently, the > expire time for the processing the next frame is computed after the > processing of each frame. This regularly causes the scheduling of frames > to shift in time. When this happens the periodic scheduling of the > requests is broken and the subsequent request is seen as a new request > by the host resulting in a 10 msec delay (first isochronous request is > scheduled for 10 frames from when the URB is submitted). > > > [ For what's worth a small change is needed to the guest driver to have > more outstanding URBs (at least 4 URBs with 5 packets per URB).] > > Signed-off-by: David Ahern > Applied. Thanks. Regards, Anthony Liguori