Streaming on localhost to bluealsa not working

[markusj]

I tried to set an additional output to bluealsa up. bluealsa playback works with aplay and gstreamer. With snapcastc (both client on server on localhost) I get high-pitched output for the fraction of a second (too fast playback?) and then only silence. At the same time, CPU usage goes up to 100%.

According to verbose output, the client does not even receive new chunks from the server. All other clients (three non-local) are not affected. verbose.txt

snapcast-client -H localhost -i 1 could not set priority. Adjusting priority helps on otherwise busy clients. Continuing. could not initialize mixer Master. Continuing with bogus volume values. You will not be able to control the volume .buffer not initialized. Old size: 0 WARN: huge loss of 15731 packets detected. Resetting seqno. This will be audible chunk size is not equal to alsa init size - (re-)initializing with samples: 48000 sample size: 2, channels 2 discarding chunk 15732 (play at: 1583630426.877745000) - too late, it is now 1583630426.980307000. BUFFER UNDERRUN BUFFER UNDERRUN BUFFER UNDERRUN BUFFER UNDERRUN Alsa buffer drained. This will be audible.

[christf]

This looks like the client is starving CPU time.

There is one way to ease load a bit: adjusting the alsa chunksize for generated silence in case there is no data. At the moment the client generates only 5ms of audio. This size was chosen to allow easier synchronisation in the beginning of the project and is a tradeoff between CPU usage and initial synchronization time and quality.

Also you could try running the client with realtime priority. When started with sudo, the client will do that automatically. If you don't want to do that you could use renice to achieve the same thing.

Since this mechanism was introduced, snapcastc has learned to create shorter amounts of silence when required. Looking back at the code I decided for a minor refactoring and in the process changed the amount of silence that is to be generated when there is no data from the network yet. Does that help already? https://github.com/christf/snapcastc/pull/58

[markusj]

This makes the CPU issue go away, but the playback is still broken. Somehow the playback speed is way to high, voices sounds like someone who inhaled helium. Is there a way how I can provide further information to help fixing the issue?

[christf]

There are still issues with the early sync code. Does the pitch change go away after playing bufferms milliseconds?

[christf]

one reason for audio issue will be resolved with #59 I am not confident at the moment all of the cases that can cause this already are covered.

[markusj]

There are still issues with the early sync code. Does the pitch change go away after playing bufferms milliseconds?

No, its stuttering and constantly present, even with #59. I uploaded a short recording of what should be a male voice: SoundRecord-2020-04-10-23-28-20.mp3.zip

Here is what the client reported (just the beginning, it printed a myriad more of buffer underruns. Anything else I can provide?

snapcast-client -i 1 -H localhost
could not set priority. Adjusting priority helps on otherwise busy clients. Continuing.
could not initialize mixer Master. Continuing with bogus volume values. You will not be able to control the volume .buffer not initialized. Old size: 0
WARN: huge loss of 116255 packets detected. Resetting seqno. This will be audible
chunk size is not equal to alsa init size - (re-)initializing with samples: 48000 sample size: 2, channels 2
discarding chunk 116256 (play at: 1586553751.453201000) - too late, it is now 1586553751.525832000. NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
handling volume change to 0 %
Packet loss for 2 packets detected: Last received audio chunk had seqno 116270, we just received 116273. NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
no more retries left for packet with id 116271 - we are missing data due to shaky network. This will be audible. no more retries left for packet with id 116272 - we are missing data due to shaky network. This will be audible.
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN
NETWORK BUFFER UNDERRUN

[christf]

how are you feeding into the snapfifo? What I think I am hearing is this:

• high-pitched voice
• intermittent pauses
• the audio sounds like speech.

From the logs I cannot see that packets are dropped but I can see that the network buffer is always empty or close to empty. The recording sounds bad. So bad, that I cannot explain it alone with bugs (I am using snapcastc to stream audio in my apartment. I get a few glitches here or there - specifically I think there is still something problematic with the handling of the priority queue in the client - but I can enjoy the music).

How exactly are you feeding your signal into the inputpipe from the server?

Hypothetically, feeding audio at 24000Hz while snapcastc is expecting 48kHz would yield a similar result: The audio would be high-pitched and there was not enough signal to go around so there would be intermittent breaks. Have you attempted to feed the inputpipe with the sox command from the readme?

sox input.ogg -r 48000 -t raw -b 16 -e signed -c 2 /tmp/snapfifo

[markusj]

* high-pitched voice
* intermittent pauses
* the audio sounds like speech.

It is, I was playing a podcast.

From the logs I cannot see that packets are dropped but I can see that the network buffer is always empty or close to empty. The recording sounds bad. So bad, that I cannot explain it alone with bugs (I am using snapcastc to stream audio in my apartment. I get a few glitches here or there - specifically I think there is still something problematic with the handling of the priority queue in the client - but I can enjoy the music).

Well, there should not be any network issues since this is coming from localhost.

How exactly are you feeding your signal into the inputpipe from the server?

The host is running mopidy which feeds the audio into the inputpipe to snapcastc-server. snapcastc-server is serving four clients: Three remote clients over network (WiFi, but that should not matter) and one local client which uses a bluealsa output device. All remote clients sound perfectly fine, just the local client has these strange pitch/stuttering problems.

Hypothetically, feeding audio at 24000Hz while snapcastc is expecting 48kHz would yield a similar result: The audio would be high-pitched and there was not enough signal to go around so there would be intermittent breaks.

This should not be a problem (since playback works for all remote clients). The mopidy stream output configuration is also pretty straightforward: audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo

If I had to guess, I would assume that the client somehow is playing back the stream too fast, thus starving. Can there be any issues with the output sampling rate configuration? Maybe at the ALSA end?

[christf]

Thank you for sharing all of this. I agree - the input is fine if playback on 3 clients is fine but on one it isn't. We have established that snapcastc is handed the audio in correct format. In 3/4 cases it is handling it correctly. Now we need to find what is different in this one case. Sure. The device is a bluetooth device but that should not be a problem.

From the client log, the frame format is correctly identifyed as 48000:2:2. So this is what is requested from alsa - I just verifyed that in alsaplayer.c (alsaplayer_init()). It could be that the device does not have resampling capabilities but somehow alsa expects it to.

How exactly do you have your bluetooth alsa device set up? It might be related to https://github.com/Arkq/bluez-alsa/issues/32#issuecomment-279977770 There is also this https://github.com/Arkq/bluez-alsa/issues/32#issuecomment-298749551

Can you play back a 48kHz file directly to your bluetooth alsa device?

[christf]

Closing for lack of response. Please reopen if the issue persists.