Sorry to re-ask, but does anyone have the same problem ? Is the problem on my side ?
Hi Rafa,
Generally, integrating a renderer requires the following:
1. A recipe for install/compile/configure all component pieces
2. A column in cfg_engine sql table for On/Off state
3. A dedicated configuration sql table and config screen if there are lot of user settings.
4. UI elements on snd-config.html and snd-config.php for on/off/name, a configure link if #3 is needed
5. Function in playerlib.php for start/stop/restart/configure the renderer
6. A startup block in worker.php for automatically starting the renderer if prior state was 'on'
7. Job case(s) in worker.php that processes submitJob() call from snd-config.php
8. The job case typically calls function mentioned in #5 but it also may do other things
9. If the renderer has hooks for pre and post processing then two bash scripts, one for saving current Moode volume, stopping play, the other for restoring Moode volume
10. A systemd unit if required for example /lib/systemd/system/squeezelite-armv7l.service and mpd.service. If the settings are configurable then code or job added to perform updates to the file usually via sed, refresh systemd, etc.
Airplay (shairport-sync) is an example of a renderer with hooks for pre/post processing, configurable software/hardware volume, binary launched as command line string. A single shairport-sync binary runs on both armv7 and armv6 platforms
Squeezelite is an example of a renderer with dedicated config page, binary launched from via systemd unit. Separate Sqeezelite binaries for armv6 and armv7 platforms.
-Tim
Thanks again for the feedback, the success report, the instructions, and for giving the courage that was missing.
I can report success using this method! I like it that, as is, it changes nothing from the original configuration, so it is 100% safe. Of course, that makes it not yet ideal (running the script not as a service or deamon requires a running cosole), but its a great start for me!
A couple of notes:
- A had to use "someone else's" spotify Key, as there appears to be issues with Spotify sending keys, as new development on Libspotify is being discouraged. This will prevent any 'true' integration to Moode, more like a hack into it, which is a shame.
- I had no need to set volume to max, I believe that is the default it follows with my external USB card, but, as with you, volume control from within spotify is not working. Not at all a problem, actually, something I would have looked for even if it changed the volume.
- I was able to login with my facebook credentials (I was worried as my login is not a regular Spotify account, but a FB account linked to my premium account).
- As you pointed out, I just need to stop one sound in order for the other to 'take over' control. This would be the key point of improvement, but, as is, not a problem at all.
- One concern is that the spotify-connect-web fellows claim that the bitrate of 320 may NOT have any effect. If this means that the setup is streaming at lower qualities, that would be a shame. I have not yet figured out to know the actual bitrate, and my ears can't tell any difference so far, so the 'judges' are still out on this one
So, the immediate TODO list is to run as a service and, perhaps, even at startup (I have some instructions somewhere to accomplish this). If that works, the next steps would be to be able to share ALSA with MPD and relinquish control from one to the other.
Also, it would be great if Moode front-end could actually 'know' (as it does with AirPlay) that it is sounding through Sportify Connect and, ideally, also output the bitrate, CPU ussage, etc. of the spotify-web-connect service.
So, bottom line: its working, still some road to go to get a better a seamless fussion with Moode.
Thanks again!
Rafa.
Perfectly comprehensive list! I'll start slowly and bother you with tons of questions once I have a better grasp. For the Rpi all-but-zero, I believe the tar file is all that is needed (and could be included in the iso?), and then its a simple extract.
The spotify-application key could be an issue.
Most complicated issue I can forsee is configuring the output device. Instructions ask for a run of:
Code:
aplay -LOther parts seem more 'farming' than really complicated issues. It can be feasable, lets see! Thanks for the great summary!
Best regards,
Rafa.
How cool! It actually detects itself!
You could select its own AP as the SSID Kidding aside, great add-on!
Rafa.
Hi Rafa,
MPD and ALSA settings for the currently configured audio device are stored in sql tables and loaded into $_SESSION vars during startup and thereafter if settings change. Session vars are available globally. Probably no need to fetch alsa config again.
Take a look at function startSps() in player lib.php. ALSA device number is obtained from mpd config via sql query while mixer name, airplay auto-volume, existence of hardware volume controller, and airplay friendly name are available in session vars.
If you want to examine the actual shairport-sync command string that Moode constructs then turn on debug logging in System config, turn Airplay off/on then look at moode log (cat /var/log/moode.log).
-Tim
Tim, I have confirmed that the variable passed as -d to Shairport in the playerlib.php file works correctly if passed as the -o or --playback_device (alias) parameters.
So that is one less thing to worry about. I was wondering if the fully comformed name was required, but the "hw:1" format worked.
Also, as mentioned before, the binary can be executed by the pi user without issues, so absolutely no need to run the chroot version.
Feels like progress!
Best regards,Rafa.
Glad that I could help!
@Rafa
Have to check bitrate passthrough functionality, but I have really high end / revealing system and sound quality is excellent. Actually, I much prefer that Pi3 is doing all the streaming (as native Spotify connect end point) that to have dedicated playback plug-in as in Volumio case. I'm using my mobile devices (and native apps) as GUI for streaming devices (including Moode in Chrome home screen mode) and don't want another interface. Actually, what's the point of streamers with LCD displays these days?! Anyhow:
- I remember that someone mentioned to me via other forum that he was unable to obtain the development key, so I've shared mine too. Not sure what's going on there.
- Speaking of automatic startup, I just use /etc/rc.local and put the start-up command line there
- Spotify-connect-web is generally very stable and I had zero problems. As mentioned, you can run it as unprivileged "pi" user straight from the git/zip download (from https://github.com/Fornoth/spotify-connect-web) without any further modifications to the system core as all system dependancies are present. As mentioned, "console_callbacks.py" in my particularly weird case was throwing an error on line 118 "min_volume_range = (1 - selected_volume_range / volume_range) * 100". I've just remarked everything and put "min_volume_range = 100" and that's about it. Speaking of volume control, it should be streamlined from Moode itself as having another volume hop is certainly not desirable, sonically or practically.
- If you can pass on default playback device as variable, as mentioned above, that's job done, as I didn't experiment with direct device name hw format.
@Rafa
Have to check bitrate passthrough functionality, but I have really high end / revealing system and sound quality is excellent. Actually, I much prefer that Pi3 is doing all the streaming (as native Spotify connect end point) that to have dedicated playback plug-in as in Volumio case. I'm using my mobile devices (and native apps) as GUI for streaming devices (including Moode in Chrome home screen mode) and don't want another interface. Actually, what's the point of streamers with LCD displays these days?! Anyhow:
- I remember that someone mentioned to me via other forum that he was unable to obtain the development key, so I've shared mine too. Not sure what's going on there.
- Speaking of automatic startup, I just use /etc/rc.local and put the start-up command line there
- Spotify-connect-web is generally very stable and I had zero problems. As mentioned, you can run it as unprivileged "pi" user straight from the git/zip download (from https://github.com/Fornoth/spotify-connect-web) without any further modifications to the system core as all system dependancies are present. As mentioned, "console_callbacks.py" in my particularly weird case was throwing an error on line 118 "min_volume_range = (1 - selected_volume_range / volume_range) * 100". I've just remarked everything and put "min_volume_range = 100" and that's about it. Speaking of volume control, it should be streamlined from Moode itself as having another volume hop is certainly not desirable, sonically or practically.
- If you can pass on default playback device as variable, as mentioned above, that's job done, as I didn't experiment with direct device name hw format.
Last edited:
Hi,
Audio info screen > Output stream shows the actual format being sent by ALSA to the audio device. Or via ssh, cat /proc/asound/card0/pcm0p/sub0/hw_params. Substitute card1 for card0 if using usb audio device.
-Tim
By bit-rate I was actually referring to which bitrate it is downloading the stream of audio. The playback is, as expected 16/44.1. What I was wondering if it is using the 'extreme' quality (320Kbps) for donwloading, the 'high' (180) or the low (96).
Then, of course, it is doing resampling. Which library is it using? I'd like to find out as well. Lots of questions still ahead.
Thanks again,
Rafa.
Hi Tim,
Yes aware of that! and using the exact method myself to follow up the bit perfect streams across the audio chain. However, as Rafa pointed out above, Spotify streaming bitrate should replicate the command line parameter instructions as no one with Spotify Premium account would want lower bitrates ultimately rendering in subpar sound quality.
I do wonder what would happen if bitrate is avoided altogether from command line ... would software inherit the actual bitrate from Spotify account settings (music quality->high quality streaming)? I've put it there as safety measure.
Cheers
Igor
Hi Igor
Spotify Connect renderer would need to expose current "streaming bitrate" otherwise some sort of external util would need to be used to determine this.
For example MPD via the 'status' command provides the 'bitrate' param. Its not guaranteed to be accurate but in practice it almost always is. This is what Moode uses to display the bitrate for streaming radio stations and decoded audio files.
-Tim
If your adapter is capable of N but isn't getting it, you may have the wrong sort of encryption set.
TKIP encryption will restrict you to G.
You need CCMP set to get to N.
https://www.raspberrypi.org/forums/viewtopic.php?t=50312&p=416523
WiFi networking will always try to connect at the fastest rate. If you have AES encryption set on your router then make sure you have CCMP set on the Pi.
Last edited:
Thanks for the info. I've had AES forced (TKIP completely off) for a very long time. Its one of the first things I do on any router install. WPA2-Personal (Not WPA/WPA2 Mixed) as well. Its weird, if I change the router from g/n to just n, my Pi won't get a connection, and neither will my iPhone 4 (not 4S). Both advertise 11n capability but when push comes to shove its not happening. I suppose it could be a router problem?