Hello, on last weekend I’m assembled my Pirate Radio (of course on jessie pi img) but have a problem with loud click when change station on VLC. How I can fix it?
Thanks.
Regards,
Yuri
Using Pulse Audio to keep the i2s clock running is basically the best fix for this at the moment but we’re looking into better/easier ones.
You might have some luck following my work-in-progress (and currently terrible) guide here: https://gist.github.com/Gadgetoid/3301cec3e47495e75b31d3120d8f17d9
Hello Phil,
Thanks for answer.
Sorry I noob on linux, may be you help me - like I understood I need install pulse audio (sudo apt -y install pulseaudio), then create config files for service - pulseaudio.service and replase client.conf and default.pa, then enable and start pulseaudio service (sudo systemctl enable && sudo systemctl start pulseaudio).
All right? If I was wrong please correct me.
I have 2 problem:
- pulse audio service don’t start automaticly after reboot, but starting manually without error;
- after I install pulseaudio I stoped hearing any sound from vlc. May be I need edit othe configuration files for vlc or something else?
PS I found error on git, you type “sudo systemctl start puluseaudio”, please correct last word to “pulseaudio”.
PSS When I’m disabled service and removed pulseaudio packet via apt, - sound return back…
Kind regards,
Yuri
I’ve expanded the guide a bit more to be clear about how the configuration should be performed: https://gist.github.com/Gadgetoid/3301cec3e47495e75b31d3120d8f17d9
If you did a straight replace on client.conf and default.pa then that might explain where your audio went.
I’ve also fixed the typo, thank you!
Thanks, I can test it only on evening (it’s on remote site), but about
first problem - “PulseAudio wasn’t start after reboot” I found this errors
on syslog:
Aug 25 12:08:43 pi-radio pulseaudio[370]: [pulseaudio] main.c: This program
is not intended to be run as root (unless --system is specified).
Aug 25 12:08:44 pi-radio pulseaudio[370]: [pulseaudio] server-lookup.c:
Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to
autolaunch a dbus-daemon without a $DISPLAY for X11
Aug 25 12:08:44 pi-radio pulseaudio[370]: [pulseaudio] main.c: Unable to
contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to
autolaunch a dbus-daemon without a $DISPLAY for X11
But it start witout error if I use "sudo systemctl start pulseaudio"
Can I fix this problem?
Best regards,
Yuri
Hooray!!! Loud click is gone and VLC play sound great, - my wife is confirm
that… ;)
Thanks for you help!
Only one problem with automatic start pulseaudio after reboot…
Best regards,
Yuri
I’ll have to look into this some more since pulseaudio has been starting okay on boot for me during my tests. I think the dbus stuff might be a red herring, and the “This program is not intended to be run as root” is to be expected (I’d really like to get the config working with the --system flag for extra security, but it’s proving tricky).
What’s your base OS? Jessie or Stretch? You can tell by running:
lsb_release -sc
Phil, I use Jessie (2017-07-05-raspbian-jessie-lite) becose I think with
Stretch I would have a lot of other problems… ;)
Information from cli:
pi@pi-radio:~ $ lsb_release -sc
jessie
pi@pi-radio:~ $ uname -a
Linux pi-radio 4.9.43+ #1026 Wed Aug 16 22:26:02 BST 2017 armv6l GNU/Linux
Best regards,
Yuri
It’s a shot in the dark, but try replacing pulseaudio.service with:
[Unit]
Description=PulseAudio Daemon
After=sound.target
Requires=sound.target
[Install]
WantedBy=default.target
[Service]
Restart=always
Type=simple
PrivateTmp=false
ExecStart=/usr/bin/pulseaudio --realtime --disallow-exit --no-cpu-limit --log-target=syslog
ExecStop=/usr/bin/pulseaudio --kill
Phil, it’s give same errors on syslog:
Aug 25 15:49:00 pi-radio pulseaudio[370]: [pulseaudio] main.c: This program
is not intended to be run as root (unless --system is specified).
Aug 25 15:49:01 pi-radio pulseaudio[370]: [pulseaudio] server-lookup.c:
Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to
autolaunch a dbus-daemon without a $DISPLAY for X11
Aug 25 15:49:01 pi-radio pulseaudio[370]: [pulseaudio] main.c: Unable to
contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to
autolaunch a dbus-daemon without a $DISPLAY for X11
but it’s run!:
pi@pi-radio:~ $ ps aux | grep pulseau
root 808 2.2 1.7 92672 7720 ? S<sl 15:51 0:00
/usr/bin/pulseaudio --realtime --disallow-exit --no-cpu-limit
–log-target=syslog
Thank you!
Best regards,
Yuri
С уважением,
Максимов Юрий (RZ3DVP)
1 Like
That’s all working for me now (and mopidy.conf didn’t need to be updated seemingly).
I have a few of the errors above, and a few errors like this: “authkey.c: Failed to open cookie file”
A few quick questions:
Also pulseaudio consistently runs at about 24% CPU. Is that ok?
How do I check if Mopidy and shairport-sync are using pulseaudio?
Ah I reckon the default stream settings in Pulse’s client config render the mopidy.conf changes redundant, good spot! I might as well drop those extra steps.
Pulse is pretty well known for using a lot of CPU, even when idle. I think this can be improved with configuration changes, but that’s a whole different issue to look into :D
The biggest chunk of CPU is usually due to the re-sampler, which takes whatever audio it’s given and re-samples it to be compatible with the output device it’s using. Careful configuration of this, and the apps feeding into it, can significantly reduce the load- I played with this quite extensively but need to tinker again to nail down a configuration.
I usually run Pulse manually in userspace to see what’s connecting to and using it. However when using this configuration, Pulse will hold the ALSA audio device open permanently, so it’s impossible (afaik) for any application to output audio unless it’s going via Pulse. So if you’re hearing audio, it’s going via Pulse.
1 Like
Checking the default stations on VLC + Pulse on a Pi Zero W shows Pulseaudio topping out at around 9%, dipping to ~2% when paused and back to 0% when the audio stream is stopped. This is on Raspbian Stretch, though, I’m not sure if that makes a considerable difference.
How are you measuring the CPU usage of Pulseaudio, and what stream is playing when you see 24% (or is it idle?)
I pared the config right back and it didn’t make much of an impression on this usage.
1 Like
I’m just using ‘top’ and I’m not playing any audio.
So have you got Pulse running all the time but using 0% when there’s no sound? I’ve found a bunch of posts, saying that it does tend to use CPU because it’s constantly playing silence, but it’s odd if you’re not getting that…
Yup, Top is saying 0% for pulse when it’s “idle”.
top - 18:08:04 up 6:52, 3 users, load average: 0.03, 0.09, 0.08
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.0 us, 0.7 sy, 0.0 ni, 97.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 444524 total, 144764 free, 43740 used, 256020 buff/cache
KiB Swap: 102396 total, 99360 free, 3036 used. 339316 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16933 pi 20 0 356256 11372 9712 S 0.3 2.6 4:39.21 pulseaudio
Ha, actually caught it a 0.3% in that copy & paste!
As far as I’m aware, when Pulse is idle it’s not outputting anything. I think the “constantly playing silence” (a term which I have used before) is a bit of a misnomer- it’s holding the ALSA sink open, but not sending it any data. Silence in a 16bit signed PCM stream just happens to be 0 which is what will be clocked out on the data pin when nothing is happening at all but the device is open and the clock is still running.
1 Like
Ok, any idea how to work out why it’s constantly using 24% on my pi zero w?
top - 19:47:36 up 2:53, 1 user, load average: 0.55, 0.56, 0.52
Tasks: 128 total, 1 running, 127 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.1 us, 24.4 sy, 0.0 ni, 67.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 493252 total, 433492 used, 59760 free, 59472 buffers
KiB Swap: 102396 total, 116 used, 102280 free. 224216 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16338 root 9 -11 103432 8200 6488 S 24.8 1.7 1:41.01 pulseaudioPulseaudio’s CPU also goes up slightly with mopidy use, but quite a lot with airplay use.
Honestly, I don’t know enough to know. I don’t know if Pulse is strict about what audio formats it accepts- matching its sink closely- when there’s just a single output, or if it’s fairly forgiving and attempts to do conversion internally. It could be that Mopidy/AirPlay are sending it data that’s more CPU-intensive to convert than other services.
Right now I’m seeing Pulse Audio using 29.4% and VLC using 21%, with Pulse Audio not only remaining to use CPU while idle but seemingly going up to 30/31% which is totally detached from what I saw before.
Now I’m confused! But at least we’re seeing similar things.