音频常识, 区块链, BBR

人的听觉范围

图上的上限是到16KHz，但并不是说16KHz以上听不到了，因为高频听力随着年龄增长而减弱直到丧失，一般来说25岁以上的人，在16KHz以上的听力几乎完全丧失，而10几岁的人，完全可以听到19KHz左右的声音（这就是有一种传说中的蚊音手机铃声神马的，在中学生间流传很广，据说老师听不到只有学生能听到，也是基于这个道理）。

各种编解码算法比较

http://www.rosoo.net/a/201012/10600.html

speech codec (G.711, G.723, G.726, G.729, iLBC)

这个帖子比较了ITU提出的G系列的各种语音编解码方案。

上图是各种音频编解码框架的比较图。

其中narrowband是指频率在4kHz以下的声音信号，一般情况下，人的说话声就位于这个频率范围内，因此又被称为“语音”。

allband是指频率在24kHz以下的声音信号。这也是人耳所能听到的频率范围。这个范围内的声音统称“音频”。

介于两者之间的，被称为wideband。

早年上网用的Modem，之所以速度上限仅为56kbs，其实主要是因为它占用的是普通电话信道，而56kbs对于电话来说，已经是绰绰有余了。

声道一般表示为X.Y的形式，其中X为高音音箱的个数，Y为低音音箱的个数。比如常见的2.1声道，就是左音箱、右音箱+低音音箱（俗称低音炮）。

一般来说，Y的值为0或1。而X的值，有以下几种：

1.X=1。单声道

2.X=2。左、右。

3.X=4。前左、前右，后左、后右。

4.X=5。前左、前右，后左、后右、中置。

5.X=7。前左、前右，后左、后右、中置、中左、中右。

上图是TI TAS5731M的2.1声道应用图。

其中的SE，表示单端连接模式（Single-End），和桥接式负载 BTL（Bridge-Tied-Load）相对应。后者在同等供电电压和负载的情况下，可以提供4倍于SE的输出功率，并具有良好的低频响应，常用于连接低音音箱。

这是TI TAS5731M数字音频的处理流程，其中上两路是高音声道，最下面一路是低音声道。

亦称I2S。Inter—IC Sound总线是飞利浦公司为数字音频设备之间的音频数据传输而制定的一种总线标准，该总线专责于音频设备之间的数据传输，广泛应用于各种多媒体系统。

I2S总线由4根线组成：

1.SDATA。数据线，根据方向的不同，又分为SDO和SDI。一根数据线可以传输两个声道的数据，但对于当前越来越多的声道来说，这显然就不够用了。因此目前的MCU设计中，多数都集成了更多的SDO线。这些SDO线共享各种时钟线。多SDO线的DMA传输，一般采用时分复用的交错数据流的方式来设置。

2.LRCK，(也称WS)。帧时钟，用于切换左右声道的数据。LRCK为“1”表示正在传输的是右声道的数据，为“0”则表示正在传输的是左声道的数据。LRCK的频率等于采样频率。

3.SCLK，也叫位时钟（BCLK）。1个脉冲对应数字音频的每一位数据。SCLK的频率=2×采样频率×采样位数。

4.MCLK，称为主时钟，也叫系统时钟（Sys Clock），是采样频率的256倍或384倍。它可以使系统间能够更好地同步。

I2S总线的性能主要由以下指标决定：

1.采样频率。根据上面对narrowband、wideband、allband的讨论，以及采样定理可知，采样频率最低为8kHz，超过48kHz可以算是allband。

2.采样位数。越大越好。目前数字功放（如TI TAS5731M）已经可以支持24bit和32bit，但wifi芯片基本还是16bit的。

I2S总线的时序标准分为三种：

1.I2S。

2.Left-Justified

3.Right-Justified

I2S总线在硬件测试时，可播放1KHz正弦波的wav文件。这个wav文件的频率，在人的声觉最敏感的范围（1KHz~4KHz）内，同时也便于示波器观察模拟端的输出信号。

文件后缀名与编码格式

文件后缀名	音频编码（空表示编码格式和文件后缀名一致）	视频编码（空表示该格式没有视频数据）
.aac .ac3 .ape .mp2 .mp3 .flac .wma
.au	pcm_s16be
.wav	pcm_s16le pcm_float
.ogg	vorbis
.m4a	mpeg4 aac
.3gp	mpeg4	amr_nb
.3g2	mpeg4	mpeg4 aac
.asf	msmpeg4	mp3
.mov	mpeg4_qt	mpeg4 aac_qt
.rm	rv10	ac3
.vob	mpeg2	ac3
.wmv	wmv	wma

常用格式中的.avi .mp4，由于支持的编码格式众多，且没有主要的使用格式，故不列出。

Pre-emphasis,预加重。与之对应的是De-emphasis去加重。是一项关于噪声整形的技术。

开源音频编解码包

1.Speex

http://speex.org/

一个老项目，教程多，但官方已经放弃，转而推荐Opus。

2.Opus

http://opus-codec.org/

最近的一个新项目，基于IETF RFC 6716（2012.9）。由于比较新，教程很少。

3.G.726等一系列算法代码

http://www.itu.int/rec/T-REC-G.191-201003-I/en

ITU官网上的工具包，包含了G.711和G.726算法。

比特币闻名已久，大概2009年时，我就听说过，然而一直没有研究它的原理。直到最近比特币大火，方才有所研究。不过这个东西，不太合我的研究兴趣，所以也就简单写一些吧。

上图是区块链的结构图。它是由若干个Block链接而成的单向链表。

Block的生成

以比特币为例，Block由特殊算法计算生成。每个Block包含一定数量的比特币。为了得到比特币，人们就需要计算，这个行为被称为“挖矿”。

“挖矿”得到的Block需要添加到现有Block chain的末端。这实际上导致了以下问题：

1.同一时间只有一个Block能够添加到Block chain。这导致比特币的交易速度不可能很快。这也是一些新的区块链协议所要改进的方向。

2.所有的历史交易记录都保存在Block chain中。比如可用以下网址查询历史记录：

https://blockchain.info/zh-cn/block-height/254642

可以想象随着交易的进行，这个链会越来越大。由于每个钱包都有特定的秘钥，虽然我们不能直接知道它的主人，但是通过对历史数据的分析，还是很有可能找到蛛丝马迹的。因此，一些山寨币开始使用更高端的加密算法，提供更好的匿名性。

比特币的交易

Block的绝大多数空间都用于保存交易记录。因此，矿工除了挖出新Block之外，还要负责将新的交易数据写进Block，这个行为被称为“打包”。

打包可以收取手续费，以获得更高的打包优先级。在中本聪的设想中，这是在挖矿越来越难的时候，保证比特币运作的一种方式。

区块链的安全性

1.块中有用于检验数据完整性的字段，这个完整性不仅包括本Block的完整性，还包括之前Block数据的完整性。因此，篡改者必须对被修改的Block之后的所有Block都进行修改才行。

2.修改需要得到多数结点确认才可以生效。理论来说，如果有组织掌握全网51%的算力，那么他们就可以为所欲为了。

各种数字货币

虽然，比特币一直是区块链技术的主角，但毕竟创建的年代已经久远，技术局限较多。以太坊不仅是数字货币，而且还是很多其它数字货币的发行平台，提供了一系列完善的数字货币发行和流通服务，当然服务的费用需要通过购买以太坊币来支付。目前，很多山寨币都是利用以太坊进行发布的。

https://www.ethereum.org/

以太坊的API是一个叫做Solidity的项目。代码会被编译运行在所谓的Ethereum Virtual Machine (EVM)上。

Solidity文档：

https://solidity.readthedocs.io/

https://zhuanlan.zhihu.com/p/32796998

10分钟搞定ICO

• 去中心化（不需要统一管理）

• 可追溯性（一人一锁，谁没锁找谁）

• 不可篡改性（这个似乎没办法）

http://tech.ifeng.com/c/82IsX1VJuPq

小区业主自制66把锁门禁系统 网友：区块链技术实体化

Bottleneck Bandwidth and Round-trip propagation time是Google于2016年10月提出的TCP拥塞控制算法，其相关代码目前已经加入Linux内核中。

经典的拥塞控制算法设计于1980年代，当时将丢包作为拥塞的信号，这是符合当时落后的实际情况的。

但是网络丢包存在两种情况：第一为拥塞丢包，第二为错误丢包。因此丢包通常并不等同于拥塞。

随着带宽的增加，第一类丢包已经大为减少。目前广域网普遍属于高带宽，高延迟的情况。这种情况术语叫做长肥管道（long-fat pipe，即延迟高、带宽大的链路）。

BBR就是针对长肥管道而设计的新式算法。

http://netdevconf.org/1.2/slides/oct5/04_Making_Linux_TCP_Fast_netdev_1.2_final.pdf

Making Linux TCP Fast

https://www.zhihu.com/question/53559433

Linux Kernel 4.9 中的BBR算法与之前的TCP拥塞控制相比有什么优势？

https://zhuanlan.zhihu.com/p/144273871

TCP拥塞控制详解

http://blog.csdn.net/dog250/article/details/52895080

Google’s BBR拥塞控制算法模型解析

https://zhuanlan.zhihu.com/p/24431669

BBR是个什么鬼？-1 带宽与RTT探测

https://zhuanlan.zhihu.com/p/26321951

BBR是个什么鬼？-2 外皮后的真相

https://mp.weixin.qq.com/s/NWNMfykpJQ-LD9oV1X6zTw

基于bbr拥塞控制的云盘提速实践

https://mp.weixin.qq.com/s/P3zAW3lxj8aowXtxXCOwqA

Google BBR拥塞控制算法背后的数学解释