[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] audio streaming from usb devices

From: David S. Ahern
Subject: Re: [Qemu-devel] [PATCH] audio streaming from usb devices
Date: Tue, 09 Feb 2010 07:11:49 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100120 Fedora/3.0.1-1.fc11 Thunderbird/3.0.1

I have not seen a response to this. If there are no objections please apply.


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 <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]