[linux-audio-user] Re: Firewire, what's the story?

Mark Knecht markknecht at comcast.net
Mon Dec 8 22:31:25 EST 2003

On Mon, 2003-12-08 at 16:29, Jack O'Quin wrote:
> Steve Harris <S.W.Harris at ecs.soton.ac.uk> 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.

   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.


More information about the Linux-audio-user mailing list