profile
viewpoint

InfoSansOrdi/CSIRL 21

Computer Science In Real Life

bleuchtang/sunxi-debian 4

Bootstrap a minimal debian rootfs for sunxi boards

mc0e/puppet-gitlab 3

Puppet module for manage GitLab installation

mquinson/simgrid-scalability-XPs 3

Scalability experiments on SimGrid

mc0e/vagrant-gitlab 2

Splitting sbadia/puppet-gitlab into a vagrant project and two puppet modules. This is the vagrant bit

sbadia/aptly 1

aptly - Debian repository management tool

sbadia/bird-exporter-deb 1

Debian package for bird_exporter (https://github.com/czerwonk/bird_exporter)

sbadia/bwlat 1

MPI/C Latency/Flow tests

issue commentbadaix/snapcast

Stutter with multiple snapclient instances and pulse-remap/alsa

IN the debug log is not really much to see. After the last line i press STRG+C (also tried SIGTERM [kill -TERM PID]) No output. Hope it helps , Ronny

2020-11-25 11-30-52.299 [Info] (Connection) Resolving host IP for: 10.0.0.51 2020-11-25 11-30-52.300 [Info] (Connection) Connecting 2020-11-25 11-30-52.306 [Notice] (Connection) Connected to 10.0.0.51 2020-11-25 11-30-52.306 [Info] (Connection) My MAC: "b8:27:eb:53:f5:6a", socket: 9 2020-11-25 11-30-53.043 [Debug] (Connection) outstanding async_write 2020-11-25 11-30-53.052 [Info] (Controller) ServerSettings - buffer: 1000, latency: 0, volume: 50, muted: 0 2020-11-25 11-30-53.056 [Info] (Controller) Codec: flac, sampleformat: 48000:16:2 2020-11-25 11-30-53.057 [Info] (Player) Player name: pulse, device: plughw:CARD=sndrpihifiberry,DEV=0, description: snd_rpi_hifiberry_dac, HifiBerry DAC HiFi pcm5102a-hifi-0 2020-11-25 11-30-53.057 [Info] (Player) Hardware device with all software conversions, idx: 6, sharing mode: unspecified, parameters: <none> 2020-11-25 11-30-53.057 [Info] (Player) Mixer mode: software, parameters: <none> 2020-11-25 11-30-53.057 [Info] (Player) Sampleformat: 48000:16:2, stream: 48000:16:2 2020-11-25 11-30-53.058 [Info] (PulsePlayer) Using buffer_time: 80 ms

NDahlem

comment created time in a few seconds

push eventRIPE-Atlas-Community/ripe-atlas-community-contrib

Vesna Manojlovic

commit sha ef0a5d59b8d8cc7488873cf7a828e51bd67c9402

Add files via upload

view details

push time in 5 minutes

issue commentbadaix/snapcast

Stutter with multiple snapclient instances and pulse-remap/alsa

can you also provide a debug log for the STRG+C issue? Please use the latest develop version (self compiled or from Actions)

NDahlem

comment created time in 16 minutes

issue commentbadaix/snapcast

Stutter with multiple snapclient instances and pulse-remap/alsa

@badaix yeahh sorry, missunderstood it, testing it now with 1 snapclient device.

When i start it with "--player pulse" i can not terminate the process with a STRG+C or SIGTERM, I have to use a SIGKILL. With the "--player alsa" i can use STRG+C / SIGTERM to stop the client.

I will do the audible audio test, at home in the evening then ;)

NDahlem

comment created time in 31 minutes

fork strider/tripleo-quickstart-extras

Extra Ansible roles to automate TripleO deployments. Mirror of code maintained at opendev.org.

https://opendev.org/openstack/tripleo-quickstart-extras

fork in 34 minutes

issue commentbadaix/snapcast

Server continually sending data even when not playing

fixed 4b7c313fa03dd6a8a558a22289a76658343aceef

fatg3erman

comment created time in 2 hours

push eventbadaix/snapcast

badaix

commit sha 4b7c313fa03dd6a8a558a22289a76658343aceef

Make sending of silence configurable

view details

push time in 2 hours

issue commentbadaix/snapcast

Server continually sending data even when not playing

yes, you're right. The Alsa stream plugin has a silence detection:

        if (std::memcmp(chunk_->payload, silent_chunk_.data(), silent_chunk_.size()) == 0)
        {
            silence_ += chunk_->duration<std::chrono::microseconds>();
            if (silence_ > 100ms)
            {
                setState(ReaderState::kIdle);
            }
        }

And this is working: after 100ms of silence, the stream state switches to "idle", but the silence is actually sent to the clients, which is not intended.

fatg3erman

comment created time in 11 hours

push eventpeering-manager/peering-manager

Guillaume Mazoyer

commit sha c1b4169491bbe71b42f75421bbd56e804e46c63e

Fix PeeringDB IX import and set the local AS on import

view details

push time in 12 hours

issue commentbadaix/snapcast

Server continually sending data even when not playing

To follow up, I tried using a pipe sink instead, and that behaves as you describe. So it seems this is only occurring with the alsa loopback sink.

Sadly the pipe sink does not work well with Mopidy. The alsa loopback works very well apart from this.

fatg3erman

comment created time in 12 hours

issue commentbadaix/snapcast

Server continually sending data even when not playing

It's not the case that the source is continually playing. Mopidy is not even running when I do these tests. The network traffic starts as soon as I start snapserver. It seems as if, with the ALSA loopback sink, snapserver thinks playback is always happening, or is just sending silence when there is no incoming audio.

Here are some logs. These were taken with the player not running. The snapcast traffic was clearly happening and started as soon as I started the server.

Nov 24 18:33:47 kodi snapserver[25842]: Settings file: "/var/lib/snapserver/server.json" Nov 24 18:33:47 kodi snapserver[25842]: Adding service 'Snapcast' Nov 24 18:33:47 kodi snapserver[25842]: PcmStream: RompR, sampleFormat: 44100:16:2 Nov 24 18:33:47 kodi snapserver[25842]: Stream: RompR, metadata={ Nov 24 18:33:47 kodi snapserver[25842]: "STREAM": "RompR" Nov 24 18:33:47 kodi snapserver[25842]: } Nov 24 18:33:47 kodi snapserver[25842]: onMetaChanged (RompR) Nov 24 18:33:47 kodi snapserver[25842]: Stream: {"fragment":"","host":"","path":"","query":{"chunk_ms":"20","codec":"pcm","device":"hw:0,1,0","name":"RompR","sampleformat":"44100:16:2"},"raw":"alsa:///?chunk_ms=20&codec=pcm&device=hw:0,1,0&name=RompR&sampleformat=44100:16:2","scheme":"alsa"} Nov 24 18:33:47 kodi snapserver[25842]: No data availabale, playing silence. Nov 24 18:33:47 kodi snapserver[25842]: Creating TCP acceptor for address: 0.0.0.0, port: 1705 Nov 24 18:33:47 kodi snapserver[25842]: Creating HTTP acceptor for address: 0.0.0.0, port: 1780 Nov 24 18:33:47 kodi snapserver[25842]: Creating stream acceptor for address: 0.0.0.0, port: 1704 Nov 24 18:33:47 kodi snapserver[25842]: number of threads: 4, hw threads: 4 Nov 24 18:33:48 kodi snapserver[25842]: Service 'Snapcast' successfully established. Nov 24 18:33:48 kodi snapserver[25842]: StreamServer::NewConnection: 192.168.0.26 Nov 24 18:33:48 kodi snapserver[25842]: StreamServer::NewConnection: 192.168.0.35 Nov 24 18:33:48 kodi snapserver[25842]: Hello from b8:27:eb:08:34:61, host: kitchen, v0.21.0, ClientName: Snapclient, OS: Raspbian GNU/Linux 10 (buster), Arch: armv7l, Protocol version: 2 Nov 24 18:33:48 kodi snapserver[25842]: Hello from b8:27:eb:9a:d5:ee, host: raspberrypi, v0.21.0, ClientName: Snapclient, OS: Raspbian GNU/Linux 10 (buster), Arch: armv7l, Protocol version: 2 Nov 24 18:33:48 kodi snapserver[25842]: StreamServer::NewConnection: 192.168.0.20 Nov 24 18:33:48 kodi snapserver[25842]: Hello from b8:27:eb:93:d1:cf, host: zero, v0.21.0, ClientName: Snapclient, OS: Raspbian GNU/Linux 10 (buster), Arch: armv6l, Protocol version: 2 Nov 24 20:14:44 kodi snapserver[25842]: next read < 0 (RompR): -1.421 ms Nov 24 20:14:44 kodi snapserver[25842]:
Nov 24 20:14:44 kodi snapserver[25842]: next read < 0 (RompR): -7.453 ms Nov 24 20:14:47 kodi snapserver[25842]: next read < 0 (RompR): -1.911 ms

Nov 24 18:33:48 zero snapclient[2046]: Connecting Nov 24 18:33:48 zero snapclient[2046]: Connected to 192.168.0.33 Nov 24 18:33:48 zero snapclient[2046]: My MAC: "b8:27:eb:93:d1:cf", socket: 8 Nov 24 18:33:48 zero snapclient[2046]: ServerSettings - buffer: 1000, latency: 0, volume: 58, muted: 0 Nov 24 18:33:48 zero snapclient[2046]: Codec: pcm, sampleformat: 44100:16:2 Nov 24 18:33:48 zero snapclient[2046]: Player name: alsa, device: hw:CARD=BossDAC,DEV=0, description: BossDAC, Boss DAC HiFi [Master] pcm512x-hifi-0 Nov 24 18:33:48 zero snapclient[2046]: Direct hardware device without any conversions, idx: 7, sharing mode: unspecified Nov 24 18:33:48 zero snapclient[2046]: Mixer mode: hardware, parameters: Digital Nov 24 18:33:48 zero snapclient[2046]: Sampleformat: 44100:16:2, stream: 44100:16:2 Nov 24 18:33:48 zero snapclient[2046]: diff to server [ms]: -4.28301e+08

That is everything in the logs.

Thanks

On 24 Nov 2020, at 21:05, Johannes Pohl notifications@github.com wrote:

Your router is getting hot from three compressed audio streams?

The server is only sending audio when the source is active. When the source is idle, the client will not receive any audio and release the PCM device after 5s, as you can see in the client logs:

2020-11-24 21-54-33.773 [Info] (Connection) Resolving host IP for: 192.168.0.3 2020-11-24 21-54-33.774 [Info] (Connection) Connecting 2020-11-24 21-54-33.780 [Notice] (Connection) Connected to 192.168.0.3 2020-11-24 21-54-33.780 [Info] (Connection) My MAC: "00:21:6a:7d:74:fc", socket: 8 2020-11-24 21-54-33.861 [Debug] (Connection) outstanding async_write 2020-11-24 21-54-33.865 [Info] (Controller) ServerSettings - buffer: 1000, latency: 0, volume: 75, muted: 0 metadata:{"STREAM":"Meta"} 2020-11-24 21-54-33.865 [Info] (Controller) Codec: flac, sampleformat: 48000:16:2 2020-11-24 21-54-33.865 [Info] (Player) Player name: alsa, device: hw:CARD=Intel,DEV=0, description: HDA Intel, CX20561 Analog 2020-11-24 21-54-33.865 [Info] (Player) Direct hardware device without any conversions, idx: 32, sharing mode: unspecified, parameters: <none> 2020-11-24 21-54-33.865 [Info] (Player) Mixer mode: software, parameters: <none> 2020-11-24 21-54-33.865 [Info] (Player) Sampleformat: 48000:16:2, stream: 48000:16:2 2020-11-24 21-54-33.865 [Info] (Alsa) Using buffer_time: 80 ms, fragments: 4 2020-11-24 21-54-33.865 [Debug] (Alsa) PCM name: hw:CARD=Intel,DEV=0 2020-11-24 21-54-33.865 [Debug] (Alsa) PCM state: PREPARED 2020-11-24 21-54-33.866 [Debug] (Alsa) channels: 2 2020-11-24 21-54-33.866 [Debug] (Alsa) rate: 48000 bps 2020-11-24 21-54-33.866 [Debug] (Alsa) frames: 960 2020-11-24 21-54-33.866 [Debug] (Alsa) buffer time: 80000 2020-11-24 21-54-33.866 [Debug] (Alsa) period time: 20000 2020-11-24 21-54-33.866 [Debug] (Alsa) periods: 4 2020-11-24 21-54-33.866 [Debug] (Player) setVolume exp with base 10: 0.75 => 0.513713 2020-11-24 21-54-33.866 [Debug] (Alsa) Resizing buffer from 0 to 15360 2020-11-24 21-54-33.866 [Info] (Stream) no chunks available 2020-11-24 21-54-33.866 [Info] (Alsa) Failed to get chunk 2020-11-24 21-54-34.130 [Info] (Controller) diff to server [ms]: 5.95066e+09 2020-11-24 21-54-34.774 [Debug] (Stream) Silent frames: 437, frames: 960, age: -9.105 2020-11-24 21-54-34.794 [Debug] (Stats) Chunk: 0 0 0 0 1 60 0 2020-11-24 21-54-35.014 [Debug] (Stats) Chunk: 0 0 0 0 12 60 0 2020-11-24 21-54-36.014 [Debug] (Stats) Chunk: 0 0 0 0 58 60 0 2020-11-24 21-54-37.014 [Debug] (Stats) Chunk: 0 0 0 0 105 60 0 2020-11-24 21-54-38.014 [Debug] (Stats) Chunk: 0 0 0 0 146 60 0 2020-11-24 21-54-39.034 [Debug] (Stats) Chunk: 0 0 0 0 187 40 0 2020-11-24 21-54-40.034 [Debug] (Stats) Chunk: 0 0 0 0 231 40 0 2020-11-24 21-54-41.014 [Debug] (Stats) Chunk: 0 0 0 0 275 60 0 2020-11-24 21-54-42.014 [Debug] (Stats) Chunk: 0 0 0 0 314 60 0 2020-11-24 21-54-43.014 [Debug] (Stats) Chunk: 0 0 0 0 359 60 0 2020-11-24 21-54-44.034 [Debug] (Stats) Chunk: 0 0 0 0 397 40 0 2020-11-24 21-54-45.014 [Debug] (Stats) Chunk: 0 0 0 0 440 60 0 2020-11-24 21-54-46.014 [Debug] (Stats) Chunk: 0 0 0 0 479 60 0 2020-11-24 21-54-47.014 [Debug] (Stats) Chunk: 0 0 0 0 500 60 0 2020-11-24 21-54-48.014 [Debug] (Stats) Chunk: -1 0 0 0 500 60 0 2020-11-24 21-54-49.034 [Debug] (Stats) Chunk: 0 0 0 0 500 40 0 2020-11-24 21-54-50.014 [Debug] (Stats) Chunk: 0 0 0 0 500 60 0 2020-11-24 21-54-51.014 [Debug] (Stats) Chunk: 0 0 0 0 500 60 0 2020-11-24 21-54-52.014 [Debug] (Stats) Chunk: -1 0 0 0 500 60 0 2020-11-24 21-54-53.014 [Debug] (Stats) Chunk: 0 0 0 0 500 60 0

Pause pressed in MPD

2020-11-24 21-54-54.194 [Info] (Stream) Exception: 0 2020-11-24 21-54-54.194 [Info] (Alsa) Failed to get chunk 2020-11-24 21-54-54.294 [Debug] (Alsa) Waiting for chunk .... 2020-11-24 21-54-59.208 [Debug] (Alsa) Waiting for chunk 2020-11-24 21-54-59.208 [Notice] (Alsa) No chunk received for 5000ms. Closing ALSA. 2020-11-24 21-54-59.308 [Debug] (Alsa) Waiting for chunk 2020-11-24 21-54-59.409 [Debug] (Alsa) Waiting for chunk ... On the server:

Nov 24 21:54:53 raspberrypi snapserver[32557]: State changed: default, state: 2 => 1 Nov 24 21:54:53 raspberrypi snapserver[32557]: onStateChanged (default): 1 Nov 24 21:54:53 raspberrypi snapserver[32557]: State changed: Meta, state: 2 => 1 with 1 = ilde, 2 = playing

enum class ReaderState { kUnknown = 0, kIdle = 1, kPlaying = 2, kDisabled = 3 }; So it rather seems that your stream source is continuously playing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

fatg3erman

comment created time in 12 hours

issue openedbadaix/snapcast

Possible to assign no source to a zone?

Is your feature request related to a problem? Please describe. Is it possible to assign nothing to a zone (no sound at all for all speakers in that zone)?

Describe the solution you'd like Something like "None" inside the Snapweb source picker would be nice.

created time in 12 hours

issue commentbadaix/snapcast

self-compiled snapclient on OpenSuSE 64-Bit doesn't work

BTW: What sound device are you using (vendor, model)?

I'm working with an older Tower-PC with an NVIDIA-card, which is currently disabled. So the speakers are connected to the (mainboard?)-audio, which seems to be Intel.

As inexperienced audio-user I'm not sure how to retrieve the HW-information.

Pulseaudio reports: alsa.card = "0" alsa.card_name = "HDA Intel PCH" alsa.long_card_name = "HDA Intel PCH at 0xf6300000 irq 41" alsa.driver_name = "snd_hda_intel"

Alsa reports: Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC887-VD Analog [ALC887-VD Analog] Sub-Geräte: 0/1 Sub-Gerät #0: subdevice #0 Karte 0: PCH [HDA Intel PCH], Gerät 1: ALC887-VD Digital [ALC887-VD Digital] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0

hp4

comment created time in 13 hours

issue commentbadaix/snapcast

Server continually sending data even when not playing

Your router is getting hot from three compressed audio streams?

The server is only sending audio when the source is active. When the source is idle, the client will not receive any audio and release the PCM device after 5s, as you can see in the client logs:

2020-11-24 21-54-33.773 [Info] (Connection) Resolving host IP for: 192.168.0.3
2020-11-24 21-54-33.774 [Info] (Connection) Connecting
2020-11-24 21-54-33.780 [Notice] (Connection) Connected to 192.168.0.3
2020-11-24 21-54-33.780 [Info] (Connection) My MAC: "00:21:6a:7d:74:fc", socket: 8
2020-11-24 21-54-33.861 [Debug] (Connection) outstanding async_write
2020-11-24 21-54-33.865 [Info] (Controller) ServerSettings - buffer: 1000, latency: 0, volume: 75, muted: 0
metadata:{"STREAM":"Meta"}
2020-11-24 21-54-33.865 [Info] (Controller) Codec: flac, sampleformat: 48000:16:2
2020-11-24 21-54-33.865 [Info] (Player) Player name: alsa, device: hw:CARD=Intel,DEV=0, description: HDA Intel, CX20561 Analog
2020-11-24 21-54-33.865 [Info] (Player) Direct hardware device without any conversions, idx: 32, sharing mode: unspecified, parameters: <none>
2020-11-24 21-54-33.865 [Info] (Player) Mixer mode: software, parameters: <none>
2020-11-24 21-54-33.865 [Info] (Player) Sampleformat: 48000:16:2, stream: 48000:16:2
2020-11-24 21-54-33.865 [Info] (Alsa) Using buffer_time: 80 ms, fragments: 4
2020-11-24 21-54-33.865 [Debug] (Alsa) PCM name: hw:CARD=Intel,DEV=0
2020-11-24 21-54-33.865 [Debug] (Alsa) PCM state: PREPARED
2020-11-24 21-54-33.866 [Debug] (Alsa) channels: 2
2020-11-24 21-54-33.866 [Debug] (Alsa) rate: 48000 bps
2020-11-24 21-54-33.866 [Debug] (Alsa) frames: 960
2020-11-24 21-54-33.866 [Debug] (Alsa) buffer time: 80000
2020-11-24 21-54-33.866 [Debug] (Alsa) period time: 20000
2020-11-24 21-54-33.866 [Debug] (Alsa) periods: 4
2020-11-24 21-54-33.866 [Debug] (Player) setVolume exp with base 10: 0.75 => 0.513713
2020-11-24 21-54-33.866 [Debug] (Alsa) Resizing buffer from 0 to 15360
2020-11-24 21-54-33.866 [Info] (Stream) no chunks available
2020-11-24 21-54-33.866 [Info] (Alsa) Failed to get chunk
2020-11-24 21-54-34.130 [Info] (Controller) diff to server [ms]: 5.95066e+09
2020-11-24 21-54-34.774 [Debug] (Stream) Silent frames: 437, frames: 960, age: -9.105
2020-11-24 21-54-34.794 [Debug] (Stats) Chunk: 0	0	0	0	1	60	0
2020-11-24 21-54-35.014 [Debug] (Stats) Chunk: 0	0	0	0	12	60	0
2020-11-24 21-54-36.014 [Debug] (Stats) Chunk: 0	0	0	0	58	60	0
2020-11-24 21-54-37.014 [Debug] (Stats) Chunk: 0	0	0	0	105	60	0
2020-11-24 21-54-38.014 [Debug] (Stats) Chunk: 0	0	0	0	146	60	0
2020-11-24 21-54-39.034 [Debug] (Stats) Chunk: 0	0	0	0	187	40	0
2020-11-24 21-54-40.034 [Debug] (Stats) Chunk: 0	0	0	0	231	40	0
2020-11-24 21-54-41.014 [Debug] (Stats) Chunk: 0	0	0	0	275	60	0
2020-11-24 21-54-42.014 [Debug] (Stats) Chunk: 0	0	0	0	314	60	0
2020-11-24 21-54-43.014 [Debug] (Stats) Chunk: 0	0	0	0	359	60	0
2020-11-24 21-54-44.034 [Debug] (Stats) Chunk: 0	0	0	0	397	40	0
2020-11-24 21-54-45.014 [Debug] (Stats) Chunk: 0	0	0	0	440	60	0
2020-11-24 21-54-46.014 [Debug] (Stats) Chunk: 0	0	0	0	479	60	0
2020-11-24 21-54-47.014 [Debug] (Stats) Chunk: 0	0	0	0	500	60	0
2020-11-24 21-54-48.014 [Debug] (Stats) Chunk: -1	0	0	0	500	60	0
2020-11-24 21-54-49.034 [Debug] (Stats) Chunk: 0	0	0	0	500	40	0
2020-11-24 21-54-50.014 [Debug] (Stats) Chunk: 0	0	0	0	500	60	0
2020-11-24 21-54-51.014 [Debug] (Stats) Chunk: 0	0	0	0	500	60	0
2020-11-24 21-54-52.014 [Debug] (Stats) Chunk: -1	0	0	0	500	60	0
2020-11-24 21-54-53.014 [Debug] (Stats) Chunk: 0	0	0	0	500	60	0

Pause pressed in MPD

2020-11-24 21-54-54.194 [Info] (Stream) Exception: 0
2020-11-24 21-54-54.194 [Info] (Alsa) Failed to get chunk
2020-11-24 21-54-54.294 [Debug] (Alsa) Waiting for chunk
....
2020-11-24 21-54-59.208 [Debug] (Alsa) Waiting for chunk
2020-11-24 21-54-59.208 [Notice] (Alsa) No chunk received for 5000ms. Closing ALSA.
2020-11-24 21-54-59.308 [Debug] (Alsa) Waiting for chunk
2020-11-24 21-54-59.409 [Debug] (Alsa) Waiting for chunk
...

On the server:

Nov 24 21:54:53 raspberrypi snapserver[32557]: State changed: default, state: 2 => 1
Nov 24 21:54:53 raspberrypi snapserver[32557]: onStateChanged (default): 1
Nov 24 21:54:53 raspberrypi snapserver[32557]: State changed: Meta, state: 2 => 1

with 1 = ilde, 2 = playing

enum class ReaderState
{
    kUnknown = 0,
    kIdle = 1,
    kPlaying = 2,
    kDisabled = 3
};

So it rather seems that your stream source is continuously playing.

fatg3erman

comment created time in 13 hours

push eventbadaix/snapcast

badaix

commit sha d832d457e131ad5cfcce14f8df11288b1f69ac06

Fix adding the snapclient user to audio group

view details

badaix

commit sha 90c7ba8a671ef119187471c6034a96c3945d08a8

Raise version number to v0.23.0

view details

push time in 14 hours

issue commentbadaix/snapcast

Snapclient build and install from source permission issue

I was able to reproduce the issue on my Linux Mint desktop. Using the script fixes the problem.

gramtech

comment created time in 14 hours

issue commentbadaix/snapcast

Snapclient build and install from source permission issue

I had the same problem some time ago with snapcast and also with pulseaudio. In my understanding of the Linux-Audio-concepts, everyone who wants access to the audio-system has to be member of the group "audio".

Therefore you have to decide how you want to integrate any software in the audio-system:

  • pulseaudio strongly discourages system-mode, so the pulseaudio-server ist started during local user-login. Therefore the local users have to be members of the "audio"-group, if they want to play audio. This clearly is not useful e.g. in a headless RasPi-environment.

  • if you want to run additional server-software like mpd or snapserver, you face the same problems, especially if they are relying on pulseaudio: you can run it in system-mode (user root) or in a user session after login, in which case the user has to be member of the "audio"-group.

  • also for clients like snapclient you have both options: you can run them as system-service in a headless environment ( in which case they should run as root or as special user like "snapclient") or as user-service during login for any user (in which case the user should be member of the "audio"-group.)

So it might be difficult for the installation/make-script to cover all those aspects.

gramtech

comment created time in 14 hours

issue commentbadaix/snapcast

self-compiled snapclient on OpenSuSE 64-Bit doesn't work

additional info: the snapclient-binary in the develop-branch references the following new libraries: libpulse.so.0 libpulsecommon-13.0.so libxcb.so.1 libsndfile.so.1 libXau.so.6 libvorbisenc.so.2 libspeex.so.1

Since the old binary didn't reference any pulseaudio-library I'm wondering, why the problem only occurs with pulseaudio in the middle. Are the failing calls to "snd_pcm_avail_delay" located in the libasound-library? And are they not used when playing directly to alsa or when using the new option "--player pulse"?

hp4

comment created time in 16 hours

issue commentbadaix/snapcast

self-compiled snapclient on OpenSuSE 64-Bit doesn't work

Seems that the device "Default ALSA Output (currently PulseAudio Sound Server)" cannot properly report the current buffer size and latency. Can you try another device, e.g. some with direct hardware access (without PulseAudio)? (Option -s <index>, available PCM devices are listed with -l). Alternatively you can try the brand new PulseAudio backend in develop branch. It can be activated with --player pulse.

sorry for the delay: I've now compiled the develop-branch and replaced the binary snapclient.

Now everytyhing works fine with the option --player pulse !!!

So since all other audio functions with pulseaudio are ok locally and remote, I think, that the "release"-(non-develop)-snapclient doesn't work correctly with the pulseaudio-alsa-environment. Since the "release"-snapclient works fine with "--player file | aplay -f cd", it obviously is "pulseaudio-in-the-middle"-problem. And since all other applications work with "pulseaudio-in-the-middle", it's probably the snapclient interface, but only in X86-64Bit-architecture.

I've also seen that pulseaudio displays reasonable values for latency/buffer size in status-commands with pactl. So may be these values are corrupted on the way back to snapclient or misinterpreted?

hp4

comment created time in 16 hours

issue openedbadaix/snapcast

Server continually sending data even when not playing

Describe the bug Snapserver is sending audio to all connected clients even when nothing is playing. This means all clients are permanently using the sound card of the machine they are running on and no other application can play audio on them.

Steps to Reproduce

  1. Start snapserver. I am using the ALSA loopback device to receive audio from Mopidy. Mopidy does not need to be running.
  2. I'm simply observing the activity lights on my ethernet switch. They all go crazy. Muting clients stops the activity on those ports, indicating it is definitely snapcast traffic.

Environment details

  • OS: Raspbian Buster
  • Snapcast version 0.22
  • Installed from package downloaded from here.

I don't know whether this is possible to fix - what's the difference between "nothing playing" and "a bit of silence in a track"? - but it's definitely undesirable behaviour. I have 3 clients connected by wifi and my router is getting hot!

created time in 17 hours

issue commentbadaix/snapcast

Stutter with multiple snapclient instances and pulse-remap/alsa

The fixes are related to the clients, server doesn't need to be updated

NDahlem

comment created time in 18 hours

issue commentbadaix/snapcast

Snapclient build and install from source permission issue

I just checked and the Snapclient install target will simply execute

adduser:
	@if ! getent passwd snapclient >/dev/null; then \
		useradd --gid audio --system snapclient; \
	fi; \

while the server makes use of the debian snapserver.postinst script

adduser:
	sh ../debian/snapserver.postinst configure

A similar script exists for the client: snapclient.postinst:

#!/bin/sh

set -e

USERNAME=snapclient
HOMEDIR=/var/lib/snapclient

if [ "$1" = configure ]; then
  if ! getent passwd $USERNAME >/dev/null; then
    adduser --system --quiet --group --home $HOMEDIR --no-create-home --force-badname $USERNAME
    adduser $USERNAME audio
  fi

  if [ ! -d $HOMEDIR ]; then
    mkdir -m 0750 $HOMEDIR
    chown $USERNAME:$USERNAME $HOMEDIR
  fi
fi

Maybe calling this script from the client make install target would fix the issue. I will try this when I have a free slot.

gramtech

comment created time in 18 hours

push eventRIPE-Atlas-Community/ripe-atlas-community-contrib

Vesna Manojlovic

commit sha 1d527e6b362179ef96fd23ddf26f8c72df7a9865

Add files via upload

view details

push time in 18 hours

push eventRIPE-Atlas-Community/ripe-atlas-community-contrib

Vesna Manojlovic

commit sha 3c33fb6b4cf244db549cb2188ed94080a1ebf148

Update README.md

view details

push time in 19 hours

push eventRIPE-Atlas-Community/ripe-atlas-community-contrib

Vesna Manojlovic

commit sha 63cb3b5346fe5584f3e04d5415813ffdf7cc23d0

Update README.md

view details

push time in 19 hours

push eventRIPE-Atlas-Community/ripe-atlas-community-contrib

Vesna Manojlovic

commit sha 8f49b7c8fae5a171b6244ed04b4601f303449388

Create README.md

view details

push time in 19 hours

push eventRIPE-Atlas-Community/ripe-atlas-community-contrib

Vesna Manojlovic

commit sha ebc8aae1fd540f9e09724d4f92983a9ba93cb306

Update README.md

view details

push time in 19 hours

issue commentbadaix/snapcast

Snapclient build and install from source permission issue

I used make

gramtech

comment created time in 19 hours

issue commentbadaix/snapcast

Snapclient build and install from source permission issue

Did you use make or cmake?

gramtech

comment created time in 21 hours

more