Commits on May 4, 2012
  1. Ensure playback is stopped before dropping ALSA buffers

    Previously if playback was paused it could call snd_pcm_drop() while the
    playback thread was still running, causing the following error:
    alsa: snd_pcm_writei error=-77, File descriptor in bad state
    Martin Panter committed Apr 17, 2012
  2. Check for stopping playback in inner ALSA thread loop

    It was possible for pause be ignored if the thread was in an indefinite loop,
    for example if palsa_callback() stopped returning data, or buffer underruns
    continually happen without the buffer ever filling up.
    Martin Panter committed Apr 17, 2012
  3. Merge from upstream

    Martin Panter committed May 4, 2012
Commits on May 3, 2012
  1. Check for reading past end before calling mp4ff_read_sample()

    Previously errors like the following would occasionally be reported at the end
    of an AAC file:
    mp4ff_read_sample: malloc failure (tried to alloc -2147483648 bytes). possible mp4ff bug or memleak! please report a bug to deadbeef developers (i'm serious).
    This was because the value of “sample” passed to mp4ff_audio_frame_size()
    caused that function to read just off the end of an array.
    Bug reported at
    Fix inspired by “Crash (SIGSEGV) in
    memcpy using libfaad2”
    Martin Panter committed with Alexey-Yakovenko Apr 23, 2012
  2. Clarify issue with “intltool” dependency

    Martin Panter committed with Alexey-Yakovenko Apr 28, 2012
  3. [by Martin Panter <vadmium à gmail·com>]

    Retry with the same data after recovering from an underrun or other error
    The palsa_callback() function seems to limit the rate it returns data, and if
    a buffer of data is dropped because snd_pcm_writei() failed, the data rate is
    not fast enough to keep up with ALSA and another buffer underrun occurs. This
    could cause an indefinite cycle, and the audio would sound slighly choppy and
    sped up. If the original data is retried, the ALSA buffer eventually tends to
    become full; perhaps the rate limit is a little faster than real time.
    When playback continues on to an MP3 file cued in the playlist, the MP3 seems
    to be scanned before it starts playing. If the scanning takes too long, in my
    case because the MP3 file is mounted with SSHFS over wifi, it causes a buffer
    The code below could also be inserted, just before the snd_pcm_writei() call,
    to artificially cause an underrun a few seconds into playback:
    static int n = 0;
    if (n >= 200 && n < 300) {
        trace ("dropping %i\n", n);
        err = 0;
        err = snd_pcm_writei (...);
    Alexey-Yakovenko committed May 3, 2012
  4. Don’t divide sample rate by number of channels

    With stereo (two channel) output, the sleep was only allowing just over half
    a "period" of frames to drain. Reduced processor usage a little bit, from
    4.5 percent to 2.6 percent.
    Martin Panter committed with Alexey-Yakovenko Apr 17, 2012
Commits on May 2, 2012
  1. ao static build fix

    Alexey-Yakovenko committed May 2, 2012
  2. Show ALSA errors, including underruns (“broken pipe”)

    Martin Panter committed Apr 18, 2012
Commits on Apr 30, 2012
Commits on Apr 29, 2012
Commits on Apr 28, 2012
  1. changelog typo fix

    Alexey-Yakovenko committed Apr 28, 2012
  2. changelog for 0.5.3

    Alexey-Yakovenko committed Apr 28, 2012
Commits on Apr 26, 2012
Commits on Apr 25, 2012
  1. fixed plt_search_process bug which was creating single-linked list in…

    …stead of double-linked;
    fixed plt_load bug which was leading to crash if playlist file fails to load early, e.g. if a file has size of 0
    Alexey-Yakovenko committed Apr 25, 2012