eGuideDog Linux 26开发日志

2026-3-26

Mate桌面由于欠维护，已从LTS版本中移除。因此，eGuideDog Linux 26将选择官方默认的Gnome作为开发基础。

Daily Build下载地址：https://cdimages.ubuntu.com/daily-live/current/

安装指南：https://cto.eguidedog.net/node/1456

2026-3-27

speech-dispatch已经更新到0.12，原来Ekho使用的版本是0.11，虽然经修复后可以使用，但还是考虑合并最新代码（@todo 1）。

piper依赖torch，安装依赖很多也很大，暂时因为以下错误失败：“RROR: Could not install packages due to an OSError: [Errno 122] 超出磁盘配额”

不知道为什么，考虑重新安装虚拟机，分配多一些磁盘空间（事实上目前还有10G剩余的）。

2026-3-30

本来想通过apt安装pytorch的，发现torch不在apt包里。

已把上游最新代码合并到speechd，过程顺利：

$ git remote add upstream https://github.com/brailcom/speechd.git
$ git fetch upstream
$ git merge upstream/master
修复冲突
$ git commit -a -m 'merge from upstream'
$ git push origin master // orgin master可不要

speechd和ibusreader在Ubuntu 24.04下也不能正常使用，先在24下调试通过再解决26的问题。

在AI帮助下修复了一个speechd的崩溃问题。

dog restart后似乎不能正常启用orca，有时要再按SUPER+ALT+s

ibusreader不能正常使用。调试ibus步骤如下：

1. export G_MESSAGES_DEBUG=all
2. 把系统的/usr/bin/ibus-daemon改名，让其不自动执行重启
3. kill 然后重启进程/usr/lib/ibus/ibus-engine-libpinyin --ibus
4. 此后，屏幕上就能看到g_message的消息了

可以看到ibusreader已经调用了spd_speak了，但没有声音。如果把屏幕阅读器关闭了，则ibusreader反而有声音，后来不知道怎么开关orca之后ibusreader就能读出来的。看起来问题是对当前开关状态的检测。

Ubuntu旧版的ibus-reader基于ibus-libpinyin-1.12.4，debian则基于1.15.2，ibus-libpinyin最新版本为1.16.5。先升级到最新版再调试：

$ git remote add upstream https://github.com/libpinyin/ibus-libpinyin.git
$ git fetch upstream
$ git merge upstream/main
修复冲突
$ git commit -a -m 'merge from upstream'
$ git push

升级后无法安装，报如下错误，这可能是当初Ubuntu保留旧版的原因：

Package dependency requirement 'libpinyin >= 2.9.92' could not be satisfied.
Package 'libpinyin' has version '2.8.1', required version is '>= 2.9.92'

Ubuntu 26.04的libpinyin是最新stable版的2.10.3。因此，我们在Ubuntu 24.04里也尝试从源代码安装最新版的libpinyin(2.11.91)。最新版ibusreader在Ubuntu 24.04下使用正常，已更新dog并发布。

下一步是在Ubuntu 26.04下调试Ekho、speech-dispatcher、ibusreader、piper。

2026-3-31

在Ubuntu 26.04上安裝了最新版ibusreader（修復了一個依賴問題），但没有声音。可能应该先让Ekho、speech-dispatcher正常工作。发现新版ibusreader可以切换简繁体，挺方便的。

2026-4-1

新版Ekho在speech-dispatcher上安装后无法启动Ekho，sd_ekho进程存在几秒后就变成了sd_espeak_ng。如果手动启动sd_ekho，会有如下情况：

$ /usr/libexec/speech-dispatcher-modules/sd_ekho /home/hgneng/.config/speech-dispatcher/modules/ekho.conf
Wed Apr  1 15:11:14 2026 [169841]: Configuration (pre) has been read from "/home/hgneng/.config/speech-dispatcher/modules/ekho.conf"

ERROR: Server did not start with INIT
Wed Apr  1 15:11:17 2026 [850126]: module_close
Wed Apr  1 15:11:17 2026 [850153]: speak_queue Joining play thread.
段错误                  （核心已转储） /usr/libexec/speech-dispatcher-modules/sd_ekho /home/hgneng/.config/speech-dispatcher/modules/ekho.conf

如果在Ubuntu24则没有段错误。很神奇的是，竟然变成了一个可与用户交互的程序，可以在屏幕输入INIT，结果如下：

$ /usr/libexec/speech-dispatcher-modules/sd_ekho /home/hgneng/.config/speech-dispatcher/modules/ekho.conf
Wed Apr  1 15:30:55 2026 [986560]: Configuration (pre) has been read from "/home/hgneng/.config/speech-dispatcher/modules/ekho.conf"
INIT
Wed Apr  1 15:31:28 2026 [70628]: module_init begin
current dir: /home/hgneng/ekho-11.0
EKHO_DATA_PATH: /usr/local/share/ekho-data
EkhoImpl::init
getPcmFromPiperServer: path=/tmp/ekho1.wav
Fail to open /tmp/ekho1.wav
getPcmFromPiperServer: readPcmFromAudioFile size=0
Wed Apr  1 15:31:28 2026 [103436]: speak_queue Creating new thread for stop or pause.
Wed Apr  1 15:31:28 2026 [103634]: speak_queue Creating new thread for playback.
Wed Apr  1 15:31:28 2026 [103737]: module_init end
299-ekho initialized successfully.
299 OK LOADED SUCCESSFULLY
Wed Apr  1 15:31:28 2026 [103785]: speak_queue Playback thread starting.......
Wed Apr  1 15:31:28 2026 [103806]: speak_queue Stop or pause thread starting.......

尝试配置/etc/speech-dispatcher/speech.conf打开日至，但是/var/log/speech-dispatcher/里一直是空的。同样的配置方法在Ubuntu24里是可以产生日至的。

经调查，Ubuntu26开始/var/log有更严格的权限，进程权限更严格，要对log、speech-dispatcher都添加足够的权限才能写入。日至默认写到/run/user/1000/speech-dispatcher/log，可以认为这把用户的日至分隔开来，更安全。

如果暂时禁用enablePiper()，则sd_ekho不会被杀掉。从speech-dispatcher的日至看，似乎是enablePiper尝试连接没有启动的piper进程时返回了一些异常信息扰乱了和speech-dispatcher的交互协议。之后，重新在orca -s里设置ekho为默认语音就可以了。ibusreader也正常工作了。

修复语音后dog restart重启speech-dispatcher。然后运行spd-say 123确认语音配置正确。

下一步下载beta版，调试piper。部分beta已经提供下载，但AMD芯片的桌面版好像还没有提供：https://cdimages.ubuntu.com/releases/26.04/beta/

搜了一下，发现AMD的版本在一个更正式的页面里提供下载：https://releases.ubuntu.com/26.04/

2026-4-2

从清华的镜像下载更快：https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/26.04/

可惜beta版安装失败了。明天再试试新的daily build版本。

2026-4-3

新的daily build已安装成功。由于忘记保存，开发日至丢失了。之前应该是做到成功安装了PyTorch（原因应该是/tmp挂在到了比较小的内存空间，不够用）。

2026-4-7

speech-api在Ubuntu26上文档模块出现编译错误，待解决。

已在代码上实现使用piper朗读英语，待测试。

2026-4-8

已解决Ekho在Ubuntu26上的安装问题，通过piper读英语也通过测试了。piper需要的内存比较多，在主机上看到占用超过1G物理内存和6.5G虚拟内存（并非swap），但因为主机共16G内存，响应很及时。在4G内存的虚拟机上感受到明显的延迟。迟些试试分配6G内存给虚拟机。

Ubuntu26上Orca的语音设置没有Ekho可选，一直都是espeak的声音。sd_ekho启动几秒后会被替换成espeak，待调查。

Ubuntu 4月16日会有candidate版发布，4月23日会发布正式版。

2026-4-9

感谢“蓦然回首”反馈实时天气问题。更新了天气软件接口，发布3.0版本。

更新了Ekho 26个字母的音频文件，修复了采样率不一致的问题。

在Ubuntu26里，spd-conf的设置似乎不生效（Ubuntu24上spd-conf不能运行），spd-say一直调用espeak的声音。

虚拟机内，piper的响应有点慢，似乎是CUP问题，而不是内存问题，可能没有办法解决。

明天继续调查Ubuntu26里speech-dispatcher无法调用Ekho的问题。

2026-4-10

piper中文占用物理内存约1G，是英文的10倍左右。合成速度也要慢10倍左右。在虚拟机里，合成一个简单的中文字词大概3秒起，速度难以接受。如果不是虚拟机则问题不大。尝试调试虚拟机硬件加速等参数，没有效果。

尝试装zhtts，但失败了。tensorflow装不上（Python 3.14还不支持这个包），尝试通过conda使用Python 3.12安装。

2026-4-13

zhtts在Ubuntu 26.04上运行报错，据说是因为glibc版本太新导致，但没有解决方案：

INFO: Created TensorFlow Lite XNNPACK delegate for CPU.
Traceback (most recent call last):
  File "/home/hgneng/zhtts/./zhttsServer.py", line 36, in <module>
    float32Data = tts.synthesis(content)
                  ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/hgneng/zhtts/zhtts/tts.py", line 100, in synthesis
    mel = self.text2mel(text)
          ^^^^^^^^^^^^^^^^^^^
  File "/home/hgneng/zhtts/zhtts/tts.py", line 70, in text2mel
    self.acoustic.invoke()
  File "/home/hgneng/miniconda3/envs/py312/lib/python3.12/site-packages/tensorflow/lite/python/interpreter.py", line 985, in invoke
    self._interpreter.Invoke()
RuntimeError: Select TensorFlow op(s), included in the given model, is(are) not supported by this interpreter. Make sure you apply/link the Flex delegate before inference. For the Android, it can be resolved by adding "org.tensorflow:tensorflow-lite-select-tf-ops" dependency. See instructions: https://www.tensorflow.org/lite/guide/ops_selectNode number 370 (FlexRandomUniform) failed to prepare.

zhtts方面暂时没有进一步的解决思路。而Piper经过一番测试，也没有找到为什么虚拟机比物理机满10-20倍的原因。多种测试显示CPU等性能和主机差别不大。明天试试在Windows的虚拟机里安装zhtts和piper，测试它们的性能。

2026-4-14

旧的Ubuntu和eGuideDog在Windows下已无法安装，升级VirtualBox也不行，原因不明。

新的Ubuntu在Virtual 7.0下无法安装，在7.2下可以安装。Windows虚拟机下piper的表现和Linux虚拟机差不多。

下一步试试下载最新版Ubuntu 24.04，装到Windows虚拟机，看zhtts性能如何。

2026-4-15

VMWare可以安装eGuideDog 0.9.1。已经装上了zhtts，但是依然报FlexRandomUniform错误。后来，在物理机上运行conda deactivate，然后通过--break-system-packages的方式安装tensorflow等依赖。zhttsServer就不再能运行了，连之前可以运行的conda base环境也不行了。下一步试试不破坏系统的python环境，直接使用conda。

尝试build eGuideDog 26 iso，安装到最后阶段的时候报错，无法继续。

前几天能安装的Ubuntu iso文件，今天不能安装了，勾选EFI选项后就可以了。

在新安装的Ubuntu里，conda构建Python 3.12环境，安装zhtts依然报错。但是构建了Python 3.7就运行成功了。zhtts基于的https://github.com/TensorSpeech/TensorFlowTTS 是运行在Python 3.7+环境上的。至于为什么之前物理机上Python 3.12环境曾经可以运行zhtts就不知道了，可能有些久远一些的情况忘记了。

zhtts在虚拟机里合成中文的速度比piper快一个数量级，虽然有点延迟，但应该勉强可以接受。

经进一步尝试，只有python 3.7和3.8才能运行zhtts，而piper只能在python 12+上安装。最终的部署方案是：使用conda安装python环境，base里安装piper，创建py38环境运行zhtts。

2026-4-16

Ekho Segmentation Fault at enablePiper(). Don't know why. Use Valgrind to detect some issues but not solve the Segmentation Fault issue. Try to install TensorSpeech to synthesize English but fail. Plan to try RHVoice(https://rhvoice.org/)

2026-4-17

考虑到piper遇到的技术问题和不稳定情况，这个版本先保留eSpeak作为英文的朗读引擎，等zhtts运行良好后再升级英文引擎，以免崩溃的时候不知道是zhtts问题还是别的问题。

下周开始完善打包脚本、安装流程及使用教程。

2026-4-20

zhttsServer不能通过sd_ekho启动，否则会卡住，可能是一些输入输出管道的问题。计划把zhttsServer作为系统服务提前启动。

ibusreader出现了一次占满CPU的情况。

ekho崩溃了一次，是sonic主动退出的：

Assertion failed: stream->newRatePosition != newSampleRate

这个页面有相关sonic代码：https://www.cnblogs.com/8335IT/p/16708777.html

第2次打包还是报错：

/tmp/tmpn9_ymy3d/mount: 文件系统类型错误、选项错误、overlay 上有坏超级块、缺少代码页或帮助程序或其他错误
dmesg(1) may have more information after failed mount system call
$ sudo dmesg
overlayfs: xino feature enabled using 3 upper inode bits.
overlay: filesystem on /tmp/tmpn9_ymy3d/upper not supported as upperdir

如果不运行chroot_custom.sh，则没有上面问题。