| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
