Not sure why you are setting RESOURCE_VARIABLE_ISOCH_PAYLOAD in the resource
flags? According to the DDK docs I am reading, that flag should be set in
the IsochDescriptor’s flags as so:
isoch_descriptor_1->fulFlags = DESCRIPTOR_HEADER_SCATTER_GATHER |
RESOURCE_VARIABLE_ISOCH_PAYLOAD;
I love this, the ddk docs say this:
“Thus with variable-size data packets, the nMaxSizeBytesPerFrame member of
the data descriptor no longer indicates the size of an individual data
packet. Each data packet can have a different size that is indicated in its
corresponding header element.”
But no where do they specify what nMaxSizeBytesPerFrame should be for the
data descriptor in this case, and of course there are no samples.
How about this:
"IsochDescriptor->nMaxBytesPerFrame =
MAX_HEADER_DATA_SIZE+FIELD_OFFSET(HeaderElement,HeaderData)
where MAX_HEADER_DATA_SIZE indicates the size of the header to be prepended
to each data packet, FIELD_OFFSET(HeaderElement,HeaderData) indicates the
length of the header element inserted immediately before each header, and
NUMBER_OF_PACKETS is the number of packets to be transmitted (including
header-only packets)."
Where is NUMBER_OF_PACKETS in the code line above? Is it supposed to be
this?:
IsochDescriptor->nMaxBytesPerFrame =
(MAX_HEADER_DATA_SIZE+FIELD_OFFSET(HeaderElement,HeaderData)) *
NUMBER_OF_PACKETS;
I suspect it is. What does one set for the nLength for the data descriptor?
Anyway, I don’t believe you are setting nMaxBytesPerFrame correctly for the
header descriptor, but then again I am not sure I believe these docs either.
All in all, there isn’t much to go on here. Make sure you query the host
controller for the HOST_INFO_SUPPORTS_ISO_HDR_INSERTION flag to make sure it
can do this.
I don’t see you setting up your third descriptor here, what does it look
like? Also, make sure your number of descriptors in AllocateResources and
AttachBuffers matches.
Are you able to allocate your bandwidth okay? Its weird you get
insufficient resources, I suspect its a size/length issue, but who knows how
it is supposed to look? Trial and error time.
My suspicion would be that you are the first user ever to try variable isoch
payloads. I can’t prove this mind you, but there aren’t many 1394 users in
general and there are even less that have done the tricky stuff. I wish you
well. If you find out anything interesting about this, please post back, I,
for one, am interested. Sorry I can’t be more help.
–
Bill McKenzie
“Varadan Venkatesh” wrote in message
news:xxxxx@ntdev…
> Hello Everybody,
>
> This is a question related to 1394 isochronous transfer in Windows.
>
> I am just wondering how to use the 1394_SCATTER_GATHER_HEADER
> to send variable size payload during isoch transmission.
> we have our own structure defined as
>
> typedef struct mystruct
> {
> USHORT HeaderLength;
> USHORT DataLength;
> UCHAR Header[8];
> }
>
> We are adopting the following procedure ----
> Step 1# ALLOCATE ISOCH RESOURCES :
> fulSpeed = SPEED_FLAGS_400
> fulFlags = RESOURCE_USED_IN_TALKING |
> RESOURCE_VARIABLE_ISOCH_PAYLOAD
> nBytesPerFrame = 16; (8 bytes header + 8 bytes data)
> numberofbuffers = 3 (1header + 1data + 1extra)
> nMaxBufferSize = sizeof (mystruct);
> RESULT = STATUS_SUCCESS (a valid resource handle is obtained)
>
> 2# INIT HEADER DESCRIPTOR
> initialize mystruct (headerLen = 8, dataLen = 8)
> Allocate MDL (size = sizeof(mystruct)) assign it to pHdrMdl
> desc->Mdl = pHdrMdl
> desc->ulLength = sizeof (mystruct)
> desc->nMaxBytesPerFrame = sizeof (mystruct)
> desc->ulTag = 1
>
> 3# INIT DATA DESCRIPTOR
> Allocate MDL (size = 8) assign it to pDataMdl
> desc->Mdl = pDataMdl
> desc->ulLength = 8
> desc->nMaxBytesPerFrame = 8;
>
> 4# ATTACH DESCRIPTORS
> When we do REQUEST_ISOCH_ATTACH_BUFFERS, we get the return value as
STATUS_INSUFFICIENT_RESOURCES.
>
> Why does this result code get returned? What are we doing wrong?
>
> We have another observation:
> In the above case, if nMaxBytesPerFrame is not set in DATA DESCRIPTOR
> we get the return value as STATUS_INVALID_PARAMETER ???
>
> Where are we going wrong??
>
> Any pointers in this regard will be greatly appreciated.
>
> Regards
> Venky