【周报】 2020年11月份每周总结

2020年11月复盘总结

---

---

一、11月份第1周

提示 结合 Toggl 针对本周的工作进行总结以及下周的工作任务安排。

1. (11.01) 这个周末属于加班日，看到Toggl 的工作时长，下午T1430 - T2030，算是加班了， 下午的工作产出还是比较高的，优化了Toast 项目断网的问题，比较重要的是针对Toast Project , 适配了Jenkins自动化固件的流程。这件事情提升了工作生产力，做过一系列项目，出版本固件还是深有体会的，一直在加班，每周过节的时候总是在出固件，每次特别麻烦，时间比较紧张，版本是出来了，但是版本的各种信息都没有，导致后续无法追踪，定位问题又增加了不少难题。

   目前项目的Jenkins是之前离职员工Rose搭建的，针对公司主流平台进行了适配，自动化编译 / 固件下载 做的比较完善，之前做NXP 项目的时候发现脚本耦合性比较高，不好拆分，就没有针对NXP项目进行适配，感觉后续出版本越走越困难，太麻烦了，每次都需要手动添加很多信息。效率太低了。

   这次Toast Project 出版本的时候，觉得Jenkins 自动化编译是必须的，特意花了一下午的时间分析了Shell 脚本的逻辑，适配了Toast项目，感觉整体的流程走顺了。

   之前看过左耳听风陈浩的极课专栏其中的一节 : 时间管理：如何利用好自己的时间 ?

   花时间在解放自己生产力的事上。在自动化 可配置 可重用 可扩展上要多花时间。对于软件开发来说，能自动化的事情，就算多花点时间也要自动化因为下次就不用花时间了。

• 针对 Docker / Jenkins 在嵌入式领域的应用，总结遇到的问题以及应用输出一篇Blog

2. （11.02） 本月第一周的周一，上午公司集体调休，下午上班，主要针对最近的改动进行整理，提交Gerrit审核。

   之前一直担心Toast Project 环境编译问题，毕竟是新的平台，环境有所不一样。在201服务器上编译的时候，发现会有一交叉编译器找不到的问题，进行了修复。但最最终打包的时候遇到的一个奇怪的问题 ，在201服务上 cp 拷贝多个问题的时间提示找不到路径，而在Docker 上边是好的，这个问题定位了很久，一直没有得到解决，这个使用rsync替代方案进行了解决。

• 201服务器上编译Toast Project 打包报错以及异常问题待解决。

  晚上一起和Tommy 同步了Toast Project 上硬件 软件 结构 认证上面的一些时间节点，发现如果11.15 送样机认证时间上面还是比较紧张的，需要加快时间节奏了。

  T2200 由于Grubby 最近每空，样机验证麦克风的一致性 气密性 需要我来，顺便找他学习下，这个就是职场，只有付出的多，回报的才会多，而且需要这些问题需要又自己的见解。

• 输出测试麦克分一致性 / 气密性的测试文档以及找Vicent 了解量产时候的Mic 测试方案，整理成博客进行输出

3. (11.03) 每周二 上午相当于和(Tommy / 47) 在开Toast 周会，而我睡过了，在家语音接入，最近样机准备送认证，讨论的问题比较多。

   下午投入了一部分时间在研究音量等级的划分上面，现在是套用Lucky的音量等级，但是实际测试发现音量很小，Volume 10 的时候用声压计测试发现之后64dB，而其他产品可以达到73dB，这也是之前做Joy EQ 功能开发的经验。梳理了SDK了中音量设置的相关代码，但是还是有疑问需要去确认，比如amixer 设置的音量和 gstreamer 设置音量之前的关联.

• 输出音量标定的流程以及代码中设置音量的逻辑以及梳理下ALSA or Gstreamer Volume 之间的关系

  这是Toast客人的软件经理法的邮件需要立即修复的问题，我马上做了验证，结果之前发给客人的SDK中的库都没有软链接，相当于一个库copy了好几次，立马定位问题，最终的问题定位出 : 固件编译的时候输出到 Toast_SugrSenseSDK 并没有问题，软链接特性还一直保留，但是通过 zip 压缩的时候就丢失了软链接的特性。

后续发布的SDK请做下处理：应在Linux下打包，so动态库保持软链接，而不是多份相同的文件。同时不要含有多余的调试文件，比如
/usr/lib/txt 文件，etc/sugr/ssh 也疑似多余。

zip -qr 与 zip -qyr 区别在于 -y参数保留了库的软链接特性 

-y   store symbolic links as the link instead of the referenced file

4. (11.04) 周三的主要工作量是集成AVS Bluetooth Function，这部分一直是自己不熟悉的领域，而且会有很多坑，总觉的打通Bluetooth会有很多问题，需要更多的时间，但是往往相反，发现一天就可以搞定了，主要是因为Toast 客人那边已经针对BlueZ进行了适配和操作,基本打通了，可以实现蓝牙的发现和连接。我这边的主要工作是AVS中集成Bluetooth，实现语音控制Bluetooth。

   刚开始移植还是挺顺利的，毕竟针对这部分已经很熟悉了，当启动bluetoothd的时候一直发现无法启动，感觉驱动缺点什么东西。立马和客人的软件工程师沟通，对方提供了Patch，之后启动正常，但是发现无法打开打开蓝牙，对比其他项目的蓝牙启动逻辑，发现有一些不通电，针对这部分进行了补充，之后发现AVS语音控制竟然通了，瞬间感觉不是熟悉蓝牙这部分，只是感觉我运气好，没有出现Bug。

• 熟悉蓝牙的相关操作，整理并输出调研Uart Bluetooth 播放音乐的可行性结果，毕竟该方案很少见

PREFIX="Voice"
bt_set_name(){
    MACID=`cat /sys/class/net/br-lan/address | tr -d : | cut -c9-12 | tr A-Z a-z`
    BT_NAME="${PREFIX}_${MACID}"
    mkdir -p /etc/sugr/bluetooth
    echo "[General]
Name = ${BT_NAME}">/etc/sugr/bluetooth/main.conf
}

start_service() {
    bt_set_name

    /usr/bin/hciconfig hci0 up
    /usr/bin/hciconfig hci0 piscan

	ln -snf /etc/bluetooth/keys/ /var/lib/bluetooth

5. (11.05) 周四 的产出比并不高，主要是下午需要打羽毛球，虽然说浪费时间，但是运动带来的价值是无价的，而且有的时候可能打完羽毛球之后，Bug很容易就解决了。

   下午在完成Toast 音量等级的标定以及数据的测试，针对软件中的参数参数如何修改参见调试数字音量等级方法，其实我i只知道怎么调试，但是不知道是原理需要这样做，这部分需要搞清楚的。

T2220 的时候更新了新的SDK 给客人 (SSB21-11.111.0.3.999_20201105-1447) 这次使用 本地的Jenkins 编译，感觉方便多了，主要是服务器的打包问题还没有解决，并不完全是自动化

6. (11.07) 周五 的产出比明显降低，而且状态不太好，感觉自己很困，注意力不集中，特别不想写代码，所以做的都是一些小功能，产出比很低。

   T2200 在5楼看到Sense N 的机器，而且有一台腔体损坏了，反正不想写代码，那就干点别的事情休息一些了，整理了Sense N 的相关机器并修好了坏的腔体。

二、11月份第2周(11.9 - 11.15)

三、11月份第3周 (11.16 - 11.22)

• (11.16) 周一 每周的周一相当于新的开始，之前周一会议特别多，但是最近每周一都可以投入软件研发，针对上周修复的软件问题，更新SSB21-11.111.0.5.999_20201115 SDK给到客人做集成验证。其中发现的主要问题是信号量超时机制由于过程中修改了系统时间导致信号量移植阻塞导致UX显示异常。另外发现双方Process 都有同步时间，但是时区不一样，所以前后显示的时间不一样。

  下午客人带着Toast项目T0结构过来组装以及验证麦克风的一致性，之前的结构手板太粗糙了，设备老化一段时间麦克风盖子都变形了，导致无法送认证，需要最新的T0结构来验证。下午本来计划修复Bug更新固件测试的，结果算法测试人员一直在开会，没人来测试，没办法，我只能顶着上去，结果一顶就是一下午，这应该是我自己的管理方法出问题了，结果本该算法测试人员干的活，别人下班了，你还的陪着客人熬夜验证腔体，尴尬了。不说这些无聊的。 验证新结构的过程中也发现了一些新的问题:

• 通过Audition看频率分析，基本1k以上的点都在20db以上，但是其中低频很多点不行，相差只有5db。明显不行，最终确定T0结构中的麦克风泡棉尺寸不合适。临时的解决方案 : 增加一个泡棉以及灯板的间隙用双面胶封死，这样的方法验证之后发现效果还可以，只有600hz附近几个点不行，但是不会影响效果。 针对这次的结果数据以及修改方法赶紧输出文档以及数据保存。 由于第一次手板验证的时候，结构调整好之后，很多细节修改的地方都没有记录，而且样机又坏了，导致现在走了很多的弯路。 这次的测试数据已经上传网盘。
  

• 新组装的T0样机，整体的感觉比手板强太多
  

• 新的结构验证麦克风的一致性和气密性的测试方法总结输出

2. (11.20) 周五

3. (11.21) 周六 这个周六在公司加班，这个问题比较奇怪也是令我百思不得其解呀。 【腾讯文档】 #11Knowels与AAC麦克风数据对比

4. (11.22) 周末 这个周末一直在加班解决Toast项目遇到的问题，中午去公司分析设备老化的结果，【腾讯文档】 #11Knowels与AAC麦克风数据对比 ，并没有的答案，需要进一步排查，这个问题今天需要缓一下，下午投入精力解决设备播放提示音出现pop音问题，这个问题排查的路线周期比较长，而且音频流路线也比较多，刚开始并不好定位，排查了将近2-3工作日才找到解决方案。最终使用alsa_loop 的解决方案修改了该问题，其实最初的方案就是采用alsa_loop方案做的，但是过程中发现MRM KPI Test 延迟较大，故抛弃了该alsa_loop方案，直接使用alsa_dmix方案替代，但是这样延迟解决了，pop音就出来了。该问题的线路:

• V1.0 : 设备最终的音频流播放采用alsa_loop方式，相当于进程A一直把音频流写入hw:0,0,0, 进程B从hw:0,1,0 取音频数据，写入最终的声卡播放hw:1,0

• V2.0 : 由于V1.0方案通过alsa_loop导致音频流最终播放出来延迟太长了，导致AVS MRM KPI Test 测试无法通过，于是修改了V1.0的解决方案，改为进程A直接操作声卡，这个时候引入了alsa plug dmix，可以实现多个设备的操作，这下解决了延迟问题

• V3.0 : 在V2.0方案测试过程中，发现播放提示音有pop音，而且概率还比较大，并且播放Spotify 也会有pop音，该引入了V3.0的临时解决方案，这个方案比较粗暴，直接 gst1-plugins-base / gstalsasink.c 打Patch ,把其中的短连接改为长连接，相当于进程A每播放一次音频流会重新打开pcm并关闭close, 改为一直打开pcm 不关闭pcm , 这种方案临时解决了pop音，而且又满足MRM KPI Test 延迟问题。

• V4.0 ： 看似V3.0这种方案合适，但其实会导致设备的音频fd句柄一直泄漏，gstreamer 每次播放音频都会重新建立连接，频繁的open / close(pcm)导致pop出现，但是改为只有open，没有close，最终fd句柄泄漏到一定值的时候导致进程A无法工作。这样的修改会导致系统无法工作。

• V5.0 : 针对V4.0 发现的问题，排查了1-2工作日，但是没有进展，这个时候团队成员A在调试蓝牙Source引入PulseAudio ，相当于进程A的音频流通过Gstreamer之后又导入到了PulseAudio，不经过Gstreamer 的alsa sink，而是通过PulseAudio 的 alsa sink 进行播放，实际测试也是可以的，并没有出现pop音问题，准备把PulaseAudio 移植到Toast项目的平台上，移植过程中出现了一些问题，而团队成员A在测试PulseAudio 过程中发现了一些问题，需要投入时间解决，这个时候意识到，目前PulseAudio并不稳定，需要寻找其他解决方案了。

• V6.0 ： 经过V5.0 的方案折腾后，更加意识的是需要稳定的解决方案，这个之后想到了最重的alsa_loop解决方案，再次移植过来，不过Toast项目并没有MRM模块，所以并不影响，绕了这么一打圈，问题没有根解，时间投入却不少。而且实现alsa_loop的进程B方案，其中部分逻辑写的是真绕。

• 设备的音频流处理整理输出

解决爆破音的问题,

四、11月份第4周

---

总结