安卓机音画不满意~ 安卓机音频噩梦？ 想组台htpc 关于配置请教~

不满意：音+画，特别是音
使用过：天猫盒子，小米旗舰盒子，x9s等   
播放设备：中等水平8系LG电视，入门dlp投影
音响：杰士rp等。。。

以下纯个人感受：
在电视上有明显差异，投影不去说了，毕竟入门~
画质：
天猫盒子免了
小米画质整体优于x9s一点，可惜系统一升级就水了（卡死人），也懒得去找教程刷机，也有贴说过好于某蓝光碟机对吧~致命问题小米不是蓝光盒子，只能购入x9s，一个我穷，其次确实用起来很顺手，没有什么大问题，价格便宜！
其次，播放同电影，画质展现最好得是硬盘直插电视usb接口，插在安卓机，不管看电视剧还是原盘，总觉得哪里不对劲，清晰度差不多，颜色等就。。。

音：
天猫盒子和小米不说了，不是蓝光盒子！
也不是非常木得木耳，听来，pc古董机，与x9s播放同电影，pc古董机好听很多！比例占30%以上！
安卓机音频噩梦？？？？？？本是吃瓜群众，只会百度xxoo,以下文章是2013年左右，不知道现在得安卓机是否也存在！

噩梦一：
SRC实际上个人觉得最不可思议的是，AudioFlinger为什么要做强制SRC？要知道，ALSA是支持硬件SRC的（早期ALSA标准API本身却不支持，这个设计也是超级傻，具体表现在如果你在Linux下使用某个使用早期ALSA API的音乐播放器，播放和硬件采样率不匹配的音频档案，就会报错，同时期的PulseAudio API反而支持……），可实际上Android4.0后ALSA已经是最新的版本了。现在的Linux通过ALSA驱动做硬件SRC也不会是太大问题，当然音质比较一般（相当于高通，全志等芯片组在44.1KHz音源下的音质）就是了。可是，AudioFlinger为什么自身要做一个强制重采样行为呢？
个人预计，实际上AudioFlinger只是Android早期音频系统API接口的继承和扩展，它遗留了太多由于早期ALSA的不足而提供的“临时解决方案”，Android1.X的时候，ALSA相对现在也是非常的糟糕，google不得已写了个SSRC插件来解决当时ALSA不支持非匹配采样率无法发声的问题。至于Google为什么现在不解决，答案很明显：原来的代码都是临时的无证程序员写的，Android有个叫中子播放器的软件就能提供相对高质量的SSRC ，google没道理写不出来。但是那样对于现在版本的ALSA能力来说简直是多余的行为，还会导致声音延时和性能损失。

噩梦二：
系统资源占用和延迟这两个为什么放到一起说？因为，高延迟意味着系统IO动作多。Google“聪明”地做了一套soundfx系统，给所有音频做预处理，比如频响均衡器（EQ），重采样后对高频进行衰减等，这些接口为开发第三方音频应用提供了方便，却导致Android的音频性能出现了极大地负载和延迟，特别是游戏应用。Android的音频接口有两个，一个是用来播放音乐，这个接口提供了较大的缓冲，延迟也比较大；另一个则是用来做实时事件音效的处理（比如乐器声，效果音等等），将声音读入高速缓存（只能缓存10秒左右），然后进行处理。Google标榜这个为“低延迟”，可实际上因为API对音频做了大量的预处理，导致就算开发人员使用高速缓存接口，出了触屏感应处理外，音频也会有180ms以上的延迟，所以一些所谓的乐器演奏软件或者音乐游戏，基本就是Android劣势的彻底体现，这样的问题也导致Android无法进行音频处理应用。

PulseAudio简介Collabora是一个开源系统解决方案的开发商，对于个人用户是免费开源的（对厂商似乎要收费，所以，Android开发厂商对此没兴趣掏钱）。PulseAudio是和AudioFlinger一样的音频系统API，PulseAudio并不完美，但是并不会有AudioFlinger的那两个致命问题。而且，HP webOS 、N900/Maemo5、N9/MeeGo都采用了PulseAudio作为系统音频API。
PulseAudio能解决的问题：1、不会强制重采样，而是交由驱动来解决，避免了AudioFlinger极度劣质的SSRC。2、不做预处理，极大减少音频延迟和系统开销（高速缓存处理延迟可以降低至20ms，虽然并不算很好，但是对于移动装置和平板来说已经足够）。这看起来很美，不是么？可是为什么没有厂商积极面对呢？实际上，更换Android的音频系统，远远不像换衣服那么简单！

授权移植费用虽然PulseAudio是开源软件，但开源不等于免费，PulseAudio很可能是针对企业收费的。这里会导致一个两头难的问题：大厂商不掏钱就用，可能会吃官司；而用了，会导致一系列连锁反应，这个会在后面介绍。小厂商可以完全不鸟什么商业授权，但是本身的孱弱的开发能力不足以对Android做二次开发。

原有的应用音频相关功能全部报废更换音频系统是个大工程，因为现在Android所有的应用都是基于AudioFlinger的，如果更换为PulseAudio，则现有的应用完全无法在新系统上使用，原有的应用匹配新的音频API可以说是一个浩瀚的工程，而普通用户如果强制在自己的Android装置上安装PulseAudio，则可能要面对的是连音乐没法听，电话都没法打的风险。这样巨大的成本和风险，是厂商和用户都无法承受的。当然，PulseAudio和AudioFlinger可以共存，可共存的代价就是更耗资源更耗电，和更可怕的系统冲突（想象一下两个不同的API同时请求驱动所导致的风险）。

开发成本，有限的应用资源如果真有一个有心的厂家思路广欢乐多，在自己的产品上使用了PulseAudio，那么厂商最少必须重写一套通信应用和音乐播放器。而厂商也会很遗憾地告诉用户，你们在切水果弹小鸟的时候，都不会有声音。想要正常发声，必须得移植大量现有的Linux应用软件，而这些应用软件不说本身代码或者用户体验怎么样，针对台式机和移动装置毕竟是完全的两码事。

但是，这并不是说PulseAudio取代AudioFlinger完全没戏，厂商可以再写一个“AudioFlinger”语法的PulseAudio API兼容现有的应用，虽然会花点时间也有不小风险，这并不算很难。可是，就是没有厂家考虑过。毕竟这方面用户很难以这个为理由把厂家弄上315晚会，厂商也不会有兴趣。所以高通的音频系统再糟糕，如果你打算和高通沟通的话，他也只会认为你需要广告费了而已。

PulseAudio不能解决的问题：高质量音频应用，就必须避免SRC，codec的硬件能力还不足以提供优质的SRC，所以，根据音源改变采样率才是最佳的选择，这点PulseAudio是做不到的。但是ALSA可以，实际上ALSA是可以和Win7一样实时更改采样率的，不过Android和PulseAudio并没有提供这个功能的API，如果真为了音质，这个是应该做到的。综上所述，Android并不是不能做好音频，而是由于google一直在使用错误的方法处理音频，而这个错误已经延续到了现在几乎难以挽回。可是现在不改正，这个巨大的成本还会像滚雪球一样倍增，因为google和开发人员的一时之便，导致现在的Android平板音质连几年前的MP3MP4都不如，这是时代的倒退。

Android音频系统的改进设想和展望（2）不过由于写得太匆忙，没有认真去分析Linux和Android相关的资料，问题也是一大堆。其中，最严重的问题就是我实在太高估Google了，认为现在Android的ALSA驱动是没问题的。可那并不能完全解释AudioFlinger为什么还要继承原来ALSA的问题。做大量的预处理和SRC，这些事情完全可以通过ALSA驱动层来调用硬件完成，而不是写一堆垃圾代码去实现劣质SRC和延迟高达350ms的“高速缓存”（APP的开发便利性不是理由，因为Google完全可以把AudioFlinger写得更简单）。所以，答案就是：Google并没有解决ALSA的问题。Android和ALSA和Linux的ALSA是两回事。

我曾提到ALSA原来并不完善，其中之一就是早期的ALSA API连SRC都无法实现，要播放非匹配采样率的音频只能通过切换采样率和通过PulseAudio等中间层API来解决。而Android内置的ALSA是早期的ALSA版本精简而来，说好听点就是Google修改的版本，实际上就是Google自己移植并去掉ALSA大量API甚至驱动层功能的阉割版本。

阉割的目的是为了减少或者说去掉GPL授权的影响，加重Google在Android源代码控制上的话语权，也能说服不愿意将自己驱动或者修改代码开源的厂商加入到Android的开发上（虽然Android也支持HAL层的私有驱动，但是……现在几乎所有的音频Codec驱动是基于ALSA的）。

虽然Google乐于听到“Android和ALSA和Linux的ALSA是两回事”的说法，并将其内部命名为“TinyALSA”（精简版ALSA）。一般来说，在维持功能的基础上精简代码是好事，可Google对于ALSA的精简，完全可以做为失败案例看待。如果说AudioFlinger是Android音频系统的噩梦，那么，TinyALSA则是Android音频系统的灾难。

　　ALSA同时掌管着Android/Linux的音频硬件驱动和底层API，因此，ALSA对于codec的性能和功能则起着决定性的作用。Google在大量删除ALSA代码的同时，并没有将失去的功能补回来。PulseAudio相对于AudioFlinger的优势就是加强底层驱动的作用，但是Android的TinyALSA则是啥功能都缺：
1、不具备重采样功能（这个待考虑，毕竟硬件支持的）
2、不具备缓存功能
3、无法切换采样率，采样率只能在编译驱动时固定
4、不具备影音相关的重要功能（双声道/多声道切换，AC3 Fliter，AC3解码等等，仿真输出只能靠AudioFlinger转换简单实现，高级实现则需要数字输出到独立的硬件译码器。）

消费者们应该庆幸GoogleTV的艰难前进，否则他们能看到的高清影像也是仅限于视讯的层面上。所以，底层驱动重写才是Android音频系统改造首要的任务。

底层的改造可以说很简单，也可以说很困难，ALSA就有一个叫SALSA（Small ALSA Library）的精简版本，但是驱动层和API的重要功能都还在，要实现低延迟，硬件采样切换和硬件SRC，就必须在驱动中实现。所以，PulseAudio想在Android上使用，首先是要在系统上安装功能和性能都相对完整的ALSA，或者使用更好的底层驱动（如OSS或者非开源的HAL厂商驱动）。

SALSA要在Android上使用并不难，难的不是技术问题，而是接近于政治的授权问题。Google并不乐意在Android里使用GPL授权的代码，去GPL化是Android最大的政治任务，而PulseAudio、SALSA等代码均是以GPL或者LGPL授权的。

实际上，这体现了Google和厂商们的极大矛盾：一方面他们依赖于整个GPL开源体系才能得到Android今天的成就，另一方面他们又想将这个成果占为己有。而实际上除了底层芯片驱动开发商，Google等企业相对于开源小区对Android，实在是九牛一毛，自己的私有代码效果还适得其反。Google自己折腾出来的AudioFlinger和TinyAlsa就是很好的例子。但就算如此，享受着开源带来的成就，Google也无法容忍GPL代码进入Android源里面，一个是因为法律问题，另一个这是为了保护厂商的利益。

就算PulseAudio和SAlsa组合能达到较好的效果，也能保证兼容性的前提下，也无法进入正规的Android体系。现在，有厂商号称解决了Android的SRC问题还申请了专利，个人估计也只是将AudioFlinger重写，让其忽略SRC处理，并不能说没有了AudioFlinger的SRC，音质就能有所改善。而且，作为厂商自主的改进，谋求利益的目标也不会让其将修改提交至Android主代码库或者分享。厂商修改了代码，却在自己的产品上用了音质不佳的处理器，那根本问题还是无法解决。而某个堆料的Android随身听号称自带播放器直接使用底层驱动。但是，TinyALSA底层驱动功能有限，而应用层依然是AudioFlinger在掌控系统，问题也无法解决。如果不能正常播放高清音频，那么，采用的DAC芯片就算有32bi192KHz的译码能力，它还是会SRC到44KHz来播放，这是极大的浪费。

Android要改善音质，到底该怎么办？对于开源小区和智能装置开发商来说，可以借助自己的开发能力或者第三方的API和驱动，绕过Android的API，从而改善延迟和SRC问题，但是不要指望能被Google接受。对于硬件厂商，他们首先要保证芯片的数字音频不能有差错，codec或者DAC要运用合理，电路设计也不能出现低级失误。而对于Google来说，必须把现在的垃圾代码全部砍掉，重来。这是最彻底，也是最好的办法。但是，现在的Google完全不具备这样的开发能力。高质量音频应用，离Android还很遥远，离Google更遥远。

本帖最后由 音画很深 于 2018-4-5 11:15 编辑
用过pc转sdr，那颜色叫一个舒服啊~口水一地
贵得安卓机也许更好？还可以音画分离，某旗舰机拆机图一看...... 或者我们公平点，这个旗舰机真的值这个价？价格也那么乱~~算了~~
补充：推荐碟机得勿扰！我穷！

聊正事，pc还是略懂，很多年没接触了，花了1-2天研究了下，选取了品牌以及价格最合适得！以下全精心挑选，2选1！
十铨超频条8g（584元）+酷冷铜牌500w（289元）+i5 7500盒装（1350元）+微星小板B250M 迫击炮（669元）+卧式机箱（300元）=3240元
十铨超频条8g（584元）+酷冷铜牌500w（289元）+i3 8100盒装（899元） +微星小板B360M 迫击炮（750元）+卧式机箱（300元）=2822元

音画分离：待定
内存条：2根4g太贵，以后便宜了直接在加根8g吧。
cpu：以上配置全来自2手东，买个安心，还是盒装

本帖最后由 音画很深 于 2018-4-5 06:18 编辑
问题：
1.是否选i3 8100 更加性价比？据说与i5 7500 性能几乎一样。由于之前i3 8100 需要用到z370主板（太贵），现在已出B360M
2.我是严重强迫症，关于噪音问题如何解决？自己古董机，cpu风扇比较吵，其次显卡风扇。有没比较静音cpu风扇推荐，记得几年前用得，越是压得住u温度风扇，风声越大！
3.关于显卡，gt1030是否可行？以下copy了很多言论，关于madvr算法，用到还不错得程度，什么显卡足够？
本帖最后由 doufunao 于 2018-2-8 10:38 编辑
麻烦请教各位chher。
cpu:g4500，8G内存，显卡是gt1030 oc 2G版本，都说gt1030播放4k hevc@10bit毫无压力，但我尝试通过pot+lav解码+madvr滤镜的组合方式，还是pot自带的解码器或者mpc-hc的自带的解码器，播放4k hevc@10bit的电影不是特别流畅，影片的信息如下。
通过win10的任务管理器可以看出,cpu占用不到30%，甚至不到20%，但是gpu几乎是99%，其中video decode也就是解码部分占用很少，90%以上是3d占用了，导致gpu使用率一直持续在99%的状态，请问各位chher有好的解决方案么？先谢过了

BluRay.2160p.x265.10bit.4Audio

RUNTiME.........: 1:48 (h:m)

SUBTiTLES.......: chs/cht/eng

FilE SiZE.......: 28.3 GiB

ViDEO BiTRATE...: 29.9 Mbps x265 2.6+24 @ crf - 17 @ preset - slower

RESOLUTiON......: 3840 x 1632

ASPECT RATiO....: 2.353 : 1

FRAME RATE......: 23.976 fps

AUDiO 1.........: English    DTS-X     7.1  4391kbps

AUDiO 2.........: English    AC3       5.1  640kbps

AUDiO 3.........: Mandarin   TrueHD    5.1  1673kbps

AUDiO 4.........: Mandarin   AC3       5.1  448kbps

[color=rgb(169, 0, 0) !important]复制代码

音画很深 发表于 2018-4-5 01:52
问题：
1.，是否选i3 8100 更加合适？据说与i5 7500 性能几乎一样。由于之前i3 8100 需要用到z370主板（ ...

如果考虑1080p软解的化那就考虑i5，否则i3还是i5随便你。
1030的化我是不推荐的，不过也不代表不行，不过硬解方式建议更改成D3D11，系统必须win 8或者以上

Bsmms 发表于 2018-4-5 02:02
如果考虑1080p软解的化那就考虑i5，否则i3还是i5随便你。
1030的化我是不推荐的，不过也不代表不行，不 ...

看看人家 不管是自己写的还是搬运的 有质量有内容

为什么要转sdr hdr直出不行吗

不满意？关键你舍得出多少钱，对比过高端蓝光碟机再说

1978710 发表于 2018-4-5 10:36
为什么要转sdr hdr直出不行吗

LZ的电视机不支持HDR，当然要转SDR啊

感觉很专业啊，小白看的头大

Bsmms 发表于 2018-4-5 02:02
如果考虑1080p软解的化那就考虑i5，否则i3还是i5随便你。
1030的化我是不推荐的，不过也不代表不行，不 ...

如果加载BlueskyFRC后出现banding问题，那么就是BlueskyFRC问题

Bsmms 发表于 2018-4-5 15:49
LZ的电视机不支持HDR，当然要转SDR啊

只要是转换了，效果肯定会直线下降。
除非没有片源，必须得转换，否则都不如直接找2K蓝光原版。

chncwk 发表于 2018-4-5 18:38
只要是转换了，效果肯定会直线下降。
除非没有片源，必须得转换，否则都不如直接找2K蓝光原版。

转了肯定不如原来的4K HDR
但是不转更不行

既然UHD破解已经呈势如破竹之态，老实说用HTPC的Pot+LAV+madVR就不是很必要啦。之前是因为木有4K片源，而点对点的特性决定了4K平板在播放2K视频时画质会有较大的劣化现象。目测LZ的情况又是比较特殊，电视机虽然是4K的但却不支持HDR，这个确实就很蛋疼鸟！
俺的建议是加载madVR时，可以把image downscaling和image upscaling都设置为直通，也就是选择DXVA2，这两个缩放选项是madVR最吃资源的，既然你放的都是UHD 4k视频了，那么何必再去强求madVR的高端缩放算法呢，当然还有一些吃资源的比如平滑或插帧也不要去开，这样就只是利用madVR的HDR转化功能问题就不会太大鸟！
PS: 就你那HTPC的配置目测也不会有太好的音质，小箱子电磁干扰太大不可能出好声音的，不如给你的x9s盒子加个四五百的线性电源试试先。

我这边是DELL笔记本XPS 13, I7-6500, 8G, 折腾了好久各种软件播放器，无法流畅播放4K，好像6代就是不行。目前只能是看1080, 还想回头买X9S呢，但是此贴来看，它音画还是不如PC啊？？

本帖最后由 Bsmms 于 2018-4-5 21:15 编辑

Old_D9 发表于 2018-4-5 20:33
既然UHD破解已经呈势如破竹之态，老实说用HTPC的Pot+LAV+madVR就不是很必要啦。之前是因为木有4K片源，而点 ...

图像缩放算法没有直通这说法，你说的DXVA说到底就是不使用MADVR内置的缩放算法而转用显卡内置的缩放算法。
除去chroma upscaling外，如果LZ的设备是4K的化那么看4K分辨率视频，image downscaling/upscaling根本不会生效。那么何来吃资源一说？
顺便很多人会忽视的一个问题，那就是chroma upscaling部分，配置不行的用户请打开MADVR设置界面找到trade quailty for performance设置选项，找到use DXVA chroma upscaling when doing native DXVA decoding选项并勾选，这样就可以chroma upscaling也使用DXVA了。
况且你说的问题，MADVR下做个profile就能解决，针对不同的片源调用不同的参数设置。这种方法也是我一直以来推荐的方法，这也是MADVR的优势之一根本没必要一套参数吃遍所有。算法的高低从画面影响最小的那块开始降，影响大的地方劲量保证高。

本帖最后由 Bsmms 于 2018-4-5 20:57 编辑

本叔2017 发表于 2018-4-5 20:33
我这边是DELL笔记本XPS 13, I7-6500, 8G, 折腾了好久各种软件播放器，无法流畅播放4K，好像6代就是不行。目 ...

现在配置就乖乖DXVA就行，就算能软解那功耗也是高的吓人
本身目前设备没有人会有什么8K设备，所以不存在所谓的Luma upscaling后带来的问题
那么也就是只存在chroma upscaling以及luma downscaling问题，而这两者的影响说句真的真的微乎其微。
所以设计这两个参数的算法，一般情况下如果硬件不够，首先从这两个算法下手，然后再去考虑其它方面。

Bsmms 发表于 2018-4-5 20:55
现在配置就乖乖DXVA就行，就算能软解那功耗也是高的吓人
本身目前设备没有人会有什么8K设备，所以不存 ...

你回复错了人了吧？

本帖最后由 Bsmms 于 2018-4-5 21:17 编辑

本叔2017 发表于 2018-4-5 21:14
你回复错了人了吧？

没有回错，你的i7软解4K本身就困难
你这种时候就应该乖乖DXVA
如果DXVA成功不可能不流畅的