Hello @medoc, I have to say I have overlooked this use case. I thought that the scenarios involving the windows capture driver were the only real use-case scenario. I will have a more in-depth look when possible.
Thank you
1 Like
A killer feature would be being able to specify sender/receiver relationships in the .env file. I donāt know if that can be done tho.
Something general like SONGCAST_MODE = Receiver/Sender
or specifying receivers by IP would be really cool.
Hello, do I need some Linn hardware in order to effectively test this new hypothetical feature?
I donāt even have any old version of the Windows Capture Driver.
It would be difficult for me to make changes I cannot test, unless the changes are limited to setting some values in the configuration file.
About binaries, I went to this page, but the windows link is dead.
Let me know your thoughts, cheers
I have not followed everything here, but Iād love a solution where I can cast to upnp to a master unpnpmpdli and it sync somehow with other devices.
1 Like
Hello Tolriq, I believe this can already be done using SnapCast, however I have zero experience on this solution.
You can have one upmpdcli connected to the mpd and then connect multiple streaming clients.
At least this seems possible looking at the project page.
This is something I have been wanting to try for a long time. Maybe itās time to experiment a little 
Sounds that I lack time to look into that as it does not sound trivial 
1 Like
I have an update concerning the 24/96 playback issues. Turns out that the first (and only) 24/96 track my sister tried was the culprit.
Her boyfriend bought a pi zero 2 W which also refused to play through it. However my raspberry pi 3b+ played it just fine multiple times.
On a hunch I recompressed the entire album with the latest flac encoder and after that, both the pi zero 2 W as well as the pi zero 1.1 W played with no issues.
Since there were no decoding errors while recompressing (with --verify) the file was fine, but there was something about it the pi zeroes apparently did not like.
Just to be sure we also tried playing back a 5.5MBit/s 24/192 song on the pi zero 1.1W which it also handled flawlessly.
That doesnāt sound too hard to configure (bare metal that is, I donāt know about docker). One thing that throws me off a bit is that you have to decide on a fixed bit depth, sampling rate and channel number for the named pipe, so a mixed quality library will often end up resampled.
However I donāt know if SongCast doesnāt also share this limitation.
Hello, I believe having a fixed sample rate and bit depth, in this scenario, is not a real problem. If you are doing critical listening, you are probably not moving around the house.
I mean, having a āsnapcastā enabled player does not preclude to have another bitperfect player, maybe on the same device with a little diy.
Let me know what you think, cheers
So did you end up experimenting with Snapcast/Songcast?
I have it on good authority that a second Pi + DAC HAT with my name on it will find its way under the hypothetical christmas tree so Iāll be able to test this kind of setup soon myself, which is why Iām revisiting this thread.
That is true.
The ideal setup I imagine is this: all Pis can be casted to individually via upmpdcli. Or alternatively the master Pi is casted to and the other selected Pis play in sync with it, either realised via Songcast or Snapcast (or another software I do not know about).
For an easy and consistent deployment a docker compose setup where you only have to substitute a few variable names or IPs would be ideal.
Has anyone here got something smiliar running and could shed some light as to the specifics if so?
unfortunately notā¦ most of the time was occupied by the tidal and subsonic plugins for upmpdcli.
But this is still in my thought, Iāll (possibly) try Snapcast, but I canāt tell you when exactly.
Thatās surprisingly easy to achieve.
All you need to do is change the mpd audio output to a fifo file, install snapcast server to the pi and then install snapcast client on all other pis and point them to the IP of the server pi.
basically for 64bit debian bookworm pi clients:
wget https://github.com/badaix/snapcast/releases/download/v0.29.0/snapclient_0.29.0-1_arm64_bookworm.deb
sudo apt install ./snapclient_0.29.0-1_arm64_bookworm.deb
sudo nano /etc/default/snapclient
SNAPCLIENT_OPTS="-h IP-address here"
and for 64bit debian bookworm pi server:
wget https://github.com/badaix/snapcast/releases/download/v0.29.0/snapserver_0.29.0-1_arm64_bookworm.deb
sudo apt install ./snapserver_0.29.0-1_arm64_bookworm.deb
sudo nano /etc/mpd.conf
add this below the
# An example of an ALSA output:
line (and comment out preexisting audio_outputs):
audio_output {
type "fifo"
name "my pipe"
path "/tmp/snapfifo"
format "48000:16:2"
mixer_type "software"
}
if you want to name the audio source:
sudo nano /etc/default/snapserver
You can also still play on the pi that runs the server. Just install the client on it as well.
The only downside of this setup is that you cannot directly play via upmpdcli on the pi with the server any more. It will always write the audio to the fifo file, then it is read by the server and played by the client (all on the same device).
And since the fifo requires a fixed bitdepth/sample rate, this could lead to some upsampling/downsampling.
To avoid this, I installed a lightweight Debian lxc container on my proxmox host and installed mpd, upmpdcli and snapcast server there. The fact that the container has no audio device does not matter since only the fifo is used anyhow.
That way I can still cast to each of my individual pis without restrictions, or I cast to the debian container and all (selected) client pis play in sync.
Works very well.
Thatās 2 pis + the debian container as cast targets in Symfonium:
Volume can be controlled individually or per group via the shipped webserver on port 1780 of the server IP or via one of the supported apps (snapdroid etc).
I also used my first waltz with corona to familiarize myself with ansible and wrote a playbook that turns any number of freshly installed pi zero Ws/pi zero 2Ws (should also work for pi 3b but havenāt tested that yet) + HiFiBerry DAC HAT into a fully configured (audio settings, configs, player name etc.) player with mpd, upmpdcli and snapclient in a couple of minutes (or many minutes in case of the pi zero W, that thing is slow as hell).
I can put that playbook + a guide on github if thereās interest. Iām extremely happy with the result.
1 Like
After tinkering with my ansible playbook for a few more days Iāve decided to release it on github as castpi2go. Do let me know if it works on Pis other than Zero 1W, Zero 2W, 2 and 3B so I can adjust the readme accordingly.
@GioF_71 I did ponder to deploy your docker container instead of installing upmpdcli and MPD bare metal but considering how little compute the smaller pis have that seemed like needless overhead.
This is the system load when casting 44.1/16 to a Pi Zero 2W:
Have fun with it!
PS: Iām not responsible for irresponsible Pi purchases that resulted from using the playbook.
Awesome!
About docker: with these little devices with limited cpu/ram capabilities, I would also go with bare metal installations
1 Like
@655321 do you still have your docker compose?
I hava a raspberry pi 4 connected with the 3,5mm jack and would like to use docker instead of using bare metal.
I am trying to use this audio-tools/players/upnp-renderer/upnp-renderer-simple/docker-compose.yaml at main Ā· GioF71/audio-tools Ā· GitHub but canāt get it to work. I can select it in symfonium but canāt hear anything and the play button always reverts to pause.
update:
I use dietpi and had to install alsaā¦
Still searching what is wrong.
update2:
well if you want to use the 3.5mm jack be sure you have the cable connectedā¦
docker-compose.yaml
---
version: '3.3'
volumes:
mpd-db:
upmpdcli-cache:
upmpdcli-confdir:
services:
mpd:
image: ${MPD_IMAGE_REGISTRY:-docker.io}/giof71/mpd-alsa:${MPD_TAG:-vanilla}
network_mode: host
devices:
- /dev/snd:/dev/snd
environment:
- MPD_BIND_ADDRESS=${MPD_BIND_ADDRESS:-127.0.0.1}
- MPD_PORT=${MPD_PORT:-6600}
- USER_MODE=${MPD_USER_MODE:-N}
- PUID=${MPD_PUID:-}
- PGID=${MPD_PGID:-}
- AUDIO_GID=${MPD_AUDIO_GID:-}
- ALSA_OUTPUT_CREATE=yes
- ALSA_OUTPUT_ENABLED=yes
- ALSA_OUTPUT_DEVICE=${MPD_ALSA_DEVICE:-default}
- ALSA_OUTPUT_MIXER_TYPE=${MPD_MIXER_TYPE:-software}
- ALSA_OUTPUT_FORMAT=${MPD_ALSA_OUTPUT_FORMAT:-}
volumes:
- mpd-db:/db
restart: ${RESTART_MODE:-unless-stopped}
upmpdcli:
image: ${UPMPDCLI_IMAGE_REGISTRY:-docker.io}/giof71/upmpdcli:${UPMPDCLI_TAG:-latest-renderer}
network_mode: host
environment:
- PUID=${UPMPDCLI_PUID:-}
- PGID=${UPMPDCLI_PGID:-}
- MPD_HOST=${MPD_HOST:-127.0.0.1}
- MPD_PORT=${MPD_PORT:-6600}
- FRIENDLY_NAME=${FRIENDLY_NAME:-UpnpRenderer}
- RENDERER_MODE=${RENDERER_MODE:-BOTH}
- CHECK_CONTENT_FORMAT=${CHECK_CONTENT_FORMAT:-yes}
volumes:
- upmpdcli-confdir:/uprcl/confdir
- upmpdcli-cache:/cache
restart: ${RESTART_MODE:-unless-stopped}
sample.env
COMPOSE_PROJECT_NAME=upnp-renderer-simple
# Restart mode
RESTART_MODE=unless-stopped
# Specify you cache registries for each component
# MPD_IMAGE_REGISTRY=docker.io
# UPMPDCLI_IMAGE_REGISTRY=docker.io
# MPD_TAG=vanilla
# MPD runs app as root by default
# MPD_USER_MODE=N
# Optionally set uid/gid for mpd
# Used if MPD_USER_MODE is set to Y
# Group id for audio is generally 29 on ubuntu/debian distros
# MPD_PUID=1000
# MPD_PGID=1000
# MPD_AUDIO_GID=29
MPD_BIND_ADDRESS=127.0.0.1
MPD_HOST=127.0.0.1
MPD_PORT=6600
# MPD_ALSA_DEVICE examples:
# hw:0
# hw:1
# hw:DAC
# hw:D10
MPD_ALSA_DEVICE=default
MPD_MIXER_TYPE=software
# Uncomment for special settings
# MPD_ALSA_OUTPUT_FORMAT=
# Optionally set uid/gid for upmpdcli
# UPMPDCLI_PUID=1000
# UPMPDCLI_PGID=1000
FRIENDLY_NAME=UpnpRenderer5
# RENDERER_MODE values:
# BOTH
# UPNPAV
# OPENHOME
RENDERER_MODE=BOTH
Classic. 
Seems like you no longer need it, but here is the last compose I used on my pi 3b with Hifiberry Dac+ Pro anyways:
services:
mpd-alsa:
image: giof71/mpd-alsa:vanilla-bookworm
container_name: mpd-alsa
devices:
- /dev/snd:/dev/snd # Allow access to the sound device
ports:
- 6600:6600/tcp
environment:
- ALSA_OUTPUT_CREATE=yes
- ALSA_OUTPUT_NAME=hifiberry-dac-plus-pro
- ALSA_OUTPUT_DEVICE=hw:CARD=sndrpihifiberry,DEV=0
- ALSA_OUTPUT_MIXER_TYPE=software
volumes:
- /opt/mpd-alsa/db:/db
- /opt/mpd-alsa/playlists:/playlists
- /opt/mpd-alsa/log:/log
- /opt/mpd-alsa/config:/user/config
- /opt/mpd-alsa/music:/music:ro
restart: unless-stopped
upmpdcli:
image: giof71/upmpdcli:bookworm-renderer
container_name: upmpdcli
network_mode: host # Use host network mode to avoid UPnP issues
environment:
- PUID=1000
- PGID=1000
- FRIENDLY_NAME="PiMalteDocker"
volumes:
- /opt/upmpdcli/cache:/cache
- /opt/upmpdcli/log:/log
- /opt/upmpdcli/config/additional-radio-list.txt:/user/config/additional-radio-list.txt:ro
restart: unless-stopped
depends_on:
- mpd-alsa
The 6 Pis (1w, 2, 2x 2w, 2x 3b) in the house running Upmpdcli, MPD and Snapcast/Snapserver were all deployed via my ansible playbook tho so I donāt use the docker compose any more.
Depending on which quality the amp/speakers are that you connect the pi to, Iād advise against using the 3.5mm jack. As far as I know the sound quality is meh.
@655321 How are you connecting your multiple piās to the speakers if not with the 3.5mm jack?
Each pi is connected to an amplifier via cinch through a Hifiberry DAC, which in turn powers 2 speakers each.
Like this:
In this case thatās a 40 year old amplifier (Kenwood KR-A20).
1 Like
Hello, I just saw this after months, sorry.
I am the developer of the two container images.
Did you solve your issues? Whatās wrong?
No issues, I just provided it because @gamebeaker asked:
The compose worked but I no longer use it as I found it easier (also less overhead) to automate the bare metal deployment and configuration of upmpdcli, mpd, snapcast & snapserver via ansible as stated here:
A few days ago I added a bash convenience script to make the configuration/maintenance of ansible/the pis even easier/quicker. Weāre now at 5 (soon 6) such pis in the house that can all be re-deployed or kept up to date conveniently and easily that way.
1 Like