Some indicators in SigmaStudio not working.

[sunfireforge]

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;

• RPi 3
• Raspbian OS
• HiFiBeffy DSP+ DAC
• Sigmatcp from hifiberry-dsp
• dspproj based on BeoCreate's Univeral dsprog, with which seems to work well except for this issue.

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

Seem to work ok;

• Level Detectors/Single Band/Running Average
• Level Detectors/Multi Band/Pass Through

Do not work

• All RMS Compressors
• Level Detectors/Multi Band/RTA to Output

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 handle_read 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 handle_read 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]

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]

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 handle_read. I found code in handle_write which uses a buffer to deal with that.

The other two commits are adding a complete hex dump during handle_read, 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]

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

[hifiberry]

Do you still want to send a PR?