Proposal: MOTU (v2) and Tascam protocol families — design ready, offering to contribute

[Dreambrother7]

Hi — first, thank you for ASFireWire. Getting DICE devices playing on Tahoe through the
adapter chain is a genuinely important piece of work.

I'd like to contribute two new device families and want to sync with you on approach
before writing code:

1. MOTU protocol-v2 devices (828mk2 first — I own one; the family covers
   Traveler, UltraLite, 896HD). Standard CIP headers (fmt 0x02, FDF 0x22) with SPH-
   timestamped data blocks; 24-bit packed PCM; register control at 0xfffff0000000.
2. Tascam FW series (FW-1884 first; FW-1082/1804 share the protocol). CIP with
   vendor FMT values (0x1e/0x3e), non-blocking, 24-in-32 quadlet samples; register
   control at 0xffff00000000; control-surface state embedded in the capture stream.

I have full written designs for both, derived from the Linux snd-firewire-motu /
snd-firewire-tascam references (behavioral study only, no GPL code) and mapped onto
IDeviceProtocol / DeviceProtocolFactory / the duplex hooks. Happy to share both docs.

Questions before I start:

• Shared IR→IT cadence replay. Both families require the host TX stream to replay
  the data-blocks-per-packet sequence observed on the device's TX stream (MOTU
  additionally replays per-block SPH presentation times). I'd like to build this once as
  a shared component — do you have a preferred home for it (Audio/Wire/ shared, or
  elsewhere)?
• Isochronous receive maturity. Both families need IR from the first streaming
  milestone (the capture stream is the timing source). What's the current state of the
  IR path beyond the DV capture sink, and is there work in flight I should build on or
  wait for?
• Factory matching. MOTU units are discriminated by the unit directory version
  field (not model ID); Tascam by an ASCII model string in the config ROM.
  DeviceProtocolFactory::Create(vendorId, modelId, …) doesn't currently carry either —
  would you take a small extension of the factory signature / discovery plumbing?
• Non-blocking cadence. Tascam streams are non-blocking (fractional blocks/packet).
  Is there anything DICE-blocking-specific baked into the IT cadence path I should know
  about?

Hardware I can test against: FW-1884, a MOTU 828mk2, M1 Mac mini on Tahoe with the
Apple TB3→TB2→FW800 chain. I'm set up to develop against the host test suite
(all 1375 tests passing locally) and to follow the project's reference/licensing rules.

I've already forked the repo (Dreambrother7/ASFireWire) and have the host test suite
building and passing locally, so if you'd rather react to a draft PR than discuss in the
abstract, happy to open one.

[mrmidi]

TL;DR; Any meaningful contributions is welcome! But If you manage to bring up your HW with latest main branch your stream will die in few seconds :)

Hi. Currently I've broken everything. I'm trying to do proper boundaries split: e.g. ASFWDriver doesn't know nothing about audio and used only as a transport. Also I'm splitting audio backends, e.g. Dice, BeBoP, OXFW (that's hw what I have at least) and trying to implement recovery and sync mechanisms. What I did broken already - it's boundary leakage again: AV/C recovery is trying to apply to Dice streams but each recovery/sync mechanism differs for different backend mechanisms.

Generally we want to sync to hw->host stream. It's not requirement, but I generally trust FireWire Crystal clock quality. Meanwhile it's important to understand what is ZTS in AudioDriverKit and clock difference: mach time is measured in ticks, and silicon Macs running on 24MHz clock. FireWire runs on 24.576MHz clock and this mismatch should be solved (it solved already). Each interrupt contains timestamp also each CIP packet contains SYT value. Regarding your questions - you should trace device/protocol bring up choreography - what's going on on device init. E.g. - MOTU is register based - similar to Dice, while BeBoP and OXFW is using AV/C, FCP and CMP to start isoch stream. So general idea - understand the order what comes after what. We are starting RX or TX first? When and how to establish clock sample rate, blocking or non-blocking transmission (I saw you noted that Tascam is non-blocking!). Regarding non-blocking in my opinion it simpler to implement (I don't remember if it's still in repo but there was a draft for non-blocking transmission cadence). Shortly - blocking requires constant packet sizes (e.g. 72 bytes for stereo 48k: 8 bytes for CIP header and 64 bytes for PCM payload - 8 audio frames) while non-blocking doesn't require NODATA packet in the cadence.

Shared IR→IT cadence replay - that I was working on right now.

Regarding RX itself - I'm trying to remove all audio related stuff from DriverKit Isoch/RX and Isoch/TX and move it to AudioDriverKit part, it's packetization, CIP generation etc. As I've said before - I'm trying to clean boundaries separation. AudioDriverKit part knows everything about audio/timing/IEC 61883-6, device configuration and completely doesn't cares about transport and vice versa. So regarding audio itself and how to align protocols - see:

/Users/mrmidi/DEV/ASFireWire/ASFWDriver/Audio/Protocols
mrmidi@MacBookAir Protocols % tree
.
├── AudioTypes.hpp
├── AVCStartReadiness.hpp
├── Backends
│   ├── AudioDuplexCoordinator.cpp
│   ├── AudioDuplexCoordinator.hpp
│   ├── AVCAudioBackend.cpp
│   ├── AVCAudioBackend.hpp
│   ├── ClockRequestBroker.hpp
│   ├── DiceAudioBackend.cpp
│   ├── DiceAudioBackend.hpp
│   ├── DiceRecoveryPolicy.hpp
│   ├── DiceRuntimeDeviceConfig.hpp
│   ├── DuplexIRMReservations.hpp
│   ├── DuplexOperationGate.hpp
│   ├── DuplexStreamProfile.hpp
│   ├── IAudioBackend.hpp
│   ├── IsochDuplexHostTransport.cpp
│   ├── IsochDuplexHostTransport.hpp
│   ├── RestartJournal.hpp
│   ├── RestartSessionStore.hpp
│   └── SyncAsyncBridge.hpp
├── BeBoB
│   ├── BeBoBMixerMap.hpp
│   ├── BeBoBPlug0StreamDiscovery.cpp
│   ├── BeBoBPlug0StreamDiscovery.hpp
│   ├── BeBoBProtocol.cpp
│   ├── BeBoBProtocol.hpp
│   ├── GenericBeBoBProtocol.cpp
│   ├── GenericBeBoBProtocol.hpp
│   ├── Phase88MixerData.hpp
│   ├── Phase88Protocol.cpp
│   └── Phase88Protocol.hpp
├── DeviceProtocolFactory.cpp
├── DeviceProtocolFactory.hpp
├── DeviceStreamModeQuirks.cpp
├── DeviceStreamModeQuirks.hpp
├── DICE
│   ├── Core
│   │   ├── DICEDuplexBringupController.cpp
│   │   ├── DICEDuplexBringupController.hpp
│   │   ├── DICENotificationMailbox.hpp
│   │   ├── DICERestartSession.hpp
│   │   ├── DICETransaction.cpp
│   │   ├── DICETransaction.hpp
│   │   └── DICETypes.hpp
│   ├── Focusrite
│   │   ├── SaffireproCommon.cpp
│   │   ├── SaffireproCommon.hpp
│   │   ├── SPro24DspProtocol.cpp
│   │   ├── SPro24DspProtocol.hpp
│   │   ├── SPro24DspRouting.hpp
│   │   ├── SPro24DspTypes.cpp
│   │   └── SPro24DspTypes.hpp
│   └── TCAT
│       ├── DICETcatProtocol.cpp
│       └── DICETcatProtocol.hpp
├── Duplex
│   ├── AudioClockConfig.hpp
│   ├── DuplexControlTypes.hpp
│   └── IDuplexDeviceControl.hpp
├── IDeviceProtocol.hpp
└── Oxford
    └── Apogee
        ├── ApogeeDuetProtocol.cpp
        ├── ApogeeDuetProtocol.hpp
        └── ApogeeTypes.hpp

10 directories, 57 files
mrmidi@MacBookAir Protocols %

Something like that. NB. AV/C, FCP stuff is not only audio related, so it lives inside driver itself, see:

rmidi@MacBookAir Protocols % tree
.
├── AVC
│   ├── Audio
│   │   ├── AudioSubunit.cpp
│   │   └── AudioSubunit.hpp
│   ├── AudioFunctionBlockCommand.cpp
│   ├── AudioFunctionBlockCommand.hpp
│   ├── AVCAddress.hpp
│   ├── AVCCommand.hpp
│   ├── AVCCommands.hpp
│   ├── AVCDefs.hpp
│   ├── AVCDiscovery.cpp
│   ├── AVCDiscovery.hpp
│   ├── AVCSignalFormatCommand.hpp
│   ├── AVCStreamFormatCommand.hpp
│   ├── AVCUnit.cpp
│   ├── AVCUnit.hpp
│   ├── AVCUnitPlugInfoCommand.hpp
│   ├── Camera
│   │   ├── CameraSubunit.cpp
│   │   └── CameraSubunit.hpp
│   ├── CMP
│   │   ├── CMPClient.cpp
│   │   └── CMPClient.hpp
│   ├── CONTROL_PLANE_CONTRACT.md
│   ├── Descriptors
│   │   ├── AVCDescriptorCommands.hpp
│   │   ├── AVCInfoBlock.cpp
│   │   ├── AVCInfoBlock.hpp
│   │   ├── DescriptorAccessor.cpp
│   │   ├── DescriptorAccessor.hpp
│   │   ├── DescriptorTypes.hpp
│   │   └── InfoBlockTypes.hpp
│   ├── FCPResponseRouter.hpp
│   ├── FCPTransport.cpp
│   ├── FCPTransport.hpp
│   ├── IAVCCommandSubmitter.hpp
│   ├── IAVCDiscovery.hpp
│   ├── Music
│   │   ├── MusicSubunit.cpp
│   │   ├── MusicSubunit.hpp
│   │   ├── MusicSubunitCapabilities.cpp
│   │   └── MusicSubunitCapabilities.hpp
│   ├── PCRSpace.cpp
│   ├── PCRSpace.hpp
│   ├── StreamFormats
│   │   ├── AVCSignalFormatCommand.hpp
│   │   ├── AVCSignalSourceCommand.hpp
│   │   ├── AVCStreamFormatCommands.hpp
│   │   ├── AVCUnitPlugSignalFormatCommand.hpp
│   │   ├── StreamFormatParser.cpp
│   │   ├── StreamFormatParser.hpp
│   │   └── StreamFormatTypes.hpp
│   └── Subunit.hpp
├── Ports
│   ├── FireWireBusPort.hpp
│   ├── FireWireRxPort.hpp
│   └── ProtocolRegisterIO.hpp
└── SBP2
    ├── AddressSpaceManager.cpp
    ├── AddressSpaceManager.hpp
    ├── SBP2_SESSION_PORT.md
    ├── SBP2CommandORB.cpp
    ├── SBP2CommandORB.hpp
    ├── SBP2ManagementORB.cpp
    ├── SBP2ManagementORB.hpp
    ├── SBP2PageTable.hpp
    ├── SBP2WireFormats.hpp
    ├── SCSICommandSet.hpp
    └── Session
        ├── CommandExecutor.cpp
        ├── CommandExecutor.hpp
        ├── DriverKitSessionScheduler.cpp
        ├── DriverKitSessionScheduler.hpp
        ├── FetchAgent.cpp
        ├── FetchAgent.hpp
        ├── ISessionScheduler.hpp
        ├── LoginSession.cpp
        ├── LoginSession.hpp
        ├── SessionRegistry.cpp
        └── SessionRegistry.hpp

11 directories, 70 files
mrmidi@MacBookAir Protocols %

Something like that.
Join discord. It's better place to discuss the stuff.
If you want to experiment with MOTU right away - try this commit: 1bbb70e it's pretty stable DICE implementation, since DICE is register based it's a good starting point. Otherwise - you could try to help me to restore stream stability. You've told Tascam is also register based - good starting point too.

Regarding RX/TX isoch - it was mature and stable enough until I've started rewriting it properly :)

regarding this: Factory matching. MOTU units are discriminated by the unit directory version
field (not model ID); Tascam by an ASCII model string in the config ROM.
DeviceProtocolFactory::Create(vendorId, modelId, …) doesn't currently carry either —
would you take a small extension of the factory signature / discovery plumbing? - feel free to do if it's required. Just try to be meaningful and careful with boundaries separation from the beginning :)

Anyway, latest main branch contains MCP and you could actually ask model "why my stream hand't started" and most probably AI agent will give you details answer - see https://github.com/mrmidi/ASFireWire/blob/main/skills/asfw-mcp-control-plane/SKILL.md for details. So - chose what's fits best for you :)

[Dreambrother7]

Thanks for the detailed answer — this is exactly the guidance I was hoping for. I'll join
the Discord for the ongoing discussion.

A quick status from my side: since opening this issue I've pushed two content-layer
branches to my fork, deliberately scoped below the transport boundary so they should
survive your refactor untouched:

• feature/tascam-wire-codec —
  TASCAM data-block geometry (FW-1884/1082/1804), PCM quadlet codec, and the rotating
  64-entry control-surface state image, with 16 host tests (golden vectors
  cross-validated against Linux sound/firewire/tascam, no code copied).
• feature/motu-wire-codec —
  MOTU v2 block layout (828mk2 chunk tables), 3-byte PCM packing, SPH timestamp math
  including the RX→TX offset cache/replay arithmetic, and the 2nd-quadlet MIDI slot,
  with 17 host tests.

Both live under ASFWDriver/Audio/Wire/{Tascam,MOTU}/, header-only, xcodegen
regenerated. Happy to rebase wherever you want them and open PRs whenever it suits your
refactor timeline — no rush from my side.

Plan based on your answers:

• I'll stay well away from the IR→IT cadence replay while you're building it — the MOTU
  SPH branch only pins down the pure arithmetic, so it should slot under whatever
  interface you land.
• Protocol layers next: MotuV2Protocol and TascamProtocol modeled on the DICE
  bring-up path, following the Linux choreography (both are register-based; I've got the
  full bring-up order documented from the Linux drivers — e.g. Tascam wants clock set →
  channel enables → session registers in a fixed order, RX and TX activated together).
• Factory/discovery: I'll propose the version-field / model-string matching as a small,
  boundary-respecting extension and we can iterate on it in a PR.
• Hardware experiments will start from 1bbb70e as suggested, beginning with the OHCI
  enumeration check on my test mini (M1, Tahoe, TB3→TB2→FW800 chain).

One heads-up so it's on the record: my FW-1884 needs the capture stream running for
playback timing (the device ignores SYT and recovers its media clock from the
data-blocks-per-packet sequence, replayed from the device→host stream), so it'll be a
duplex-always design like MOTU. The 2-second quiet window after a rate change is its
other notable quirk — bring-up timeouts will need to be per-protocol.

[mrmidi]

"my FW-1884 needs the capture stream running for
playback timing (the device ignores SYT and recovers its media clock from the
data-blocks-per-packet sequence, replayed from the device→host stream)"

You are so lucky. DBC is so much simpler to calculate than SYT, it's just a 1 byte monotonic counter, wraps at 0xFF. Since Tascam running in non-blocking mode you probably won't even bother with DATA/NO-DATA DBC logic: some devices increasing it in NO-DATA blocks, some right after NO-DATA block, you probably will always have DATA blocks with this type of transmission. You will definitely will be able to sync it from RX stream with ease (hw->host).

[mrmidi]

And I probably don't want to look for your ongoing work if you don't mind. I have my own pain. Based on your description you doing it great already. Only if you have some concrete question send a link to line or code block. Anyway, I don't have neither MOTU or Tascam to test it, so you have to be independent and self-sustained here.

One thing I would recommend is 2 other references I'm always using: it's libffado and absolutely amazing https://github.com/alsa-project/snd-firewire-ctl-services. 3rd good but not absolutely reliable option is actual drivers decompilation, probably poking it with Hydra or IDA Pro is good idea, just simply because Audio stack in linux vs macOS differs a lot. Old macOS KEXTs were using IOAudioFamily instead of AudioDriverKit but may shed some light on proper direction. DriverKit is much more user-friendly with much less boilerplate.

[Dreambrother7]

Understood on all counts — thanks for taking the time, this was genuinely helpful. We'll work independently and self-sustained (hardware validation for both families is covered on my side), and the only pings you'll get from me are a concrete question with a line link, or a PR when something's actually worth your review time. Good luck with the refactor — and the DBC news about the Tascam made my day.

[mrmidi]

Ok, the good news - there IS some bugs, but yesterday I've tested Apogee Duet and had stable glitchless audio stream for about 8 hours on macOS Tahoe 26.5. The failure I've described was isolated: I was tested the driver on macOS 27 Golden Gate Developers Beta 3 and I suppose Apple is doing something with CPU scheduling here that's not finished and that was the reason stream died (shortly: core audio is writing pcm data to DMA slower than firewire audio hw expects). This draft PR is pretty solid - you could try start from here if you want: #82