DSPi users (and prospects) projects discussions

[Tell]

Yeah, I noticed that too. You can't really blame them for no refresh when they think they're the only 'setter of DSPi' out there.

The CliRemote gui updates only when you click refresh although the new Optical button refreshes periodically when it's turned on since it's kind of necessary for it to be useful.

My servers are running astoundingly reliably at this point. I realized my Mac (music server) was connected to the wrong Hub router and WiFi marginal and my control was still solid. Now that the Mac is on the nearby router it's ridiculously fast/solid so I'm optimistic.

Yesterday I watched a movie with the wife and at the last scene realized I had volume leveling on and when I then turned it off I couldn't hear the dialog... nice feature. Oh, and Optical was running in the background the entire movie to pipe the spdif into my DSPi via the Mac's usb input.

I haven't really tested the Preset changer since Preset copy just came out and so my rather complex crossover only worked on one preset. I'll take a look at it.

Postscript: hmmm, lost the Preset copier with the last DSPiConsole revision but anyway afaik the Preset seems to be working fine. Maybe I'm too default-y. I have 2 different presets I tried swapping between and it seemed to work ok. What are you trying/seeing?

latest releases: https://github.com/MZachmann/DSPiCliRemote/releases

I just updated DSPi to 1.14 beta along with your latest release (also installed .net 8) but it just says "Not connected" everywhere, any idea why?

 

[Weeb Labs]

I just updated DSPi to 1.14 beta along with your latest release (also installed .net 8) but it just says "Not connected" everywhere, any idea why?

Have you updated to the latest DSPi Console? In v1.1.4, the device vendor ID has changed, so previous Console versions will not be able to find it.

 

[Tell]

Have you updated to the latest DSPi Console? In v1.1.4, the device vendor ID has changed, so previous Console versions will not be able to find it.

Yes, everything should be the latest version.

 

[markz]

@Tell Because 1.1.4 identifies differently. Please get the latest release that was just posted when 1.1.4 came out

 

[Tell]

@Tell Because 1.1.4 identifies differently. Please get the latest release that was just posted when 1.1.4 came out

I am using the latest release yes, I've downloaded it twice just to make sure.

 

[markz]

@Tell - Nuts, I'm out of town for a week. I'll look into it Saturday and it should be an easy fix. It worked for me but I tested minimally.

There was an issue that maybe the new USB code in the console is locking the port. I seem to remember having to not run the DSPi console when using the CliRemote app. I didn't have time to find the root cause and I use the DSPi USB library.

 

[Tell]

@Tell - Nuts, I'm out of town for a week. I'll look into it Saturday and it should be an easy fix. It worked for me but I tested minimally.

There was an issue that maybe the new USB code in the console is locking the port. I seem to remember having to not run the DSPi console when using the CliRemote app. I didn't have time to find the root cause and I use the DSPi USB library.

Cool, no stress

 

[markz]

Cool, no stress

@Tell I think I've gotten everything repaired and improved in DSPiCliRemote. No real changes but it should now run comfortably without needing to do anything but decompress it in windows. MacOSX just requires a chmod +x. See the README for more.

Let me know if not.

 

[Tell]

@Tell I think I've gotten everything repaired and improved in DSPiCliRemote. No real changes but it should now run comfortably without needing to do anything but decompress it in windows. MacOSX just requires a chmod +x. See the README for more.

Let me know if not.

I tried it now, but still can't get it to connect I just installed the latest firmware for DSPi and use the week old Windows console for it, and downloaded your release from yesterday. Am I doing something wrong or is something missing?

I'm going to try it out on my laptop later to see if it might be something off with my Windows desktop.

 

[Tell]

@Tell I think I've gotten everything repaired and improved in DSPiCliRemote. No real changes but it should now run comfortably without needing to do anything but decompress it in windows. MacOSX just requires a chmod +x. See the README for more.

Let me know if not.

Uhm so I got it to run, I just closed DSPiConsole.exe before running the remote server. Are they not supposed to be working at the same time? Anyways, still nice to get it running

 

[webfrog]

As I commented in the main DSPi thread, I'm moving any further discussion of my little web service app to this thread. So, as an intro:

it lives at: https://github.com/MZachmann/DSPiCliRemote

it's a tiny (current 5MB) app that runs Windows, Mac, Ubuntu and soon Raspbian. Intended to run full-time on your DSPi-connected computer (not the Pico) to let you remotely (via web browser) control the DSPi.

For example, my current Pico box is a Mac Mini under the TV and here's a screen shot from my office desktop running Edge. The Log is just for diagnostics for now.

Mark

View attachment 528329

Current state: as of today it runs fairly reliably on all three tested devices. Mac and Ubuntu both require manual steps to point to drivers (Mac) or enable access to the usb devices (Ubuntu). I'll doc that and add the binaries to the next Release.

I downloaded the current Linux version but the directory structure is missing in the zip file, I had to manually create the directories wwwroot and js and rename all files.

unzip -l DSPiCliremote-LinuxX64.zip

Archive:  DSPiCliremote-LinuxX64.zip

  Length      Date    Time    Name

---------  ---------- -----   ----

   117392  2023-10-24 16:16   DSPiCliremote-LinuxX64\CommunityToolkit.Mvvm.dll

    72568  2026-05-09 08:11   DSPiCliremote-LinuxX64\DSPiCliServer

     2603  2026-05-09 08:11   DSPiCliremote-LinuxX64\DSPiCliServer.deps.json

    46592  2026-05-09 08:11   DSPiCliremote-LinuxX64\DSPiCliServer.dll

    23752  2026-05-09 08:11   DSPiCliremote-LinuxX64\DSPiCliServer.pdb

      340  2026-05-09 08:11   DSPiCliremote-LinuxX64\DSPiCliServer.runtimeconfig.json

    24576  2026-05-09 07:50   DSPiCliremote-LinuxX64\DSPiConsole.Core.dll

    27840  2026-05-09 07:50   DSPiCliremote-LinuxX64\DSPiConsole.Core.pdb

    41472  2026-05-09 07:50   DSPiCliremote-LinuxX64\DSPiConsole.Usb.dll

    46996  2026-05-09 07:50   DSPiCliremote-LinuxX64\DSPiConsole.Usb.pdb

   243444  2026-05-03 06:50   DSPiCliremote-LinuxX64\libusb-1.0.dll

    80896  2025-01-17 07:32   DSPiCliremote-LinuxX64\LibUsbDotNet.dll

     1461  2026-05-01 07:28   DSPiCliremote-LinuxX64\wwwroot\cli.html

     2920  2026-05-03 07:07   DSPiCliremote-LinuxX64\wwwroot\index.html

     1142  2026-04-27 23:18   DSPiCliremote-LinuxX64\wwwroot\js\cli.js

     6432  2026-05-03 06:54   DSPiCliremote-LinuxX64\wwwroot\js\script.js

---------                     -------

   740426                     16 files

 

[markz]

Here's what I just did ->

1. Run Ubuntu 24.04 on my old Mac Mini i3
2. Download the zip file in Releases
3. Double-click the zip file to produce the folder container
4. Move the folder container to the Desktop so I don't lose it
5. Run terminal
6. cd ~/Desktop/DSPiCliRemote
7. chmod +x DSPiCliServer
8. try to run the app. when I do it warns me I need to install .NET 8
9. go to Microsoft and download the X64 .Net 8 sdk
10. install it using the three lines they tell you to use
11. install libusb following the README
12. add rights to the USB access following the README
13. as requested, reboot then return to this folder
14. type ./DSPiCliServer
15. and it runs

So, I'd like to help but it just worked as per the README instructions for me. The directory structure is complete and it's all there.

 

[somebodyelse]

For those more used to Windows those filenames probably look fine. The problem is that in linux the backslash is just another character in the filename, so those are literally the file names. So we end up needing to do things like:

mkdir -p wwwroot/js
mv DSPiCliremote-LinuxX64\\wwwroot\\js\\script.js wwwroot/js/script.js

I'll be filing an issue for the Ubuntu instructions once I've checked everything - the USB permissions thing looks dangerously over-permissive among other things.

 

[markz]

For those more used to Windows those filenames probably look fine. The problem is that in linux the backslash is just another character in the filename, so those are literally the file names. So we end up needing to do things like:

mkdir -p wwwroot/js
mv DSPiCliremote-LinuxX64\\wwwroot\\js\\script.js wwwroot/js/script.js

I'll be filing an issue for the Ubuntu instructions once I've checked everything - the USB permissions thing looks dangerously over-permissive among other things.

Huh? I just double-clicked the zip in the Download folder view and the folder it created had the exact correct structure. Are you sure you are doing this right? I use Linux a lot so I'm not really clueless.

 

[somebodyelse]

Interesting - it seems to depend which tool is doing the unzipping. Ark is giving me the filenames with backslashes, but unzip in a terminal gives the tree structure.
edit: that would be https://bugs.kde.org/show_bug.cgi?id=469345

 

[somebodyelse]

On the ubuntu front:

sudo apt-get install dotnet8

should install the .NET 8 runtime. Does it miss something that's needed, or is the other stuff needed to compile it? I had initially installed dotnet10 since FixUbuntu.txt said to install .NET 10, but when trying to run DSPiCliServer I got:

You must install or update .NET to run this application.

App: /home/ajohnson/Downloads/DSPiCliremote-LinuxX64/DSPiCliServer
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '8.0.0' (x64)
.NET location: /usr/lib/dotnet

The following frameworks were found:
  10.0.7 at [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

With dotnet8 it runs, but it's not connecting. I assume that's down to the USB permissions - I'm trying to do something more restrictive than giving everyone read-write access to all USB devices but probably messed it up.

 

[markz]

On the ubuntu front:

sudo apt-get install dotnet8

should install the .NET 8 runtime. Does it miss something that's needed, or is the other stuff needed to compile it? I had initially installed dotnet10 since FixUbuntu.txt said to install .NET 10, but when trying to run DSPiCliServer I got:

You must install or update .NET to run this application.

App: /home/ajohnson/Downloads/DSPiCliremote-LinuxX64/DSPiCliServer
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '8.0.0' (x64)
.NET location: /usr/lib/dotnet

The following frameworks were found:
  10.0.7 at [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

With dotnet8 it runs, but it's not connecting. I assume that's down to the USB permissions - I'm trying to do something more restrictive than giving everyone read-write access to all USB devices but probably messed it up.

@somebodyelse Yes, Windows and Linux use different path delimiters, but the stock uncompress apps (i.e. double-click in the gui) for both OSes are smart enough to handle that. I've extensively tested both Ubuntu and Raspbian installs as listed in the README.

There are a number of different ways documented to install .net 8. The one that works easiest and best is to follow Microsoft's instructions. When you download the archive file it shows a page of instructions with essentially 3 bash lines (untar and then add a couple of path settings). Run those and it's done. The built-in Ubuntu methods (like snap) didn't do it for me. In my README there are also lines that worked reliably.

You must also install libusb as described in the README since it just isn't in a stock Ubuntu build. This does a build and could be better but works. My MacOSX and Windows installs have a pre-compiled libusb but the Linux flavors do builds.

Finally, yes, the USB ports require permission, and numerous links provided the exact same method so that's what I showed in my README. It works and is very low-risk, it just creates a group with USB permission and adds yourself as the one group member (which requires admin permission). Yes, the USB permission is rather broad but it's a lot easier than specifying exactly which dll & version to allow and we're not exactly plugging the DSPi into a secure corporate server.

Finally, @Tell - I haven't looked into the USB code that carefully, but it does seem that the DSPi-Console USB library (which I copy from the DSPi-Console and use totally as-is) is single-threaded. In Windows there is a multi-thread version of libusb available but I haven't tried it and it's not the one normally installed. As it is, I include the latest Windows libusb (RC2) because the currently shipping version with LIBUSBDOTNET doesn't support Windows 10.

 

[somebodyelse]

Yes, Windows and Linux use different path delimiters, but the stock uncompress apps (i.e. double-click in the gui) for both OSes are smart enough to handle that.

If only Ark is the default on KDE (double click to open, or right click to extract directly) and fails to handle it. The bug report has been open for 2 years with only 1 comment and 1 duplicate, so I guess people just don't run into it very often. It was a first for me, hence the initial assumption it was a problem with the file instead of the tool I used to extract it. @webfrog what did you use? If we can narrow it down we can at least add a warning for those likely to run into this.

There are a number of different ways documented to install .net 8. The one that works easiest and best is to follow Microsoft's instructions. When you download the archive file it shows a page of instructions with essentially 3 bash lines (untar and then add a couple of path settings). Run those and it's done. The built-in Ubuntu methods (like snap) didn't do it for me. In my README there are also lines that worked reliably.

So is Documentation/FixUbuntu.txt obsolete?

I prefer to use the packaged versions wherever possible as it's almost always less painful in the long run - updates, dependencies etc. I've also run into too many vendor-supplied scripts that do bad things to run them blind. I'll look into it if it's really necessary, in which case a warning that alternate methods won't work would be useful. From a quick read of the instructions it looks like it might install a full SDK not just a runtime, and possibly multiple versions. I'm a bit confused about what dependencies are for running binaries vs. to compile everything.

You must also install libusb as described in the README since it just isn't in a stock Ubuntu build. This does a build and could be better but works. My MacOSX and Windows installs have a pre-compiled libusb but the Linux flavors do builds.

I already have libusb-1.0-0 installed due to other things using it. I assumed libusb-1.0-0-dev wouldn't be needed as I'm just running the binaries not compiling anything - compile time vs. runtime dependency confusion again.

Finally, yes, the USB ports require permission, and numerous links provided the exact same method so that's what I showed in my README. It works and is very low-risk, it just creates a group with USB permission and adds yourself as the one group member (which requires admin permission). Yes, the USB permission is rather broad but it's a lot easier than specifying exactly which dll & version to allow and we're not exactly plugging the DSPi into a secure corporate server.

Bad security practice remains bad even when it 'works' and is widely repeated, or set as the default. It's how we end up with so many poorly secured servers exposed on the internet. This is like 'fixing' a blocked port by turning off the whole firewall instead of identifying and opening the port you need. Doing it properly isn't much harder, and it should stop former sysadmins complaining

I have no issue with creating a group and adding yourself to it - that part is a good idea, but might not be needed which I'll come to. The issues are:
1. Instead of adding just a group write permission (0664 or even 0660) you make it writeable by everybody (0666) - if you had meant to do that then you could have skipped creating the group.
2. You apply this permission to every USB device, not just the one that needs it. We know the vendor and product IDs so we can limit on those using something like:

SUBSYSTEM=="usb", ATTRS{idVendor}=="2e8b", ATTRS{idProduct}=="feaa", MODE="0660", group="usbwriters"

As for rebooting, it shouldn't be necessary although it's the easiest to explain than reloading udev rules. I think you can use 'TAG+="uaccess"' instead of the group to grant access to the currently logged in user, but in the long run (making it a service rather than just being run by a logged in user) the group is probably better.

So far I have a Pico (RP2040) running DSPi-RP2040-v1.1.4-beta2.uf2 and appearing as an audio device. I can run DSPiCliServer and get the web page, but it just says it's not connected:

[14:30:24] Sent: get_presets | Received: Not connected
[14:30:24] Sent: get_activepreset | Received: Not connected
[14:30:24] Sent: get_vol | Received: Not connected
[14:30:25] Sent: get_loudness | Received: Not connected
[14:30:25] Sent: get_leveling | Received: Not connected
[14:30:25] Sent: get_crossfeed | Received: Not connected
[14:30:25] Sent: get_samplerate | Received: Not connected
[14:30:25] Sent: get_deviceid | Received: Not connected
[14:30:25] Sent: get_input | Received: Not connected
[14:30:25] Sent: is_running | Received: False

Is there a verbose logging option to help me find out where the problem is?

 

[webfrog]

@webfrog what did you use? If we can narrow it down we can at least add a warning for those likely to run into this.

I'm on Linux Mint 22.3 which is based on Ubuntu (which is based on Debian) and used commandline unzip without parameters. I never had problems with unzip and directories before.

$ unzip -v
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 13.2.0 for Unix (Linux ELF).

The date "20 April 2009" shown in the version information above seems to be very old , but I think this is misleading.

I tried some other programs:
gnome archive manager (file-roller 43) - same problem
7z e DSPiCliremote-LinuxX64.zip - same problem

 

[webfrog]

I did some online search and found

Convert a Windows-created ZIP to Linux (internal paths issue)

I have a .zip created on a Windows machine (outside of my control). The zip file contains paths that I need to preserve when I unzip. However, when I unzip, all files end up like: unzip_dir/\windo...

unix.stackexchange.com

If the informations are correct the zip file is not complying to the ZIP file format specification,

The path stored MUST NOT contain a drive or
device letter, or a leading slash.  All slashes
MUST be forward slashes '/' as opposed to
backwards slashes '\' for compatibility with Amiga
and UNIX file systems etc.