Liquidsoap 2 (beta) ARMHF (32-bit) debs

[technicaldesign]

Hello and thank you for your fantastic software and for the excellent documentation, including the new book. Would it be possible to add ARMHF (32-bit) Liquidsoap 2 debs (for Debian 11 Bullseye) to your repos, even now that it is in beta, so that we can start gaining confidence with it? I'm asking because I haven't been able to follow the recommended installation process (using OPAM) on my BeagleBone Black, because of compilation failure due to memory constraints (both RAM < 1Gb and hard disk space). Setting up a cross-compilation environment for such a method seems too tricky and the outcome too uncertain and unstable for my skills.

[toots]

Hi! Thanks for the kind words! I would love to add builds for those architectures but I do not have access to such hardware at the moment. Would you by any chance have some machines around that I could use for it? Romain Le lun. 23 août 2021 à 09:47, technicaldesign ***@***.***> a écrit :

…

Hello and thank you for your fantastic software and for the excellent documentation, including the new book. Would it be possible to add ARMHF (32-bit) Liquidsoap 2 debs (for Debian 11 Bullseye) to your repos, even now that it is in beta, so that we can start gaining confidence with it? I'm asking because I haven't been able to follow the recommended installation process (using OPAM) on my BeagleBone Black, because of compilation failure due to memory constraints (both RAM < 1Gb and hard disk space). Setting up a cross-compilation environment for such a method seems too tricky and the outcome too uncertain and unstable for my skills. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1844>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGUVFAE7P347DKKR3EEJGDT6H4IFANCNFSM5CT7ZVXA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[technicaldesign]

Hi and thank you for your kind and immediate reply. Sadly my old BeagleBone Black is the only board I have and it's not even exposed on the Internet, since I only have a mobile connection. BTW it only has 512Mb of RAM and 4gbs of MMC (mostly eaten up by the Debian 11 OS) so that's why it fails at compiling. Perhaps you could use the same machine you build your ARM64 debs on (if you don't cross-compile) and just boot an ARMHF version of the OS you are using, I suspect the hardware should be backwards-compatible (I say this because apparently the Raspberry PI has been running a 32-bit OS on 64-bit HW for a while). I would be very grateful if you provided the 2.0 debs because I wouldn't want to ditch my local setup just because of this issue and this new version of LS looks like it's a real game changer going forward. Audio streaming is a great application for legacy 32-bit systems that we can recycle and your software works perfectly!

[toots]

I was able to build a base image for this architecture that should be usable in our CI workflow: https://hub.docker.com/layers/163956466/savonet/liquidsoap-ci/arm32v7_debian_bullseye_armhf/images/sha256-79ee367d131a64f5459a6d35f8f6ed5b2c2f778af9e7dec476a4ed80e3704824?context=repo

However, I'm having trouble integrating it into the normal workflow as this needs some cross-compilation magic. But hopefully we can make this work!

[technicaldesign]

Thank you so much! In the last couple of days I was peeking in the actions page once I realized you took action (not that I could figure out what was going on apart from the build failures, since I'm not skilled enough). I almost felt guilty that I had made this request, since it would probably benefit a tiny percentage of your potential user base. This would, however, make this superb software available to many legacy 32-bit RPi owners (I have a Beaglebone Black) so that they could recycle them for this application and could learn on them (like I'm doing). It should be said that the processing power available on these boards is very borderline, especially in terms of using the new functionality. They already struggle with real-time re-encoding, for example when using transitions, like in my case, since I'm trying to use OGG/OPUS to keep quality and native metadata (libshine MP3 might improve the situation, as I have witnessed trying out other software that also uses FFMPEG, even on my board that does have an FPU), so I suspect the new video functionality will not be realistically available.

Regarding your efforts, with the due comparison in programming skills (I'm an amateur), I find that perseverance usually pays out and leads to learning, stronger self-confidence and better overall code, but feel free to drop the issue if it is too time and resource consuming and if it subtracts energy from much more important tasks, I really appreciate it already!

PS there are also a lot of legacy Intel 386 32-bit machines around (many notebooks, I have an old little EeePC, I might try to install 2.0 through the recommended process, but I'm still not sure that I have enough disk space to complete it) which could be ideal to run Debian and Liquidsoap and might be powerful enough to be useful with LS 2.0. I wonder how automated your workflow is so that once your environment is set up, it is automatic. Perhaps you could just label such 32-bit builds as experimental or for educational / non production purposes only so that you're not dragged into supporting obscure bugs.

Once again, thank you for your amazing work (BTW as a newbie, I've started reading the 2.0 book and it's awesome!).

All the best from Rome, Italy
Stefano

[technicaldesign]

Wow I'm so excited and happy, thank you++! I'm currently running Liquidsoap 2.0 on my Beaglebone Black on Debian armhf (32-bit) Bullseye. Installation was a breeze, all dependencies were fully available on the standard repos for the architecture. I Just modified my old very basic v1.43 .liq script (based on the complete case analysis) according to the awesome documentation (all that I had to change was the log and telnet lines) and it just executed fine. The only problem that I found was that it displays a "HTTP error 404 File Not Found" warning which seems to be related to the "# Add the ability to relay live shows" feature (as in the CCA example) where it looks like LS is checking for the live stream to be present (which is not the case by default) and complains (which it actually shouldn't do since the stream is supposed to kick in optionally), even though it does correctly fall back to the local playlist. When I removed that feature from the script the error disappeared, however it's somewhat annoying because it checks constantly and keeps on showing up on the log, which is otherwise clean. I retried back with v1.43 and it doesn't behave like that. I must check again better on the documentation if I did something wrong (that portion of the script looks unchanged between v1.43 and DEV doc) and also parse the discussions re 2.0 for explanation, but, for the time being I just wanted to thank you for the great and successful porting effort over the last week or so, which is clearly almost completed (looks like you just have one minor bump with the alpine apk release).

EDIT >>> I think I might have figured out the problem, which could be due to using (as suggested in the DEV CCA example) the methods "input.http()", but now I have tried with the "input.harbor()" and the errors disappear. It could be that there is a different way the two methods are handled in terms of polling and logging between versions 1.x and 2.0. If this is the case, it might be useful to amend the CCA examples in the docs.

All the best,
Stefano

[toots]

Glad to hear it's working out for you! Just merged the changes into main. That was my last TODO before making a rc branch!

[technicaldesign]

Amazing work, armhf build all green, mission accomplished! Will switch to RC1 ASAP. Thank you for your consideration.

Stefano