Hi Shuzhen,
On Tuesday 21 December 2010 08:04:04 Shuzhen Wang wrote:
> I narrowed the issue a little bit more. It looks like a bandwidth/
> throughput issue. The sequence is like this:
>
> Timestamp(seconds)
> 101.995432 Queue 0
> 101.995705 Queue 1
> 101.995978 Queue 2
> 101.996250 Queue 3
> 103.129925 Frame 0 complete
> 103.165819 Frame 1 complete
> 103.201672 Frame 2 complete
> 103.237764 Frame 3 complete
> 103.239244 Dequeue 0
> 103.241105 Queue 0
> 103.241153 Dequeue 1
> 103.243283 Queue 1
> 103.243333 Dequeue 2
> 103.245113 Queue 2
> 103.245161 Dequeue 3
> 103.247259 Queue 3
> 103.296360 Frame 0 complete
> ....
>
> In this case, the frame interval is: 33ms-33ms-33ms-67ms.
> So in this case, effectively 1 frame is dropped at the driver level.
>
> One thing worth noting is that the user space application has a loop
> like this (in pseudo code):
>
> Stream on
> ......
> while(true) {
> Dequeue buffer;
> Queue buffer;
> }
>
>
> Is the frame drop due to the isochronous nature of the UVC protocol?
> In other words, because of the multiple Dequeue & Queue operations
> happening at the 103.239244 timestamp, the next frame doesn't have
> enough time/processing bandwidth to finish. Hence 1 frame is dropped.
>
> Does this make sense?
I'd rather say that the driver starts receiving the next frame between
103.237764 and 103.239244. As there's no buffer left at that point the frame
is dropped.
What puzzles me is why your application doesn't start dequeuing (and
requeuing) buffers at 103.129925, when the first frame is complete. It lets
the buffers queue get empty, resulting in frame drop.
--
Regards,
Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
