[haiku-development] Usage change proposal for queue_isochronous( ..., startingFrameNumber, .... )

  • From: Siarzhuk Zharski <zharik@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 03 Jul 2013 12:35:48 +0200

Dear Colleagues,
As I have promised in this list some months ago I'm trying now to bring my long-playing development of USB audio to state with some perceptible results. It is usual for Haiku system coding that you have to fix many issues in other parts of system before you can bring "your" one to life. :-) So I have obviously get stuck into USB isochronous support testing and fixing. One task was finishing implementation of OHCI bus module. Below are some thoughts about current state of isochronous support I had during this work.
I have read many times that the startingFrameNumber parameter of the queue_isochronous call has no useful meaning for the driver because of it's controller specific nature. Yes, it is specific but not so useless in my opinion.
Let me continue with some example. Imagine that we have UHCI controller and need to feed some iso endpoint continuously with 4000-bytes blocks using 20 packets pro block. This is audio endpoint so to keep the user in the good spirits we must to have from 1 to 2 blocks scheduled for transfer at a time.
We submit the first block and it was allocated by UHCI bus module starting from the frame 100 up to frame 119. Note that the number 100 will be returned in the startingFrameNumber. The attempt to feed the second (for pending!) data block will result in allocating, for example, frames from 108 up to 127. Current implementation of UHCI bus module look only for "enough time to be ahead of controller" and the "next frame with available bandwidth". It takes no care that some bandwidth was already allocated for this endpoint for those frames. So most of the packets in the second transfer will be rejected by controller.
And now it is time to think about the starting frame number. Unfortunately it is of little use as designed currently. On the driver side you can, of course, calculate the next frame number using your knowledge about amount of already scheduled data and the size of frame/micro-frame (1ms/125µs) and submit the second transfer at the next free starting frame you have just calculated. But all becomes much easier if we agree to return the frame number that is just after the end of ones scheduled for the transfer. In our sample it should be 120. Using this info submitting the second data block will succeed on frames 120 - 139. The driver will be saved from complex calculations, leaving the controller specific stuff in the controller bus module. The startingFrameNumber plays in this case as really opaque, cookie-like variable. 

In pseudo-code:

uint32 frame = 0;
queue_isochronous(..., &frame, USB_IO_ASAP, ....);

while (...) {
  queue_isochronous(..., &frame, 0, ....);
}
The first call allocates at next available frame with enough bandwidth and the following ones will schedule data without overlaps and gaps.
So, what do you think about proposed USB bus modules design modification? 

--
Kind Regards,
   S.Zharski

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 07-2013