Skip to content
Aleksandr Shabelnikov edited this page Aug 8, 2026 · 1 revision

Reporting an issue

Good reports are what make a driver like this fixable without the maintainer owning your hardware. Even a failed test report is valuable — "it does not enumerate at all" is still useful data.

What to include

  • ASFireWire version — the release tag you installed (e.g. v0.2.0-audio)
  • Mac model and macOS version
  • FireWire hardware — the full chain (e.g. Thunderbolt 3 → TB2 adapter → TB2-to-FireWire 800 adapter), or the PCIe OHCI card
  • The audio interface — exact model
  • How far it got — does the device enumerate, publish a CoreAudio device, start playback/capture?
  • When it failed — during enumeration, at playback start, at capture start, or after some minutes of streaming
  • Logs — see below

Which artifact to attach

The app produces two different dumps. They cover different layers, so attach whichever matches your problem — and both if you're unsure.

Artifact Covers Applies to
1394 Diagnostics Report The bus and host controller: topology, Self-ID, gap count, bus-manager/IRM/cycle-master policy, OHCI registers, recent async transactions Any device
DICE Device Report One device's DICE register spaces: clock, stream layout, router, mixer DICE/TCAT interfaces only

Rule of thumb: "my device isn't detected / the bus misbehaves / resets keep happening" → 1394 Diagnostics. "the device is there but audio is wrong" → DICE report (plus diagnostics if it's a detection or clock problem).

1394 Diagnostics Report (any device)

The universal artifact — attach this one if you attach nothing else. It captures the whole bus contract in one paste: decoded Self-ID and topology tree, gap-count policy, bus-manager and IRM election state, cycle-master decisions, the OHCI register snapshot, and a rolling trace of the last async transactions with acks and response codes.

That async trace is often the fastest route to a diagnosis — it shows exactly which reads went out, to which addresses, and what came back.

Note

PHY register reads are deliberately suppressed while an isochronous stream is running, so that section will read "Unavailable while isochronous streaming is active" during playback. That's expected, not a fault. To capture PHY state, take a report with audio stopped.

What a diagnostics report looks like (abridged)
ASFW 1394 DIAGNOSTICS REPORT
════════════════════════════════════════════════════════════
Driver Build:                  v0.2.0-audio (87501a8 DIRTY @ dev2)
ABI Version:                   11
Generation:                    3

=== Bus Contract ===
Local Node:                    node 0 / 0xFFC0
Root Node:                     node 1 / 0xFFC1
IRM Node:                      node 1 / 0xFFC1
Node Count:                    2
Gap Count:                     63

=== Topology & Self-ID ===
  NodeID   Local   Root    Contender  Speed Power       LinkActive
  0        Yes     No      No         S800  bus≤3W      Yes
  1        No      Yes     Yes        S400  bus+7Wlink  Yes

=== OHCI Link/Controller Snapshot ===
OHCI Version:                  0x00010010
Node ID Register:              0x8800FFC0
Cycle Timer Register:          0x3BC505F0

=== Recent Async Transactions Trace ===
  Δt(us)     Dir Ctx    TL  TCode    Src    Dst    Address        Ack   RCode
  0.0        TX  ATReq  20  RdQuad   0xFFC0 0xFFC1 0xFFFFE02004C4 0x00  complete
  1549.5     RX  ARRsp  20  RdQResp  0xFFC1 0xFFC0 -              0x11  complete

… policy engines, CSR contract, gap/root/power milestones follow …

The real report is several hundred lines. Attach all of it.

DICE device report (DICE/TCAT interfaces)

If your interface is DICE/TCAT, attach a device report. It is far more informative than logs alone — one paste tells the maintainer your exact model, ASIC, firmware version, clock state, stream layout at every rate mode, and the full router and mixer state.

In the control app, open the DICE Device Report tab:

  • Refresh — captures a fresh snapshot
  • Save to .txt… — writes it to a file you can attach to an issue
  • Copy — same content to the clipboard

Important

The report is read-only, but each refresh issues real FireWire reads. Don't run it while audio is playing — capture it before starting playback, or after stopping.

Paste it whole. Do not trim sections. Parts that look like noise (the router table, peak slots, the section offset table) are often exactly what identifies the problem.

If the report shows a device as unstable or unavailable rather than captured, say so — that state is itself useful information.

What a report looks like (abridged)
ASFW DICE DEVICE REPORT
=======================
Generated: 2026-08-08T05:30:06Z
Report app: 0.2.0 (build 2)
Driver:     0.2.0-audio (87501a8 on dev2, dirty) built 2026-08-05T09:15:34Z
Rate mode: low (32-48k)

IDENTITY
--------
GUID:          0x00130E0402004713
Vendor:        Focusrite
Model:         Saffire Pro 24 DSP
TCAT vendor:   0x00130E
TCAT category: 0x04  (standard DICE)
ASIC:          TCD2210 (DICE Mini)

GLOBAL
--------
CLOCK_SELECT       = 0x0000020C   source=12 (internal)  rate=2 (48000)
ENABLE             = 0x00000001   streaming=yes
STATUS             = 0x00000201   locked=yes  nominal=48000
CLOCK_CAPABILITIES = 0x112C001E
    rates   : 44100 48000 88200 96000

TX STREAMS  (device transmits -> host capture)
    PCM channels = 16    MIDI ports = 1    SPEED = S400
RX STREAMS  (device receives <- host playback)
    PCM channels = 8     MIDI ports = 1

… router, peak, mixer and per-rate-mode stream formats follow …

The real report is several hundred lines. Attach all of it.

Collecting logs

Please share the logs with the issue report:

  1. Open System Logs in ASFW.
  2. Reproduce the problem.
  3. Copy the entries around the failure and attach them to the report.

Include the ASFireWire version, device, and approximate reproduction time. There is no need to interpret the messages or remove repeated entries; the complete log is usually more useful than a summary.

If ASFW cannot show the logs, use Console.app to reproduce the problem and export the entries mentioning ASFW. Attach that file instead. See Logging only if a maintainer asks for additional system logs.

README § Collecting logs

Confirm the driver is actually loaded

systemextensionsctl list

net.mrmidi.ASFW.ASFWDriver should be [activated enabled]. If it is not, the problem is installation rather than the driver — check Installing first, especially that SIP is disabled and systemextensionsctl developer on was run afterwards.

Devices the project specifically wants tested

See README § Call for testing. Owners of a PreSonus StudioLive 16.4.2 / 24.4.2 / 32.4.2 are particularly wanted — those mixers are recognized but not audio-enabled, and a short register capture from the ASFW app is all that's needed to add support.

Please also add a row to Device Compatibility.

Open issues at https://github.com/mrmidi/ASFireWire/issues.

Clone this wiki locally