Type
Refactor 提案(欢迎讨论)。本提案是 PR #371 的后续 ,建议在其合并后推进。
背景
PR #371 (尚未合并 )为 DashScope 引入了音频时钟光标进度、runId 重入防护,以及真正的 suspend()/resume()。若其合并,DashScope 与 Edge 在两个机制上会形成分叉:
而两者本质都是「流式取音频 → 排进 Web Audio 时间轴」的播放器,共享大量骨架(AudioContext/scheduledEnd 生命周期、200ms 结束检测 checkEndTimer、suspend/resume、分块循环与 abort/清理),目前各写一份 。此外 Edge 的当前句高亮是 setTimeout 计时器,pause() 清除后 resume() 不重排,故 Edge 暂停/继续目前只能走「重说」(直接真正恢复会高亮跳格)。
提案
抽一个共享基类(如 StreamingAudioTTSPlayer),统管:Web Audio 生命周期、音频时钟光标进度、runId 重入、suspend/resume + 真正恢复 + 配置陈旧守卫、结束检测;子类只实现引擎特定的「取一段文本 → 产出音频样本」(DashScope = SSE 裸 PCM,Edge = WebSocket MP3 解码)。系统引擎(SpeechSynthesis,无 Web Audio、事件驱动)留在基类之外。
收益
消除 DashScope / Edge 的重复,避免上述机制长期分叉;
Edge 迁到音频时钟光标后,高亮能扛过暂停 → 解锁 Edge 真正恢复、消除「恢复后高亮跳格」;
减少 store 里的 per-engine 特判。
风险与前置建议
player 依赖 AudioContext,node 环境无法有意义单测,回归只能靠手动验证——重构面越大风险越高。建议前置/并行:把更多纯逻辑抽成可单测(调度数学、配置签名、状态迁移),或搭一个 mock-AudioContext 测试夹具来降风险。
这是对正常工作的子系统做结构优化,属可维护性投资、非必需,建议在 fix(tts): DashScope 进度同步与暂停/继续修复 #371 增量推进。
粒度(可选)
窄:仅抽流式播放器基类(上述);
中:再把 store 的 play/pause/resume/jumpToChunk 编排按「能力位(如 supportsTrueResume)+ 配置签名」统一,折叠重复回调。
具体要不要做、做到哪一档、何时做,由维护者评估。
Type
Refactor 提案(欢迎讨论)。本提案是 PR #371 的后续,建议在其合并后推进。
背景
PR #371(尚未合并)为 DashScope 引入了音频时钟光标进度、
runId重入防护,以及真正的suspend()/resume()。若其合并,DashScope 与 Edge 在两个机制上会形成分叉:resolveCurrentChunk+ 边界表);Edge →setTimeout(startDelayMs)对齐;runId;Edge →aborted标志。而两者本质都是「流式取音频 → 排进 Web Audio 时间轴」的播放器,共享大量骨架(
AudioContext/scheduledEnd生命周期、200ms 结束检测checkEndTimer、suspend/resume、分块循环与 abort/清理),目前各写一份。此外 Edge 的当前句高亮是 setTimeout 计时器,pause()清除后resume()不重排,故 Edge 暂停/继续目前只能走「重说」(直接真正恢复会高亮跳格)。提案
抽一个共享基类(如
StreamingAudioTTSPlayer),统管:Web Audio 生命周期、音频时钟光标进度、runId重入、suspend/resume+ 真正恢复 + 配置陈旧守卫、结束检测;子类只实现引擎特定的「取一段文本 → 产出音频样本」(DashScope = SSE 裸 PCM,Edge = WebSocket MP3 解码)。系统引擎(SpeechSynthesis,无 Web Audio、事件驱动)留在基类之外。收益
风险与前置建议
AudioContext,node 环境无法有意义单测,回归只能靠手动验证——重构面越大风险越高。建议前置/并行:把更多纯逻辑抽成可单测(调度数学、配置签名、状态迁移),或搭一个 mock-AudioContext 测试夹具来降风险。粒度(可选)
supportsTrueResume)+ 配置签名」统一,折叠重复回调。具体要不要做、做到哪一档、何时做,由维护者评估。