[PROBLEM] PEQ + certain tracks = crash

[Sehnsucht]

I have a few tracks which, if I play them (to the end, without issue, every time) in a queue then the next track doesn't play and the log is full of:

Jul 09 20:25 : alsa_output: Decoder is too slow; playing silence to avoid xrun

At this point, the system gets really laggy with mpd using around 96% cpu and I have to reboot it.

This is on a pi zero w on v8.3.9.  It doesn't happen with no PEQ but I can reproduce it 100% with PEQ set to:
master gain: -4.2
band 1: 3400hz, q 1, gain -1.4
band 3: 5200hz, q 2, gain 3.9.

Yes, it's fine if I use band 1 & 2!!!  Took a while to narrow that down especially the bands (I use all 12).  There doesn't seem to be anything weird about the tracks which provoke it - they're not corrupt; the format looks ok; they play on multiple players and I can convert them from flac to wav without error.  I have a short one I can provide if required.

[Sehnsucht]

It seems that although a certain file and certain peq config can demonstrate a lot of the problem/logging, just playing any tracks will often have a line or 2 of the logs in between them, and a short extra delay.   I cannot get this to happen on my pi 4.  No amount of fiddling with the buffer or overclocking the pi has any effect on the problem.

Absolutely no problems with the PEQ disabled or using EQ.

If anyone wants to test this on their pi zero w, just put together an hour or two's worth of tracks, enable PEQ and set up a few filters, and just leave it playing. Check /var/log/mpd/log for errors between tracks.

[the_bertrum]

Could be that the zero just isn't powerful enough to do PEQ. Try monitoring with htop while it is playing, I'd wager something (cpu or memory or both) are getting maxxed.

[Nutul]

Could be that the zero just isn't powerful enough to do PEQ.  Try monitoring with htop while it is playing, I'd wager something (cpu or memory or both) are getting maxxed.

Memory is my first take...
The fact that it happens "on certain tracks", maybe those tracks are long (e.g. big in size) and go OOM... still a wide guess, this of mine, but seems reasonable.

[the_bertrum]

Could be that the zero just isn't powerful enough to do PEQ.  Try monitoring with htop while it is playing, I'd wager something (cpu or memory or both) are getting maxxed.

Memory is my first take...
The fact that it happens "on certain tracks", maybe those tracks are long (e.g. big in size) and go OOM... still a wide guess, this of mine, but seems reasonable.

If it is memory, could be that the track playing is incidental, if track + PEQ + some other regular operation (mount monitor, log cleaning, whatever) = more than memory.

[Nutul]

If it is memory, could be that the track playing is incidental

Taking the PEQ out of the equation could tell it straight away... if it plays, then PEQ is eating too much memory; if it still crashes, well... it's still the drop that overflows the vase (of memory...).

Or... put one - or, better, two or three - of the tracks somewhere on the InterWeb (cit.) and send their download links to me (@Nutul), @Tim Curtis and @TheOldPresbyope, and one of us will have a deeper look into it.

[the_bertrum]

Taking the PEQ out of the equation could tell it straight away...

Absolutely no problems with the PEQ disabled or using EQ.

That's what made me suspect memory in the first place.

[TheOldPresbyope]

@Sehnsucht 

Like @Nutul  and @the_bertrum I suspect memory when users say their player becomes sluggish.

I don't know the inner workings of the PEQ code but I'm willing to play along at home. 

I have moOde 8.3.9 installed on a Pi Zero W with Creative Technology BT-W2 USB adapter as output device. 

I have created a 2-band PEQ filter with the parameters you stated. 

I arbitrarily loaded my queue with 256 hours of music (ok, so that's more than an hour or two).

Several hours in, I've not seen memory usage exceed 50 percent as stated by moodeutl -m. (The percentage reported by moodeutl has to be taken with a grain of salt but clearly I'm not out of memory.)

If you have a specific track or two you know triggers your problem then do what Al suggested and shoot it/them to us.

Regards,
Kent

[Sehnsucht]

@Sehnsucht 

Like @Nutul  and @the_bertrum I suspect memory when users say their player becomes sluggish.

I don't know the inner workings of the PEQ code but I'm willing to play along at home. 

I have moOde 8.3.9 installed on a Pi Zero W with Creative Technology BT-W2 USB adapter as output device. 

I have created a 2-band PEQ filter with the parameters you stated. 

I arbitrarily loaded my queue with 256 hours of music (ok, so that's more than an hour or two).

Several hours in, I've not seen memory usage exceed 50 percent as stated by moodeutl -m. (The percentage reported by moodeutl has to be taken with a grain of salt but clearly I'm not out of memory.)

If you have a specific track or two you know triggers your problem then do what Al suggested and shoot it/them to us.

Regards,
Kent

Thanks.
I'm just preparing the files now and will send you them shortly.   A few things:

htop shows 100% cpu at the point each track ends before returning to bouncing around between about 18% and 45%.  When the problem is happening badly (ie multiple lines and the pi locking up) htop shows 100% cpu but still only 240mb ram used.  Sometimes you just get a line or two of error.  When I said "crash" it just seems that way - it can be locked up for minutes so it's quicker to pull the plug but perhaps if left long enough it might always recover.  You can kill mpd (with a -9 signal) and then play another track and everything seems fine again.

There's 145meg used out of 430meg as the track plays.  I'll share two files: 3.2mb and 45mb so this isn't a memory problem.

You can click to near the end of the track to save time (one is longish) and it still goes wrong.

Edit: sent. btw I tried also sending to @the_bertrum but "PMs are disabled for this user"...

[Nutul]

Edit: sent.  btw I tried also sending to @the_bertrum but "PMs are disabled for this user"...

When asked to send files, please, stick with the member(s) list you are being provided with, as those agreed upon receiving files for analysis.