You are not logged in.
Hey,
I've recently noticed abnormal cpu usage in mpd and found the bug.
https://github.com/MusicPlayerDaemon/MPD/issues/391
Is there any I can currently get past this without disabling dmix ?
EDIT: a new mpd release which fixes this was released
Last edited by buttcake (2018-11-17 20:48:31)
Offline
What kind of audio files/format are you listening to? Don't listen to stuff that engages a considerable resampling effort, unless configured otherwise dmix defaults to 48KHz 16bit samples and it cannot automatically readjust. If you play audio that isn't in that format it will get resampled to that format. If you want something that can change this around on the fly you might consider pulseaudio, as it contains necessary code to automatically readjust sample rates where possible.
FWIW if this really is a bug in dmix, you might want to report that upstream.
Last edited by V1del (2018-11-05 09:58:15)
Offline
I can't even find the alsa bug tracker to be honest.
EDIT: I'm playing plain old 320cbr/v0/v2 mp3, aac, rarely flac.
EDIT2: I've had bad experiences with pulseaudio in the past, I'd rather follow this bug through than switch.
Last edited by buttcake (2018-11-05 11:18:17)
Offline
The container format doesn't matter, what sample rates are we talking? If this is indeed bog standard 44KHz and/or 48KHz then this really looks like a bug, as for the bug tracker traditional wisdom was to post on the mailing list however it seems[0] that the ALSA project has recently switched to github and one can make an issue, don't know which subproject would be the best fit here: https://github.com/alsa-project
Offline
If this is indeed bog standard 44KHz and/or 48KHz then this really looks like a bug
Not sure what makes you say this, resampling between 44.1KHz and 48KHz is especially hard, since it's not a linear conversion. And it can happen easily:
User has a browser window open, which has a paused video with samplerate 48000 and mpd plays a 44100 song. Resampling will happen in this case.
In fact the *only* way to get around resampling is to output to the hardware directly (hw:0), but you will lose the ability to play multiple sounds at once. (at least with most soundcards, some can do mixing in hardware)
Anyway, back to the actual issue...
Options you can try: Use a different mp3 decoder by adding this to your mpd.conf:
decoder {
plugin "mad"
enabled "no"
}
decoder {
plugin "mpg123"
enabled "no"
}
This will then use ffmpeg to decode mp3, but judging from that bug report it might not help.
Alternatively you can force a samplerate in mpd by adding
format "44100:16:2"
(or whatever matches your native samplerate) to your alsa output plugin in mpd.conf.
Then you can use mpd's own resampler which has some options to force a cheaper algorithm:
https://www.musicpd.org/doc/html/plugin … er-plugins
This would bypass dmix own resampler and hopefully prevents those wakeups.
Last edited by Rasi (2018-11-07 01:21:25)
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
...
I can confirm none of that works.
Not even switching to soxr. The bug is still present. I don't have a github account. I'll make one after I get home.
Offline
Rasi you're right of course, and it wasn't my intention to make it sound like that was simply interchangeable, however I'd find it interesting to see if the issue only happens during a resample pass or also while it can be omitted. I'd suspect this being one of the regressions in the 1.1.7 alsa bundle release. FWIW before reporting a bug you might want to narrow down the problem scope, check if the issue still happens if you downgrade to 1.1.6 of the relevant packages (alsa-{lib,plugins,utils}) if it doesn't you can report it as a regression
Offline
check if the issue still happens if you downgrade to 1.1.6 of the relevant packages (alsa-{lib,plugins,utils})
That was the first thing I did. The behaviour is still there.
Offline