We want to remove gcc.h eventually. This takes care of all the
G_LIKELY/G_UNLIKELY macros.

Allow pcm_volume() to increase volume.

It may be desirable to change the range of integer volume levels
(e.g. to 1024, which may utilize shifts instead of expensive integer
divisions).  Introduce the constant PCM_VOLUME_1 which describes the
integer value for "100% volume".  This is currently 1000.

24 bit output is as important as 16 bit output.  Provide a
pcm_convert() implementation which can convert to 24 bit with as
little quality loss as possible.

The old pcm_convert_size() ignored most of the destination format,
e.g. it did not check its sample size, and assumed it is 16 bit.
Simplify and universalize it by using audio_format_frame_size().

pcm_convert() converted only to 16 bit.  To be able to support other
sample sizes, move that 16 bit specific code to a separate function.

Separate code from pcm_utils.c to keep it small and simple.

Separate the resampling code from the rest of pcm_utils.c.  Create two
sub-libraries: pcm_resample_libsamplerate.c and
pcm_resample_fallback.c.

Copied and adapted code from the mp3 decoder plugin.  This library now
replaces the old and low-quality function pcm_convert_24_to_16().

Splitting a frame between two buffer chunks causes distortion in the
output.  MPD used to assume that the chunk size 1020 would never cause
splitted frames, but that isn't the case for 24 bit stereo (127.5
frames), and even less for files with even more channels.

Instead of manually calling memset(0) on the pcm_convert_state struct,
client code should use a library function from pcm_utils.c.  This way,
we can change the semantics of the struct easily.

Renamed all functions which were still in CamelCase.

No CamelCase, and a struct instead of a typedef.

When calculating the conversion buffer size, don't hard-code the
formulas for only mono<->stereo.

Convert any number of channels to stereo.  In fact, this isn't really
stereo, it's rater mono blown up to stereo.  This patch should only
make it possible to play 5.1 files at all; "real" conversion to stereo
should be implemented, but for now, this is better than nothing.

In order to be able to deal with non-trivial conversions,
pcm_convertChannels() needs to know both the input and the output
channel count.  Simplify buffer allocation in that function.

Moved code from pcm_convertChannels() to pcm_convert_channels_1_to_2()
and pcm_convert_channels_2_to_1().  Improved the quality of
pcm_convert_channels_2_to_1() by calculating the arithmetic mean value
of both samples.

Pass int16_t pointers instead of char pointers to functions which can
deal with 16 bit audio only.

The last bit of CamelCase in audio_format.h.  Additionally, rename a
bunch of local variables.

"bits" and "channels" cannot be negative.

In the libsamplerate fallback code, a "const" attribute was missing.

"volume" was passed as an unsigned integer, which is correct.  It's
just that when it was multiplied with the sample value, the whole
operation was changed to unsigned, breaking the algorithm (and Qball's
ears).  Internally change "volume" to signed.

When there are standardized headers, use these instead of the bloated
os_compat.h.

Add support for 24 bit PCM samples to all functions.  Note that
pcm_convertAudioFormat() converts 24 bit samples to 16 bit; to
preserve full quality, support for "real" 24 bit conversion should be
added.

Moved code into separate bit specific functions:
- pcm_volumeChange() -> pcm_volume_change_X()
- pcm_add() -> pcm_add_X()
- pcm_convertTo16bit() -> pcm_convert_8_to_16()

pcm_mix() might overflow the destination buffer if it is smaller than
the second buffer.  This is ok because the physical buffer size passed
by cross_fade_apply() is always big enough, but clutters pcm_mix()
with complicated length checks and contains a dangerous buffer
overflow pitfall.  Simplify pcm_mix()/pcm_add() and pass only the
smaller buffer size; let cross_fade_apply() do the memcpy().

Since we use a C99 compiler now, we can assert that the C99 standard
headers are available, no need for complicated compile time checks.
Kill mpd_types.h.

Seeing the "mpd_" prefix _everywhere_ is mind-numbing as the
mind needs to retrain itself to skip over the first 4 tokens of
a type to get to its meaning.  So avoid having extra characters
on my terminal to make it easier to follow code at 2:30 am in
the morning.

Please report any new issues you may come across on Free
toolchains.  I realize how difficult it can be to build/maintain
cross-compiling toolchains and I have no intention of forcing
people to upgrade their toolchains to build mpd.

Tested with gcc 2.95.4 and and gcc 4.3.1 on x86-32.

Make the code more readable by moving the range checks to pcm_range().
gcc does quite a good job at optimizing it: the resulting binary is
exactly the same, although it contains a parametrized shift instead of
hard-coded boundaries.

Merge some code into an inline function, so we can optimize it later
only once.

Get rid of CamelCase, and don't use a typedef, so we can
forward-declare it, and unclutter the include dependencies.

The previous patch enabled these warnings.  In Eric's branch, they
were worked around with a generic deconst_ptr() function.  There are
several places where we can add "const" to pointers, and in others,
libraries want non-const strings.  In the latter, convert string
literals to "static char[]" variables - this takes the same space, and
seems safer than deconsting a string literal.

Also enable -Wunused-parameter - this forces us to add the gcc
"unused" attribute to a lot of parameters (mostly library callback
functions), but it's worth it during code refactorizations.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7360 09075e82-0dd4-0310-85a5-a0d7c8717e4f

They're probably not needed, but less noise => faster debugging

git-svn-id: https://svn.musicpd.org/mpd/trunk@7302 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@7298 09075e82-0dd4-0310-85a5-a0d7c8717e4f

There were some const pointers missing in the previous const-cleanup
patch.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7290 09075e82-0dd4-0310-85a5-a0d7c8717e4f

It is a good practice to constify pointers when their dereferenced
data is not modified within the functions or its descendants.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7234 09075e82-0dd4-0310-85a5-a0d7c8717e4f

When dealing with in-memory lengths, the standard type "size_t" should
be used.  Missing one can be quite dangerous, because an attacker
could provoke an integer under-/overflow, which may provide an attack
vector.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7205 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This will make refactoring features easier, especially now that
pthreads support and larger refactorings are on the horizon.

Hopefully, this will make porting to other platforms (even
non-UNIX-like ones for masochists) easier, too.

os_compat.h will house all the #includes for system headers
considered to be the "core" of MPD.  Headers for optional
features will be left to individual source files.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7130 09075e82-0dd4-0310-85a5-a0d7c8717e4f