为什么要在 WSL 上运行呢？因为今天在虚拟机里测试的时候偶然发现，云音乐的 Linux 客户端无视了大部分播放限制，比起 Windows 客户端要不知高到哪里去了。——这是一条新的路，不是俗套的本地代理。我一直是挂着代理用云音乐，但是毕竟代理有速度（勉强能接受）和隐私两个问题；还有一个无法下载封面的副作用。
发现了这个有意思的东西之后，我首先测试这是不是因为网络连接方式的不同导致的。如果两个客户端的内部逻辑是一样的，那么在不在虚拟机内应该不会影响可播放与否。除此之外就可能是客户端的逻辑不同了。不管是哪一种，都需要 WSL 来测试。WSL 和主机是共享端口和硬件的，所以不存在虚拟硬件，也不存在桥接，在服务器看来和其宿主是一样的。正好作为实验组。
为了验证猜想，同时也是解决代理带来的问题，我决定在 WSL 上运行云音乐客户端。
摸索试验花了五个小时（包括本文开始写作之后），大概有了一套理论，不过仍然有暗坑。使用注意。
首先，客户端在虚拟机（Ubuntu 17.10）里运行，一切正常。标称的最低支持是 Ubuntu 14.04。
开始进入 WSL。由于 WSL 不带图形界面，所以我们装一个。大体过程如这篇教程。不过注意 xfce4-terminal 要在 xfce4 之后安装，而且建议不要用那个下拉的终端模拟器（看个人，我是因为习惯从任何目录直接开终端，而那玩意儿不支持）。还有就是，和教程不同的，如果用的是较新的 WSL，那么 D-Bus 就不用修了。
装完之后安装客户端。一运行，怎么什么反应都没有？开控制台，启动 netease-cloud-music，看输出。结果发现了异常的原因是这样一个错误（类似这个）：
Assertion ‘pthread_mutex_unlock(&m->mutex) == 0’ failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.
开始的时候我没注意看。客户端不是还依赖 VLC 嘛，所以我就打开了 VLC，结果同样无法启动，报告的是类似的错误。想了想应该是 PulseAudio 的问题。（以前在 WSL 上试过 ALSA 结果根本不能用……）找。顺着找到的东西继续翻，首先原因是这个，楼下有人提了简单的 workaround。不过我就没这个条件重新编译了，于是继续翻，果然有人做好了。于是添加 PPA 并重新安装 libpulse0（自然也要重新安装 xfce 和 netease-cloud-music）。
还有一些说明。不过里面的内容过时了。PulseAudio 的 Windows community port 版本才是1.1，太老了。自动安装脚本所安装的是版本6，也太老了——而且没法正常运行（路径问题）。
那怎么办呢？PulseAudio 的 FAQ 指出了一种方法，用 Cygwin 的组件。自然，作为一个合格的开发人员，Cygwin 肯定是有的。可以见到，此处的版本是11.1，比上面两个要新得多。安装之后，照着配置。稍微不同的是这里不使用 default-server 配置项，而是在 WSL 的 .bashrc 中加入：
export PULSE_SERVER=tcp:localhost
但是运行又出了问题，报告“failed to create secure directory”。解决方法也是有的。不过为什么不更自动化一点呢？在 Cygwin 的 .bashrc 中加入：
export PULSE_STATE_PATH=$HOME/.config/state
export PULSE_RUNTIME_PATH=$HOME/.config/runtime
这样就能正常运行 pulseaudio 这个服务端了。启动之后，在 VLC 和云音乐客户端就能听到声音了。
不过可能你也注意到了，输出一直很糟糕。我们接着来解决播放的问题。
首先使用 -vvv 选项启动 pauseaudio。从输出中可以看到出现大量这样的消息：
D: [waveout] sink-input.c: Requesting rewind due to uncorking
D: [(null)] module-suspend-on-idle.c: Sink output becomes busy, resuming.
D: [waveout] protocol-native.c: Requesting rewind due to end of underrun. （※这一条会出现多次）
D: [waveout] sink-input.c: Requesting rewind due to corking
D: [(null)] module-suspend-on-idle.c: Sink output becomes idle, timeout in 5 seconds.
D: [waveout] protocol-native.c: Requesting rewind due to end of underrun.
会不会是 waveout 模块的锅呢？这个配置已经得到了修正。那只能猜想是 corking（自动降低音量）的问题了。我尝试取消加载 modue-role-cork，感觉上好一点了——至少只在开头的地方会出现噪音。搜索了一下之后我认为这应该是 VLC 播放对齐（aligning）的问题，比如这个讨论。
在折腾的过程中，我发现云音乐客户端有很大概率无法正常启动，进程挂在那里，窗口不出现。虽然尝试解决了一下，但是仍然十分玄学。随着后面 PulseAudio 的调整，启动成功率似乎高一点了。
为了减少它的烦人程度，不用每次都手动终止进程（ps -ef | grep xxx 然后 kill yyy），建议安装 xfce4-taskmanager。
对 PulseAudio 配置文件的修改：
在 default.pa 中——
在“Network access”节增加：
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1 auth-anonymous=1
取消加载 module-role-cork 模块（我们也不需要）：
#load-module module-role-cork
在 daemon.conf 中——
设置启动为守护进程：
deamonize = yes
注意，一旦成为了守护进程，就看不到输出，就无法调试了。不过好处是启动后即使关闭了 Cygwin Bash，pulseaudio 仍然在运行。
修改 exit-idle-time，配合守护进程（要不过一段时间就自动退出了）：
exit-idle-time = -1
仍然有的问题：
- 8-bit 音乐，比如这种，无法输出，全是卡顿。从调试信息中可以见到 CEF 除了启动了标准的声音客户端，系统还分配了一个“尖峰检测”客户端。我猜是这个平滑波形的问题。
- 类似地，根据乐曲开头的规则程度，会有不同时长的垃圾信号。这个接近玄学。
- 会变调。频繁卡顿过后有一段时间音调比原曲要高一点（大约3度），然后过一段时间就降回来了。这可能还是采样的缓冲问题。
总之就要接受这样一个过程：
|-- t1 ->|-- t2 -->|-- t3 (~2s) -->|-- t4 -->|
| 卡顿 | 音调异常 | 降调 | 正常播放 |
还有一点奇怪的是，尽管云音乐用了 VLC 作为后端，但是 VLC 在进行转到指定时间（seek）结束的时候还会像开头那样来一段卡顿，严重的甚至会影响视频解码（怎么回事？），而云音乐不会。不知怎么解释。
好像禁止了 module-role-cork 还是会出问题……虽说这个模块是调整麦克风输入的（检测到输入较大，如讲话时，降低其他应用程序的音量），其实跟输出波形也应该么关系（不带反馈），但还是不知道怎么回事。同一首几分钟的歌，有时播放了几秒就稳定下来开始降调了，有时候播完了都是卡顿。唉，玄学。只能说 Linux 的（普通）用户体验还是太差太差了，不要说什么“hackable”，我不想投入，也没精力投入在这些根本不是目标、不值得操心的事情上。而 Linux 下的应用软件，就是能工作了算是走运，不能工作，假如找到了某种方案，必须附一句 YRMV。而且还真的就是 YRMV。心疼巴塞罗那的市政局工作人员。