- 03 Aug, 2019 1 commit
-
-
Max Kellermann authored
-
- 02 Aug, 2019 18 commits
-
-
Max Kellermann authored
This also fixes a bug which caused the bit rate to not update after seeking.
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
Broken since commit f8bfea8b
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Diomendius authored
The JACK output plugin would not correctly upmix mono input files when exactly 2 output ports were configured. This fixes that.
-
Max Kellermann authored
The "end of stream" packet is not special; it contains normal data, and thus we should pass it to OnOggPacket(). This fixes one part of https://github.com/MusicPlayerDaemon/MPD/issues/601
-
Max Kellermann authored
-
- 29 Jul, 2019 4 commits
-
-
Max Kellermann authored
-
Max Kellermann authored
Closes https://github.com/MusicPlayerDaemon/MPD/issues/604
-
Max Kellermann authored
Closes https://github.com/MusicPlayerDaemon/MPD/issues/607
-
Max Kellermann authored
-
- 12 Jul, 2019 2 commits
-
-
Max Kellermann authored
This exception is usually thrown by class DecoderBridge, but the Opus plugin (ab)uses it as well, so we need to catch it.
-
Max Kellermann authored
-
- 03 Jul, 2019 1 commit
-
-
Max Kellermann authored
-
- 28 Jun, 2019 8 commits
-
-
Max Kellermann authored
MPD used to do that when this code lived in the player thread, but it was removed by commit 98a7c62d; and the replacement code in the ALSA output plugin didn't have it.
-
Max Kellermann authored
Without this timer, DispatchSockets() may disable the MultiSocketMonitor and if Play() doesn't get called soon, it never gets a chance to generate silence. However if Play() gets called, generating silence isn't necessary anymore... Resulting from this misdesign (added by commit ccafe3f3 in 0.21.3), the silence generator didn't work reliably.
-
Max Kellermann authored
In DispatchSockets(), when there was not enough data, but enough for current playback, the method would disable the "active" flag so the next Play() call would re-enable the MultiSocketMonitor. This was an abuse of the flag which could result in a crash in Cancel(), because that method asserts that the period_buffer is empty, which it may be not. The solution is to add anther flag called "waiting" which shares some behavior with the old flag.
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
Draining isn't finished just because the period_buffer has run empty. It is only finished after snd_pcm_drain() has succeeded.
-
Max Kellermann authored
Apparently, if snd_pcm_drain() returns EAGAIN, it does not actually want to be called again; the next call will snd_pcm_drain() will also return EAGAIN, forever, even though the PCM state has meanwhile switched to SND_PCM_STATE_SETUP. This causes a busy loop; to fix this, we should always check snd_pcm_state() to see if draining is really required.
-
- 26 Jun, 2019 6 commits
-
-
-
Max Kellermann authored
Fix build breakage from commit ea639269
-
Max Kellermann authored
-
Max Kellermann authored
Closes https://github.com/MusicPlayerDaemon/MPD/issues/589
-
Max Kellermann authored
This makes the configuration error more visible, possibly addressing one part of https://github.com/MusicPlayerDaemon/MPD/issues/589
-
Max Kellermann authored
-