Crash on unexpected response (sometimes) from getInputSource()

[mfeif]

Sometimes (I can't figure out when/why) I am getting a crash:

  File "/home/mjf/python3-minidsp/minidsp/board_2x4hd.py", line 53, in getInputS
ource
    raise RuntimeError("Received unexpected response: " + str(resp))
RuntimeError: Received unexpected response: [5, 255, 218, 27, 0]

It seems to commonly happen when first attaching to the MiniDSP, if that's worth anything.

Not having access to the initial raw datalogs about what this thing is spitting out, I don't know how to figure out what those bytes are supposed to be.

It does tend to work if you just do the same thing again.

Thanks!

[mfeif]

This keeps happening. I've wrapped up the relevant bits to have it try several times, and that makes the hard crash happen less frequently, but sometimes it still sneaks through.

I saw the discussion over on the node version about it being related to IR activity, which I can't confirm.

(I also can't install the node version to look for variations. I hate node, and this is one of the reasons why. I'm literally starting from a blank install on a current OS, installing node as per "best practices" and it crashes trying to install that project because of a dependency that crashes.)

[markubiak]

Yeah, I remember the HID library for Node being an absolute nightmare. I think I had to build it separately and move it to node_modules like some kind of caveman.

I do believe this to be related to IR activity. I did have some code, somewhere, that would listen for commands "emitted" from the HID driver, and I think they were very similar to the above. I'd handle and decode it myself. See my process_buffer() in my JS code: https://github.com/markubiak/minidsp-control/blob/master/minidsp-control.js

Again, not using this anymore and the device is a couple thousand miles away, so quite hard for me to test. Hope this helps.

Mark

[mfeif]

Cool, thank you. So did your .js version have some more features than your .py version?

I'm not good with JS, and though I can follow the code, it's hard to tell if it all maps over.

[markubiak]

Yes, its job was to listen for IR commands on the wire and update a small display with the current values. That's how I know IR blasters emit USB HID commands - I've read and parsed them.

If you have any specific questions on the code, please let me know. Trust me, I hated writing this so I feel your pain. Python + Rust is the future...

[mfeif]

Oh, you were listening for events on the MiniDSP itself? Cool! That didn't make it over to python land, eh?

[markubiak]

That was the plan, but I never got to it unfortunately. cython-hidapi was less than pleasant to work with, I no longer needed SPDIF input, and I found some reports of glaring issues with the 2x4HD's sample rate conversion and DAC. So I've moved to a custom filterbank engine in Rust, running on a Pi, with I/O using JACK. I like it a lot.

[mfeif]

Neat! Care to say more about the 2x4HD? I've kinda worried about that too.

I'd love to read more about where you landed, if you plan to document it, consider this a +1.

[markubiak]

March Audio did a few good measurements: https://www.audiosciencereview.com/forum/index.php?threads/measurements-of-minidsp-2x4hd.2459/

Really, those DSP chips in the MiniDSPs are so overkill for the task at hand. With the ARM NEON DSP extensions and an RTOS, that number of IIR and FIR filters is pretty easy. Thanks for the +1, but I'm hesitant to write something up if I don't plan to support it, why I'm keeping my Rust code private for the time being. With the release of the SHD, those with several thousand to blow on amplifiers should be pretty happy.

[mfeif]

I finally took time to read through that thread. Interesting stuff, thanks for sharing.

I'm not sure what your task is, but yeah, I imagine so. For me, I've built some of these. I spent a while trying to reproduce the DSP EQ curves that Mr. Linktwitz spec'd with an ALLO 2 dac board. The way that the environment specified curves was sufficiently different that I just didn't know what I was doing, and I don't have measurement equipment. I decided that I could try and learn the fundamentals of digital signal processing, and how to map one set of metaphors over to another, or I could just follow the damn instructions and get a MiniDSP. Since my goal was to have speakers, not learn DSP, I chose that path.

I'm quite certain that an rPi4 could handle whatever the EQ curves are in software, but I don't know that I could map it over. Also, I need the analog input for a turntable.

Anyway, I thought I'd put this here for anyone who finds it ever. It's trivial to tell the Pi to use very high quality SOX resampling which is built into PulseAudio, and those modules come standard in Raspbian. So I'm resampling BEFORE I send to the MiniDSP. This was the comparison that March Audio used to shoe the inferior resampling inside of the MiniDSP. I'm resampling to 48K, and hoping that the 48K -> 96K upsampling code in the MiniDSP is ok :-)

I'm sure that other stuff would sound better, and I'm itching to try some of that stuff out. But this is good for now.

One interesting further note I'll leave here. Via the USB interface on Linux, you can see the 4 channels of the MiniDSP post transfer functions, and get the audio. It's been volume-limited and everything. So if one were picky about the DAC sound on the MiniDSP2x4HD, one could snarf the USB audio streams and send them via a loopback configuration to outboard DACs connected to the Pi.

[mfeif]

Solved this over here: https://github.com/mfeif/python3-minidsp/commit/f1bfa4625995cf428549f2f43bf4ccf682a70487

[markubiak]

Very cool that you're building your own speakers! That's out of my building skills especially as I don't have a good workshop. I have a pair of KEF LS50s, I thought about doing a digital crossover but didn't want to get 4 channels of amplification going, so I found an aftermarket crossover that has been performing wonderfully.

There's no extra CPU overhead from running at 48k to 96k, the computationally intensive stuff is non-integer resampling (44.1k -> 48k) which you are already doing. So 44.1k -> 96k is not any harder, I'd recommend going that route since there are published results saying that is OK.

[mfeif]

I came to the same conclusion yesterday, actually, and switched up my pi to stick at 96.

But my USB isolator won't work at that speed, so have to buy a new one. :-(

So is your rust/dsp code for room correction, if you're not doing crossover? I'd assume that the KEF would have their own... I'm confused :-)