Re[2]: 1394 talk/listen DMA buffer alignment requirements?

NTDEV
1

Philip,

Hi Robert, thanks for your reply. Out of curiosity, did any of your buffers
ever cross page boundaries? If so, were there issues with that?

My buffers are usually 188928 bytes long so yes they cross page
boundaries and no this has never caused a problem. I did, in the past,
have problems when they didn’t start on page boundaries. As I
mentioned I have no recent testing of this.

I have absolutely no problem with listen, but with talk. Of course, it only
occurs on one customer’s machine (laptop, WinXP Prof. SP2), and only at one
sample rate (96k). The symptom exposed by WPP traces is that talk callbacks
stop being called (DMA simply stop?), and eventually the maximum number of
talk packets are attached, with no talk callbacks being called. There are
no errors in attach/detach completion routines at all. Of course, I have
never seen this on any of my test machines, UP, SMP, or HT; it would be too
easy.

Do you have any idea why DMA on talk would just stop? For sure it is not
being starved; WPP traces confirm this, buffers are being attached. The
only reason I could think of was a buffer_alignment/page_boundary_crossing
issue, but this itself seems fairly unlikely, because I reuse all of my
talk/listen descriptors/MDLs/buffers, and initially talk callbacks are being
called. Any ideas?

I’ve done talk but very little and only for test purposes. When
attaching buffers for listening I always follow the operation with a
REQUEST_ISOCH_LISTEN to ensure no starvation problems.

When doing a listen I did discover that if the buffer size does not
divide into an integral number of packets it would be filled okay but
I would receive no callback when the buffer was full but this doesn’t
seem to relate to your problem.

I have had lots of issues with XP sp2 especially with regard to bus
resets. A spurious bus reset may possibly stop things if it is not
handled correctly. Are you tracking and dealing with resets?

Robert Newton

2

> Do you have any idea why DMA on talk would just stop? For sure it is not

being starved; WPP traces confirm this, buffers are being attached. The

I admit to knowing nothing about the general Firewire area, but one question
here. Are you absolutely sure that there was no period in time when there
would have been zero buffers available for a few nanoseconds and NT (or the
hardware) stopped the DMA transfer just before you attached some new
buffers? 96K is flowing data pretty quickly, especially if this is a
multi-channel audio device.

I suspect if the hardware will stop DMA if there are no chained buffers that
it could even have happened after you had submitted buffers for attachment,
but before they got attached.

Loren

3

First, my apologies if this is seen twice, but I sent this reply over the
weekend, and apparently we had some major mail server problems. Since this
message has not appeared on the list, I have elected to send it again.
Sorry if members see this twice, my apologies.

Original reply follows:

Hello Loren, thanks for your reply.

Yes, I’m pretty sure that some talk buffers are always attached, due to
highly verbose WPP traces. Since I cannot duplicate this in house, I cannot
be 100% sure, but the verbose traces which I have make me pretty confident
that talk buffers are always attached in some quantity. WPP traces confirm
that the number of attached talk buffers remains constant, because talk
callbacks are being called (this proves that DMA has started). Then
eventually talk callbacks stop being called, and the number attached talk
buffers starts to rise until the maximum amount are attached. Thereafter
starvation sets in, because the talk callbacks are never called anymore, and
I always reuse the talk MDLs/buffers.

This is why I am so mystified; talk DMA has clearly started (as proven by
the initial talk callbacks), and NO talk/listen completion routine has
reported any errors. The user’s config is not too low (~1.5 GHz AMD), and I
have gotten 96k streaming to work on much, much lower machines (~600 MHz)
over 8 channels under ASIO, and simple stereo with WMP. This user cannot
even get stereo 96 kHz going with WMP, to say nothing of multichannel ASIO.

What is strange is that when I forced page aligned talk buffers which do not
straddle page boundaries, the user reported improved results, but still with
intermittent problems (stalling). Perhaps this is mere coincidence, or
incidentally related. FWIW, the DDK does not seem to require specific
buffer alignment; it’s true that talk “scatter-gather” mode (NOT
scatter-gather DMA) require some buffer alignment, but discussions of
“standard” talk in the DDK do not mention alignment. In any case I have
abandoned using “talk scatter gather mode” for various reasons. IIRC the
horrible 1394 DDK examples do NOT force any talk buffer alignment. I
emailed xxxxx@microsoft.com but I have not replied any reply to my question
on alignment from this quarter.

thanks for your reply,

Philip Lukidis

-----Original Message-----
From: Loren Wilton
To: Windows System Software Devs Interest List
Sent: 02/12/2005 9:43 PM
Subject: Re: [ntdev] 1394 talk/listen DMA buffer alignment requirements?

Do you have any idea why DMA on talk would just stop? For sure it is
not
being starved; WPP traces confirm this, buffers are being attached.
The

I admit to knowing nothing about the general Firewire area, but one
question
here. Are you absolutely sure that there was no period in time when
there
would have been zero buffers available for a few nanoseconds and NT (or
the
hardware) stopped the DMA transfer just before you attached some new
buffers? 96K is flowing data pretty quickly, especially if this is a
multi-channel audio device.

I suspect if the hardware will stop DMA if there are no chained buffers
that
it could even have happened after you had submitted buffers for
attachment,
but before they got attached.

Loren

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Philip Lukidis

-----Original Message-----
From: Loren Wilton [mailto:xxxxx@earthlink.net]
Sent: Saturday, February 12, 2005 9:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 talk/listen DMA buffer alignment requirements?

Do you have any idea why DMA on talk would just stop? For sure it is not
being starved; WPP traces confirm this, buffers are being attached. The

I admit to knowing nothing about the general Firewire area, but one question
here. Are you absolutely sure that there was no period in time when there
would have been zero buffers available for a few nanoseconds and NT (or the
hardware) stopped the DMA transfer just before you attached some new
buffers? 96K is flowing data pretty quickly, especially if this is a
multi-channel audio device.

I suspect if the hardware will stop DMA if there are no chained buffers that
it could even have happened after you had submitted buffers for attachment,
but before they got attached.

Loren

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com