请问有nw-zx300相关的开发文档吗

[fish4terrisa-MSDSM]

我在github上目前仅找到这个项目，是关于nw-zx300的插件，在想要开发自己的插件的情况下，我目前缺乏相关的文档。请问有相关文档吗？如果没有文档的话，请问使用adb连接nw-zx300需要特殊操作或密码吗，可以正常进入shell吗，还有根目录是否有保留空间？

[zhangboyang]

没有文档的。。。虽然没有文档，但是因为是linux所以sony依照gpl许可发布了内核的代码，具体链接可以参照get_kernel.sh。。。至于用户空间的程序就没有源代码可以参考了。

启用adb的话需要刷写修改过的固件，我是参照了https://www.rockbox.org/wiki/SonyNWUPGTool ，具体代码可以看llusbdac_installer.py的相关部分，启用adb后直接adb shell就可以得到root shell了。如果想启用adb但懒得自己折腾代码，可以直接用发布的llusbdac安装包，安装时选上启用adb就可以了。

[fish4terrisa-MSDSM]

非常感谢，顺便我想问一下在刷好固件后根目录还有空间吗，我想在封装固件前先测试一下

[zhangboyang]

我忘了有没有空间了23333，你进adb看一下吧

[ShuFengYingt]

有点好奇这个项目是基于什么原理降低DAC延迟的

[zhangboyang]

有点好奇这个项目是基于什么原理降低DAC延迟的

总的来说，没有魔法，全部是软件层面的改动，不涉及到硬件。

原版usbdac延迟很高，是因为无论是否开启“直接源”，音频数据都要过一遍sony在用户空间的处理程序，而这个程序开的buffer很大，大概在MB这个级别，对应到时间上就是秒级的延迟。如果把buffer改小，也能达到降低延迟的效果。但是由于sony在用户空间的那个程序是闭源的，我无法直接看到源码，因此很难进行修改。另一方面，如果需要达到很低的延迟，需要将buffer的大小降得非常小才行，这种情况下一旦用户空间程序的实时性没有得到保障，就很容易出现buffer underrun或者overrun导致音频发生破损。

我这个程序相当于在linux内核里写了个音频播放器，绕过了用户空间。音频数据从usb驱动直接发送到位于内核内的音频播放器，这个播放器再通过alsa调用声卡进行播放。这样做的好处是：因为sony必须遵守gpl开放linux的源代码，我能直接看到代码并进行修改；另一方面由于全部操作都在linux内核中完成，保证内核线程的实时性相对容易，而且音频数据不再跨越内核/用户空间，因此可以将音频播放器的buffer降到很低，从而降低延迟。

[ShuFengYingt]

有点好奇这个项目是基于什么原理降低DAC延迟的

总的来说，没有魔法，全部是软件层面的改动，不涉及到硬件。

原版usbdac延迟很高，是因为无论是否开启“直接源”，音频数据都要过一遍sony在用户空间的处理程序，而这个程序开的buffer很大，大概在MB这个级别，对应到时间上就是秒级的延迟。如果把buffer改小，也能达到降低延迟的效果。但是由于sony在用户空间的那个程序是闭源的，我无法直接看到源码，因此很难进行修改。另一方面，如果需要达到很低的延迟，需要将buffer的大小降得非常小才行，这种情况下一旦用户空间程序的实时性没有得到保障，就很容易出现buffer underrun或者overrun导致音频发生破损。

我这个程序相当于在linux内核里写了个音频播放器，绕过了用户空间。音频数据从usb驱动直接发送到位于内核内的音频播放器，这个播放器再通过alsa调用声卡进行播放。这样做的好处是：因为sony必须遵守gpl开放linux的源代码，我能直接看到代码并进行修改；另一方面由于全部操作都在linux内核中完成，保证内核线程的实时性相对容易，而且音频数据不再跨越内核/用户空间，因此可以将音频播放器的buffer降到很低，从而降低延迟。

原来如此，非常感谢！