On Mon, 2003-12-08 at 16:29, Jack O'Quin wrote: > Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx> writes: > > > Latency shouldn't be an issue - the 1394 bus is low latency - higher > > latency than PCI I expect, but still not measurable in audio terms. > > Does it have the same problem as USB, using fixed-time rather than > fixed-size packets? > > I seem to recall that it does, but that the packet size is smaller, > making the latency problem easier to deal with. Jack, I don't know if this is of interest, but this is the technology I do for a living, so I humor myself if not you. ;-) 1394 has two modes of operation - asynchronous and isochronous. Async - A 1394 device will arbitrate for the bus and when it is granted then transfers a packet (request or response) of an arbitrary size to a specific device. It then receives back an acknowledge from the target device. The 1394 bus is split transaction bus, meaning to do a transaction firs t a request is sent, and acknowledge is received and the device then gets off and waits for a response to come back some time later. 1394 async operation is 'guaranteed delivery', meaning that without a bus failure, if a device transfers a packet it is guaranteed to be delivered to the intended target. If it isn't the initiator does not receive an acknowledge. If a bit in the packet is corrupted then the transmitting device may retransmit the packet at it's next opportunity. In Async mode latency is somewhat unbounded, other than it can never be longer that 100mS IIRC. Isoch - 1394 has a timer operating on the bus. This timer happens (roughly) every 125uS. Immediately after this timer event occurs any device that wishes to transfer Iso data may do so. To be legal the device must have allocated bandwidth on the bus, but nothing stops a device from transferring Iso data on any given cycle. (There's no lockout.) Iso data is transferred and may be received by any device listening on the channel. The length of the packet is arbitrary, up to the amount of bandwidth allocated for that channel. 1394 defines 64 channels. One is broadcast, 63 are left for any device to allocate and use as it wishes. Iso data is not guaranteed delivery, but is (supposedly) guaranteed bandwidth. If a bit in the packet is corrupted then the packet is lost. In Iso mode latency is bounded in the sense that a round trip could never be shorter than 125uS, and shouldn't be long if all devices that want to transmit have allocated bandwidth, but will basically be multiples of 125uS. 61883 operation is a protocol that runs on top of 1394 Iso cycles. It embeds a clock and other timing information, sort of like MPEG-2 to allow devices to sync their clocks to each other. This can get around the problem we have with multiple sound cards not using the same clock and getting clicks and pops if the target devices have the right hardware. OHCI controllers in PCs typical do NOT have this hardware so they typically cannot be sync'ed in this manner. I don't know if that's the sort of info you wanted. Maybe it will be of interest in any case. Cheers, Mark
