Improve Snapcast-Handling

[DerPicknicker]

Hi,

we discussed this already on Discord.

Here are my main points:

• Add a slider for the buffer size current setting with 1000ms is to small for MCUs like esp32. It should be a slider because not all devices supporting such high values like 2500ms+. This will result in a more reliable playback.

• Add a input field for the initial volume 100 is a very bad setting if you connected the end device to speakers. It can cause damaging your speakers and your ears ;-)

• Don't stop stream and recreate them while track change => RealFlowMode

• Add support for pausing tracks

• Add the option to use downsampled audio ideally for an mono speaker

• Make Stream Name better readable, add Track-Name or something else which makes it possible to distinguish which stream content is playing and which player is connected to it or the speaker name

[OzGav]

Sounds very do-able.

[DerPicknicker]

Hey @OzGav ,

yes I think that too. For a 2.1 Release maybe? This would make my life happier because I don't have to use a seperate snapcast server ....

I would also love to see if scrubbing comes to the mobile webapp.

[Bram-diederik]

Is this the right place to talk about the snapcast stream name. that has no reference to the speaker at all.
if you now join a speaker to play the audio in a other room you cant distinguish in the ha what player is the master.

adding the speaker name in the stream name would make it fixable.

[DerPicknicker]

Vote my discussion up - I will Add that.

[SantiagoSotoC]

What range should the slider have?

[DerPicknicker]

I think starting from 500ms - 10000ms should be fine. Currently using a 5000ms buffer ;-)

[SantiagoSotoC]

Ok I take it into account, for the next improvements.

[DerPicknicker]

Cool! Would be great if you could also have the other things on your list ;-)

[SantiagoSotoC]

Changing the name of the stream is a bit complicated, because snap server identifies the streams by name and making it dynamic is not a good idea. also the name of the streams does not work very well in the clients until it is updated.
What do you think about metadata ? snapweb allows you to see what is being played in that stream and I think snapdroid supports it as well.

[SantiagoSotoC]

What do you think of an initial volume of 20?
Yes, I am going to put a slider but a default value is still needed

[SantiagoSotoC]

Good question, the idea is to use the snap server parameter, from what I understand it only applies when connecting a snapclient for the first time. @DerPicknicker did you try it ?

[OzGav]

Yeah I was thinking everyone’s circumstance will be different and in my case 100 is good as I adjust the physical volume of the speakers on my desk. If it remembers, then no problem otherwise maybe 20 is way too low?

[SantiagoSotoC]

It depends on what you have connected to the snapclient, it can be almost anything, from headphones to an amplifier of several hundred watts. It is just a value for the equipment to be protected.

[OzGav]

Yes will see what derpicknicker answers. Hopefully the value is saved.

[DerPicknicker]

Initial Volume is the volume which will be set for new speakers which are never used before. If you set the volume after first time of use to 20 it will be saved.

[SantiagoSotoC]

Can you develop the idea of downsampled audio, and how it would work in a group ? From what I understand I would have to create a lower quality stream and a single channel, the quality of the whole group would be affected.

[SantiagoSotoC]

Yes, the pause is complicated, I have to pause and resume the ffmpeg process something I tried and failed several times. I don't even know if this approach would work, or it requires changes outside the provider

Pause is a big change, this is simpler.

[DerPicknicker]

From my perspective (maybe I am totally wrong...) it should be enough:

1. Storing current position
2. Stream a not hearable sound to the speaker
3. If I resume go to saved position and drop off the not hearable sound.

This has one big advantage - it's a real flow mode. Because currently each time you start a song a new stream will be created. Which is not super smart.

[SantiagoSotoC]

Yes, the streams thing is not the most optimal, I was looking at how to change it and I have an idea and it doesn't seem so complicated but I don't want to leave streams hanging. I have to delete them at some point.

[SantiagoSotoC]

@marcelveldt What do you think about pausing ffmpeg by sending the subprocess a SIGSTOP and resuming with SIGCONT, I mean to implement the pause

[marcelveldt]

@marcelveldt What do you think about pausing ffmpeg by sending the subprocess a SIGSTOP and resuming with SIGCONT, I mean to implement the pause

It is way easier than that even, you just pause sending audio chunks to the pipe/tcp port

[grunjol]

When you are using an external Snapcast server and you are playing some external source on a specific speaker (or group) and you get an announcement, the speaker doesnt change back to the original external source after the announcement is played.

[OzGav]

Not surprising. How would you envisage that could work?

[SantiagoSotoC]

Yes, snapcast now always returns to the stream called "default". This is one of the pending changes

[grunjol]

Before i started with music assistant I managed all the announcements manually saving the state of the snapcast streams/clients mapping using the snapcast.snapshot service, set the announcement stream to the specified clients and restore it back using snapcast.restore to the previous mapping once it was played. This was my first approach and I implemented using HA scripts.

Second version I implemented and I think its a better solution for announcements (using native snapcast functionality) is create a meta stream with the announcement as a first priority and the 'music' stream as second. As you dynamically create the streams it should be no problem.

I implemented all these in HA using standard HA scripts and automation, but MA is way better to integrate.

[SantiagoSotoC]

Yes, the experience with MA is simpler, my idea is to bring snapcast to as many people as possible and external sources are not well supported yet, the snapshots service is not ideal, because it saves volume as well. I have to create a version that only saves the old stream.

The meta stream option is a problem because we create the streams dynamically and MA does not need a new stream for announcements.

I have some doubts about how to implement it, ma has no control over external sources and snapcast can only pause mopidy and MPD.
It can be a problem.

[DerPicknicker]

@SantiagoSotoC ..

What's the current status? Could you please tell me if your changes (if you already made some...) are available in the current beta?

[SantiagoSotoC]

Fixing bugs, no new features yet

[SantiagoSotoC]

Has anyone noticed that snapcast is more stable using PCM as transport codec?
Do you think it would be a better default?

[DerPicknicker]

Hi @SantiagoSotoC ..

Flac is lossless but compressed. It's 40-50% smaller than pcm (Wikipedia).

The esp32 boards don't struggle with flac decoding. As it's an easy format to decode. I can't see any difference on raspberry pi and esp32. Because flac is easily for decoding devices.

The main concern is that you need 40-50% more bandwidth to transmit the same data. So maybe give us the option but keep the best between both worlds. If you create more than 1 stream your WiFi have to transmit more than required.

[SantiagoSotoC]

That's what doesn't convince me, but in android the flac decoder fails sometimes, I was using flac, but because of those failures I switched to pcm and the stream is more stable.
yes, i know that more data is sent, for an esp32 isn't it better something like opus ?

Yes, in the new version you can choose the codec, I mean what would be the best option for most users. In snapweb I also feel it is more stable

[DerPicknicker]

Then it's fine. I would use flac as default regarding bandwidth.. Opus is currently not supported on esp32 Plattform.

[grunjol]

In my experience FLAC is better than PCM in both Rpi Zero W and ESP32 devices, specially when the device is not close to the AP or you have crowded wifi channel. This also allow you to set a smaller buffer resulting in lower latency, improving the overall experience.
And as @DerPicknicker said this both devices handle FLAC without problems.

[SantiagoSotoC]

Well then we leave it default to FLAC and put in the documentation that some stability problems are due to the codec and that it is best to test which one gives the best result on your system.

[SantiagoSotoC]

There is a problem with "RealFlowMode" the stream change is used to clear the buffer. If it is not done this way the previous song remains. Currently it only re-creates the stream when you hit the next button or send a TTS.

And on the other hand snapcast does not support renaming a stream for now, the option would be to put the name of the sync master.

[DerPicknicker]

Hey @SantiagoSotoC

Some thoughts from a person who doesn't know the internals of MA:

Why you don't expose one stream to the snapcast devices and internally create new ones?

So you're sending an endless stream to a speaker or a group of speakers. And if a tts message should be sent you can only switch the audio source of that stream.
More or less like a loopback device.

The device will always listen to one stream and the audio source will change internally. With this approach you don't need to recreate a stream on track change...

Or did I miss something here?