Repository navigation
FireWire Fundamentals
FireWire (IEEE 1394) connects devices such as audio interfaces, DV cameras, disks and scanners. ASFireWire rebuilds the parts of the macOS stack needed to communicate with these devices after native support was removed in Tahoe. Shared bus support and a recognized device identity do not automatically provide a working device-class driver.
Asynchronous transactions carry reads, writes and locks used for discovery and control. Acknowledgments, response matching and retry/error handling distinguish them from time-sensitive streaming. They are also necessary while audio/video streams run.
Isochronous packets provide time-scheduled data movement for audio/video. A missed packet is lost; the driver needs explicit recovery and buffering policies rather than assuming perfect delivery. Format, timestamps, cadence and channel mapping depend on what the device sends and expects.
OHCI has asynchronous transmit/receive request and response contexts, and isochronous transmit/receive contexts. A context is a controller execution mechanism, not a device or audio channel. Isochronous stream channel numbers are bus resources managed separately.
Bus resets rebuild topology and change generation. Cached node addresses and old transactions cannot silently be reused as if the topology were unchanged. The IRM manages bus-wide isochronous channel and bandwidth resources; an occupancy bitmap does not identify which node owns an allocation.
OHCI is the programming interface for compatible FireWire host controllers: registers, interrupt events, DMA descriptor programs and execution contexts. It moves packets; higher layers manage policy, device protocols and content.
OHCI descriptor headers use little-endian representation; IEEE 1394 wire payloads use big-endian representation. Do not infer one from the other. Packet analyzers can reveal wire errors that coarse controller status does not explain.
Historical OHCI 1.1 material is available from IBM's archive. Later draft behavior and working silicon must be checked against behavioral references; a historical PDF alone does not establish the complete descriptor/ring mechanism. Do not invent a specification section or assume a paywalled standard can be retrieved by an API-doc tool.
| Mechanism | Typical role |
|---|---|
| Config ROM | Bus identity, device/unit enumeration and capability clues |
| AV/C over FCP | Audio/video discovery and device control; CMP connects plugs |
| IEC 61883 / CIP / AM824 | Content framing used by compatible streams |
| DICE/TCAT | Audio clock, stream geometry, routing and device-specific registers |
| MOTU / RME vendor protocols | Family-specific control and audio packet formats |
| SBP-2 | Storage/SCSI transport, including supported film scanners |
CIP belongs to content framing, not OHCI transport. It covers more than audio. A device may expose incomplete, misleading or revision-dependent information; packet movement and successful discovery are necessary but insufficient evidence of working playback, recording, scanning or capture.
Apple's kernel-based stack provided useful behavioral references:
- AppleFWOHCI: controller mechanism; its production implementation was not open-sourced.
- IOFireWireFamily: bus framework, enumeration, policy and interfaces.
- IOFireWireAVC: AV/C support.
- IOFireWireSBP2 and IOFireWireSerialBusProtocolTransport: SBP-2 and storage integration.
- AppleFWAudio: audio integration; not an open-sourced implementation.
Apple used DCL and later NuDCL abstractions for isochronous programs. Historical Mac OS 9 material and IOFireWireLib headers can help explain those concepts. ASFireWire uses DriverKit services with different lifecycle, concurrency and ownership constraints; the old kext architecture is not a template to copy into the new driver.
Local references/ is gitignored; do not assume a source is present. The repository's
engineering guidance lists
upstreams: Linux drivers/firewire for OHCI mechanism, Linux sound/firewire for audio,
ALSA userspace controls and FFADO for device protocols, and Apple's open FireWire stacks
for bus policy/ordering and AV/C/SBP-2 behavior.
Read the whole relevant loop, including how it advances and terminates. Use references to establish observable behavior, then implement fresh code. GPL, LGPL and APSL sources are read-only references, not code to transplant into the Apache-2.0 driver.
Useful starting points:
- Apple IOFireWireFamily
- Apple IOFireWireAVC
- Apple IOFireWireSBP2
- Linux FireWire controller source
- Linux FireWire audio source
- ALSA FireWire control services
- DriverKit overview
- System Extensions and DriverKit, WWDC 2019
- Modernize PCI and SCSI drivers with DriverKit, WWDC 2020
For API signatures, check current SDK headers and documentation. For lifecycle and ownership, validate behavior in the isolated AudioDriverKit lab or working references. For specifications unresolved by those sources, ask for the actual specification. See Architecture Overview and Development for the current stack.