From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NfIEi-0001gh-5A for qemu-devel@nongnu.org; Wed, 10 Feb 2010 14:28:32 -0500 Received: from [199.232.76.173] (port=34073 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NfIEh-0001gR-KW for qemu-devel@nongnu.org; Wed, 10 Feb 2010 14:28:31 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NfIEg-0005I6-74 for qemu-devel@nongnu.org; Wed, 10 Feb 2010 14:28:31 -0500 Received: from mail-iw0-f194.google.com ([209.85.223.194]:55466) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NfIEe-0005Hu-QP for qemu-devel@nongnu.org; Wed, 10 Feb 2010 14:28:29 -0500 Received: by iwn32 with SMTP id 32so636896iwn.14 for ; Wed, 10 Feb 2010 11:28:28 -0800 (PST) Message-ID: <4B7308CD.30507@codemonkey.ws> Date: Wed, 10 Feb 2010 13:28:13 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] audio streaming from usb devices References: <4B699B13.60802@cisco.com> In-Reply-To: <4B699B13.60802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "David S. Ahern" Cc: qemu-devel@nongnu.org, kvm-devel 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