| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
On WIN32, "%F" and "%T" are not implemented.
|
|
|
|
|
| |
In the winsock headers, the setsockopt() argument is declared as
"const char *", not "const void *".
|
| |
|
|
|
|
| |
This function is empty on WIN32, but we need to return a value.
|
| |
|
|
|
|
|
| |
input_stream_buffer() has a check for "buffer==NULL", so we don't need
an explicit empty implementation.
|
|
|
|
|
| |
Pay attention to the ReplayGain mode "auto" and the
replay_gain_missing_preamp parameter inside of decoder_replay_gain().
|
| |
|
|
|
|
| |
Added #ifdefs on the macros AFMT_S24_NE and other OSS4 extensions.
|
|
|
|
|
| |
Removed the "supported" / "unsupported" arrays, and auto-detect on
every open() call, just like the ALSA output plugin.
|
|
|
|
| |
Removed the macro AFMT_S16_MPD.
|
|
|
|
|
|
| |
In mingw32, int16_t is not defined by sys/types.h, but it is by stdint.h,
and it is in the int16_t man page as being defined in stdint.h. Thanks to
mithi for help debugging.
|
|
|
|
| |
This is portable for win32 and fixes client logins there.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Don't add it to the filter chain, because we need to apply replay gain
before cross-fading with the next song. Add a second replay_gain
filter which is used for the song being faded in (chunk->other).
|
|
|
|
|
| |
Remove cross_fade_apply(), and call pcm_mix() in the output thread,
mixing the chunk and chunk->other together.
|
|
|
|
| |
Preparation for cross-fading support in the output thread.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Supports a number of videogame music formats, more info here:
http://www.fly.net/~ant/libs/audio.html
I wrote this plugin for the latest svn, get it here:
http://code.google.com/p/game-music-emu/source/checkout
|
| |
| |
| |
| |
| |
| |
| | |
This is useful at the maximum depth level, to update newly created
directories. It is however questionable if the hard-coded 5 seconds
delay is enough to create new directory trees with all of their files,
but we might make that delay configurable in the future.
|
| |
| |
| |
| |
| | |
Limits the depth of the watched directories. This is useful to keep
resource usage down and speed up MPD startup.
|
| | |
|
|/
|
|
|
|
|
|
|
| |
What's happening is the `ptr' argument to that function is NULL for me
every time. `ptr' is unconditionally dereferenced to generate a log
message, and this is where mpd crashes.
Attached is a simple patch that tests for NULL and omits the log. With
this patch the crash disappeared and mpd went back to working well.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.. rather then append to the end of the previous one
Cuebreakpoints from the cuetools package has three modes of operation,
and the default is to append pregap (INDEX 00) to the end of the
previous track. This is the behavior most compliant to the existing
cue files.
Here is the patch which fixes the issue. I borrowed bits of
implementation from cuebreakpoints. I assumed that the whole audio
file must be covered by head-to-head going tracks, which is how
hardware CD players probably work. In cue_tag I changed rounding from
rounding up to rounding down because the thing in mpd which calculates
actual track duration (and current position) rounds it down, and I
didn't want to see in my playlist values different from whose in a
now-playing progress bar.
I've compared the resultant mpd behaviour with "mplayer -ss MM:SS.MS"
where the time was supplied by cuebreakpoints and noticed that mplayer
started each track a bit earlier then mpd, though this was the same
before the patch.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
NEWS
configure.ac
src/cue/cue_tag.c
src/decoder/mpcdec_decoder_plugin.c
src/player_thread.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"When playing musepack files with mpd v0.15.8, rg seems to have no effect.
Using sample file below, mpd says 'computing ReplayGain album scale with gain 122.879997, peak 0.549150'.
One thing though, if I build mpd against old libmpcdec-1.2.6, rg works
as expected: 'computing ReplayGain album scale with gain 16.820000,
peak 0.099765'"
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, tags of the new song being cross-faded in were sent
immediately. That can cause wrong information being displayed,
because the "previous" song might send its tag at the end again,
overriding the "next" song's tag. This patch saves & merges the tag
of the next song, and sends it when cross-fading is finished, and the
next song really starts.
|
| |
| |
| |
| |
| | |
Like tag_merge(), but can deal with NULL parameters, and frees both
tag objects.
|
| |
| |
| |
| |
| |
| | |
"There is a bug in fixed-point musepack (musepack_src_r435) playback.
In floating-point audio is OK but in fixed audio is distorted. I have
made a patch for this"
|
| |
| |
| |
| |
| |
| |
| | |
With single+repeat enabled, it is expected that MPD repeats the
current song over andd over. With random mode also enabled, this
didn't work, because the song order was shuffled internally. This
patch adds a special check for this case.
|
| |
| |
| |
| |
| |
| | |
Removed the decoder_command_finished() call at the end of
mp3_decode(). This is invalid, because decoder_command_finished() has
already been called in mp3_read().
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Adds mixrampdb and mixrampdelay commands. Reads MIXRAP_START and
MIXRAMP_END tags from FLAC files and overlaps instead of crossfading.
|
| |
| |
| |
| | |
For int16_t.
|
| |
| |
| |
| |
| |
| | |
When decoder->timestamp is calculated, the PCM data is already
converted to out_audio_format; using in_audio_format may cause funny
speedups/slowdowns.
|
| |
| |
| |
| |
| |
| |
| | |
When handle_update() was modified to use uri_safe_local(), suddently
"mpc update ''" and "mpc update '/'" stopped working, because both are
not a "safe" local URI. This patch adds a special case for these, to
retain backwards compatibility.
|
| |
| |
| |
| |
| |
| |
| | |
Did you ever accidently click "stop" while feeding a radio station?
This option sets the output device to "pause" to disable the "close"
method. It falls back to "pause" then, which is specific to the
plugin. Some plugins implement it by feeding silence.
|
| |
| |
| |
| |
| | |
If we're not doing this, and a new song is played after pause ends,
then you will hear the rest of the previous song.
|
| |
| |
| |
| |
| | |
Always use the same number of samples from each channel's ring
buffer. This ensures that all channels are kept in sync.
|