search

hifiberry / hifiberry-dsp

DSP toolkit
MIT License
138 stars 36 forks source link

Some indicators in SigmaStudio not working. #25

Closed sunfireforge closed 3 weeks ago

sunfireforge commented 3 years ago

Hello!

I've been trying to debug why some level indicators work real-time in sigmastudio while some do not, crashing the comms channel with sigmatcp or sigmastudio altogether.

I'm using;

Thus far I've tested, with level Indicator switch ON;

Seem to work ok;

Do not work

All other functionality of the cells work, meaning, compressors apply compression and allow you to adjust params, but if you flip the "Indicators On" switch the comms channel crashes after a couple of seconds.

I initially thought it might be overloading sigmatcp, causing the daemon to become unresponsive.

I stopped the service; sudo systemctl stop sigmatcp and started it from a terminal session; /usr/local/bin/sigmatcpserver -v

After trying a few different things, based on the debug level output, I'm pretty sure the daemon was not overloaded. I had multiple "working" indicators and could still make live changes to other cell types (volume sliders, mutes).

I then forked the server and added some (rudimentary) read caching and additional log output; https://github.com/joshzampino/hifiberry-dsp

Here's my instrumented _handleread output (a = addr, l: length, d: data);

A) A known good indicator (Running Average)

  1. DEBUG:root:received request type 10
  2. DEBUG:root:handle_read: a:41 l:4 d:b'\n\x00\x00\x00\x0e\x01\x00\x00\x00\x04\x00)\x00\x00'
  3. DEBUG:root:read_cache add: 41:bytearray(b'\x00JF#')
  4. DEBUG:root:Sending 18 bytes answer to client

B) A known bad indicator (Level Detectors/Multiple Bands/RTA to Output);

  1. DEBUG:root:received request type 10
  2. DEBUG:root:handle_read: a:37 l:4 d:b'\n\x00\x00\x00\x0e\x01\x00\x00\x00\x04\x00%\x00\x00'
  3. DEBUG:root:read_cache add: 37:bytearray(b'\x07\x00\x00\x00')
  4. DEBUG:root:Sending 18 bytes answer to client

C) Known bad indicator (Dynamics Processors/Multiband Compressor)

  1. DEBUG:root:received request type 10
  2. DEBUG:root:handle_read: a:340 l:4 d:b'\n\x00\x00\x00\x0e\x01\x00\x00\x00\x04\x01T\x00\x00'
  3. DEBUG:root:read_cache add: 340:bytearray(b'\x00\x00\x15\xd1')
  4. DEBUG:root:Sending 18 bytes answer to client
  5. DEBUG:root:received request type 10
  6. DEBUG:root:handle_read: a:341 l:4 d:b'\n\x00\x00\x00\x0e\x01\x00\x00\x00\x04\x01U\x00\x00\n\x00\x00\x00\x0e\x01\x00\x00\x00\x04\x01\\x00\x00'
  7. DEBUG:root:read_cache add: 341:bytearray(b'\x7f\xff\xff\xff')
  8. DEBUG:root:Sending 18 bytes answer to client

Looking at this output, I now think that the comms channel is crashing because the data offset or format is not what sigmastudio expects.

  1. Line A-3 and C-3 look healthy
  2. Line B-3 and C-7 are not what I would expect from a register value with an active signal
  3. C-3 and C-7 are two registers for the same compressor cell
  4. C-6 looks to have much more info than _handleread parses/uses

Before I dig in any further I wanted to check and see if this is something I'm missing in my configuration? I'm not very familiar with the DSP config and register values, perhaps there is an OS setting?

Please let me know if I can provide anymore detail, and thanks for looking.

hifiberry commented 3 years ago

There is no OS setting for this. There isn't a full documentation of the TCP protocol. It has been reverse engineered from AD's sample code (with some bug fixes already). It's possible that it's still not 100% correct. However, without a protocol documentation, I simply can't say how it should look like.

sunfireforge commented 3 years ago

Thanks for the response. I found this; https://wiki.analog.com/resources/tools-software/sigmastudio/usingsigmastudio/tcpipchannels

I submitted and closed a PR with some changes you might want to consider; https://wiki.analog.com/resources/tools-software/sigmastudio/usingsigmastudio/tcpipchannels

One fixes the issue with line C6 above. There were actually two packets being passed to _handleread. I found code in _handlewrite which uses a buffer to deal with that.

The other two commits are adding a complete hex dump during _handleread, and use the total packet length in the response header instead of the header len.

This is what the log output looks like;

  1. DEBUG:root:received request type 10
  2. DEBUG:root:read_req: 0a0000000e010000000400290000
  3. DEBUG:root:read_rsp: 0b120000000100000004002900000039911d
  4. DEBUG:root:Sending 18 bytes answer to client

All of these changes work, but none of them fix the indicator issue. I think my next step is to debug sigmastudio and see if i can figure out what these breaking cells are looking for. Luckily, its .net, hopefully it's not obfuscated.

Let me know if you want me to re-send that PR.

hifiberry commented 3 years ago

If you have a PR that fixes this, please send it.

hifiberry commented 1 year ago

Do you still want to send a PR?