You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ZED-R16 support needs to expose the missing 88.2/96 kHz sample-rate modes.
Draft PR #224 proposes a small change that extends the existing DICE format-selection path with a ZED-R16-specific fallback. It checks device identity and current stream geometry, preserves successful EAP discovery, and keeps existing rate-capability filtering and rate-change handling.
This issue and the linked draft PR are intended as a concrete starting point for review of that approach. Clock-source selection will be a separate contribution.
Hi. DICE report could be more useful here instead of opening the PR. And logs too. :)
I'm trying to build universal path when you don't need to hardcode capabilities for DICE and I'm trying to understand what's broken.
Thanks, understood. I agree that understanding why the existing discovery path misses these modes is more useful for the universal approach.
I’m currently running my own locally patched ASFireWire build, where 88.2/96 kHz works and I can switch between Internal and ADAT clock sources through macOS Audio MIDI Setup. Both have been working in my current setup, although testing is still limited.
The attached DICE report and logs come from my patched build (0.6.0/build 41), running at 96 kHz with ADAT as the clock source. They document the device’s state with my changes in place; they do not reproduce the missing-rate issue on an unmodified upstream build.
Would you prefer a comparison capture using a specific upstream build? I’m happy to provide that and any additional sample-rate captures that would help.[
Activity
mrmidi commentedon Oct 23, 2026
Hi. DICE report could be more useful here instead of opening the PR. And logs too. :)
I'm trying to build universal path when you don't need to hardcode capabilities for DICE and I'm trying to understand what's broken.
fix(dice): offer every CLOCK_CAPS rate on devices without EAP (#223)
Merge pull request #222 from mrmidi/fix/dice-advisory-clock-wait
stephanterning commentedon Oct 23, 2026
Thanks, understood. I agree that understanding why the existing discovery path misses these modes is more useful for the universal approach.
I’m currently running my own locally patched ASFireWire build, where 88.2/96 kHz works and I can switch between Internal and ADAT clock sources through macOS Audio MIDI Setup. Both have been working in my current setup, although testing is still limited.
The attached DICE report and logs come from my patched build (0.6.0/build 41), running at 96 kHz with ADAT as the clock source. They document the device’s state with my changes in place; they do not reproduce the missing-rate issue on an unmodified upstream build.
Would you prefer a comparison capture using a specific upstream build? I’m happy to provide that and any additional sample-rate captures that would help.[
README.txt
SHA256SUMS.txt
system-and-build.txt
driver-log-after-report.txt
ZED-R16-DICE.txt
1394-diagnostics-before-report.txt
asfw-extension-status.txt
driver-log-before-report.txt
](url)