Any thoughts on how to disable the Raspi3 on-board sound card? I need to stop the snd_bcm2835 module from loading. I have been unable to disable it inside the resin container.
Sorry, what do you mean by being unable to disable it?
Usually modules that are automatically loaded are just removed with
rmmod for example in the start script of the application. Just checked, and normally
rmmod snd_bcm2835 should work (probably with some thought around it).
By the way, what sort of use case you have in mind?
If you are trying to send the audio over HDMI instead of the onboard audio, then you can do that by enabling these options in
(which can be done remotely better with with Fleet or Device configuration
RESIN_HOST_CONFIG_hdmi_group set to
RESIN_HOST_CONFIG_hdmi_drive set to
2). See more info in the list of the available
config.txt settings on the Raspberry Pi site.
Thanks @imrehg, I’ll give
rmmod a try.
It needs to be disabled for hardware timing reasons:
Shouldn’t setting the device config variable
audio=off disable on-board sound? (I tried setting it but
snd_bcm2835 was still loaded.)
How come ResinOS loads
snd_bcm2835 even though there’s no
config.txt (like in Raspbian)?
First off, whatever works on Raspbian should work on resinOS as well, because we are using their config/kernel/etc, provided that you are comparing the specific Raspbian version where that kernel/firmware was used (that is not to compare across software versions, e.g. kernel 4.4 Raspbian with kernel 4.1.21 resinOS).
I’ve tried it out a bit, and there seems to be indeed a discrepancy, will check it out in more detail and get back with whatever we find!
Looks like found the culprit. As my colleague @andrei pointed it out, the sound module is actually manually loaded on the Raspberry Pi by the current setup: resin-init-board. I’m guessing this is for historical reasons, but it’s definitely not a correct behaviour (as we are thinking now, based on your feedback and all). We’ll be checking out how to fix this while not breaking existing applications that rely on this behaviour (I do have a couple that would be broken by removing this, even if I didn’t know before ).
In the meantime, manually removing the module with
rmmod at the application start is probably the best. In general we think it’s better to explicitly specify and load the modules you need with
modprobe in the beginning of your application as well. (explicit requirements and less magic is more reliable for everyone - we are only halfway there in this case)
Hey guys, just to let you know, I have popped an issue up on the resinOS repo for this, so just subscribe to this: https://github.com/resin-os/resinos/issues/195 and hopefully we can get it fixed and working as expected asap.
rmmod does seem to be working for the time being. Though it tells me that the module isn’t loaded when I run it. Is that something that is persisting through restarts, so that maybe it worked the first time but now it still sees the module as unloaded?
If it’s container restarts with the device staying on (e.g. when you
git push resin master or restart just the container) that could be the case, yeah. Though it’s not a worry – running
rmmod against a module that’s not loaded won’t actually have any bad effects. You just get the warning message that the module isn’t actually loaded.
You could suppress that if you want by doing something like
rmmod modulename 2&> /dev/null
if it is a concern.
@danielmahon do you get the libary work on a Pi3 to show images or something to the LEDMatrixes?
@MariusSG5 Yes! I am using a Raspi3 (on resin) to run Pixel Pusher server and display on 12 32x64 led matrix panels from Adafruit. An Intel NUC (on resin) is running an ElectronJS interface which controls a Processing sketch which is broadcasting to the Pixel Pusher server at ~30fps.
Do yo have also tried to get the HDMI Signal from the Pi over the Adafruit Hat on the led matrix panels from Adafruit.
Because i want to display the HDMI Signal of the Pi to 24 32x64 led matrix panels, the libary compiled and works but i did not got any Signals to the panels
I have. But you will never be able to power that many displays over the Pi hat unfortunately (to my knowledge). The signal will degrade too quickly and the entire setup is unstable as it is. Took me weeks to get it stable enough for production. Check out https://github.com/hzeller/rpi-rgb-led-matrix, I used that library and a custom built “active adapter” described there to run my panels in parallel.
Also, the trick is to get it to work with a small number of panels first. Then once it’s running smoothly, start slowly adding sets of panels until you run into problems. My guess is that you will need to run 3 parallel signal lines to get 24 panels to work. Make sure you have plenty of power to the panels. I think I had a 500W supply.
Yes my Problem is maybe the Problem you said 24 are to much for 1 Pi with the Adafruit HAT. I get it work on 12 Display with the library from Adafruit https://learn.adafruit.com/raspberry-pi-led-matrix-display/software
But when i take 24 only about 19 Panels works but the Signal is at Panel 20 also activ and the Adafruit links to the hzeller library so i want to check if this library maybe works with the Size of the Panels. Do you only work with 12 panels or do you try it also with more panels?
I had twelve but I only used 2 of the 3 available channels on the adapter. The Pi3 can push 3 channels. I think the theoretical limit is higher than 12. Though keep in mind being 32x64 panels, 12 really means 24. Since they are just two joined 32 panels. So you’re pushing 48 panels. Check the issues/wiki in that repo for more info on getting it to work. I think you could make 24 work but I’d bet you’d need that active adapter so you can split the signal power and ditch the adafruit hat. You’ll have to do some SMD soldering if you build the adapter yourself so just watch your connections. Also, not sure if your using pixel pusher but it does work nice although there is also a row length limit that you’d have to dig into if you needed to support something larger.