Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

click during pause #433

Open
Wang-Yue opened this Issue Dec 5, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@Wang-Yue
Copy link
Contributor

Wang-Yue commented Dec 5, 2018

Hi I'm running MPD 0.21.3 on Linux using alsa plugin. I have a question, Why there is a click every time it tries to pause or stop?

As one of the mpd OS X plugin developers I don't find the issue on Mac. Nor does it present on cmus under Linux using their ALSA output plugin. So I guess it's a MPD + ALSA only issue.

Probably it was trying to consume the remaining stale buffer before actually pausing?

@MaxKellermann

This comment has been minimized.

Copy link
Member

MaxKellermann commented Dec 5, 2018

I don't know, this problem doesn't occur here.
When you pause or stop playback, MPD calls snd_pcm_drop():

This function stops the PCM immediately. The pending samples on the buffer are ignored.

cmus also uses snd_pcm_drop(), but only if the PCM cannot be paused; if the PCM can be paused, then it waits using snd_pcm_wait(), and then calls snd_pcm_pause(): https://github.com/cmus/cmus/blob/master/op/alsa.c#L297-L317

It would be interesting to see what happens when you hack cmus to always set alsa_can_pause=false to force it to use snd_pcm_drop(). If this also renders the "click", then this is a bug in your ALSA driver or in your sound chip.

@MaxKellermann

This comment has been minimized.

Copy link
Member

MaxKellermann commented Dec 5, 2018

One more idea: if you pause an ALSA output, MPD will close it, to avoid blocking it. While MPD is paused, other programs can use the ALSA device.
Your sound chip may "click" when it is being closed. This, too, would be an issue with your sound chip, not with MPD.
What we could do is have an option to use snd_pcm_pause() (if supported by the ALSA driver), and keep the ALSA device open while paused. I never cared enough to implement it, because I believe MPD shouldn't block the device when not actually playing something, but it might be a workaround for your problem.

@Wang-Yue

This comment has been minimized.

Copy link
Contributor Author

Wang-Yue commented Dec 5, 2018

I changed alsa_can_pause to false and I do saw the same problem in cmus. Thank you for your detailed explanation.

I do hope snd_pcm_pause() get implemented. I think a lot of people would prefer a music player hog the device (in Mac OS X term) or use exclusive mode (in Windows term) while started. Otherwise if a program use the soundcard during mpd's pause and they forgot to release it and steal the resource, it would be an even more frustrated issue.

@MaxKellermann

This comment has been minimized.

Copy link
Member

MaxKellermann commented Dec 5, 2018

My idea was that MPD should release its lock on the device whenever possible; and I expect all other programs to do the same. I use that all the time (and I want to avoid the horrors of dmix); all day, MPD plays music, but when I want to watch a video, I pause MPD and then mpv plays the video; after mpv is finished, I can resume MPD playback.
Of course, misbehaving software is frustrating, and I at least wanted MPD to be a good one.

I have one more idea which may work around your problem: some sound chips have a problem with partial periods, i.e. if you leave an unfinished period in the buffer at the end of playback. For example, the Raspberry Pi 1 DAC had this problem, and it would play whatever random data was still in the unfinished portion of the period.
Back then, I wrote a hack which fills the unfinished period with silence before calling snd_pcm_drain(). That made the RPi bug disappear.
Next idea (I had this idea a few months ago already): never really write partial periods to ALSA; wait until data for at least one full period is accumulated, and then write it all in one single call. That gives more control to MPD, may avoid other DAC bugs and doesn't even increase latency (no buffer bloat) because partial periods cannot be played anyway. And: it simplifies thread synchronization inside MPD (between output thread and rtio thread).

@Wang-Yue

This comment has been minimized.

Copy link
Contributor Author

Wang-Yue commented Dec 5, 2018

Great. Looking forward to see the idea get implemented. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.