Nah you’ve been massively helpful thus far so no stress.
Getting back to the real issue, to be honest I don’t know whats going wrong? I have the pHat Beat running internet radio. I get a similar occurrence every once in a while when a stream gets lost. Usually just switching to another stream, or pressing the play pause button fixes it. You have a totally different issue. Hopefully @gadgetoid can help you sort out what’s happening. I’m a noob at the inner workings of Linux.
I’m the other side of the coin, lol. It’s been the hardware side of things for me. Latter on in my career the software was what I used to run diagnostics on the hardware. But that was written by somebody else, and I had no control over that. All I did was fix and maintain the hardware. I just turned 60 and have been soldering since I was in my teens. Its just second nature to me now. I didn’t learn any coding until after I retired and started playing around with my first raspberry Pi. I’m still no Python expert, but it doesn’t intimidate me it like it used to.
Anyway I really hope you sort this out. Its so much fun when things come together. But it can also be really frustrating when they don’t. I’ve had my share of those situations so I know what that’s like.
1 Like
I went diving into the logs but I’m not really seeing anything interesting or unexpected. I guess the power issue is the likely cause, but I’m unsure how to go forward at this point.
/var/log/syslog
Jun 2 20:11:31 raspberrypi pulseaudio[426]: Using device: speaker-phat
Jun 2 20:11:35 raspberrypi pulseaudio[426]: Using device: speaker-phat
/var/log/daemon.log
Jun 2 20:10:43 raspberrypi systemd[1]: Stopped PulseAudio Daemon.
Jun 2 20:10:43 raspberrypi systemd[1]: Started PulseAudio Daemon.
Jun 2 20:10:43 raspberrypi pulseaudio[425]: Using device: speaker-phat
/var/log/messages
Jun 2 20:10:43 raspberrypi pulseaudio[425]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
/var/log/user.log
Jun 2 20:10:43 raspberrypi pulseaudio[425]: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified).
OMG HOLY SHIT I’m an idiot and I fixed it. I shoulda paid more attention to power concerns initially. The USB cable I had connecting to the RASP PI power converter had a SPIRAL in it. Which okay sure looks rad as hell, but also makes the cable super long and so the drop over that length cause the pi zero to not have enough power while driving the speaker.
I’m sorry @alphanumeric I feel like I wasted so much of your time, but thank you for rubberducking with me.
1 Like
No problem, don’t worry about it. I enjoy this stuff. You learned something so that’s cool. If you hadn’t been running headless you would have seen a lightning bolt symbol flash up on the screen indicating a low voltage condition. I’m pretty sure you don’t see that over SSH. You’d have to be doing it with remote desktop in a GUI environment.
I find the Pi Zero is especially prone to stuff like this. I have my Pirate Radio wired up to a 5v 4A power supply with a Y cable on it. When I plug my other Pi into the other lead from the Y my Pirate radio starts up all on its own. When I shut down my Pirate Radio I leave it powered up. I have a button wired to the run terminals to boot it up when I want to listen to my tunes. It saves me from having to unplug it and plug it back in to start it up. The power bump or spike when the other Pi is connected makes it boot up.
I’ve also had Pi Zero’s reboot and or boot up when I plug something into the OTG USB port. If I plug a hub in, and plug devices into that its fine. Direct connections to the OTG jack not so much?
1 Like
This comment is “not” directed at you. Just have to get it off of my chest. One of my biggest pet peeves is people determined to get something for the absolute cheapest price. Like E-Bay for example. Then complain because that 50 cent item doesn’t work like the 5 dollar item on a reputable site selling quality items. Power supplies is one of those items. And the power cords.
Some sites will sell 5.2V supplies with nice thick beefy wires. Those are the ones I look for. Even if you get a voltage drop, you still get 5V at the Pi input. ;)
If you have a Pi 3B or 3B+ it becomes even more important to get a good quality supply. IMHO even the official 2,5A supply is getting iffy if you have a lot of “Hardware All on Top”. I believe that’s what HAT stands for?
It’s always the USB cables. I’ve bought replacements for things only to find the USB cable was bad. They’re conspiring against us!
Sorry I sort of dropped off the map here- and thank you @alphanumeric for consistently being awesome in my absence! (and when I’m here, too)
1 Like
@gadgetoid I’m retired so every day is a holiday, lol. You only get two days a week you can call yours so I try not to bug you unless I have to on the weekend. ;) I think most people know the weekend isn’t the best time to look for answers on a forum. I learned that long ago. I’ve also learned a lot from you, keep up the good work. =)
Power supplies (and the cables) are IMHO a big issue for the Pi. Especially with the 3B and 3B+. With all the cool Hats and pHats and Bonnets etc, you need a good reliable power supply. I don’t blame people for “trying” to use what they have on hand, a lot of the time it will work. Just please don’t buy that E-Bay el- cheapo junk.
1 Like
If we could leave the I2S clock running all the time we shouldn’t get any clicks. Now that leaves a DC voltage on the speaker which could be solved with a series capacitor to the speaker so no DC voltage would ever be present on it.
So how do we keep the I2S channel continuously open and sending clock to the DAC?
I believe the main issue is that the i2s clock continues running, but the LRClock does not since presumably incoming samples are required to know what state the LRClock should be in. This state is totally incompatible with the DAC. This change happened somewhere between our initial development/testing of the boards, and their general release, which is frustrating. I found several ways to fix it in software- including running PulseAudio on the Pi to continuously play “silence” where no other audio output is active. On PiratePython for Pirate Radio I directly modified the kernel module to stop the clock when no audio is playing.
As far as I can glean, this is a bug in the kernel module (don’t quote me on this, it’s a complex subject I don’t fully understand and I don’t want to throw anyone under the bus), but may also be something that other boards rely upon so it cannot readily be fixed.
We’ve since implemented a fix in hardware in a new revision, but for older versions there’s Pulse Audio or the PirateRadio software both of which work pretty handily. Lesson learned to never trust a data bus to behave how you might expect it, or to continue to do so either!
How complex is the hardware modification? Being a retired engineer I don’t personally have an issue making the modification. Back in my day I used to do ECOs all the time. Still for 12 bucks US I’m not going to cry over it, I can still use the board in the garage where a few clicks isn’t a big deal.
That said, how long before one can get the new board and are any of the other I2S boards you have going to get the same basic modification?
Considering what I’m using them for, my home automation system alerts, I would’t mind a board with just a wee bit more punch say 4-5 W, I don’t use the internal speaker, and still just mono.
The new boards have been in circulation for some months now, as far as I’m aware! When/where did you purchase yours? I don’t believe it’s pop proof (powering on/off still causes issues), but should be significantly reduced.
Picked mine up at my local Microcenter so it may have been older stock. Does Adafruit now have the newer boards?
I have one of the older original boards. With the new installer / software I only hear one or two pops on boot up. After that no more pops when pushing buttons and changing channels etc.