SqueezeWave

时间：2020.1.20
单位：UC Berkeley

abstract

（1）vocoder问题是需要condition on previous information，因此难以并行化；
（2）WaveGlow用flow-based代替自回归，因此可以并行化，但是难以应用到实时的系统
本文是基于WaveGlow的改进，SqueezeWave–light vocoder，可以生成相似的语音质量，但是可以在61x–214x MAC上跑。

introduction

之前的语音合成、翻译等网络都是在云端计算，然后把结果传到本地。然而，部署在本地设备的必要性：
（1）手机移动设备的性能大幅改进，如果在移动设备上部署，会大大降低云端的计算消耗；（2）数据传到云端，会有数据安全的隐患；
（3)低延时的用户需求，避免受到网络的干扰。

非自回归的WaveGlow可以在一个前传生成很多样本，但是生成1s 22KHz的语音需要229G MAC的计算，可以在NVIDIA V100上实现实时，但是并不能在移动端设备上应用。
本文是对WaveGlow的网络结构进行重新设计，从而大大减少计算量。

2. COMPUTATIONAL COMPLEXITY OF WAVEGLOW

WaveGlow双向操作，将audio映射到高斯分布latent embedding，然后可以从latent embedding恢复为audio。mel_spec----audio

3 SQUEEZEWAVE

3.1 Reshaping audio waveforms

WaveGlow输入audio统一规整到$L\times C_g=$ 20008，mel的维度6380
（1）对audio进行一维卷积，卷积的复杂度和L线性相关；
（2）audio和mel的长度不匹配，因此mel送入网络前先进行上采样（插值方式），然后cond_layer的卷积，因而造成很大的计算冗余。
（3）WN计算的输入是channel=8,在函数内增加到channel=128/256，更多的channel给到模型更大的拟合力，但是输出端直接将channel压缩到8，以匹配输出。急剧的压缩造成information bottleneck，而且会造成中间层向量的信息损失。

SqueezeWave
（1）节省1d卷积和cond_layer的计算量：
将audio reshape到更大的channel和更小的时间轴，尝试了两组配置
$L\times C_g=64\times 256$：时间轴和mel_spec一致，因此不需要上采样；

$L\times C_g=128\times 128$：mel_spec先cond_layer卷积，再上采样；

3.2 Depthwise convolutions

对于输入$C_{in}\times L_{in}$，输出$C_{out}\times L_{out}$ （C是channel, L是时间域）
常规卷积
kernel_size：$K\times C_{in}\times C_{out}$，因此消耗
$K\times C_{in}\times C_{out}\times L_{out}$的MACS。计算$L_{out}$次

==depthwise separable ==
常规应该是$K\times C_{in}\times C_{out}\times L_{out}$,本题中$L_{in}=L_{out}$,
第一步：depthwise convolution
C_out=1,$L_{out}=L_{in}$，因此消耗$K\times C_{in}\times L_{in}$的MACS
第二步：pointwise convolution
K=1，消耗$C_{in}\times C_{out}\times L_{in}$

对于K=3,C_out=256,对于in_layer的计算量减少3x

3.3 Other improvements

（1）因为时间域很短，因此不需要空洞卷积增大感知野，这样对硬件也是更友好的；
（2）WaveGlow的res_skip_layer输出分成两个分支，但是两个分支的拓扑结构非常相似，因此假设这个划分是不必要的，所以在SqueezeWave中取消划分，并且将channel减少一半。

4. EXPERIMENTS

数据集 LJSpeech，13100条语音，分成训练集和测试集

在MBP和树莓派 3b+上测试，考虑语音质量和合成效率
合成效率参考指标
（1）生成1s语音需要的MACS
（2）模型参数量
（3）1s内合成的样本数量

语音质量差不多（亚马逊众包测试），但是SqueezeWave有背景噪声，需要额外的噪声去除