录音/制作/创作 吉他 扩声技术 视频技术 作品展示 生活 信息 更多... | 音频应用专卖店

CPU资源已耗尽”的官方解决方法 为什么我设置了没用?

( 18 )
12
 
[收藏]
-  第 1 页  -

13
#1 24-7-16 23:48

CPU资源已耗尽”的官方解决方法 为什么我设置了没用?

有没有人能教我怎么解决一下pc系统下这个cpu占用的问题呀  每次弹cpu满载的时候 实际cpu占用才一点点


我看了《
[size=1.5em]“CPU资源已耗尽”的官方解决方法
》 这个帖子 我看下面留言好像里面的方法 大家试了 都有用  

但是

不知道为什么我任务管理器 进程 右键 protools ”转到详细信息“这个选项是灰色的 点不了
于是我就直接从任务管理器 上面的选项中 找到了倒数第二个 详细信息  里找到protools。exe 右键 然后完成了 取消勾选cpu0的这个操作 但是我试了很多次 发现还和以前一样 满载弹窗

而且我把 cmd /c start "Pro Tools" /affinity fffffffffffffffe "C:\Program Files\Avid\Pro Tools\ProTools.exe" 这段也按照贴里的步骤复制到了pt属性里 根目录位置也是对的 但是每次打开 pt cpu0 都会重新被勾上


我不知道是为什么别人好像都能管用到我这就不行


求懂得朋友支支招 谢谢大家

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?注册

x

51
#2 24-7-17 02:57
系统的cpu占用和软件内部的cpu占用的具体参数其实不一样,系统是按cpu工作时间占比来算,而daw是按照即时计算出来的音频长度在可用缓冲区的占比来算的,也就是说假设你缓冲区设置512,你的宿主内cpu占用面板在50%的意思是你现在cpuh可以在一半都缓冲区时间内就能把音频计算完,从而不会产生爆音,当你的cpu占用满载的时候代表你的cpu计算速度跑不过播放速度也就是缓冲区欠载了。这是两者统计内容不同而造成的不一样,是完全正常的。如果你想问为什么软件里面cpu都算不过来了。但是我电脑系统的cpu时间上占用才这么点呢?下面我引用fl studio用户手册的话来给你解答(主要看一下时间尺度和逻辑尺度,指标尺度就是我上边解释的):


人们通常会打开Windows 任务管理器或macOS 活动监视器,并注意到并非所有核心都在充分使用,或者 FL Studio CPU 计量表和操作系统 CPU 计量表不匹配。如果您遇到音频故障并且发现操作系统 CPU 使用率远未达到 100%,这可能会令人沮丧。让我们看看 FL Studio CPU 仪表与操作系统 CPU 仪表,看看为什么这是预期的和正常的。我们将考虑指标、时间和逻辑:

不同的指标- 实时音频以称为“音频缓冲区”的短段生成(长度约为 5-20 毫秒,具体取决于您的设置)。当您按“播放”时,在第一个音频缓冲区填满并且第二个缓冲区开始工作之前,不会听到任何声音。换句话说,您始终在收听过去创建的 1 个缓冲区的音频。FL Studio CPU 仪表测量每个音频缓冲区的填充速度。具体来说 - (填充缓冲区所需的时间/缓冲区长度)。50% 表示缓冲区的音频是在可用时间的一半内生成的。另一方面...
操作系统CPU计量器测量总体 CPU“利用率”。利用率是 CPU 上正在使用的处理单元的百分比。将它们想象成计算器,并想象您的 CPU 有 16 个可用的计算器。具体来说 - (正在使用的处理槽/可用的处理槽)。50% 意味着一半的处理单元正在使用中,或者对于我们的示例,16 个计算器中有 8 个正在使用。因此,利用率与处理能力有关,而不是处理给定任务(例如 FL Studio 音频)的速度。简而言之,FL Studio 的仪表测量时间(处理速度),操作系统测量容量(正在使用的处理槽)。这两个衡量指标并不相同,即使它们都以百分比形式报告!但是等等,还有更多:时间尺度和逻辑。

时间尺度- FL Studio CPU 仪表与音频缓冲区大小相关,约为 10 毫秒。操作系统 CPU 计量器以固定的 ~ 1000 ms 间隔工作。时间尺度相差100倍左右!虽然操作系统 CPU 仪表可能显示 30% 的利用率,但在过去 1000 毫秒内,在此期间可能多次出现实时音频处理中断的情况。为什么?如果实时音频流必须等待输入流完成,您可能会遇到音频故障,或者至少会遇到非常高的 FL Studio CPU 仪表读数。同时,操作系统可能会报告总体和/或单个 CPU 利用率较低。CPU 可能有很多空闲处理单元。只是所使用的设备无法跟上实时输出的情况。对于音频生成来说,CPU 必须等待程序和系统相关任务完成才能继续,因此可能很难跟上实时音频输出。每秒不间断地持续生成约 44100 个样本并不是一项简单的任务。CPU 必须“等待”的原因与逻辑有关:


音频处理的逻辑-有一长串必须按顺序处理的任务,这意味着逻辑上不能并行处理(多线程)。例如:插件必须等待来自钢琴卷帘和播放列表的指令才能发出声音。效果器必须等待来自上游乐器和 FX 的音频,然后才能对其进行处理。此外,无法并行处理(多线程)位于同一 Mixer 通道(其中音频混合在一起)的乐器和 FX,甚至无法并行处理同一 Mixer 路由管道(当一个 Mixer 轨道链接到另一轨道时)和另一个)。即使FX 处理在 FX 堆栈中也有从上到下的顺序)。然后,主混音器轨道必须等待每个乐器 > 混音器轨道 > 效果处理完毕,然后才能通过主效果处理音频。因此从逻辑上讲,存在大量等待,这是顺序音频处理的自然且不可避免的事实。将音频生成视为一条生产线。这意味着 CPU 可能不会特别繁忙,会使用其所有处理单元和内核,但它却没有时间来填充音频缓冲区。为什么?因为有很多需要按顺序处理的事情需要等待,等待基本上就是浪费缓冲时间。应该清楚的是,快速处理非常重要,这与多核/多线程处理不同。

换言之就是在一条链路上的声音要依次计算,下一个必须等待前一个算好才可以继续算,这个时候多核cpu显得就没那么有用了,而单核自己的性能往往更重要,当然多核本身就是很重要的对于庞大工程必不可少,但并不能解决一条链路中计算时间过长的问题,类似于短板效应
当然两个宿主软件不一样,但是背后基本逻辑是一样的,希望楼主可以参考。
原信息网址https://www.image-line.com/fl-st ... anels.htm#panel_cpu
你在protools的操作手册上应该也能找到类似的话

本帖最后由 ARCHIMAGE 于 24-7-17 03:03 编辑

2374
#3 24-7-17 03:46
ARCHIMAGE 发表于 24-7-17 02:57
系统的cpu占用和软件内部的cpu占用的具体参数其实不一样,系统是按cpu工作时间占比来算,而daw是按照即时计 ...

这就体现出reaper的强大了,fl官方说音频不能多线程处理,结果人家reaper却实现了……

51
#4 24-7-17 08:56
ken_20 发表于 24-7-17 03:46
这就体现出reaper的强大了,fl官方说音频不能多线程处理,结果人家reaper却实现了……

哈哈哈那reaper确实是吊的 本帖最后由 ARCHIMAGE 于 24-7-17 09:01 编辑

2552
#5 24-7-17 10:08
PT12主要就是对CPU的优化有毛病,
为了插件你就忍了吧

1466
#6 24-7-17 12:53
没得搞 就这样吧

790
#7 24-7-17 13:05
ken_20 发表于 24-7-17 03:46
这就体现出reaper的强大了,fl官方说音频不能多线程处理,结果人家reaper却实现了……

怪不得我用FL 混音后导出的时候,CPU只能用到20%,我一直以为是其他什么问题造成的

636
#8 24-7-17 13:44
还是reaper稳

13
#9 24-7-17 19:50
死亡爱抚 发表于 24-7-17 10:08
PT12主要就是对CPU的优化有毛病,
为了插件你就忍了吧

那要 protools什么版本的?

13
#10 24-7-17 20:01
ARCHIMAGE 发表于 24-7-17 02:57
系统的cpu占用和软件内部的cpu占用的具体参数其实不一样,系统是按cpu工作时间占比来算,而daw是按照即时计 ...

https://audiobar.cn/forum.php?mo ... 4%D2%D1%BA%C4%BE%A1

那为什么这个帖子里很多人好像反馈这个方法有用呢 我很好奇

而且如果pt里满载是是真的cpu满载了 那为什么我pt里满载的时候我宿主外面的插件感受不到cpu负载很严重呢
我不理解

13
#11 24-7-17 20:04
ARCHIMAGE 发表于 24-7-17 02:57
系统的cpu占用和软件内部的cpu占用的具体参数其实不一样,系统是按cpu工作时间占比来算,而daw是按照即时计 ...

而且 我试过 reaper 里能挂载的插件比pt差不多 多一倍  虽然也会有这种 满载实际没满载的体感 但是比pt就是好了 很多  但是说实话用pt用习惯了 不想折腾新宿主

2374
#12 24-7-17 22:39
其实所有从单核开始发展到现在的DAW都有这个问题,他们的一个音频路径就只会使用一个核心去运算,所以这些老DAW尽量使用外部输出作为编组,外部输出接去调音台,这样就能避免一核跑满其他核围观。又或者完全不使用bus通道,你尝试一下就知道只要不跑bus,你能用的插件就会变多。而完全按现在世代开发的reaper就很好的避免了音频流跑单核的问题,他能平均运算到多个核心,当然老一辈DAW为啥不改设计应该有很大一部分原因是让用户能更好兼容老工程,哪天真的能狠下心彻底让老工程跟新工程不兼容的话这些老DAW也应该能发挥完整的电脑性能。其实要实现完整的多核运算真心不难的,像izotope RX、SpectraLayers 等降噪软件独立运行的时候就是能完整跑满所有核心(我amd 3900 12核24线程都明显看到能平均跑到所有线程窗口上),甚至waves的降噪插件Clarity Vx他不作为通道插件而是直接对音频块渲染的时候也是能跑满所有核心的,也就是单核跑满多核围观的问题是来自DAW设计的不合理。目前解决这些不合理的方法要不就换reaper,要不就找一个多输出的声卡,多路输出作为bus使用,通过建立回录音频轨道当作bus,或者通过调音台summing。PT全软件混音的就推荐声卡输出然后建立音频轨道回录这个方式,然后设置PT的延迟补偿(可以单独设置每个IO的延迟补偿时间)
如果觉得这些设置麻烦的话就放弃PT转头reaper的怀抱吧,起码价格来说都比pt便宜多了,习惯PT界面和快捷键的都有skin和快捷键模板的,上手也很快

13
#13 24-7-17 23:46
ken_20 发表于 24-7-17 22:39
其实所有从单核开始发展到现在的DAW都有这个问题,他们的一个音频路径就只会使用一个核心去运算,所以这些 ...

最新版本的宿主也是这样么  mac上也这样么 大家做音乐的 都吃得这么差么

2374
#14 24-7-18 00:59
oneleg 发表于 24-7-17 23:46
最新版本的宿主也是这样么  mac上也这样么 大家做音乐的 都吃得这么差么

一样,我就是最新版的PT

51
#15 24-7-18 06:34
oneleg 发表于 24-7-17 20:01
https://audiobar.cn/forum.php?mod=viewthread&tid=559265&highlight=CPU%D7%CA%D4%B4%D2%D1%BA%C4%BE%A ...

因为你宿主外边的插件不在一条链路上边啊,就可以调用其他空闲的核进行计算了。再仔细研究一下我上面发的资料吧,宿主里的“cpu满载”并不是cpu真的满载了,主要原因是计算必须符合先后顺序,你插件前后有顺序。得一个一个算,尤其是你并轨输出到总线上边,你总线上的插件得等所有其他分轨都算完了才能计算,这种时候并不是cpu满载了,而是其中算的快的几条链路必须等其他挂了一堆插件计算量大的算完才处理。这种时候可以称之为单核满载了但是其他很多核可能根本没用上,因为没法并行处理,你宿主外边挂的插件也好,跑的程序也好,和这条链路本身没有关系。可以并行处理,所以就一切正常。换句话说如果你外部也走了一大堆的插件链路,超过了你单核的计算速度,你照样还是跑不动,形成满载的情况。音频的实时播放重要的就是“实时”两个字。如果你是混音导出,完全不受影响因为cpu可以慢慢算。而且protools本来似乎就对cpu优化并不好,实在接受不了就换更好的cpu或者换宿主吧
您需要登录后才可以回帖 登录 | 注册

本版积分规则

搜索