Never change a running system - my pirate radio need to be reinstalled with jessie for stability!
It seems that the stretch distribution is not really stabile. After several reboots the system doesn’t start properly. Sound or LED is not available.
Did you actually update from to with sudo apt get dist-update? Or start fresh with Stretch?
That’s curious. Did you do a dist-upgrade from Jessie to Stretch? I find those tend to turn my SD cards to mush.
With Stretch being hot off the press (the Raspbian flavour of it at least) there’s still plenty of things we haven’t tested- so bear with me while we flail through debugging steps.
I did a update like explained on raspberrypi.org.
Fortunally I have a few sd cards so I can test even with directly flashed Stretch.
From here, https://www.raspberrypi.org/blog/ Down in the “How to get Raspbian Stretch” part
"Upgrading an existing Jessie image is possible, but is not guaranteed to work in every circumstance." ;)
I have so far deliberately avoided going that route. Mainly because of all the file edits. And that it might not work anyway. I won’t upgrade my Pirate Radio to Stretch until I have to redo the card because it won’t work anymore. I run it headless anyway so no real advantage to doing it now. Pretty well the same deal with most of my Pi’s. Most run headless, or aren’t running Raspbian anyway. I have one I’m going to do a fresh image on. It’s a 3B with a Pi Foundation touch screen on it. It’s in need of a redo anyway. It has lots of stuff installed for testing sensors and breakout board’s cluttering it up. Those boards were tested and then moved to other projects.
I will check - in the moment I prepaire 2 SD cards - Jessie & Stretch for the Pirate Radio - I’ll give feedback!
I have also got some problems with the VU meter on the Phat Beat. Installed Stretch from scratch… It is blinking, but only the left LEDs and there only the last 2. Even if I turn the volume up or down, nothing changes.
I’ve had a few reports of the VU meter failing on Stretch, it’s something I hadn’t tested beforehand since I made the (incorrect) assumption that it would just work. From experience with past updates it’s only usually Unicorn HAT that gives me trouble :D
I’m now fixing Flotilla, which is my own fault for not packaging it properly yet, and will look into pHAT BEAT/Speaker pHAT/ETC and the wider landscape of Pi VU Meter (which I’m still keen to move to sockets + Python) on Monday when I can get my hands on the boards to test against.
1 Like
Did a fresh install of Stretch yesterday for my Pirate Radio. Pi VU Meter works as expected, no problems at all.
AirPlay also works fine, but from time to time there’s a strange echo in the audio. No idea what causes it. Internet radio via VLC works, but can’t be restarted after playback is stopped/paused or reaches the end of the playlist.
Disclaimer: Just got my Pirate Radio on Friday, so I don’t know if any of these behaviors are also present in Jessie.
Yes, I am experiencing the same issue with VLC. It crashes once you reach the end of a playlist or you click play/pause. I am also unable to go to the webclient afterward. But I also think that this is a issue with VLC itself rather than a Phat Beat specific one, but I don´t know ;). And no, these behaviours were not present in Jessie. Everything worked fine there.
1 Like
It’s possible the crash is happening in Pi VU Meter/ALSA when the audio device is closed, and subsequently taking everything else with it. I’ll look into it.
I experience a similar crashing issue on my radio, however, I leave mine on constantly, and it often fixes itself overnight! (Might be useful information. :D ) This is on Jessie however!
Mine will just stop, freeze, sometimes. No sound and VU meter just stays lit at what ever it was showing when it stopped. Pressing play/pause starts it again as if nothing had happened. Most times anyway. Also still on Jessie. I just assumed it lost the stream or something. Changing channels gets it going again too. I haven’t had a total lockup, have to reboot, in a while. I have a button wired to the Pi’s RUN pins. I shut down with the pHat Beat power button, and press the RUN button to start it up again. I don’t ever unplug the power supply. I added my own buttons in place of the those mini buttons on the pHat Beat. Mini arcade buttons mounted in the top of my case. makes it easy to change channels, or volume etc. Especially when I can’t find the IR remote control. Mine is mounted in an old subwoofer box. No easy access to the actual buttons on the pHat Beat.
Same problems with Speaker PHAT and a brand new stretch install. symptom is a long pause then a segmentation fault after any playback completes (mplayer, aplay, speaker-test etc).
gdb traceback dump below for mplayer - same for the others - hope this helps.
thread 2 “mplayer” received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xaf87b1a0 (LWP 9071)]
get_channel_level (channel=channel@entry=0, offset=offset@entry=25788,
size1=size1@entry=39748, size2=874512448, size2@entry=3068139472,
max_decay=max_decay@entry=3650617, max_decay_temp=,
level=, level=) at src/pivumeter.c:116
116 s = *ptr;
(gdb) bt
#0 get_channel_level (channel=channel@entry=0, offset=offset@entry=25788,
size1=size1@entry=39748, size2=874512448, size2@entry=3068139472,
max_decay=max_decay@entry=3650617, max_decay_temp=,
level=, level=) at src/pivumeter.c:116
#1 0xafa27518 in level_update (scope=) at src/pivumeter.c:171
#2 0xb6e00d34 in ?? () from /usr/lib/arm-linux-gnueabihf/libasound.so.2
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I’ve been looking into the intermittent Segfault that pops up, even when just playing a wav file via aplay. It’s - as far as I can tell - the fault of Pi VU Meter, but I couldn’t get it to happen within gdb to figure out where it was going wrong.
In all cases of instability with audio, I’d point the finger at Pi VU Meter and suggest you back up and remove the “asound.conf” to disable Pi VU Meter and see if the problem goes away.
I’d hoped the idea of a VU meter ALSA plugin for Raspberry Pi add-ons would attract the attention of slightly more seasoned C developers to pick apart my code, but thus far that hasn’t been the case :(
If I could only program better in C, I would. Sadly, as you might have guessed, I can’t… :/
@gadgetoid I have deleted “asound.conf” but still the problems occur. Raspbian Stretch has changed more “than expected”…
Dang! Even with a from-scratch install. Bizarre! Playing a radio stream from the internet is hardly the most novel of use cases :D
On my Jessie radio setup I’ve been playing songs from Spotify and radio streams via VLC through pulse at the same time and starting/stopping both repeatedly for testing so perhaps it is a Stretch regression.
Hmm… I have installed Jessie again and everything works like it should. Really strange…
Okay, I’ve done a bit of sleuthing into this and found that the issue lies with “dmix” rather than Pi VU Meter
Removing dmix from the equation gets audio output- including Pi VU Meter- up and running stably again.
Dmix was included in an attempt to allow multiple audio streams to output to the same device, which is not really an issue with Pirate Radio and probably something better solved with Pulse Audio (since it also solves the popping issue).
I’m not 100% sure what’s happening, but since the plugins in ALSA seem to share access to the same PCM channel buffer my hypothesis is that dmix is silently corrupting or trashing it somehow and that, in turn, causes Pi VU Meter to segfault when it tries to access it.
I am still testing this configuration on my own Pirate Radio setup, but so far it’s run for longer than 2 minutes and most fails have been at the 1-2 minute mark, so it looks pretty promising.
Now, an actionable fix for Stretch users? Just replce your /etc/asound.conf with the following:
pcm.!default {
type plug
slave.pcm "softvol_and_pivumeter"
}
ctl.!default {
type hw
card 0
}
pcm.pivumeter {
type meter
slave.pcm "hw:0,0"
scopes.0 pivumeter
}
pcm.softvol_and_pivumeter {
type softvol
slave.pcm "pivumeter"
control {
name "PCM"
card 0
}
}
pcm_scope.pivumeter {
type pivumeter
decay_ms 500
peak_ms 400
brightness 128
output_device phat-beat
}
pcm_scope_type.pivumeter {
lib /usr/local/lib/libpivumeter.so
}
pcm.dsp0 pivumeter
1 Like