jing332
Edge 插件用不了
使用城盘的 ttsrv-plugin-Edge v2.json 插件。
如果加载插件后，将 audio-24khz-48kbitrate-mono-mp3 更改为 webm-24khz-16bit-mono-opus，在选择声音时会出现以下播放错误：
androidx.media3.exoplayer.ExoPlaybackException: Source error androidx.media3.exoplayer.source.UnrecognizedInputFormatException: 可用的解析器 (a, c, a, e, i, a, y, c, E, b, e, a, c, d, b, a, a, a, a, a, a) 均无法读取该流。{contentIsMalformed=false, dataType=1}
然而，audio-24khz-48kbitrate-mono-mp3 和 audio-24khz-96kbitrate-mono-mp3，则播放可正常完成。
@jing332 webm/opus supports streaming playback but you need to add caching to the InputStreamMediaDataSource https://github.com/jing332/tts-server-android/compare/compose...mobad:tts-server-android:compose#diff-afb6b2f0602fed56e8cc88159cbe7e3e62b9805495dbba928f9ec5057c037f03R31 For whatever reason opus will seek backwards once in a while so you need to cache the response as you are reading it so it can seek backwards. This should also allow you to get rid of compatOpus in AudioDecoder.
Also in AudioDecoder in some situations it can remove the first 15 bytes from the input stream so you need to cache like so https://github.com/jing332/tts-server-android/commit/1928036ef8bd6a9f140cb52b318748519da0c60a#diff-30c7f202c39a9599793d2e8f08faaf19d4cba0ccc0403344e72dbd9dfd4c2ad3R159
The websocket client from my changes might be worth looking at as well https://github.com/jing332/tts-server-android/compare/compose...mobad:tts-server-android:compose#diff-fe99ebb96e2094836772f98bce26e7d68bb59585b2b4488182b15309e03e569bR54 It adds some additional methods of timeout and switches from PipedInputStream to Pipe as PipedInputStream has some issues where if the thread changes it can cause random exceptions https://stackoverflow.com/questions/1866255/pipedinputstream-how-to-avoid-java-io-ioexception-pipe-broken Not sure if that's still relevant to the latest code though.
Edit: Oh and one more thing I took a look at a while back with websocket streaming mode and PipedInputStreams but not sure if it's still relevant (but from what I can see it is) If you are streaming a response back and you get the first audio packet but then for whatever reason it times out before you get the turn.end, it won't timeout properly and will hang and it won't retry because the retry stuff happens before you get a response. Also PipedInputStream only knows about .close() but doesn't have a way of reporting whether you actually have gotten the complete audio or not so you might need to add a method of detecting whether you've actually gotten the complete audio and retry if you haven't.
