MODEP no longer running following rpi-update

#1

Hi

I have recently picked up an audioinjector soundcard to use with my Pi running MODEP.
In order to install the necessary gubbins it states it needs rpi-update to be ran, and a few adjustments to the /boot/config to update which audio device is loaded.

Before running this update the software booted and performed as expected, finding the audioinjector card as you’d like to see (I’m only doing this update as the card’s ins and outs were not usable in alsamixer. But following the update the Access Point is no longer available to connect to.

Is there anything in a kernel update that would bring this down?

Thanks for your time

0 Likes

#2

Hi, no, not really.

Does the system work otherwise? Can you access it via an ethernet cable or keyboard & monitor?

0 Likes

#3

Thanks for your reply @Giedrius. I performed the update via Ethernet and all seemed fine via SSH.
I will try again this evening to see if I can still connect to it that way.
I hope it’s something simple.

0 Likes

#4

Hey, I ran in to this issue recently, after running an apt-get update and apt-get upgrade, on a raspberry pi running MODEP, but not on official pisound hardware.

I shoddily fixed it by commenting out some offending lines in the script that enables the wifi hotspot, which caused it to just exit when it does not find a ‘pisound’ midi device. The location of the script is:

/usr/local/pisound/scripts/pisound-btn/enable_wifi_hotspot.sh

If you edit the script to comment out the common function source, and the lines for flash_leds, then you should be able to run the wifi setup script successfully:

. /usr/local/pisound/scripts/common/common.sh
flash_leds 1
# and then this at the bottom
flash_leds 20

I have not yet taken the time to fix the code properly and make a pull request for it, but it should not be too hard, and I’ll look into it shortly.

Hopefully that gets you back up and running!

4 Likes

Connecting hotspot to Lemur on iPhone
#5

Thank you so much for this buddy! When I’m back from holiday next week I will give this a go!

0 Likes

#6

Thank you @whofferbert for pointing this out, I released an update to pisound-btn package (1.09-2) which fixes the flash_leds early exit issue. (https://github.com/BlokasLabs/pisound/commit/8b66cb6247e7517675a0c34dcec50774b795ec5d)

To get the fix on MODEP:

sudo apt update
sudo apt install pisound-btn

sudo systemctl enable wifi-hotspot
sudo systemctl start wifi-hotspot
2 Likes

#7

Hey, glad to help. Thanks for getting the code fixed properly! :slight_smile:

1 Like

#8

Hey buddy

Tried this update, and still not able to find the hotspot I’m afraid.

0 Likes

#9

Hey,

There was kind of a lot of information to cover, but I just put up a lengthy post, detailing stuff about the WiFi on MODEP, how it’s probably broken, and how you can fix it:

I hope the troubleshooting steps there helps get this sorted out for you.

3 Likes

#10

Thank you for your help and patience buddy.
I will give this a go tonight.

0 Likes

#11

Hey Craig,

I did a bit more testing at home, and found that I too had (different, non-wifi) issues with rpi-update and an Audioinjector sound card (the Octo). I can confirm that on my system as well, after an rpi-update (or now also, apt-get upgrade s as well), the sound card is not detected any longer. This did not keep my WiFi hotspot from working, but it did break everything else that I cared about!

You will probably want to log in to your pi, run the dmesg command, and review the output. Problems generally highlighted in red, to draw your attention there. You might see something like this:

[    6.701854] audioinjector-octo soc:sound: ASoC: CODEC DAI cs42448 not registered - will retry
[    6.701870] audioinjector-octo soc:sound: snd_soc_register_card failed (-517)
[    8.261814] audioinjector-octo soc:sound: ASoC: CODEC DAI cs42448 not registered - will retry
[    8.261827] audioinjector-octo soc:sound: snd_soc_register_card failed (-517)

That’s how it looks when the kernel can’t deal with setting up the sound card (the Octo at least).

It appears that some changes in the most recent 4.19 kernels are also causing issues for these cards. Fortunately, this fix is not too involved.

It is possible to use the rpi-update command again, and point it at an older commit to revert back to an older kernel. You can review the available commits here: https://github.com/Hexxeh/rpi-firmware/commits

I decided to roll back to the last kernel in the 4.14 branch where things seemed to all work before: 4.14.98:
sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b

After the upgrade (downgrade) back to the 4.14 branch, and a reboot, my Octo is happily recognized again, as expected.


Now, the other half of this problem is that if you like to keep your packages up to date (apt-get update / apt-get upgrade), then you can run into this problem there as well.

The raspberrypi-kernel and raspberrypi-bootloader serve as packages that update the kernel, similar to what rpi-update does. In my testing, it appears that the kernel that’s now provided by raspberrypi-kernel is causing problems for my audioinjector card as well. (package version 1.20190517-1)

To prevent those packages (and their related packages) from updating during an apt-get upgrade, we can put those packages on hold:
sudo apt-mark hold libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel

To review what packages you have held, we use apt-mark showholds:

modep@modep:~ $ apt-mark showholds
libraspberrypi-bin
libraspberrypi-dev
libraspberrypi-doc
libraspberrypi0
raspberrypi-bootloader
raspberrypi-kernel
modep@modep:~ $ 

With those packages marked as held, they should not be able to be installed, upgraded, or removed, until they are explicitly unheld. In case you need it in the future, the syntax for that would be:
sudo apt-get unhold <package list>

I won’t be able to fully reimage my system and test this all again until later, but between the other post with all the wifi info, and the kernel revert, you should hopefully have a working audioinjector setup again.

Let me know if that sorts it out for you

0 Likes

#12

Thank you for this matey. I’m glad it’s not only me having issues with this setup ha ha!
I have gone for the apt-get update and upgrade route; before doing this the card was detected but i could not enable the inputs/outputs. Doing apt-get update and install fixed this, but broke the Wi-Fi.
I had a look last night through your really helpful Wi-Fi based guide, and found that the dpkg new conf file didn’t exist; I think I’ll try to update and upgrade again and see if it highlights any problems there.

Once I’ve got this fixed I can finish building my lovely acrylic box for it and get it into action :slight_smile:

0 Likes

#13

dmesg highlighted a handful of errors.
It also highlighted a brief undervoltage as well, but have resolved that with a more reliable cable for testing.
Good job it’ll be getting fed by a 50W supply with thick gauge cables in its final enclosure ha ha.

0 Likes

#14

For my power supply, I use a laptop power supply, around 19.5 V and 4.75 A, which feeds a variable linear regulator: XL4015 (good up to 3A at least), from XLSEMI, which regulates the supply to 5.0V. That’s then also connected to a step-up isolated power supply transformer, for getting isolated 9V from the 5v linear regulator. I then have an ICL7660 later to make -9v from the isolated +9v (for analog audio stuff). It seems pretty reliable so far.

I see in your dmesg output some of the same snd_soc_register_failed that I was getting, and getting back into a 4.14 kernel fixed that for me. Have you tried the sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b + reboot yet?

The other brcmf errors seem to be pointing at your wl0 (wireless?). If your wireless interface is not named wlan0, that could possibly cause conflicts with hostapd config. If you are on a 4.14.x kernel then that might point to other wifi issues.

There are some known issues with the 4.19 kernels and various drivers, as detailed here: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=224931 , so definitely rolling back into the 4.14.x kernels would be a good troubleshooting step.

EDIT: Just wanted to add that I’m using aplay -l to verify that the sound card is recognized properly after the updates/changes. If the sound card is seen there, and the card has been specified by the same name in /usr/lib/systemd/system/jack.service, then that should be proper for MODEP.

One other thing to check are the card-specific overlay settings in /boot/config.txt. I does not look to me like the audioinjector cards have explicitly different overlays from each other, so if that’s the case, you probably want everything in that file commented out except for dtoverlay=audioinjector-addons.

Here’s a snippet from the end of my config.txt:

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on
# enable the AudioInjector.net sound card
dtoverlay=audioinjector-addons
0 Likes

#15

Thanks mate. I have rolled back the kernel to 4.14, and the soundcard appears in alsamixer and all functions are available. On the newer kernels it appears, it everything is set to ‘off’, and switching them on isn’t available.
I shall check the aplay output this evening.

I definitely suspect the issue to lie with the wlan0 setup- I’d noticed in the dmesg output that it never seems to get up and running like eth0 does. Plenty of lines stating that it isn’t ready or available yet.
I’ll also check my boot config too; I followed the guide on the audioinjector site but it’s always worth another check.

Slowly getting closer :sunglasses:

0 Likes