After upgrading the ssd in the reform I started using the new Image V4 and am really liking it so far.
I’ve opened this thread to share things that I noticed, either minor issues or praises, so if you tried the new image, feel free to share your thoughts here.
I, for one, love the fact tat Lukas doubled down on sway and wayfire. Now we get one floating and one tiling window manager, both of which are pretty lightweight and comfortable to use.
The addition of reform-tray has made the system in general beginner friendly and I really appreciate that.
Some things I’ve noticed:
There is a package missing, pulseaudio-utils for providing pactl used in the sway config to control volume
reform-tray could use systemctl poweroff/reboot to turn off instead of pkexec shutdown/reboot now. Right now it will show a password before shutting down
I was thinking about suggesting a suspend option, but held off considering the flakyness of it for some users.
Unfortunately, there has been an issue with the new images for me, where I cannot connect to WiFis anymore. It will endlessly connect disconnect with seemingly conflicting error messages. I will post a kernel-log soon.
I have heard the same issue from jfred in IRC after an apt upgrade. It looks like the commandline args for imx8mq are not picked up correctly, esp. pci=nomsi.
Edit: it looks like some of our u-boot deployments on imx8mq have the board name “MNT Reform 2.0” instead of “nitrogen8m_som”.
Please note, that when you make changes to files in /usr/share, those changes will be overwritten once you upgrade the package that this file belongs to.
The good news is, that with reform-tools 0.30 (the package that would overwrite this file), this issue is fixed and you do not need to manually edit anything, just make sure you have reform-tools 0.30 or later installed.
@minute have you considered shipping the kernel with CONFIG_PREEMPT_DYNAMIC=y? That would allow setting preempt=none|voluntary|full on the kernel command line for more (or less) realtime-oriented setups as required.
The new A311D is very pleasant to use and it can almost do live realtime audio (with a multitrack synthy project) at audio buffer sizes above 256, so I’m trying to tune the system a bit further to see if’s possible to make it run with 256 or 128-sample sized buffers.
Alternatively, what’s the current recommended way of building a kernel with a custom config and installing it to the SD card? Is reform-debian-packages/linux a good place to start?
I think it would make sense for you to first try out this setting yourself and then report back what it improves for you. I’d also like to talk with Debian linux maintainers about that option. To compile yourself a custom kernel, you clone the reform-debian-packages git and run:
If you want to add another kernel config option, just put it into linux/config where also the other custom options live. Building natively on the reform takes around six hours on imx8mq. Would be nice to have some numbers for that on the a311d.
Trying to do the above (after installing a few missing packages using .gitlab-ci.yml for reference) I am hitting this error when sbuild starts:
W: No chroots are defined in ‘/etc/schroot/schroot.conf’ or ‘/etc/schroot/chroot.d’
W: No chroots are defined in ‘/etc/schroot/schroot.conf’ or ‘/etc/schroot/chroot.d’
E: unstable-arm64: Chroot not found
Chroot setup failed
E: Error creating chroot session: skipping linux
If I create ~/.sbuildrc with $chroot_mode = "unshare";, I have a different error:
I: No tarballs found in /home/art/.cache/sbuild
Unable to find unstable-arm64 in /home/art/.cache/sbuild
E: Error creating chroot session: skipping linux
Is there any prerequisite I might have missed when running the script?
Yes, you need to have sbuild set up and working. One way to do that is to use $chroot_mode = "unshare"; in your ~/.sbuildrc. But independent on what chroot backend you choose, you have to have a chroot tarball prepared and put it into one of the search paths. For unshare mode, that is ~/.cache/sbuild. So after creating that directory, you can create a tarball like this (assuming you are on arm64):
Thank you for the help, I’ve managed to build it with the bundled config in a bit less than 3 hours. Going to try playing with preempt options now and see if that helps with my original problem!
So far CONFIG_PREEMPT_DYNAMIC works well and seems to improve audio performance with preempt=full. I was unable to get rid of clicks completely under heavier load, but it’s much better. Renoise can almost run a relatively complex demo song with preempt=full with occasional xruns:
CONFIG_PREEMPT_DYNAMIC also provides a way to switch preempt at runtime by writing to /sys/kernel/debug/sched/preempt.
To enable preemption, I had to add the following options to reform-debian-packages/linux/config:
CONFIG_PREEMPT=y
CONFIG_PREEMPT_DYNAMIC=y
The system will boot with preempt=full by default.
Previous Reform config from the original system image had CONFIG_PREEMPT_VOLUNTARY=y too, so I think it might be a good idea to keep voluntary as the default, this is what recent Fedora also does (while having dynamic preempt enabled).
Going to try enabling that as default and do a rebuild too. If that is something that you think makes sense to have in the factory image, I’m happy to submit a PR.
After running the system with dynamic preemption for the last couple of days I haven’t noticed any regressions, so I have raised a PR for the kernel package, @josch could you please have a look?
The CI pipeline fails to run for some reason, is that because forks cannot run CI? It builds and runs very well locally though.
This is very interesting, thanks for sharing the video also! From my POV we should merge this. But I also wonder what is the culprit of the remaining clicks in the sound, because the CPU load looks pretty OK to me. Could it be USB or interrupt related?
Thank you @artfwo for your well worded case and merge request. In Debian, amd64 already has this enabled by default and I wondered whether there was a reason why it is not enabled for arm64. The setting is not explicitly enabled or disabled by the Debian kernel build but the default comes from the upstream kernel. I raised a discussion about this with the Debian kernel maintainers:
I’m not in a position to decide on this MR. If @minute thinks it’s okay then it will happen. Otherwise I guess we’ll see what the result of the thread on the debian linux kernel mailinglist is.
Hard to say, as the CPU load is OK indeed. The clicks also happen with the internal audio. In the past I have encountered USB (and Firewire) interfaces clicking, because of sharing interrupts with the laptop WiFi, but I’ve been testing this setup with WiFi softly switched off. Perhaps something else is sharing the interrupt on Reform? Is there any way to test this?
I have tried another compile-time kernel option that’s highly recommended on the internet: CONFIG_HZ=1000 (specifically CONFIG_HZ_1000=y in the reform build config), but that seems to have no effect on the audio xruns for me.
I am going to try tuning pipewire a bit more, in particular setting api.alsa.period-num and api.alsa.period-size with wireplumber (I’m currently at 256/48000 “latency” option), there is a number of online recommendations regarding this too, but more on the “magic that works” side.
pipewire seems to be the problem indeed. After stopping it completely and re-running Renoise with raw ALSA, I was able to achieve click-free* playback of the demo songs with audio buffer size of 128x3 (8ms latency with 48000 output sample-rate). This is on a freshly built kernel with dynamic preemption (set to full) and without CONFIG_HZ=1000. Tested with the internal audio and several external USB audio interfaces.
Going to keep digging why pipewire is failing in the default configuration - it works great on my other x86_64 machine with Fedora.
Overall, with the above caveats, looks like the latest OS with A311d hardware can be a good audio workhorse for some use-cases, this is getting exciting
[*] The built-in Convolver effect still requires larger buffers and will produce clicks no matter what. Weird, I thought this issue was fixed long ago.
Further tests confirm that pipewire was the original culprit for audio xruns. I have rebuilt the kernel with the stock configuration (disabling dynamic preemption and CONFIG_HZ). And again, after disabling pipewire, I no longer experience any clicks, but this time not even with the Convolver effect - this runs at buffers as low as 64 samples (4ms latency).
At first sight, it looks like without pipewire the stock v4 kernel performs better with CONFIG_PREEMPT_VOLUNTARY=y, so that might be one of the reasons why dynamic preemption is not enabled on arm64 by default?
I’ll mark the above PR as draft until I’m able to do some more tests.
