Flex HTx shim with WebSocket telemetry and HTTP control

[thcdru2k]

I originally stumbled into this because I happened to still have my old 2x4 HD connected to my Raspberry Pi. I lost a lot of my automation functionality when I added a Flex HTx to my system and this shim has basically allowed me to restore it to how it was before when I was only using the 2x4 HD. I noticed that, despite the Flex HTx feeling more closed and having removed FIR import from its console, I could still reliably read live input and output levels and full status from the HTx via the minidsp CLI. That observation prompted me to build a single file shim that turns the HTx into a properly networked device with a real time WebSocket telemetry stream, a clean HTTP control API, a stateful internal model, and a single writer automation lease. It does not restore native FIR capability on the HTx, but it does make serious external FIR workflows, such as CamillaDSP or other convolution engines, practically feasible for those who want to pursue them, while also returning a level of programmability that many power users assumed had been lost with the move to Flex HTx.

For clarity, I am not currently running external FIR in my own system. My approach is primarily IIR based, which already meets my goals so I do not need external FIR for my setup. That said, I suspect others with more time, curiosity, or different objectives could use this shim as inspiration or a starting point to experiment further.

 

[danstahl]

how is this different than https://minidsp-rs.pages.dev/daemon/http#websocket-streaming?

 

[thcdru2k]

how is this different than https://minidsp-rs.pages.dev/daemon/http#websocket-streaming?

For whatever reason I could not get built-in websocket to work with minidsp-rs in my system with Flex HTx alone, only when I had my 2x4 HD plugged in. The shim is HTx specific, works even when minidsp-rs cannot talk to the HTx. Maybe there was an easier solution to my problem but I was not able to figure out why websocket was not working with my Flex HTx in my system. I went ahead and added consistent HTTP control API, a stateful internal model with observed versus intended state, a single writer automation lease to prevent races, localhost-only writes, a small event ring buffer, and stable real-time WebSocket level telemetry with a controllable poll rate.

 

[danstahl]

For whatever reason I could not get built-in websocket to work with minidsp-rs in my system with Flex HTx alone, only when I had my 2x4 HD plugged in. The shim is HTx specific, works even when minidsp-rs cannot talk to the HTx. Maybe there was an easier solution to my problem but I was not able to figure out why websocket was not working with my Flex HTx in my system. I went ahead and added consistent HTTP control API, a stateful internal model with observed versus intended state, a single writer automation lease to prevent races, localhost-only writes, a small event ring buffer, and stable real-time WebSocket level telemetry with a controllable poll rate.

If I'm reading your code correctly you are still using the minidsp cli, which requires minidsp-rs to talk to the HTx? I don't use the minidsp-rs websocket capability but I do use the HTTP capability. You have to set a config like this to access the HTTP/WS endpoints from another computer: https://github.com/danielhstahl/minidsp-remote-control/blob/main/examples/minidsp.toml

 

[thcdru2k]

If I'm reading your code correctly you are still using the minidsp cli, which requires minidsp-rs to talk to the HTx? I don't use the minidsp-rs websocket capability but I do use the HTTP capability. You have to set a config like this to access the HTTP/WS endpoints from another computer: https://github.com/danielhstahl/minidsp-remote-control/blob/main/examples/minidsp.toml

You are reading it correctly. If that configuration had solved my issue I would have used it, but in my case minidsp-rs could not reliably talk to the Flex HTx at all unless a 2x4HD was also connected. My problem was at the device-recognition layer. Maybe there was something I missed diagnosis wise and it would have saved a lot of time. The CLI worked reliably for me so that is why I made the shim.

 

[Mort]

Would you be willing to ELI5 this? Particularly, this I guess: "a real time WebSocket telemetry stream, a clean HTTP control API, a stateful internal model, and a single writer automation lease. "

 

[thcdru2k]

Would you be willing to ELI5 this? Particularly, this I guess: "a real time WebSocket telemetry stream, a clean HTTP control API, a stateful internal model, and a single writer automation lease. "

Real-time is nice for making a graphical user interface. if i check my GUI hosted on my pi, if it says volume is -35db i can trust that it is -35 db. clean control just means if i press change input to toslink or analog i can trust that the command will go through. internal model just means if i refresh the gui; it will still show my correct information like what minidsp preset is in. that is helpful because if your device is in a rack and not easily visible its better to see from a gui and trust it. single writer means if my wife is on the GUI on her phone, and i am on the GUI on my phone the system doesnt get overwhelmed.