Error writing from AlsaSink buffer to PCM

[ceewees]

Hello

Thanks you for putting so much effort and time in this project.
Am trying to learn, new to Linux, first time to post on GitHub, not looking for sandwhich...
I am running raspotify on dietpi 8.9.2 on an Odroid C4 (aarch664).
Sometimes I run into the following problem:

Oct 17 17:47:48 DietPi librespot[3982]: [2022-10-17T15:47:48Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'EPIPE: Broken pipe'
Oct 17 17:47:48 DietPi librespot[3982]: ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred

I am not able to reproduce it at will.
How to approach this problem ...?

aplay -Dhw:1 --dump-hw-params /usr/share/sounds/alsa/Front_Right.wav gives
Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
HW Params of device "hw:1":

ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S24_3LE
SUBFORMAT: STD
SAMPLE_BITS: 24
FRAME_BITS: 96
CHANNELS: 4
RATE: [44100 192000]
PERIOD_TIME: [125 990703)
PERIOD_SIZE: [6 43690]
PERIOD_BYTES: [72 524280]
PERIODS: [2 1024]
BUFFER_TIME: (62 1981429)
BUFFER_SIZE: [12 87381]
BUFFER_BYTES: [144 1048572]
TICK_TIME: ALL

aplay: set_params:1343: Sample format non available
Available formats:

• S24_3LE

Any help is appreciated, thank you.

[JasonLG1979]

One of 2 things or possibly both are going on. 1 your audio buffer is too small or 2 the CPU on that device doesn't have enough juice to run librespot consistently.

[JasonLG1979]

I like a 500ms buffer with 100ms periods. That seems to work well on most devices.

[ceewees]

Now Using
AlsaSink with format: S24_3 and
period 4410
buffer 22050
fingers crossed ...

[ceewees]

So far so good, did not had any drop outs 👍
I peeked in
https://www.alsa-project.org/wiki/FramesPeriods
but I don't get my head around it. Journalctl shows this:

== Starting sink ==
Oct 19 07:38:21 DietPi librespot[1814]: [2022-10-19T05:38:21Z TRACE librespot_playback::audio_backend::alsa]
Desired Frames per Buffer: 16384
The device's min reported Period size was greater than or equal to it's max reported Period size,
or the desired min Period size was greater than or equal to the desired max Period size.
Buffer size: 16384
Desired Period Frame range: 1638 (Buffer size / 10) - 4096 (Buffer size / 4)
Actual Period Frame range as reported by the device: 1024 - 1024
Failed to set Buffer and/or Period size, falling back to the device's defaults.
You may experience higher than normal CPU usage and/or audio issues.
Actual Frames per Buffer: 16384
Actual Frames per Period: 1024
Period Buffer size in bytes: 6144
Period Buffer capacity: 6144

so if my dac is only capable in 1024 - 1024, then the changes I made in sound.conf would not matter?

[JasonLG1979]

but I don't get my head around it.

ALSA buffers are basically segmented ring/circular buffers. The buffer size is the size of the entire buffer and a period is the size of the segments. When you feed the buffer it bites off period size chunks. An underrun is when the buffer doesn't have at least a period's worth of data in it when it should. Ideally you want to keep the buffer full.

You don't need to worry about byte size, you can't set the buffer to a specific byte size anyway. Just know that a "Frame" is basically the same as samples. Like I said previously, regardless of format or channel count anything with a given sample rate is the same number Frames. So U8 44100 Mono and S32_LE 44100 12 Channel are both 44100 Frames per Second. You can also use time in micro seconds to specify buffer and period sizes and period counts. So I could tell ALSA that I want a Buffer that's 5000000us with periods that are 1000000us or I could say I want a 5000000us buffer with 5 periods and it's the same as telling it in Frames. But ultimately it's all really just a strong suggestion. The Device has to actually support the settings.

[JasonLG1979]

I wrote a small utility that generates a asound.conf for you based on what the device actually supports and what you choose. It's pretty through in that it actually tests all the given configurations as much as it can.

If you have the Raspotify repo enabled you can install it with:

sudo apt update && sudo apt install -y asound-conf-wizard

And run it with:

sudo awiz

At the very least even if you just bailed before it actually writes asound.conf it should tell you what your device is capable of.

[ceewees]

made sure raspotify and dac were not in use, installed and ran your wizard, but wizard says:
There are no available Playback PCMs…
There are no available capture PCMs…
running aplay -l and aplay -L gives me plenty of results ...

[ceewees]

still don't get the indent thing ... J

[JasonLG1979]

still don't get the indent thing ... J

You're quoting a quote,lol!!!

double >'s quotes a quote.

like this.

So in your case it should have looked like this:

(single >)

I wasn't sure what you meant by mixing?

(no >)

I was not sure myself what you meant with mixing: I thought you meant mixing as like in a DAW.
In my case the Odroid/Dietpi machine only meant for Spotify playback, later I intend to run a convolution engine to load FIR filters and go active. There is a learning curve ahead...

(single >)

I'm pretty sure that basically the only way to play stereo on more then 2 channels is to de-interleave the stream, pad the other channels with zeros and then zip it back together? (I could be wrong though?)

(no >)

I couldn't say really....
As I said above, will need to start digging. Will report back if I see something which might contradict your assumption.

(single >)

So right now I'm going to say that's a no go.
I think using plug or plug + dmix is the way to go.

(no >)

Understood, will do.
Thanks very much for your patience and the spoon feeding lol!

[JasonLG1979]

Thanks very much for your patience and the spoon feeding lol!

Not a problem. We were all beginners at some point. (not that I'm an expert by any means,lol!!!)

Attitude means a lot. Wanting to learn and just wanting someone else to fix something for you are 2 completely different things. I'm more then happy to help someone learn (as generally I also learn something along the way) What I'm not happy to do is be someone's free tech support. If a person does not care to actually learn anything and just wants me to fix their shit for free I got no time for them.

You come from the 1st camp, people who actually want to learn.

[ceewees]

Gotcha on no/single > 😅
Yes, certainly want to learn. But as a casual hobbyist/end-user I am not afraid to admit often the steepness of the learning curve is overwhelming ... must be my age 😆

[JasonLG1979]

Yes, certainly want to learn. But as a casual hobbyist/end-user I am not afraid to admit often the steepness of the learning curve is overwhelming

It certainly can be. Knowledge from other OS's can actually be a detriment, or more precisely assuming that Linux should/will work like other OS's. People that are "experts" in other OS's are the hardest people to teach. So basically forget what you think you know.

must be my age

Hey, I'm no spring chicken myself,lol!!!