SoundCraft 硬件就绪度完整核对指南对照 Pro Tools把每个结论翻到源码【免费下载链接】iloaderUser friendly sideloader项目地址: https://gitcode.com/GitHub_Trending/iloa/iloaderSoundCraft 是一款 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 的 trivialaux 延迟补偿 #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与ArcSession快照命令走 channel位置与表头走原子量加try_lock快照回调永不阻塞稳态下不分配还配了音频线程感知的 logger。唯一要小心的 在这里track.commit走真实渲染而track.freeze只是置一个t.frozen标志见 crates/engine/src/cmd/track.rs没有任何冻结后改用预渲染结果、跳过插件处理的分支所以不省 CPU。 有路径、但没到语义的设备能力这一档最多也最容易误读。下面每条都按结论 → 源码位置 → 为什么不是 ✅来。cpal 设备选择怎么验证设备选择的全部状态收敛在 crates/playback/src/devices.rs 的AudioConfig五个字段全是OptionNone统一表示系统默认pub struct AudioConfig { pub system: OptionString, // WASAPI / ASIO / CoreAudio / ALSA pub output: OptionString, pub input: OptionString, pub sample_rate: Optionu32, pub buffer_size: Optionu32, }这个设计和设备选择随机器保存、不写进工程严格对应。为什么不是 ✅选播放/输入设备在 Windows 已验证WASAPI、ASIOmacOS 与 Linux/FreeBSD 仍是尚未验证。用户影响你在这台机器上选的设备只在这台机器生效。10-12 那条 minor 变更落地的就是这套AudioConfig与 Playback Engine 窗口。缓冲区怎么校验、怎么两级回退UI 下拉给的是标准档位 32–8192devices.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: Optionu32, 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-incrates/playback/Cargo.toml 里那行注释把原因说透了# Off by default: building it downloads Steinbergs 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 ToolsSoundCraft源码位置MIDI 输入/输出设备、Thru、Beat Clock、MTC✅❌ 无 MIDI 设备层setup.midi_input_devices只存名字crates/engine/src/cmd/setup_more.rsEUCONS 系列、Dock、Control app✅❌ Avid 专有 SDKowner decision同上HUI / Mackie Control / 通用 MIDI 控制器✅❌同上LTC/MTC 跟随、Word clock、视频输出✅❌setup.external_timecode_offset只写偏移无跟随同上长素材磁盘流式✅❌ 整个文件解码进SourcePoolcrates/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}排查顺序和源码的失败链保持一致看日志里的audio device: … … Hz, … ch, …, buffer …crates/playback/src/lib.rs出现了说明流已打开出现no usable audio stream; using a silent clock说明三级回退全失败转由静默时钟接管那条soundcraft-clock线程每 10 ms 按真实时间推进帧数。界面显示 no device (silent clock)走带与表头正常但无声不是混音问题。播放中突然停并提示 stopped asking for audio对应 2 秒块计数停滞判定不是设备真消失。故障在Fault::trouble()里分三类Bug某块 panic此后静音、Gone设备消失/流被 invalidate需重连、Stalled播放中设备不再索要音频且只在第一次上报reported.swap(true)保证只报一次。改设备被拒并提示 stop recording before changing the audio device是apply_audio_config()在保护正在录的 take。Linux 初次构建失败先补 ALSA 头文件Debian/Ubuntulibasound2-devFedoraalsa-lib-devel。人时预算与依赖顺序硬件约 110–180 h、性能约 40–70 h。推进上 G-01音频设备层、G-02MIDI 设备层是 alpha blockerG-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考