New input plugin: TCP stream

[badaix]

I'm currently using MPD as input for snapcast (connected via pipe) and now I started playing with Mopidy, which seems to be more actively developed and more feature rich.
I've observed some strange audio loops during my Mopidy tests, using this setup GStreamer setup:

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo

I was wondering if there are GStreamer sinks that are more reliable and implemented a TCP stream that can be configured to act as client or as server, allowing the following setups:

Snapcast running in TCP server mode

snapcast.conf:

[stream]
stream = tcp://127.0.0.1?name=mopidy_tcp

the general pattern is: tcp://<IP of the listen interface>:<port>?name=<name>&mode=[client|server]
default for port (if omitted) is 4953, default for mode is server

mopidy.conf (running GStreamer in client mode)

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpclientsink

Snapcast running in TCP client mode

snapcast.conf:

[stream]
stream = tcp://127.0.0.1?name=mopidy_tcp&mode=client

in client mode the IP and port are the server's IP, port to connect to (default for port is again 4953)

mopidy.conf (running GStreamer in server mode)

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpserversink

If you want to give it a try: it's available in the current develop branch, any feedback is appreciated!
This would also solve #486 (well, at least it would work around it)

[uSpike]

Awesome! I think this would be very useful for streaming pulseaudio from a different machine on the network.

[slowphil]

I'd love to test that on my Raspberry 4 running Raspbian Buster. I hope it could solve frequent drop-out of music when I interact with the desktop (for instance browsing internet).

Could you please update the building instructions for Raspbian? (in particular, Boost provided with Raspbian Buster seems too old...)

[badaix]

I will do so tonight. You will just need header only boost libs, i.e. it's enough to download and unzip the latest boost and let make/cmake point to the directory. I think you can pass the boost path to cmake like this cmake -DBOOST_ROOT=<path to your unzipped boost root> (no guarantee, I have to cross check on my dev machine tonight).

[miLORD1337]

Interesting. I'm using Mopidy since I first found out about Snapcast. I did not experience audible looping issues... How are you testing for that? Our GStreamer setup is the same.

[gerroon]

I had terrible issues with Mopidy and Gstreamer, changing songs or radio channels meant delays, glitches, looping feedbacks etc then I moved to Mpd and it works great with SC. However I am interested in this imporvement as well.

[JayGatsby7]

I'm currently using MPD as input for snapcast (connected via pipe) and now I started playing with Mopidy, which seems to be more actively developed and more feature rich.
I've observed some strange audio loops during my Mopidy tests, using this setup GStreamer setup:

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo

I was wondering if there are GStreamer sinks that are more reliable and implemented a TCP stream that can be configured to act as client or as server, allowing the following setups:

Snapcast running in TCP server mode

snapcast.conf:

[stream]
stream = tcp://127.0.0.1?name=mopidy_tcp

the general pattern is: tcp://<IP of the listen interface>:<port>?name=<name>&mode=[client|server]
default for port (if omitted) is 4953, default for mode is server

mopidy.conf (running GStreamer in client mode)

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpclientsink

Snapcast running in TCP client mode

snapcast.conf:

[stream]
stream = tcp://127.0.0.1?name=mopidy_tcp&mode=client

in client mode the IP and port are the server's IP, port to connect to (default for port is again 4953)

mopidy.conf (running GStreamer in server mode)

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpserversink

If you want to give it a try: it's available in the current develop branch, any feedback is appreciated!
This would also solve #486 (well, at least it would work around it)

Has anyone tried this? I run several clients and a server on raspberry pi's and have some issues with mopidy that don't seem to exist when using librespot - appreciate your good work on this software.

[uSpike]

I'm running with the latest dev commit, and the following configs:

stream = tcp://0.0.0.0:4953?name=Spotify_1
stream = tcp://0.0.0.0:4954?name=Spotify_2
stream = tcp://0.0.0.0:4955?name=Mopidy

Librespot is running on two separate docker containers and is forwarding FIFO to network via netcat:

nc ${TARGET_HOST} ${TARGET_PORT} </tmp/snapfifo &
librespot ... --backend pipe --device /tmp/snapfifo

and mopidy:

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpclientsink host=snapcast port=4955

It seems to work well :) I'll do more stress testing this week.

[fatg3erman]

Ooh this looks good, just been discussing th issues Gstreamer has with fifos with the mopidy devs and one of them pointed me at this. I need to give this a try.

One thing is slightly confusing me though, is the nomenclature around client mode/server mode. I'd assume snapserver would always need to be in 'server mode' and snapclient in 'client mode' - but I'm not sure if that makes sense - and then mopidy in... what mode?

[fatg3erman]

OK I managed to get it to build natively on a RaspberryPi 3B+ and the good news is it's working!

For anybody interested in trying, here's what I did. I'm no expert at editing MakeFiles so I just blundered around making edits until it built, so here's the full list of what I changed.

Download the latest libboost and unzip it somewhere. This will give you a directory we'll call <boost dir>

I only rebuilt the Snapcast server. So, in <snapcast dir>/server:

Edit CMakeLists.txt and find the SERVER_INCLUDE section and change it to

set(SERVER_INCLUDE
    ${CMAKE_SOURCE_DIR}/server
    ${CMAKE_SOURCE_DIR}/common)

list(APPEND SERVER_INCLUDE "<boost dir>")

Then edit Makefile:

Find the long line beginning CXXFLAGS += and change it to

CXXFLAGS += $(ADD_CFLAGS) -std=c++14 -Wall -Wextra -Wpedantic -Wno-unused-function -DBOOST_ROOT=<boost dir> -DBOOST_ERROR_CODE_HEADER_ONLY -DHAS_FLAC -DHAS_OGG -DHAS_VORBIS -DHAS_VORBIS_ENC -DHAS_OPUS -DVERSION=\"$(VERSION)\" -I. -I.. -I../common  -I<boost dir> 

and change the LDFLAGS line below it to

LDFLAGS  += $(ADD_LDFLAGS) -lvorbis -lvorbisenc -logg -lFLAC -lopus -latomic

Now do

make
sudo make install

In my /etc/snapserver.conf I have

stream = tcp://127.0.0.1?name=mopidy_tcp&port=4953

And in /etc/mopidy/mopidy.conf I have

output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpclientsink host=127.0.0.1 port=4953

Note that using 'localhost' in the mopidy.conf didn't work, I got errors saying GStreamer could not open the source, but using 127.0.0.1 fixed that. Wierd.

The only minor issue I now have is that the playback position reported by mopidy is about 5 seconds ahead of what's coming out of my speakers. I assume this is some buffer size thing in the tcp sink, it'd be interesting to know how to change that.

[gerroon]

Can Snapcast run multiple modes at the same time? I still would like to be able to use fifo together with tcp

[uSpike]

@gerroon you can define multiple streams that have different sources (fifo, tcp)

[KraigoMpls]

FWIW, the Mopidy team just dropped version 3.0.1 eleven days ago. I haven't had a chance to play with it yet. It requires Python 3.7 I've read and it uses a much more recent version of GStreamer, 1.14.0. This might be enough to resolve your issue. I'm planning on playing with it tonight. I got all of my backups in line this morning so I can step back if necessary, but I'm really excited about it.

https://mopidy.com/blog/2019/12/22/mopidy-3.0/

KO

[fatg3erman]

I'm already running it. It doesn't solve the issue :) The Mopidy devs say that GStreamer and FIFOs don't play well together. They did try to make a fifo output within Mopidy some time ago but again, GStreamer makes it hard. This new TCP sink is the way forward.

[KraigoMpls]

My biggest concern is that the configuration seems to rely on static IP addresses, which I spent a few days getting rid of in favor of DHCP when I went to OpenWRT a month or two ago . I really want to stay dynamic. My implementation of the static IP addresses was ugly and I'd really prefer to not step back to it.

[fatg3erman]

Well if you're using it in place of a fifo - which you can't use over a network anyway - then the only IP address you need is 127.0.0.1, which is 'local loopback' and requires no configuration.

[KraigoMpls]

TYVM!

[uSpike]

I've been testing this all night, and it's working great with a bunch of streams. I've been able to separate my services (multiple librespot instances, mopidy, etc) and the FIFO mess is gone!

I've also been able to stream the audio from my PC to snapcast from pulseaudio.

Config:

stream = tcp://0.0.0.0:4956?name=PC

On my PC I pipe pulseaudio to netcat:

$ parec --rate=48000 --format=s16le --channels=2 | nc snapserver.home 4956

Does anyone know of a better way to have pulseaudio send raw PCM over a network to a host?

[uSpike]

@badaix I have one suggestion... instead of tcp://...&mode=[client|server] how about tcp-server://... and tcp-client://...? I think it'd be a lot more immediately clear what's going on there.

[natumbri]

Another confirmed working: the develop branch builds just fine on Armbian (ubuntu bionic) after manually installing the ubuntu libboost1.71-dev package (https://launchpad.net/ubuntu/+source/boost1.71).

And the tcp stream works great with mopidy 3.0.

Thanks!

@fatg3erman very early testing suggests something seems to be up with the RompR snapcast volume control when using the TCP stream. Here's the output I get:

RompR v1.30

Cheers
Nik

[eoware]

If I understand this correctly, I could run a stream in server mode, and on another machine netcat a PCM stream to the IP/PORT set in the stream, is that right? This is great timing as I've been looking for a way to easily stream a PCM capture from a remote device.

[uSpike]

@eoware yes, correct.

[JayGatsby7]

I'm running with the latest dev commit, and the following configs:

stream = tcp://0.0.0.0:4953?name=Spotify_1
stream = tcp://0.0.0.0:4954?name=Spotify_2
stream = tcp://0.0.0.0:4955?name=Mopidy

Librespot is running on two separate docker containers and is forwarding FIFO to network via netcat:

nc ${TARGET_HOST} ${TARGET_PORT} </tmp/snapfifo &
librespot ... --backend pipe --device /tmp/snapfifo

and mopidy:

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpclientsink host=snapcast port=4955

It seems to work well :) I'll do more stress testing this week.

can't seem to get this to work with librespot (raspotify) -- could be my lack of understanding about netcat . . . I'm running librespot on the same server as the snapserver.... TCP seems to work ok with mopidy.

[uSpike]

can't seem to get this to work with librespot (raspotify) -- could be my lack of understanding about netcat . . . I'm running librespot on the same server as the snapserver.... TCP seems to work ok with mopidy.

@JayGatsby7 can you provide more information?

[JayGatsby7]

can't seem to get this to work with librespot (raspotify) -- could be my lack of understanding about netcat . . . I'm running librespot on the same server as the snapserver.... TCP seems to work ok with mopidy.

@JayGatsby7 can you provide more information?

1. Do you have a pipe open on snapserver.conf for tmp/snapfifo? Or just the setting for TCP?

2. Netcat configs in your example. Are you putting those parameters in the librespot / raspotify config?

I’m using mopidy with tcp for the time being but would like to get librespot working with tcp on a separate port as well.

[badaix]

My biggest concern is that the configuration seems to rely on static IP addresses, which I spent a few days getting rid of in favor of DHCP when I went to OpenWRT a month or two ago . I really want to stay dynamic. My implementation of the static IP addresses was ugly and I'd really prefer to not step back to it.

@KraigoMpls: I will keep this in mind for the next version. I already started to implementing host resolution, but removed it for this first version of the tcp plugin. I think for most users the audio source will run on the same host. You can open a feature request for this, so that I will not forget about it.

[gerroon]

@hawkeye217

To be honest I think that Mopidy using Gstreamer as a backend was a bad move and I myself wasted so many hours on the same issue while trying to fix it.

[hawkeye217]

To be honest I think that Mopidy using Gstreamer as a backend was a bad move and I myself wasted so many hours on the same issue while trying to fix it.

Great, glad to know it's not me. I'll stop wasting more hours then :)

Ironically I've had a little more success with Mopidy by using the alsasink output in mopidy.conf:

[audio]
output = alsasink device=snapcast_fifo

and then creating a custom entry in my /etc/asound.conf file like this:

pcm.snapcast_fifo {
    type plug
    slave {
        pcm {
            type file
            file "/tmp/snapfifo"
            slave.pcm null
            format raw
        }
        rate 48000
        format s16_le
        channels 2
    }
}

But it still is not as reliable as mpd. Off to try something else... Volumio maybe?

[lealoureiro]

Any ideas when this plugin might be on official release?

I'm interested because of remote parec

[lealoureiro]

I've been testing this all night, and it's working great with a bunch of streams. I've been able to separate my services (multiple librespot instances, mopidy, etc) and the FIFO mess is gone!

I've also been able to stream the audio from my PC to snapcast from pulseaudio.

Config:

stream = tcp://0.0.0.0:4956?name=PC

On my PC I pipe pulseaudio to netcat:

$ parec --rate=48000 --format=s16le --channels=2 | nc snapserver.home 4956

Does anyone know of a better way to have pulseaudio send raw PCM over a network to a host?

Did you tried to use --server in parec command?

According to documentation you can specify hostname.

[hav0ck]

Dumb question.
I'm having a an issue when I have more than 1 client connected to snapcast. One client plays a digital scream for about 10 seconds and then resumes the stream, the other blanks the audio for about 10 seconds as well.
I made the changes to mopidy.conf and snapcast.conf but I am getting errors like "mopidy.audio.actor: Setting GStreamer state to GST_STATE_PLAYING failed" and "mopidy.audio.gst: GStreamer error: gst-resource-error-quark: Could not open resource for reading"

I've read and re-read this issue and it looks like a plugin is needed?
I'm running the latest stable which was installed with the .deb file on Ubuntu 18.04.

Thanks

[fatg3erman]

I’ve been running this regularly since it was first released and have at some point encountered all the problems described in the thread. I’ve done a lot of debugging and a lot of research and have come to the conclusion that, if it’s not outputting directly to audio hardware, GStreamer just isn’t very good.

To everybody having issues with mopidy my only advice is either learn to live with them or switch to MPD.

[gerroon]

GStreamer just isn’t very good.

This is why Mopidy is not cutting it. I exactly did what fatg3erman says, switched to MPD.

[badaix]

Are there other output plugins available that could me more reliable?
Also one could consider writing another sink for gstreamer, maybe a real pipe sink, instead of a file sink.

[hav0ck]

I did get the TCP stream working after upgrading to Mopidy 3.
I need to do more testing but lastnight there were frequent short audio drops and no audio at all for extended periods of time. Last night may have been wi-fi congestion...

[william-bohannan]

Have the following working with TCP between Mopidy and Snapcast, works much better than FIFO:

1. Mopidy Mobile (Android): select music.local and play song. Plays on both remotes (music-1.local and music-2.local).
2. Mopidy Mobile (Android): select music-1.local and play song. Plays on music-1.local.

The issue is if i do 1. and 2. at the same time then both songs come out of music-1.local speakers at the the same time. It there a way to have it so the latest action cancels the previous action? Below are the configurations:

Server (Unraid VM/Ubuntu 20.04): music.local

/etc/snapserver.conf
stream = tcp://127.0.0.1:3333?name=mopidy_tcp

/etc/mopidy/mopidy.conf

[file]
media_dirs = /mnt/user/tunes

[http]
hostname = 0.0.0.0
zeroconf = Tunes on $hostname

[mpd]
hostname = 0.0.0.0
zeroconf = Tunes on $hostname

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpclientsink hotost=127.0.0.1 port=3333

Remote/s (RPI/Ubuntu 20.04): music-1.local, music-2.local

/etc/defaults/snapclient
SNAPCLIENT_OPTS="--host 192.168.2.5"

/etc/mopidy/mopidy.conf

[file]
media_dirs = /mnt/user/tunes

[http]
hostname = 0.0.0.0
zeroconf = Tunes on $hostname

[mpd]
hostname = 0.0.0.0
zeroconf = Tunes on $hostname

[audio]
output = alsasink

[kingosticks]

Does anyone have problems with seeking when using tcpclientsink ?

Yes, if used with wavenc. But we don't need wavenc since snapcast wants S16LE PCM @ 48K (or whatever you have configured) and that's what audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE provides us with. I've had no seeking problems (so far) using:

output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! tcpclientsink host=127.0.0.1

I've tested with GStreamer 1.16.2.0 on Ubuntu 20.04 and GStreamer 1.14.4.0 on Raspbian Buster.

However, I do see the issue with the playback position within Mopidy not corresponding to what snapcast is playing. Mopidy's position is delayed. Need to spend more time looking at that. I also hear a little stutter when playing starts or seeks but I'm not convinced that's a Mopidy/GStreamer issue.

It's maybe worth also mentioning that seeking actually works OK if you substitute wavenc for a different encoder e.g. opusenc. Obviously snapcast can't decode opus (although it does try and it doesn't sound great!) but the seek does actually work and there's no GStreamer error as with wavenc. I don't know what's specifically wrong with wavenc or if it's a combination of it's problem along with the tcp*sinks themselves. Those sinks don't see much usage / love, I'm not sure how great they are (but I do like that they let you run Mopidy and Snapcast on different systems and they would also work for Mopidy on Windows).

I gave this all a try after also trying filesink. I didn't actually hit any problems using filesink myself - gapless worked, seeking worked, the playback position remained accurate. But it's a complicated beast and it's really not designed with FIFOs in mind, it just happens to work with them ...some of the time. There's a stark difference when comparing GStreamer's jack-of-all-trades filesink implementation to MPD's super simple FIFO output. FIFO-specific things like creating the FIFO (and then removing it after) and sensibly handling the full condition are handled by MPD but not by filesink. I'm a little tempted to have another look at a dedicated GStreamer fifosink... Although I'd want to understand better and reproduce what's currently wrong with filesink.

[fatg3erman]

Latest snapcast has an ALSA loopback sink which is working much better than either fifo or tcp for me with mopidy. Still has the playback position being off, but surely that's just buffering in snapserver?

[kingosticks]

but surely that's just buffering in snapserver?

Unsure. Bizarrely the playback position offset seems to be noticeably better (less) when Mopidy is running on a different machine to snapserver. Not sure I expected that.

EDIT:
Oh wait. I wasn't thinking, it makes sense. It would take longer for the audio data to travel over the network from the Mopidy machine to the snapserver machine, would arrive at snapserver later, and so would be played later. If there was enough delay then playback would appear more synchronised w.r.t Mopidy's delayed current position (but it's just dumb luck).

But for Mopidy's position to be behind, I think that must be a problem within Mopidy. Maybe tcpclientsink is reporting a much larger latency than it's actually seeing.

[christf]

It's maybe worth also mentioning that seeking actually works OK if you substitute wavenc for a different encoder e.g. opusenc. Obviously snapcast can't decode opus (although it does try and it doesn't sound great!) but the seek does actually work and there's no GStreamer error as with wavenc. I don't know what's specifically wrong with wavenc or if it's a combination of it's problem along with the tcp*sinks themselves. Those sinks don't see much usage / love, I'm not sure how great they are (but I do like that they let you run Mopidy and Snapcast on different systems and they would also work for Mopidy on Windows).

I gave this all a try after also trying filesink. I didn't actually hit any problems using filesink myself - gapless worked, seeking worked, the playback position remained accurate. But it's a complicated beast and it's really not designed with FIFOs in mind, it just happens to work with them ...some of the time. There's a stark difference when comparing GStreamer's jack-of-all-trades filesink implementation to MPD's super simple FIFO output. FIFO-specific things like creating the FIFO (and then removing it after) and sensibly handling the full condition are handled by MPD but not by filesink. I'm a little tempted to have another look at a dedicated GStreamer fifosink... Although I'd want to understand better and reproduce what's currently wrong with filesink.

That would be interesting. I am using filesink as well and I am seeing playback stop in a playlist after every track. I am not using waveenc as that would mess up the data by including wav headers. As you write, PCM should be just fine.
I have seen an end of stream but cannot figure out why playback stops.

[pcwii]

I've now also tested this with mopidy and things work fine apart from one fact: If I stop music on mopidy or switch the song, this sometimes takes ~ 30 seconds to propagate to the snapclient instances. Any ideas on that? Sounds a like the buffer is too large.

@languitar I realize this was over a year ago now but did you ever solve this problem? I am not using mopidy but have the same results with the android client.

[christf]

On Wed, May 19, 2021 at 12:34:33PM -0700, pcwii wrote: > I've now also tested this with mopidy and things work fine apart from one fact: If I stop music on mopidy or switch the song, this sometimes takes ~ 30 seconds to propagate to the snapclient instances. Any ideas on that? Sounds a like the buffer is too large.

***@***.*** I realize this was over a year ago now but did you ever solve this problem? I am not using mopidy but have the same results with the android client. This is the logic being implemented in snapcast. In snapcastc (an own rewrite that was created at a time when badaix was busy and I wanted things changed) I did experiment with other mechanics for start/stop and pausing. The program follows the same principle as snapcast but has different behavior in those two aspects: * when starting, the audio plays back instantly. Buffers are filled in the background. * When stopping the same behavior as with snapcast exists except when audio is stopped and shortly therafter re-started. In this case the buffers are discarded and instant playback for the new track starts. This allows quick switching of songs. There might be other things that could be tried. In essence snapcast(c) must be told the users intent. So a side channel is needed besides the audio stream. If mopidy supports calling hooks this could be realized with extending the API of either tool.

…

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

[pcwii]

Thanks for the background. Just to update. I changed my tcp connection from mode=server to mode=client and I no longer of the 30 second delay. Now when I start the audio the snapcast begins within <2 seconds.

[badaix]

What about using an ALSA loopback device?
TCP buffers can be large and patient...

[pcwii]

What about using an ALSA loopback device?
TCP buffers can be large and patient...

Not sure. I have all my source material on one computer (debian) and running the snapcast docker on a second headless computer (were I have all my other containers). TCP seamed to be the logical choice. I tried a pipe fifo with an smb share but that gave me nothing but problems, I also tried analog out of one computer to analog in of second computer but quality was horible.

[jwillikers]

@badaix The ALSA loopback works great for me and fixes the seek and playback position issues I was experiencing with the TCP stream.

[PureTryOut]

In general TCP seems to work well and more reliable than FIFO. However I have been noticing an issue that requires me to restart the Mopidy instance every once and while. If Mopidy has been paused and thus not been playing music for a while, it changes the Snapcast state to idle according to the logs.

State changed: Mopidy, state: playing => idle
onStateChanged (Mopidy): idle

(mopidy is the name of the stream here)

However when I then want to resume the music, the state is never changed to playing any more and only restarting Mopidy does, even though Mopidy itself (through the Iris frontend) indicates music is playing. I'm not sure if this is an issue in Snapcast or some other part of the stack though. Has anyone been able to reproduce this or do you all have music playing 24/7? 😅

[fatg3erman]

According to the Mopidy devs, errors relating to FIFOs and TCP streams are usually down to GStreamer, which really isn't designed to be used that way. I switched to the ALSA loopback method some time ago and I haven't experienced a single problem since, and I sometimes leaves Mopidy paused for days on end.

[letshin]

I've been trying to do this and based on the logs it seems that I'm able to connect to the server but the client doesn't output any sound. It has a No chunk received for 5000ms. Closing ALSA. error. The settings I've used are:

mopidy.conf:
output = decodebin ! audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! tcpclientsink host=192.168.1.238 port=1704

snapserver.conf:
[stream] stream = tcp://127.0.0.1:1704
[http] doc_root = /usr/share/snapserver/snapweb

snapclient (via docker-compose):

devices: /dev/snd/
environment: HOST=192.168.1.238 PORT=1704
command: "-s PCH"

aplay -l:
' card 0: PCH [HDA Intel PCH], device 0: ALC3234 Analog [ALC3234 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 '
Error:

2023-10-08 11-26-23.245 [Info] (Snapclient) Version 0.26.0
2023-10-08 11-26-23.245 [Info] (Connection) Resolving host IP for: 192.168.XXX.XXX
2023-10-08 11-26-23.245 [Info] (Connection) Connecting
2023-10-08 11-26-23.246 [Notice] (Connection) Connected to 192.168.XXX.XXX
2023-10-08 11-26-23.246 [Info] (Connection) My MAC: "XXXXXX", socket: 7
2023-10-08 11-26-23.248 [Info] (Controller) ServerSettings - buffer: 1000, latency: 0, volume: 100, muted: 0
2023-10-08 11-26-23.248 [Info] (Controller) Codec: flac, sampleformat: 44100:16:2
2023-10-08 11-26-23.248 [Info] (Player) Player name: alsa, device: default:CARD=PCH, description: HDA Intel PCH, ALC3234 Analog
2023-10-08 11-26-23.248 [Info] (Player) Default Audio Device, idx: 1, sharing mode: unspecified, parameters: <none>
2023-10-08 11-26-23.248 [Info] (Player) Mixer mode: software, parameters: <none>
2023-10-08 11-26-23.248 [Info] (Player) Sampleformat: 44100:16:2, stream: 44100:16:2
2023-10-08 11-26-23.248 [Info] (Alsa) Using default buffer_time: 80 ms, default fragments: 4
2023-10-08 11-26-23.251 [Info] (Alsa) Period time too small, changing from 20000 to 21333
2023-10-08 11-26-23.251 [Info] (Alsa) PCM name: default:CARD=PCH, sample rate: 44100 Hz, channels: 2, buffer time: 85328 us, periods: 4, period time: 21333 us, period frames: 940
2023-10-08 11-26-23.251 [Info] (Stream) No chunks available
2023-10-08 11-26-23.251 [Info] (Alsa) Failed to get chunk
2023-10-08 11-26-23.313 [Info] (Controller) diff to server [ms]: 0.005
2023-10-08 11-26-24.232 [Info] (Stream) Exception: Not enough frames available, requested frames: 933, available: 662
2023-10-08 11-26-24.232 [Info] (Alsa) Failed to get chunk
2023-10-08 11-26-29.246 [Notice] (Alsa) No chunk received for 5000ms. Closing ALSA.
2023-10-08 11-26-48.413 [Info] (Snapclient) Received signal 15: Terminated
2023-10-08 11-26-48.495 [Notice] (Snapclient) Snapclient terminated.

I'm not sure if it makes a difference but I'm trying to play a .flac file

What does this mean and how can I solve it please.