1394 talk/listen DMA buffer alignment requirements?

Hello. Since I could not find any definitive answer in the archive or the
docs, I'll ask here: for the cases of 1394 talk using equal sized packets
and listen (both using packet based DMA, i.e. RESOURCE_USE_PACKET_BASED),
are there any restrictions on alignment, size and/or straddling a page
boundary? I found some mention of this in the DDK, but only for the case of
DESCRIPTOR_HEADER_SCATTER_GATHER (which I stopped using). Are there any
descriptor buffer alignment/size/page_boundary_straddling restrictions for
the more general cases (i.e. no DESCRIPTOR_HEADER_SCATTER_GATHER and no
RESOURCE_VARIABLE_ISOCH_PAYLOAD for talk, plain listen, both packet based)?

thanks for your time,

Philip Lukidis

Raj
Wed Feb 16 14:21:03 CST 2005

I am not confident on 1394 Isoch in Win 2000. In Windows XP it works fine.
Use data length as multiples of 4.

"Philip Lukidis" wrote:

> Hello. Since I could not find any definitive answer in the archive or the
> docs, I'll ask here: for the cases of 1394 talk using equal sized packets
> and listen (both using packet based DMA, i.e. RESOURCE_USE_PACKET_BASED),
> are there any restrictions on alignment, size and/or straddling a page
> boundary? I found some mention of this in the DDK, but only for the case of
> DESCRIPTOR_HEADER_SCATTER_GATHER (which I stopped using). Are there any
> descriptor buffer alignment/size/page_boundary_straddling restrictions for
> the more general cases (i.e. no DESCRIPTOR_HEADER_SCATTER_GATHER and no
> RESOURCE_VARIABLE_ISOCH_PAYLOAD for talk, plain listen, both packet based)?
>
> thanks for your time,
>
> Philip Lukidis
>
>
>

Philip
Wed Feb 16 16:56:20 CST 2005

"Raj" <Raj@discussions.microsoft.com> wrote in message
news:5A3DE63F-4D06-4919-85A3-85D4491B8F05@microsoft.com...
> I am not confident on 1394 Isoch in Win 2000. In Windows XP it works fine.
> Use data length as multiples of 4.
>
>
[snip]
Hello Raj, thanks for replying.
Many people say so, but so far, at least with SP4 (which we require our
clients), I did not bump into serious issues. All my lengths are quadlet
aligned.

However, (my device is an audio device), at 96k sampling I run into
problems. On one customer's machine, WinXP SP2, talk DMA callbacks stop
being called. Listen callbacks never stop being called. I cannot at all
reproduce this here. Have you ever seen talk callbacks simply stop being
called?

My talk packet setup is fairly straightforward:

-I allocate my talk bandwidth: 1394_header_size + data size per packet.
-I allocate my talk channel.
-I allocate my talk resource:
-packet based DMA, talk based resource.
-400 Mbps.
-nNumberOfBuffers: x+1 number of buffers.
-nMaxBytesPerFrame: 1394_header_size + data size.
-nMaxBufferSize:
nMaxBytesPerFrame*m_currentNumberOfPacketsPerTalkDescriptor.
-no quadlets stripped.
-I setup my x talk descriptors:
-create the descriptors, and their buffers and MDLs. MDLs are
created via IoAllocateMdl, and MmBuildMdlForNonPagedPool.
-The descriptor is formatted as follows:
-nMaxBytesPerFrame data size **(not including 1394_header
size). This follows from the fact that
I do not allocate buffer for the 1394 header in my
descriptor buffer (OHCI does this I guess), and
the docs say: "On writes, the data in the buffer is
split into isochronous packets of this size".
So it follows that the descriptor's
nMaxBytesPerFrame should not include the 1394 header.
-fulFlags: DESCRIPTOR_PRIORITY_TIME_DELIVERY for now as a
test.
-ulTag: 1.
-ulLength: MmGetMdlByteCount(pMdl).

If you have any idea how talk DMA can suddenly cease (i.e. talk callbacks
stop being called, please let me know).

thanks,

Philip Lukidis

Raj
Thu Feb 17 10:53:05 CST 2005


I observed the problem you explained( Isoch complete callback not called)
in Windows 2000 SP4. SP4 is better than other service packs of 2000. I dont
know when it can happen and how to reproduce or how to solve. You can test it
by having some kind of loop with different packet sizes and different buffer
sizes.
You will observe test loop doesnot work 24 hours for Windows 2000.

I didnt observe the problem in XP SP1. Try XP and make sure it is not your
driver problem and then fight your way in 2000.

Thanks,
Raj

"Philip Lukidis" wrote:

> "Raj" <Raj@discussions.microsoft.com> wrote in message
> news:5A3DE63F-4D06-4919-85A3-85D4491B8F05@microsoft.com...
> > I am not confident on 1394 Isoch in Win 2000. In Windows XP it works fine.
> > Use data length as multiples of 4.
> >
> >
> [snip]
> Hello Raj, thanks for replying.
> Many people say so, but so far, at least with SP4 (which we require our
> clients), I did not bump into serious issues. All my lengths are quadlet
> aligned.
>
> However, (my device is an audio device), at 96k sampling I run into
> problems. On one customer's machine, WinXP SP2, talk DMA callbacks stop
> being called. Listen callbacks never stop being called. I cannot at all
> reproduce this here. Have you ever seen talk callbacks simply stop being
> called?
>
> My talk packet setup is fairly straightforward:
>
> -I allocate my talk bandwidth: 1394_header_size + data size per packet.
> -I allocate my talk channel.
> -I allocate my talk resource:
> -packet based DMA, talk based resource.
> -400 Mbps.
> -nNumberOfBuffers: x+1 number of buffers.
> -nMaxBytesPerFrame: 1394_header_size + data size.
> -nMaxBufferSize:
> nMaxBytesPerFrame*m_currentNumberOfPacketsPerTalkDescriptor.
> -no quadlets stripped.
> -I setup my x talk descriptors:
> -create the descriptors, and their buffers and MDLs. MDLs are
> created via IoAllocateMdl, and MmBuildMdlForNonPagedPool.
> -The descriptor is formatted as follows:
> -nMaxBytesPerFrame data size **(not including 1394_header
> size). This follows from the fact that
> I do not allocate buffer for the 1394 header in my
> descriptor buffer (OHCI does this I guess), and
> the docs say: "On writes, the data in the buffer is
> split into isochronous packets of this size".
> So it follows that the descriptor's
> nMaxBytesPerFrame should not include the 1394 header.
> -fulFlags: DESCRIPTOR_PRIORITY_TIME_DELIVERY for now as a
> test.
> -ulTag: 1.
> -ulLength: MmGetMdlByteCount(pMdl).
>
> If you have any idea how talk DMA can suddenly cease (i.e. talk callbacks
> stop being called, please let me know).
>
> thanks,
>
> Philip Lukidis
>
>
>

Philip
Thu Feb 17 11:09:42 CST 2005

"Raj" <Raj@discussions.microsoft.com> wrote in message
news:2BB140D0-76A8-4A7A-9D11-F3C71C60E8A3@microsoft.com...
>
> I observed the problem you explained( Isoch complete callback not called)
> in Windows 2000 SP4. SP4 is better than other service packs of 2000. I
dont
> know when it can happen and how to reproduce or how to solve. You can test
it
> by having some kind of loop with different packet sizes and different
buffer
> sizes.
> You will observe test loop doesnot work 24 hours for Windows 2000.
>
> I didnt observe the problem in XP SP1. Try XP and make sure it is not your
> driver problem and then fight your way in 2000.
>
> Thanks,
> Raj
>
[snip]
Thanks again for replying Raj.

I have a Win2k SP4 box which has been streaming here for days on end
(perhaps a week now?) at 96k. Of course, since streaming is done at a fixed
rate for audio, the isoch session uses the same packet sizes, and same
descriptor sizes without resets. Luckily, our product mandates SP4 for
Win2k users, or they get no support.

The user in question has WinXP SP2 installed, and I cannot reproduce it here
at all, on several machines. Too bad, or I could probe the OHCI card
registers to check for issues (FIFO overflow?). On another WinXP SP1
machine, he had no issues. It's a really strange problem, especially as
there is another dimension to it now. It appears that in Cubase he has no
issues, but with WMP there is the isoch DMA stop issue which I mentioned.
Strange indeed.

thanks,

Philip Lukidis