1394 isoch: stream-based mode and variable sized packets

NTDEV
1

Hi All,

I was planning a 1394 driver implementation where a single driver would receive multiple isoch streams. I was planning on handling the isoch transfers in stream-based mode, i.e. all the receive buffers are used as one big contiguous buffer and data received in one packet is written to the buffer where the data from the previous packet left off. The intention was to have the DMA system “merge” the streams packet by packet into the receive buffer.

Although this design seems possible from the DDK documentation, there are strong indications on the internet that handling isoch transfers in stream-based mode does not work with variable sized isoch packets, as packets may straddle pages. Thesycon, that has based their VHPD driver on the Microsoft 1394 bus driver states:

“Using stream-based mode with variable-sized packets can cause problems because packets will straddle buffer boundaries. This is not correctly supported by the 1394 OHCI device driver included with Windows. Consequently, stream-based mode should not be used if the packet size varies. Thesycon recommends to always use packet-based reception mode.”

Is this limitation due to a bug in the legacy 1394 bus driver, or is it a general limitation when using DMA? If it is a bug in the legacy 1394 bus driver, does it work correctly with the new 1394 bus driver?

Best regards
Thomas

2

Hi,

this is not a general DMA limitation. This reception mode is supported well by the OHCI controller. See also OHCI spec section 10.2.1 (stream-based mode is called buffer fill mode in the spec). The statement you cited is based on experience we made with the legacy 1394 bus driver in XP. I think the problem has been fixed in later releases (service packs).

We successfully implemented drivers that use multi-channel receive mode. On isoch resource allocation you need to set RESOURCE_USE_MULTICHANNEL but you must not set RESOURCE_USE_PACKET_BASED. This was tested with the legacy driver. I don’t know whether it works equally well with the new implementation shipped with W7.

Note that with stream based mode there is a problem with error recovery. When any packet is missing (e.g. due to CRC error) then your data will be shifted in the buffer. Therefore, we always prefer to have a parser which checks and interprets the isoch packet headers, lengths etc. and then copies payload to application buffers. The intermediate copy (if implemented efficiently) does not cause any noticeable CPU load, even at S800. When you use a parser then packet mode is to be preferred as it enables the parser to recover from errors more reliably.

Udo Eberhardt
Thesycon