From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David S. Ahern" Subject: Re: [Qemu-devel] [PATCH] audio streaming from usb devices Date: Tue, 09 Feb 2010 07:11:49 -0700 Message-ID: <4B716D25.5090608@cisco.com> References: <4B699B13.60802@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm-devel To: qemu-devel@nongnu.org Return-path: Received: from sj-iport-2.cisco.com ([171.71.176.71]:39139 "EHLO sj-iport-2.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754554Ab0BIOLx (ORCPT ); Tue, 9 Feb 2010 09:11:53 -0500 In-Reply-To: <4B699B13.60802@cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: I have not seen a response to this. If there are no objections please apply. Thanks, David Ahern On 02/03/2010 08: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 > >