4 ms·

I don't like how it is distributed. Background: I'm using a Beocreate 4 Channel amp since a few months, and it's great (even if a little bit expensive, but it

I don't like how it is distributed. Background: I'm using a Beocreate 4 Channel amp since a few months, and it's great (even if a little bit expensive, but it perfectly fits my usecase). As mentioned elsewhere, I use it for phase correct cross overs via FIR (at 250 Hz, which means it requires lots of taps), and also for DRC and cabinet correction (same FIR filters). I "simply" adjusted their DSP program (using SigmaStudio) to my needs. The OS looks nice, and it allows to relatively easy manage DSP programs/adjustments and, what's also kind of important, playback music. BUT I have one HUGE problem with it: The whole software is only really available as an OS image. That plain sucks. This seems all the rage these days, but if I would run every piece of software on an RPi of it's own, I'd end up with a small RPi cluster in a year or two, while one RPi would be enough for all of that. I tried to build AUR packages, but this was utter frustrating to figure out which software depends on what else (the buildroot dependencies they have are good-enough, but not exact; and some software seems to be randomly split across packages) and how they're properly configured and so on. So I gave up after a few weekends and am now only running the sigmatcp server.

antoinealb 6y ago
I think the os image distribution is a way to reduce support and improve quality. It is much easier to check that the result is working in the lab rather than test packages and setup instructions. One thing you could eventually do if you wanted to go the low effort route but still share it on a raspberry pi would be to build the rootfs using buildroot in a tar archive and then import that as a container. I don't really know if it would work, perhaps you would need one container per service or something, but it could be an approach.
- jefurii 6y ago
  Devs might consider something like FPM (https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm) to make DEB/RPM/whatever packages that are a lot easier to install and manage.
- archi42 6y ago
  I understand the reasons why, and they're perfectly fine. But I still think it's a bad decision to rely solely on that approach, because I ultimately hate wasting hardware. My low effort route was to run their image in a podman systemd container, but the setup magic wasn't happy with that and some services failed and I eventually gave up debugging that. Maybe I could have setup a qemu to run it in a VM, but that requires to somehow pass through i2c and spi.

antoinealb 6y ago

I think the os image distribution is a way to reduce support and improve quality. It is much easier to check that the result is working in the lab rather than test packages and setup instructions. One thing you could eventually do if you wanted to go the low effort route but still share it on a raspberry pi would be to build the rootfs using buildroot in a tar archive and then import that as a container. I don't really know if it would work, perhaps you would need one container per service or something, but it could be an approach.

jefurii 6y ago
Devs might consider something like FPM (https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm) to make DEB/RPM/whatever packages that are a lot easier to install and manage.
archi42 6y ago
I understand the reasons why, and they're perfectly fine. But I still think it's a bad decision to rely solely on that approach, because I ultimately hate wasting hardware. My low effort route was to run their image in a podman systemd container, but the setup magic wasn't happy with that and some services failed and I eventually gave up debugging that. Maybe I could have setup a qemu to run it in a VM, but that requires to somehow pass through i2c and spi.