Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
smoother waveform #589
smoother waveform #589
Changes from 2 commits
cdbf2a1
b89b265
3d08de0
8fec2fd
653aabf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
如语音沟通,这里有两个已知的缺陷:
录制(
recording: true
)与文件(recording: false
)两种情况下,绘制结果的平滑程度不同;虽然都走了这里的renderFunction
这个差异应该是
peaks
的密度差异带来的,即,wavesurfer-record
中renderMicStream
处理与 wavesurfer 对文件处理逻辑的差异带来的blockSize 不会随着音频长度增加持续增加,这导致在录制过程中,录制越久,波形越不平滑
这是因为 blockSize 越大,累计单个 block 需要的时间越久,波形更新越不频繁,给人“卡顿”的感觉;可能的处理方式是:不等到累计满一个 block 才去更新波形,不满的 block 也可以被绘制出来,这样在录制越久时,虽然波形变更越慢,但更新频率是固定的,不会显得“卡顿”
可以看下好不好处理,不好处理的话在代码中先注释说明下
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我希望在之后可以重写整个逻辑去掉wavesurfer,这样之后也方便解决渲染逻辑不一样导致的密度不统一的问题。
问题2我看了下,如果说要绘制不满的 block,波形图“向左推”的速度依然会越来越慢,同样会导致视觉上的卡顿。“绘制不满的 block”不能改变“向左推”的速度,而我们预期应该是波形图在视觉上持续地收缩。可能的解决方案是非线性的波形图渲染,但这样可能更加麻烦。我目前倾向于设置一个上限让波形图看起来不至于卡顿。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
这个我没问题
慢跟卡是不一样的,如果更新是高频率的,即使变更很小,也不应该会感觉到卡
绘制不满的 block 不是为了改变“向左推”的速度,而是让眼睛看到的“推”更频繁(虽然每次推的距离在缩小)
这个必要性不大
如上面提到的,卡是问题,但慢不应该是问题
如果是说 blockSize 频繁变更(对应均值计算结果的缓存失效)导致卡顿(大量的点重新计算均值),这个我能理解,不过那是另一个问题了,涉及的应该是 blockSize 的阶梯,而不是上限
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
懂了。我想了一下,按目前的实现要做到这种效果会比较麻烦。我先加个注释,之后要再重构的时候一起想办法实现