summaryrefslogtreecommitdiff
path: root/hw/usb-serial.c
diff options
context:
space:
mode:
authorDavid S. Ahern <daahern@cisco.com>2010-02-03 08:49:39 -0700
committerAnthony Liguori <aliguori@us.ibm.com>2010-02-10 12:45:11 -0600
commit8e65b7c04965c8355e4ce43211582b6b83054e3d (patch)
treed5bea256dfef27deb2743505dfd32f0fc846f2bb /hw/usb-serial.c
parent41b4bef65f1e2b2f313cae0f88a1c76a9cb3f222 (diff)
downloadqemu-8e65b7c04965c8355e4ce43211582b6b83054e3d.tar.gz
qemu-8e65b7c04965c8355e4ce43211582b6b83054e3d.tar.bz2
qemu-8e65b7c04965c8355e4ce43211582b6b83054e3d.zip
audio streaming from usb devices
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 <daahern@cisco.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'hw/usb-serial.c')
0 files changed, 0 insertions, 0 deletions