SoundCraft 硬件就绪度完整核对指南：对照 Pro Tools，把每个结论翻到源码

SoundCraft 硬件就绪度完整核对指南：对照 Pro Tools，把每个结论翻到源码

【免费下载链接】iloaderUser friendly sideloader项目地址: https://gitcode.com/GitHub_Trending/iloa/iloader

SoundCraft 是一款 Rust 写的 DAW。这份对照 Avid Pro Tools Ultimate 2026.4.1 的审计，给了它硬件就绪度约 12%、性能约 35% 两个数。CI 机器上没装任何声卡，它的整套集成测试照样跑完——撑住这条流程的是一条叫soundcraft-clock的静默时钟线程。那 12% 到底可信吗？差的具体又差在哪？我把和这两个百分比相关的每条结论都翻到了源码逐条核对，下面就是核对结果。

评分口径：先说清这两个百分比是怎么来的

在谈任何能力之前，三条前提决定了后面所有结论的可信边界。

测量对象不同源。SoundCraft 一侧的结论全部来自crates/playback（底层是 cpal，一个跨平台音频设备库），以及"仓库里根本没有任何 MIDI 设备层与控制面代码"这个事实；Pro Tools 一侧来自它的官方文档与 Setup 菜单。所以这不是把两台机器放一起的黑盒对照。

两个数字都是估算。硬件约 12%、性能约 35%，原文写着 "estimated"，并明确"没有任何一项跟 Pro Tools 跑过对照基准"。剩余工作量按人时计：硬件约 110–180 小时，性能约 40–70 小时。

结论可追溯到提交。审计头部记着Last reviewed: 2026-10-10 · Last updated: 2026-10-13，变更等级从 10-10 的 major（创建整份审计）到 10-12 的 minor（音频设备设置落地、可选 ASIO）再到 10-13 的 trivial（aux 延迟补偿 #246）。docs/gaps.md 的惯例是"关闭一个缺口就在同一个 PR 里删掉条目并更新时间戳"。我核对时就是顺着这条修订记录往回找提交的。

图例是四态：✅ 可用 / 🟡 部分可用 / ❌ 缺失 / 未测量。这里必须点破 🟡 的真实含义——它不是"差一点就完成"，而是有一条路径能出声，但 Pro Tools 用户期望的关键语义还没实现。比如设备能选，但输入输出仍是两条独立的流。

✅ 已经扎实的几条硬事实

这三条都能在源码里指到具体函数与测试，是 35% 里最硬的部分。

并行混音是怎么实现的（rayon 的两个开关）

打开 crates/mix/src/threads.rs 的run_strips，并行不是无条件开的：

let audio = on_audio_thread(); work.par_iter_mut().for_each(|w| as_audio_thread(audio, || f(w)));

第一个条件藏在外面：strip（一条混音通道）数 ≥ 4 才并行，否则顺序执行——少通道时 rayon 的调度开销不划算。第二个条件是线程标记的传播：as_audio_thread进入时存下本线程原标记、设成继承值，退出靠Drop还原，即使闭包 panic 也能恢复。这让"为音频线程渲染的 pool worker"在语义上继续算音频线程，从而不破坏下一条纪律。测试strips_rendered_for_the_audio_thread_count_as_the_audio_thread_and_only_then从正反两面验证了这一点。

延迟补偿是怎么实现的（#246 修的 aux 回喂 bus）

延迟补偿（按最慢路径把各条 strip 对齐，避免相位错位）分三类累加，见 crates/mix/src/lib.rs：轨道插入最慢延迟lmax_t、aux 返回最慢延迟lmax_a、主推子插入延迟lmax_m，总延迟latency = lmax_t + lmax_a + lmax_m。

特殊的是被 aux 回喂的那条 bus：写进它的音频要额外补偿那条 aux 链路的延迟，所以bus_latency()会条件性地加上aux_latency。离线 bounce（把一段渲染落盘）在 crates/mix/src/offline.rs 会先问一次这个延迟，然后多渲染这么多帧再丢掉头部。#246 这条 trivial 变更（10-13）就是让"被 aux 回喂的 bus 的 bounce 像主混音一样补偿延迟"。回归测试在master_insert_latency.rs与aux_routing_order.rs。

音频线程为什么不阻塞

crates/playback/src/lib.rs 模块文档里写清了线程模型：UI 线程持有Player，音频回调持有MixEngine与Arc<Session>快照；命令走 channel，位置与表头走原子量加try_lock快照，回调永不阻塞，稳态下不分配，还配了音频线程感知的 logger。

唯一要小心的 🟡 在这里：track.commit走真实渲染，而track.freeze只是置一个t.frozen标志（见 crates/engine/src/cmd/track.rs），没有任何"冻结后改用预渲染结果、跳过插件处理"的分支，所以不省 CPU。

🟡 有路径、但没到语义的设备能力

这一档最多，也最容易误读。下面每条都按"结论 → 源码位置 → 为什么不是 ✅"来。

cpal 设备选择怎么验证

设备选择的全部状态收敛在 crates/playback/src/devices.rs 的AudioConfig，五个字段全是Option，None统一表示"系统默认"：

pub struct AudioConfig { pub system: Option<String>, // "WASAPI" / "ASIO" / "CoreAudio" / "ALSA" pub output: Option<String>, pub input: Option<String>, pub sample_rate: Option<u32>, pub buffer_size: Option<u32>, }

这个设计和"设备选择随机器保存、不写进工程"严格对应。为什么不是 ✅？选播放/输入设备在 Windows 已验证（WASAPI、ASIO），macOS 与 Linux/FreeBSD 仍是"尚未验证"。用户影响：你在这台机器上选的设备只在这台机器生效。10-12 那条 minor 变更落地的就是这套AudioConfig与 Playback Engine 窗口。

缓冲区怎么校验、怎么两级回退

UI 下拉给的是标准档位 32–8192（devices.rs里STANDARD_BUFFERS九个值、STANDARD_RATES六个采样率），但命令层实际允许 16–8192，并把请求向上取整到 2 的幂、封顶 8192、默认 1024——这句话的来源就是 crates/engine/src/cmd/setup_more.rs 里engine_settings的那段 clamp。真正生效的缓冲区走另一条路：AudioConfig.buffer_size→devices::buffer_size()，打开设备时还要再校验一次，越界就退回设备默认：

pub(crate) fn buffer_size(want: Option<u32>, supported: &cpal::SupportedBufferSize) -> cpal::BufferSize { match (want, supported) { (Some(n), cpal::SupportedBufferSize::Range { min, max }) if (*min..=*max).contains(&n) => Fixed(n), (Some(n), cpal::SupportedBufferSize::Unknown) if (16..=8192).contains(&n) => Fixed(n), _ => cpal::BufferSize::Default, } }

两级回退在 crates/playback/src/lib.rs：先试用户指定的缓冲区，被拒再试设备默认（first_started的契约是"第一个既能构建又能play()成功的尝试获胜"，失败项只记日志）。注意混音本身固定跑 512 样本块，缓冲区只调设备自身延迟，不改混音块长。为什么不是 ✅？"驱动允许时使用设备缓冲区"在多数平台仍是尚未验证。

ASIO 为什么是 opt-in

crates/playback/Cargo.toml 里那行注释把原因说透了：

# Off by default: building it downloads Steinberg's ASIO SDK (its own licence) # and needs LLVM (libclang) for the bindings. asio = ["cpal/asio"]

默认关闭，因为构建期会下载 Steinberg 的 ASIO SDK（自带许可条款），且绑定生成要 LLVM/libclang。官方二进制默认走 WASAPI shared；想要 ASIO 得显式构建。这也是它被记成 "owner decision" 的原因——SDK 许可和项目分发策略有冲突。

重采样和 InputRing 怎么桥接

输入输出是两条独立的 cpal 流，各自设备、采样率、缓冲区互不共享——这就是"单时钟双工流（输入输出共用同一时钟、同一条流）"整行为 ❌ 的根因。跨设备/跨采样率靠一块叫InputRing的小 FIFO 桥接：

/// A small interleaved FIFO from the input callback to the output callback, /// for input monitoring. Both sides only `try_lock`; it holds at most ~0.5 s /// and drops the oldest frames. pub struct InputRing { ... }

容量上限约半秒输入（未知采样率时 24 000 帧），超限丢最旧帧；读取端按rate_in / rate_session做线性插值。测试monitor_converts_input_rate_to_session_rate用 16 kHz 的 1 kHz 正弦验证升到 48 kHz 后音高不变（误差 < 0.05）。能出声、能对音高，但不是一个时钟，所以严格意义的双工流仍是 ❌。

多通道怎么按顺序写、环绕怎么折叠

crates/playback/src/callback.rs 的write_frame()：设备通道数 ≥ 混音通道数时按顺序逐通道拷贝；更少时先做 ITU-R BS.775 立体声折叠，单声道设备再取左右平均。out_sample()在送设备前把样本夹到[-1.0, 1.0]并把 NaN/无穷变静音。为什么不是 ✅？模型层有Route::Hardware(String)这种"按路径名指到硬件输入/输出"的变体，但播放路径只按顺序写设备通道，没有 I/O Setup 那种把某条路径绑到第 3–4 物理通道的映射表。

录音落盘：环满怎么补静音、坏样本怎么清零

Recorder的落盘链路：输入回调把每块拷进预分配的无锁环，写线程把它流式写成每个 take 一个 WAV 文件，每秒重写一次头，崩溃后文件仍可播放。环满时不丢时间轴，而是把丢失样本记成"欠账"，下一块之前补静音保持 take 时序；NaN/INF 在入库前就被清零。测试a_full_ring_owes_the_lost_samples_as_silence覆盖了补静音结果。FreeBSD 的录音是编译期直接返回错误，而不是运行期悄悄失败。

录音中为什么禁止改设备

crates/ui-egui/src/app/audio.rs 里有一条硬约束：录音中拒绝改设备。apply_audio_config()会先close_editors()再丢弃旧Player（插件实例随旧 player 一起释放，编辑器窗口必须在主线程关闭，否则成孤儿窗口），重建后用player.locate(at)保留走带位置。集成测试audio_device.rs覆盖了这条。用户影响：录着 take 时去改设备会被拒绝。

虚拟 MIDI 键盘卡在哪

MIDI 编辑器窗口存在，但没有实时试听通路——crates/ui-egui/src/panels/midi_editor.rs 里那行注释直接说明：// Audition on the instrument would go here (needs a live MIDI input path)。为什么是 🟡 而不是 ❌？窗口能画、能离线导入，只是缺一条实时弹奏的输入路径。

❌ 整层缺席的能力

这几块不是"差一点"，是整层没有。共性形态一句话就能概括：设置项存在、语义未实现——能往工程里存名字、存开关，但没有任何设备协议代码去读它。

能力	Pro Tools	SoundCraft	源码位置
MIDI 输入/输出设备、Thru、Beat Clock、MTC	✅	❌ 无 MIDI 设备层，setup.midi_input_devices只存名字	crates/engine/src/cmd/setup_more.rs
EUCON（S 系列、Dock、Control app）	✅	❌ Avid 专有 SDK，owner decision	同上
HUI / Mackie Control / 通用 MIDI 控制器	✅	❌	同上
LTC/MTC 跟随、Word clock、视频输出	✅	❌setup.external_timecode_offset只写偏移，无跟随	同上
长素材磁盘流式	✅	❌ 整个文件解码进SourcePool	crates/mix/

MIDI 侧能查到的证据是仓库里不存在midir/CoreMIDI/WinMM/ALSA sequencer 代码；docs/gaps.md 的 G-02 把它标成 alpha blocker。同步侧同理：setup.external_timecode_offset与setup.video_sync_offset只写进sync.external_offset/video.sync_offset，视频偏移还支持以帧为单位（测试里 2 帧 → 3200 样本），但没有任何东西去跟随时码。G-11 明确写了这条链要排在 G-01/G-02 之后，预计 15–25 小时，因为一条可用的同步必须先有可用的双工音频与 MIDI 设备层。

未测量不等于不行

性能表里有一行写的是unmeasured：轨道数（Pro Tools Ultimate 上限 2,048 voices）。"未测量"和"不行"是两回事——仓库里现在有的是render_bench.rs、plugin_bench.rs这类例子程序，不构成与 Pro Tools 的对照基准，所以证据列直接给了行动项：补cargo xtask bench。这也是性能整体标 "~35%（estimated）" 而不是精确分数的原因。读这张表时务必把"未测量"单独拎出来，别和 ❌ 混在一起。

没有声音时的排查顺序与推进路径

跑这几条命令，先确认设备到底开没开、要不要 ASIO、机器上有哪些系统：

cargo run --release -p soundcraft -- --demo cargo build -p soundcraft --features asio soundcraft-cli app --port 7801 ui.audio_device '{"list":true}'

排查顺序和源码的失败链保持一致：

1. 看日志里的audio device: … @ … Hz, … ch, …, buffer …（crates/playback/src/lib.rs）：出现了说明流已打开；出现no usable audio stream; using a silent clock说明三级回退全失败，转由静默时钟接管（那条soundcraft-clock线程每 10 ms 按真实时间推进帧数）。
2. 界面显示 "no device (silent clock)"，走带与表头正常但无声，不是混音问题。
3. 播放中突然停并提示 "stopped asking for audio"，对应 2 秒块计数停滞判定，不是设备真消失。故障在Fault::trouble()里分三类：Bug（某块 panic，此后静音）、Gone（设备消失/流被 invalidate，需重连）、Stalled（播放中设备不再索要音频），且只在第一次上报（reported.swap(true)保证只报一次）。
4. 改设备被拒并提示 "stop recording before changing the audio device"，是apply_audio_config()在保护正在录的 take。
5. Linux 初次构建失败，先补 ALSA 头文件（Debian/Ubuntu：libasound2-dev；Fedora：alsa-lib-devel）。

人时预算与依赖顺序：硬件约 110–180 h、性能约 40–70 h。推进上 G-01（音频设备层）、G-02（MIDI 设备层）是 alpha blocker，G-10（控制面，40–70 h，需硬件验证）、G-11（同步，15–25 h）明确排在它们之后。

怎么读这两个百分比

12% 硬件就绪度的主要拖累不是音频驱动——音频侧虽然 🟡 多，但每条都有真实路径。真正拖低它的是完全缺席的 MIDI 设备层与控制面协议（EUCON/HUI/MCU），加上同步整块 ❌。35% 性能里已经有几条源码可证的 ✅：并行 strip 渲染、#246 的 aux→bus 延迟补偿、音频线程不阻塞与 logger 交接。真正的空白只有磁盘流式与任何形式的对照基准。

把这两个百分比当"能力清单"读很容易误读。按状态分层看下去——✅ → 🟡 → ❌ → 未测量——你会发现它其实是一张依赖图：每个缺口都能在 docs/gaps.md 里找到编号、人时和先后顺序。这份审计的价值不在百分比，而在于每一行都能落到一个文件、一个函数、一个测试名。

【免费下载链接】iloaderUser friendly sideloader项目地址: https://gitcode.com/GitHub_Trending/iloa/iloader