Re: 1394 isoch recv buffer size integral number of by tes per packet?

NTDEV
1

Thanks for your reply. I’ll try it. I assumed
RESOURCE_VARIABLE_ISOCH_PAYLOAD is for isochronous talks only so far.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, September 23, 2003 6:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: 1394 isoch recv buffer size integral number of
bytes per packet?

Can RESOURCE_VARIABLE_ISOCH_PAYLOAD help?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Moebius, V.”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, September 23, 2003 7:06 PM
> Subject: [ntdev] 1394 isoch recv buffer size integral number
> of bytes per
> packet?
>
>
> > Hello,
> >
> > after posting the same issue in
> > news:\microsoft.public.development.device.drivers some
> time ago and getting
> > no satisfying answer I’ll try my luck here:
> >
> > Excuse me if resubmitting a known issue. But after scanning
> several news
> > groups I
> > found some hints confirming that buffers provided for
> isochronous listening
> > in stream mode must be
> > sized of integral number of 1394 packet size. And
> unfortunately my own tests
> > endorse this
> > assumption.
> >
> > I found no statements referring to this in DDK
> documentation nor in 1394
> > OHCI spec.
> >
> > Can anybody acknowledge (or rebut) this issue please?
> >
> > Is there an easy way to receive a 1394 multi packet frame
> not integral
> > number of packet size sized?
> > An approach providing two buffers meeting the above
> requirement together one
> > receiving the user data
> > the other gathering the junk trailer does work but I’m
> looking for a more
> > elegant solution. Does anybody know if chained MDLs are
> supported by the
> > 1394 class driver and ohci adapter driver?
> >
> > Thanks
> > Volker
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@baslerweb.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

2

> Are you NOT specifying RESOURCE_USE_PACKET_BASED when allocating isoch

resource?

No. I receive a multi packet spanning frame ‘cumulative’ directly into an
user (mode) provided buffer stripping all headers. Thats why, streaming mode
seems to be appropriate for my purposes. The user data is generally not
integral packet size sized and the user mode interface is unfortunately
already designed to be not aware of any size or alignment restrictions.

If I try to attach the arbitrary sized buffer directly than I will not be
called back. But if I trim the buffer to be integral packet size sized it
works as expected. Naturally the residual data are missing during this
approach.

Thanks for the answer.

Regards
Volker

-----Original Message-----
From: Mathieu Routhier [mailto:xxxxx@cvdsinc.com]
Sent: Tuesday, September 23, 2003 7:53 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: 1394 isoch recv buffer size integral number of
bytes per packet?

RESOURCE_VARIABLE_ISOCH_PAYLOAD is indeed only meant for
talking. BTW,
variable-size packets are only supported starting from XP. Be aware
that this is not indicated in the DDK and there’s no way to query for
this capability.

Are you NOT specifying RESOURCE_USE_PACKET_BASED when allocating isoch
resource? Since you referred to stream-based transfer, I presume you
already know that :slight_smile:

Mat

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Moebius, V.
Sent: Tuesday, September 23, 2003 1:25 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: 1394 isoch recv buffer size integral number of by
tes per packet?

Thanks for your reply. I’ll try it. I assumed
RESOURCE_VARIABLE_ISOCH_PAYLOAD is for isochronous talks only so far.

> -----Original Message-----
> From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> Sent: Tuesday, September 23, 2003 6:16 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: 1394 isoch recv buffer size integral number of
> bytes per packet?
>
>
> Can RESOURCE_VARIABLE_ISOCH_PAYLOAD help?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Moebius, V.”
> > To: “Windows System Software Devs Interest List”
>
> > Sent: Tuesday, September 23, 2003 7:06 PM
> > Subject: [ntdev] 1394 isoch recv buffer size integral number
> > of bytes per
> > packet?
> >
> >
> > > Hello,
> > >
> > > after posting the same issue in
> > > news:\microsoft.public.development.device.drivers some
> > time ago and getting
> > > no satisfying answer I’ll try my luck here:
> > >
> > > Excuse me if resubmitting a known issue. But after scanning
> > several news
> > > groups I
> > > found some hints confirming that buffers provided for
> > isochronous listening
> > > in stream mode must be
> > > sized of integral number of 1394 packet size. And
> > unfortunately my own tests
> > > endorse this
> > > assumption.
> > >
> > > I found no statements referring to this in DDK
> > documentation nor in 1394
> > > OHCI spec.
> > >
> > > Can anybody acknowledge (or rebut) this issue please?
> > >
> > > Is there an easy way to receive a 1394 multi packet frame
> > not integral
> > > number of packet size sized?
> > > An approach providing two buffers meeting the above
> > requirement together one
> > > receiving the user data
> > > the other gathering the junk trailer does work but I’m
> > looking for a more
> > > elegant solution. Does anybody know if chained MDLs are
> > supported by the
> > > 1394 class driver and ohci adapter driver?
> > >
> > > Thanks
> > > Volker
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@baslerweb.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cvdsinc.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@baslerweb.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>