I'm not familiar with the airplay side of things but...
On MoOde, running "amixer controls" and "amixer scontrols" shows the names of mixer items known to the system. Hardware volume control is one of these items. In MPD, you name the hardware device ... e.g. HW:0 and the name of the mixer control you want... e.g. "PCM" or "Speaker".
I assume the same would be true or Shairport?
In MPD, output device and mixer device and name can be seen in the audio out section(s) at the bottom of /etc/mpd.conf.
J.
Code:
pi@moode:~ $ amixer controlsnumid=2,iface=MIXER,name='PCM Playback Switch'
numid=1,iface=MIXER,name='PCM Playback Volume'
numid=5,iface=PCM,name='IEC958 Playback Con Mask'
numid=4,iface=PCM,name='IEC958 Playback Default'
Code:
pi@moode:~ $ amixer scontrols
Code:
pi@moode:~ $ cat /etc/mpd.conf# This file is automatically generated by
# the player MPD configuration page.
#########################################
follow_outside_symlinks "yes"
follow_inside_symlinks "yes"
db_file "/var/lib/mpd/tag_cache"
sticker_file "/var/lib/mpd/sticker.sql"
log_file "/var/log/mpd/mpd.log"
pid_file "/var/run/mpd/pid"
music_directory "/var/lib/mpd/music"
playlist_directory "/var/lib/mpd/playlists"
state_file "/var/lib/mpd/state"
user "mpd"
group "audio"
bind_to_address "any"
port "6600"
log_level "default"
zeroconf_enabled "yes"
zeroconf_name "moode"
samplerate_converter "soxr very high"
volume_normalization "no"
audio_buffer_size "4096"
buffer_before_play "10%"
filesystem_charset "UTF-8"
id3v1_encoding "UTF-8"
gapless_mp3_playback "yes"
auto_update "no"
mixer_type "software"
max_output_buffer_size "81920"
restore_paused "yes"
replaygain "off"
max_connections "20"
decoder {
plugin "ffmpeg"
enabled "yes"
}
input {
plugin "curl"
}
audio_output {
type "alsa"
name "ALSA default"
device "hw:1,0"
dsd_usb "yes"
}
audio_output {
type "alsa"
name "ALSA crossfeed"
device "crossfeed"
dsd_usb "yes"
}
Still get this,
pi@moode:~ $ /usr/local/bin/shairport-sync -vv -a "Moodey Airplay" -S soxr -w -B /var/www/com
mand/spspre.sh -E /var/www/command/spspost.sh --metadata-pipename=/tmp/shairport-sync-metadat
a --get-coverart -- -d hw:1 -c "PCM"^M
Looking for the configuration file "/etc/shairport-sync.conf".
Looking for configuration file at full path "/etc/shairport-sync.conf"
Output device name is "hw:1".
Open Mixer
Failed to find mixer element
Request to shut down all rtsp conversation threads
asking playing threads to stop
^Cshutdown requested...
pi@moode:~ $ pgrep shairport*
So, my real motivation for airplay is to get TIDAL. Since TIDAL has an extension that runs in chrome and plays lossless, all I would need is the ability to fire up a browser in moode. Is it possible to have an entry in the menu for a browser?
From doing a little digging...
Code:
.... -c "PCM"From your output of the amixer commands, you seem to only have a "PCM,0". This I would associate with the Pi's onboard audio. There are no other mixer controls.
Is it possible your soundcard doesn't have hardware volume control?
Can you try the shairport-sync command but leave out the "-c "PCM" bit.
I have been using Tuneblade successfully to stream from Spotify to Moode for some time. However Tuneblade said yesterday that streaming had stopped because 10 minutes had elapsed. According to the Tuneblade web site, there is no such 10-minute limitation when streaming to Shairport.
Any ideas?
Many thanks.
Any ideas?
Many thanks.
This is what Tuneblade support answered me in August:
"Recently ShairPort-Sync devs made a change in their code which is causing TuneBlade to not identify ShairPort-Sync as a non-propriety system. Please reach out to the ShairPort-Sync team and suggest them to :
"Remove the am field in Zeroconf text records , or change the am value to something like ShairPort-Sync which TuneBlade can use to identify it. In latest versions, they have changed the value to 'AirPort ... ' which is an identifier for AirPort express devices and so TuneBlade will stop streaming after 10 minutes as it finds it to be an AirPort device.
You can also do this on your own if you are familiar with modifying and building the ShairPort--Sync code."
Hi Klausi69,
Many thanks for the prompt response. This perhaps sounds like a job for Tim if he has the time. At least it's worth adding to his to-do list.
Cheers.
Many thanks for the prompt response. This perhaps sounds like a job for Tim if he has the time. At least it's worth adding to his to-do list.
Cheers.
Hi,
I would think that the makers of Tuneblade would contact the dev for shairport-sync.
-Tim
Hi Tim,
I had imagined that the solution would be simple, and that's why I thought that you'd be able to provide a quick fix.
The shairport-sync component that's built into MoOde is advertising itself as "AirPort" and that's causing Tuneblade to treat MoOde as a non-generic device and that triggers the 10-minute timeout.
I thought that the advertised name would be a text string in a config file and that it would be easy to find and change. I found the file /etc/shairport-sync.conf but most of the entries appear to be commented out and it's not clear to me what might need to be edited.
Many thanks.
Hi,
Sometimes it is a simple fix so its always a good idea to post, but in this case the name "Airport" is something that must be set by shairport-sync internally. Moode only sets the service name using the value from the input field on System config screen. This name is what appears in the Airplay list on clients.
You could post the question to shairport-sync Github issues list
https://github.com/mikebrady/shairport-sync/issues
-Tim
Last edited:
So, freshly booted moode
airplay and airplay metadata previously turned on in prior boot
airplay renamed to Moodey Airplay
ssh into RPi
ps axjf reveals (among lots of other processes)
in another terminal
I killed off shairplay
and started shairport with
Note: no '-c PCM' at the end
NOW IT SHOWS UP ON MY PHONE!
Thank you good sir.
Now where do I find the startup script for shairport-sync Tim so I can modify it??
And might as well Remove the am field in Zeroconf text records as Klaus found.
airplay and airplay metadata previously turned on in prior boot
airplay renamed to Moodey Airplay
ssh into RPi
ps axjf reveals (among lots of other processes)
Code:
1 1033 598 598 ? -1 S 0 0:00 sudo /usr/local/bin/shairport-sync -a Moodey Airplay -S soxr -w -B /var/www/com
1033 1039 598 598 ? -1 S 0 0:00 \_ /usr/local/bin/shairport-sync -a Moodey Airplay -S soxr -w -B /var/www/comm
Code:
pi@moode:~ $ /usr/local/bin/shairport-sync -vv -a "Moodey Airplay" -S soxr -w -B /var/www/command/spspre.sh -E /var/www/command/spspost.sh --metadata-pipename=/tmp/shairport-
Code:
sync-met
adata --get-coverart -- -d hw:1
Looking for the configuration file "/etc/shairport-sync.conf".
Looking for configuration file at full path "/etc/shairport-sync.conf"
Output device name is "hw:1".
The processor is running little-endian.
Version: "2.8.4-OpenSSL-Avahi-ALSA-stdout-soxr-metadata"
statistics_requester status is 0.
daemon status is 0.
rtsp listening port is 5000.
udp base port is 6001.
udp port range is 100.
Shairport Sync player name is "Moodey Airplay".
Audio Output name is "(null)".
on-start action is "/var/www/command/spspre.sh".
on-stop action is "/var/www/command/spspost.sh".
wait-cmd status is 1.
mdns backend "(null)".
userSuppliedLatency is 0.
AirPlayLatency is -1.
iTunesLatency is -1.
forkedDaapdLatency is -1.
stuffing option is "1" (0-basic, 1-soxr).
resync time is 2205.
allow a session to be interrupted: 0.
busy timeout time is 120.
drift tolerance is 88 frames.
password is "(null)".
ignore_volume_control is 0.
playback_mode is 0 (0-stereo, 1-mono).
disable_synchronization is 0.
audio backend desired buffer length is 6615.
audio backend latency offset is 0.
volume range in dB (zero means use the range specified by the mixer): 0.
zeroconf regtype is "_raop._tcp".
configuration file name "/etc/shairport-sync.conf" resolves to "/etc/shairport-sync.conf".
metdata enabled is 1.
metadata pipename is "/tmp/shairport-sync-metadata".
metadata socket address is "(null)" port 0.
metadata socket packet size is "500".
get-coverart is 1.
Successful Startup
avahi: avahi_register.
avahi: register_service.
avahi: service 'ABCD3702CDF2@Moodey Airplay' group is not yet commited.
avahi: request to add "_raop._tcp" service with metadata
avahi: service 'ABCD3702CDF2@Moodey Airplay' group is registering.
avahi: service 'ABCD3702CDF2@Moodey Airplay' successfully added.in another terminal
I killed off shairplay
Code:
killall shairport-syncand started shairport with
Code:
/usr/local/bin/shairport-sync -vv -a "Moodey Airplay" -S soxr -w -B /var/www/command/spspre.sh -E /var/www/command/spspost.sh --metadata-pipename=/tmp/shairport-sync-metadata --get-coverart -- -d hw:1Note: no '-c PCM' at the end
NOW IT SHOWS UP ON MY PHONE!
Thank you good sir.
Now where do I find the startup script for shairport-sync Tim so I can modify it??
And might as well Remove the am field in Zeroconf text records as Klaus found.
dropouts when streaming over airplay
Tim, I ran shairport with the debug settings you recommended upthread until I got a dropout (about 60 seconds in this room). The relevant portion of daemon.log looks like this
Does that suggest it's a wifi issue?
(And thank you for your patience with this kind of query, as well as for your software!)
Tim, I ran shairport with the debug settings you recommended upthread until I got a dropout (about 60 seconds in this room). The relevant portion of daemon.log looks like this
Code:
Oct 9 17:55:28 moode shairport-sync[27194]: PCM handle name = 'default'
Oct 9 17:55:28 moode shairport-sync[27194]: alsa device parameters:
Oct 9 17:55:28 moode shairport-sync[27194]: access type = RW_INTERLEAVED
Oct 9 17:55:28 moode shairport-sync[27194]: format = 'S16_LE' (Signed 16 bit Little Endian)
Oct 9 17:55:28 moode shairport-sync[27194]: subformat = 'STD' (Standard)
Oct 9 17:55:28 moode shairport-sync[27194]: number of channels = 2
Oct 9 17:55:28 moode shairport-sync[27194]: number of significant bits = 16
Oct 9 17:55:28 moode shairport-sync[27194]: rate = 44100 frames per second (precisely).
Oct 9 17:55:28 moode shairport-sync[27194]: precise (rational) rate = 0.000 frames per second (i.e. 0/1088784512).
Oct 9 17:55:28 moode shairport-sync[27194]: period_time = 5804 us (>).
Oct 9 17:55:28 moode shairport-sync[27194]: period_size = 256 frames (precisely).
Oct 9 17:55:28 moode shairport-sync[27194]: buffer_time = 371519 us (>).
Oct 9 17:55:28 moode shairport-sync[27194]: buffer_size = 16384 frames (>).
Oct 9 17:55:28 moode shairport-sync[27194]: periods_per_buffer = 64 (precisely).
Oct 9 17:55:45 moode shairport-sync[27194]: Error -- ALSA device in incorrect state (4) for play.
Oct 9 17:55:48 moode shairport-sync[27194]: Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in
microseconds: 7989.9, 12471.8, 67526.0.
Oct 9 17:56:03 moode shairport-sync[27194]: Error -- ALSA device in incorrect state (4) for play.
Oct 9 17:56:08 moode shairport-sync[27194]: Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in microseconds: 7980.2, 12747.1, 131880.0.
Oct 9 17:56:10 moode shairport-sync[27194]: Error -- ALSA device in incorrect state (4) for play.
Oct 9 17:56:16 moode shairport-sync[27194]: Error -- ALSA device in incorrect state (4) for play.
Oct 9 17:56:16 moode shairport-sync[27194]: Error -- ALSA device in incorrect state (4) for play.
Oct 9 17:56:23 moode shairport-sync[27194]: Lost sync with source for 4 consecutive packets -- flushing and resyncing. Error: 2379.
Oct 9 17:56:23 moode shairport-sync[27194]: syncing to seqno 53753.
Oct 9 17:56:28 moode shairport-sync[27194]: Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in microseconds: 7989.0, 12432.2, 41610.0.
Oct 9 17:56:48 moode shairport-sync[27194]: Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in microseconds: 7976.8, 12767.8, 132991.0.Does that suggest it's a wifi issue?
(And thank you for your patience with this kind of query, as well as for your software!)
A reply to my own post: by running shairport-sync with "basic" as the stuffing, instead of soxr, I managed to eliminate all these dropouts on the pi that is also running pihole. Looking more carefully, I notice that this is actually an ancient pi B (not B+) so it probably did get overwhelmed by trying to run soxr as well as pihole, or even soxr by itself.
Since it doesn't have a proper dac or amp attached, the basic stuffing seemed a small price to pay for continuous sound
Since it doesn't have a proper dac or amp attached, the basic stuffing seemed a small price to pay for continuous sound
Last edited:
(I edited the post to say this, obviously after you had read it and before I saw your reply)
It's a model B (not B+) -- I just walked across the room to check. I had entirely forgotten. The one at home is a B+
It's a model B (not B+) -- I just walked across the room to check. I had entirely forgotten. The one at home is a B+
Slightly off topic but what Pi is it. Original B came with a T-shirt instead of an extra 256MB of RAM. My one of those is painfully slow to boot.... or do anything really. My "B rev 2" OTOH seems capable enough. Though I do run it overclocked to 900MHz.
There has been some discussion about libraries and optimisation of resampling on ARM devices recently. I don't resample or upsample so I didn't bookmark it. Ballpark figures were something like a reduction from 40% of a CPU to 5-10% on a Pi2/3, I think.
Hi,
Just for reference, two of my test systems are Pi-1B 512MB that are OC to 1Ghz and no audio glitches running SoX via MPD or via shairport-sync.
-Tim