| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Preparation for cross-fading support in the output thread.
|
| |
|
|
|
|
|
| |
Apply the replay gain in the output thread. This means a new setting
will be active instantly, without going through the whole music pipe.
And we might have different replay gain settings for each audio output
device.
|
| | |
|
| |
|
|
|
|
|
|
| |
This updates the copyright header to all be the same, which is
pretty much an update of where to mail request for a copy of the GPL
and the years of the MPD project. This also puts all committers under
'The Music Player Project' umbrella. These entries should go
individually in the AUTHORS file, for consistancy.
|
| |
|
|
|
|
|
|
| |
A larger chunk size means less overhead for managing them. 4 kB seems
to be a reasonable choice: it contains 23 ms of 44.1 kHz 16 bit stereo
data, or 3 ms of 192 kHz 24 bit stereo data. The original value of
1020 seemed to be too small, there were quite a lot of system calls
and context switches.
|
| |
|
|
|
|
|
| |
In !NDEBUG, remember which audio_format is stored in every chunk and
every pipe. Check the audio_format of every new data block appended
to the music_chunk, and the format of every new chunk appended to the
music_pipe.
|
| | |
|
| |
|
|
|
|
|
|
| |
Turn the music_pipe into a simple music_chunk queue. The music_chunk
allocation code is moved to music_buffer, and is now managed with a
linked list instead of a ring buffer. Two separate music_pipe objects
are used by the decoder for the "current" and the "next" song, which
greatly simplifies the cross-fading code.
|
| |
|
|
|
| |
Moved some code from music_pipe_write() and music_pipe_expand(). Only
music_chunk.c should access the music_chunk internals.
|
| |
|
