Hi All,
I have implemented an AVStream mini-driver to stream DV data over USB 2.0
high speed bus. I submit nearly 250 packets (each of size 480 bytes) per
buffer to the bus driver with about 4 buffers in operation at any time.
While streaming sometimes i see that the USB packet status is
USBD_STATUS_BABBLE_DETECTED (0xC0000012L). Can anyone tell me what this
means and how to circumvent this problem?
Regards,
Hari.
Celebrate Easter. Eggs, bunnies et al.
http://server1.msn.co.in/sp03/easter/index.asp Send e-cards.
Babble is a condition on the USB where the device has continued to transmit
data past the end of frame.
Marc Reinig
System Solutions
“Hariharan Krishnamurthy” wrote in message
news:xxxxx@ntdev…
>
> Hi All,
>
> I have implemented an AVStream mini-driver to stream DV data over USB 2.0
> high speed bus. I submit nearly 250 packets (each of size 480 bytes) per
> buffer to the bus driver with about 4 buffers in operation at any time.
> While streaming sometimes i see that the USB packet status is
> USBD_STATUS_BABBLE_DETECTED (0xC0000012L). Can anyone tell me what this
> means and how to circumvent this problem?
>
> Regards,
> Hari.
>
> _________________________________________________________________
> Celebrate Easter. Eggs, bunnies et al.
> http://server1.msn.co.in/sp03/easter/index.asp Send e-cards.
>
>
>
>
Thanks Mark for the reply. But how does the host controller identify “end
of frame” condition? “End of frame” condition could entirely be format
specific! Could this mean any buffer constraints?
Also i observed the following situation:
- I submit 3 buffers 0,1,2 to the bus driver
- buffer 0 gets complete and my completion routine gets called and after
processing the data from the completion routine i submit buffer 0 again!
- Now buffer 1 gets complete (This is where the problem is)
The isochronous packets i receive in my buffers are not the same as what is
shown on the bus. I checked through the bus analyzer - between buffer 0
complete and buffer 1 start there are atleast 5 IN tokens and corresponding
data transfers on the bus but the data i receive through my completion
routine (for buffer 1) is not in sync with the data on the bus.
If the host controller is sending IN tokens it means that it has enough
buffers avaiable with it. Am i correct? Then i fail to understand how come
nearly 5 isochronous packets are missed!!!
Any thoughts/ideas on this will be highly appreciated!
Thanks,
Hari.
Babble is a condition on the USB where the device has continued to transmit
data past the end of frame.
Marc Reinig
System Solutions
“Hariharan Krishnamurthy” wrote in message
>news:xxxxx@ntdev…
> >
> > Hi All,
> >
> > I have implemented an AVStream mini-driver to stream DV data over USB
>2.0
> > high speed bus. I submit nearly 250 packets (each of size 480 bytes)
>per
> > buffer to the bus driver with about 4 buffers in operation at any time.
> > While streaming sometimes i see that the USB packet status is
> > USBD_STATUS_BABBLE_DETECTED (0xC0000012L). Can anyone tell me what this
> > means and how to circumvent this problem?
> >
> > Regards,
> > Hari.
> >
> >
> > Celebrate Easter. Eggs, bunnies et al.
> > http://server1.msn.co.in/sp03/easter/index.asp Send e-cards.
> >
> >
> >
> >
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Get cool ringtones. Make a statement. http://www.msn.co.in/Mobile/tunes/ Get
noticed.
“Hariharan Krishnamurthy” wrote in message
news:xxxxx@ntdev…
>
> Thanks Mark for the reply. But how does the host controller identify “end
> of frame” condition? “End of frame” condition could entirely be format
> specific! Could this mean any buffer constraints?
No. End of Frame in this case is entirely USB specific. USB time is in
frames. There is one frame per millisecond, no more, no less.
> Also i observed the following situation:
> 1) I submit 3 buffers 0,1,2 to the bus driver
The buffers are all 480 bytes long?
How fast do you submit your URBs?
> 2) buffer 0 gets complete and my completion routine gets called and after
> processing the data from the completion routine i submit buffer 0 again!
How much processing are you doing?
Are you resubmitting your IRP from the completion routine or another thread?
What size is the MaxPacketSize in your isochronous endpoint?
Are you sure that you don’t send more than that in response to a single IN?
That could cause Babble.
> 3) Now buffer 1 gets complete (This is where the problem is)
> The isochronous packets i receive in my buffers are not the same as what
is
> shown on the bus. I checked through the bus analyzer - between buffer 0
> complete and buffer 1 start there are atleast 5 IN tokens and
corresponding
> data transfers on the bus but the data i receive through my completion
> routine (for buffer 1) is not in sync with the data on the bus.
>
> If the host controller is sending IN tokens it means that it has enough
> buffers avaiable with it. Am i correct? Then i fail to understand how
come
> nearly 5 isochronous packets are missed!!!
No, you are thinking of Interrupt endpoints. For Interrupt endpoints, if
there is no URB pending, then no Interrupt IN is requested. For
Isochronous, I’m pretty sure it just merrily sends IN’s every frame,
queue’d URB or not. As long as you have enough URBs queued, and can keep up
with the data rate, you will get all your data. If not, you will lose
packets.
Marc Reinig
System Solutions
> > Also i observed the following situation:
> 1) I submit 3 buffers 0,1,2 to the bus driver
The buffers are all 480 bytes long?
The buffer size is one DV frame size : nearly 120000 bytes long!
How fast do you submit your URBs?
After the completion of each buffer, i resubmit another URB!
How much processing are you doing?
Are you resubmitting your IRP from the completion routine or another
thread?
Not much iam logging the packet headers and then resubmitting in the
completion routine obviously at DISPATCH_LEVEL.
Are you sure that you don’t send more than that in response to a single IN?
Are you asking this from device perspective? If yes, then no more than
maxpacket size is sent by my device!
No, you are thinking of Interrupt endpoints. For Interrupt endpoints, if
there is no URB pending, then no Interrupt IN is requested. For
Isochronous, I’m pretty sure it just merrily sends IN’s every frame,
queue’d URB or not. As long as you have enough URBs queued, and can keep
up
with the data rate, you will get all your data. If not, you will lose
packets.
I tested this without submitting any URBs to the bus driver. In this case,
no IN tokens are sent by WIN XP bus drivers.
Thanks,
Hari.
Get cool ringtones. Make a statement. http://www.msn.co.in/Mobile/tunes/ Get
noticed.
Marc Reinig wrote:
No, you are thinking of Interrupt endpoints. For Interrupt endpoints, if
there is no URB pending, then no Interrupt IN is requested. For
Isochronous, I’m pretty sure it just merrily sends IN’s every frame,
queue’d URB or not. As long as you have enough URBs queued, and can keep up
with the data rate, you will get all your data. If not, you will lose
packets.
One other thing to be aware of is that if you use high-speed isochronous
transfers, each URB must contain a multiple of 8 packets to get continuous
streaming, because URBs are scheduled at frame granularity (not microframe).
Burkhard.
Burkhard Daniel
Software Technologies Group, Inc.
xxxxx@stg.com * http://www.stg.com
fon: +49-179-5319489 fax: +49-179-335319489
I sure am taking care of the “multiple of 8 packets” alignment. Thanks a
lot for the advice. Sometimes i get USBD_STATUS_BABBLE_DETECTED or even
USBD_STATUS_ISO_NOT_ACCESSED_BY_HW in the status field of
USBD_ISO_PACKET_DESCRIPTOR structure. Increasing the number of buffers
submitted seems to solve this issue!
Also i am facing another problem: the rate at which i submit buffers to the
bus driver seems to be faster than the rate at which directshow (AVStream
class drivr) gives buffers to my driver. Any thoughts on how i can speed up
this operation?
Hari.
Marc Reinig wrote:
>
>No, you are thinking of Interrupt endpoints. For Interrupt endpoints, if
>there is no URB pending, then no Interrupt IN is requested. For
>Isochronous, I’m pretty sure it just merrily sends IN’s every frame,
>queue’d URB or not. As long as you have enough URBs queued, and can keep
>up
>with the data rate, you will get all your data. If not, you will lose
>packets.
One other thing to be aware of is that if you use high-speed isochronous
transfers, each URB must contain a multiple of 8 packets to get continuous
streaming, because URBs are scheduled at frame granularity (not
microframe).
Burkhard.
Burkhard Daniel
Software Technologies Group, Inc.
xxxxx@stg.com * http://www.stg.com
fon: +49-179-5319489 fax: +49-179-335319489
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Travel deals. Pick 'em up. http://www.msn.co.in/Travel/ Only on MSN.
Hari K wrote:
I sure am taking care of the “multiple of 8 packets” alignment. Thanks
a lot for the advice. Sometimes i get USBD_STATUS_BABBLE_DETECTED or
even USBD_STATUS_ISO_NOT_ACCESSED_BY_HW in the status field of
USBD_ISO_PACKET_DESCRIPTOR structure. Increasing the number of buffers
submitted seems to solve this issue!
That seems logical, as those latter two statuses indicate that the
processing of the buffers that takes place in the USB stack took too long
for the buffers to reach the host controller hardware in time to be filled
with data. In other words, the host controller ran out of buffers.
Also i am facing another problem: the rate at which i submit buffers to
the bus driver seems to be faster than the rate at which directshow
(AVStream class drivr) gives buffers to my driver. Any thoughts on how
i can speed up this operation?
I’m not sure (I have no experience with the AVStream driver), but you might
want to try to increase the size of the buffers you get from the AVStream
class driver and then split those buffers up into multiple smaller ones
which you then submit to the USBD in turns. So, one AVStream buffer would
then be represented by several URBs which you recycle independently.
This effectively increases the queue depth between your driver and the USBD.
Hope this helps,
Burk.
Burkhard Daniel
Software Technologies Group, Inc.
xxxxx@stg.com * http://www.stg.com
fon: +49-179-5319489 fax: +49-179-335319489