DSPi users (and prospects) projects discussions

[somebodyelse]

That's odd - unzip is what worked for me. I'm on KDE Neon (based on Ubuntu LTS 24.04 but with latest KDE packages) so probably the same version. Checking package version:

DSPiCliremote-LinuxX64$ apt-cache policy unzip
unzip:
  Installed: 6.0-28ubuntu4.1
  Candidate: 6.0-28ubuntu4.1
  Version table:
 *** 6.0-28ubuntu4.1 500
        500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
        100 /var/lib/dpkg/status
     6.0-28ubuntu4 500
        500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages

Rechecking, I see there's even a warning about the backslashes in the output:

$ unzip DSPiCliremote-LinuxX64.zip
Archive:  DSPiCliremote-LinuxX64.zip
warning:  DSPiCliremote-LinuxX64.zip appears to use backslashes as path separators
  inflating: DSPiCliremote-LinuxX64/CommunityToolkit.Mvvm.dll 
  ...

And we wonder why companies don't like making software for linux

Interesting find on the zip specification by the way - probably explains why I've not had a problem with zips from Windows before. And now we're digging into which bits of linux don't have a workaround for other tools not following the specification...

 

[webfrog]

That's odd - unzip is what worked for me.

@somebodyelse
You are totally right, unzip is working and extracted the files into the correct subdirectories.
I don't understand what happened, but yesterday I had the described problems with unzip. I checked my apt history and could'nt find any relating updates. Linux Mint and KDE Neon are using the same unzip versions. Perhaps I tried too many different tools.
Regardless of this strange behaviour the problem still persists with 7z and gnome archive manager.

@markz
I'm sorry if I caused any confusion about unzip which seems to work under some circumstances but with warnings.
Perhaps there are some other linux users who can confirm the problems.

 

[markz]

@webfrog It's fine. I've never had an issue unzipping stuff. I even used Windows' Compress to ensure it would be compatible and I did indeed test on Raspbian and two flavors of Ubuntu although I just added the script. It's named CompressIt.ps1 so if there's a better version I'm all for it. I had hoped for more options with the PowerScript compress but it's pretty disappointing.

@somebodyelse Yes, the FixUbuntu was my first version. I completely forgot it existed and have been maintaining the README.MD instead. I'll take care of them because I do like having a second clear doc around.

Also, the 0666 I agree. I've changed the README to 0660 which was the intent (and the writeup, oops my bad, thanks for commenting on that).

 

[somebodyelse]

@webfrog It's fine. I've never had an issue unzipping stuff. I even used Windows' Compress to ensure it would be compatible and I did indeed test on Raspbian and two flavors of Ubuntu although I just added the script. It's named CompressIt.ps1 so if there's a better version I'm all for it. I had hoped for more options with the PowerScript compress but it's pretty disappointing.

https://github.com/PowerShell/Microsoft.PowerShell.Archive/issues/54
It's a Compress-Archive bug - one of several related to unix filesystem properties. It's not clear whether they've just stopped maintaining it, or whether everything now happens behind closed doors. The answer seems to be to use a different compression tool such as 7zip.

@somebodyelse Yes, the FixUbuntu was my first version. I completely forgot it existed and have been maintaining the README.MD instead. I'll take care of them because I do like having a second clear doc around.

Thanks for the clarification. It's an example of why having more than one document covering something is considered bad practice in the document management world - they'd argue there should be one true source, and others should point to it rather than repeat its content.

Also, the 0666 I agree. I've changed the README to 0660 which was the intent (and the writeup, oops my bad, thanks for commenting on that).

Thanks. Have you tried the vendor and product ID filters? Without them it'll break expected ownership for serial devices (usually assigned to group 'dialout' on debian-based distros) and who knows what else. I know about the serial stuff as I'm using it for other things.

 

[markz]

https://github.com/PowerShell/Microsoft.PowerShell.Archive/issues/54
It's a Compress-Archive bug - one of several related to unix filesystem properties. It's not clear whether they've just stopped maintaining it, or whether everything now happens behind closed doors. The answer seems to be to use a different compression tool such as 7zip.

Thanks for the clarification. It's an example of why having more than one document covering something is considered bad practice in the document management world - they'd argue there should be one true source, and others should point to it rather than repeat its content.

Thanks. Have you tried the vendor and product ID filters? Without them it'll break expected ownership for serial devices (usually assigned to group 'dialout' on debian-based distros) and who knows what else. I know about the serial stuff as I'm using it for other things.

Thanks. wtf. I'll switch away from Compress-Archive I guess. That's ridiculous. As noted it is dealt with by most of the default unzips but meanwhile it's dumb.

I haven't looked into additional filters. Yes, I know it fusses the dialout group but again this isn't a corporate server. Feel free to research something more appropriate but what I want to avoid is having to go in there and edit stuff if DSPi changes the usb ids or something (which happened at 1.1.4).

Postscript: ok, I've switching to compressing with 7Zip which seems to have reverted back to / and should be a little more consistent. Feel free to check the latest release zips.

 

[john61ct]

Anyone can answer, please

An IIR filter by its nature can't really be linearized but cascaded all-pass filters (DSPi supports these) can be used to approximate a target phase curve.
...
Crossovers in most active monitors like the JBL 305P and Genelec 8030C are minimum phase and the data produced by controlled listening studies indicates that minimum phase and linear phase approaches are generally indistinguishable within this context.

I don't use those speaker types (already using DSP)

but if I have non-DSP crossovers that are already performing well in magnitude/FR, but showing phase issues

are you saying that IIR all-pass can do time-domain "corrections" that end up in practice working just as well as replacing those existing crossovers

with FIR filtering to create linear phase crossovers from scratch?

If "yes" is that just as true for existing crossovers implemented with passive devices, ass opposed to non-DSP electronic active ones?

Finally, is there any difference in this regard between
crossing over a passive multi-way (internal xovers to be left as is) and single-driver DIY boxen,

as opposed to multiple instances of the latter?

 

[Rocky Maine]

I'm thinking of getting an RPi 5 to use as a streaming source (Tidal, etc, via browser). It would be positioned next to the DSPi and the two connected via USB. DAC is there as well. Would a 4GB model be adequate for this use case?

 

[john61ct]

Overkill. RPi4B is the sweet spot for if your I/O to the host is stereo only.

Note the DSPi Pico requires a host computer, and your RPi can do that

as well as also run CamillaDSP, say if you need FIR convolving. Even then 2GB likely plenty, but 4GB gives overkill at a small price difference.

Your RPi HATs doing audio I/O will already give you a DAC

 

[Rocky Maine]

Overkill. RPi4B is the sweet spot for if your I/O to the host is stereo only.

Note the DSPi Pico requires a host computer, and your RPi can do that

as well as also run CamillaDSP, say if you need FIR convolving. Even then 2GB likely plenty, but 4GB gives overkill at a small price difference.

Your RPi HATs doing audio I/O will already give you a DAC

RPi4B sounds good financially. Yes, my music needs are quite straightforward. And I have the DAC already (Modi 3). This is more of a fun retirement project than anything else. Dipping my toes into Linux after a 20+ year hiatus from Unix.

 

[somebodyelse]

The browser is likely to be the most RAM-hungry bit. There are a load of images like piCorePlayer, Volumio, Moode etc. that turn a Pi into a streamer if you want something less like a traditional PC desktop. You can control them via browser or phone app. Most also support some sort of display, often including the Pi touchscreen. They've each got a different take on how things should work, and a different mix of features, so you should be able to find something that matches your preferences.

 

[john61ct]

LMS + Squeezelite are super for integrating Local file library with the internet stuff, plugins for everything, but yes geekish.

Multi-room player nodes! SqueezeDSP!

 

[DatSpeakerTho]

Note the DSPi Pico requires a host computer, and your RPi can do that

For now, i2s input will mean no host, which is what my box is built for currently. Just waiting on the update.

 

[Rocky Maine]

RPi4B sounds good financially. Yes, my music needs are quite straightforward. And I have the DAC already (Modi 3). This is more of a fun retirement project than anything else. Dipping my toes into Linux after a 20+ year hiatus from Unix.

Ended up with a RPi 5 8Gb. Currently using a 32Gb µSDXC card. When streaming via browser or VLC media player, CPU & GPU barely register utilization. htop shows about 600Mb memory use with the media player. CPU temp is 35° +/- . Fan in case has yet to spin. This is an impressive little system. Looking forward to the DSPi Terminal.