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

[David S. Ahern]

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