| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Adds support for ffmpeg 2.2 and 1.2. Right now the maintenance overhead
of supporting both libav implementations is not that big.
Fixes #437 and #435.
|
|
libav 9.12 and ffmpeg 2.2 have been tested.
Here’s why: My mp4 “parser” *cough* never was a mp4 parser in the sense
that it actually understood the file format. Instead it grepped the
input stream for “magic” strings (section identifiers). That alone
should be sufficient to throw away the code and rewrite it. Additionally
libfaad2 has not been updated for ages. I guess it was abandoned in
favor of libav/ffmpeg.
With libav/ffmpeg, which we support both as long as the API’s don’t
diverge too much, pianobar gains fast and reliable AAC and MP3 decoding
without bothering too much about the details. Most users will have it
installed already. On my own machine libav consumes about 2/3 CPU time
compared to the previous solution when playing AAC. Unfortunately memory
usage doubled and my attempts to disable unused protocols/formats/codec
failed due to libav’s API limitations.
While cleaning up a small detail regarding the eventcmd API has changed
too: Song duration and position are measured in seconds instead of
milliseconds now. Since libav/ffmpeg keeps track of accurate timing the
precision pianobar keeps track of can be reduced, while still being
sufficient for most users.
|
|
1) Make sure that multiple bad playlists in a row don’t result in a
temporary ban
2) Ignore songs skipped because the playlist timed out after pausing for
too long
|
|
Add commands that always play and always pause, in addition to the
current toggle pause command.
Closes #342.
|
|
This reverts commit 7df9371491e96a99c1e463f7787aede352ac5a37.
|
|
This reverts commit f6dffd1822404522b8354ac453a911a0d98bfc61.
|
|
1) Realtime signals don’t exist in OS X
2) libao apparently locks a mutex in ao_play, which is locked again in
ao_close and causes a deadlock
Closes #256, although I’m considering the option of partially reverting
7df9371491e96a99c1e463f7787aede352ac5a37, as this introduces more nasty
behavior than it solves.
|
|
No more mutex locking/checking for quit condition. Should (slightly)
increase responsiveness of the player thread. Closes #250.
|
|
Move player buffer to heap, a few const’s here and there, increase
header buffer size, fix comments.
|
|
Pointed out by -Wpadding. Does not decrease memory usage/binary size
though.
|
|
|
|
Closes #88
|
|
See issue #103.
|
|
Again. And hopefully the last time.
|
|
|
|
|
|
Pressing any key before the player thread set mode to PLAYER_INITIALIZED
lead to a song skip and spawning of another player thread. The two
player threads were operating on the same variables/memory area,
resulting in a crash.
Adding a new player state (PLAYER_STARTING) and setting it _before_
invoking pthread_start should resolve this, 'cause the "if
PLAYER_FREED-branch" is not taken any more, ergo no second player thread
is started.
|
|
Under certain circumstances (fast station switching e.g.) a new playlist
was not fetched, because the player thread returned 0x1 (== libao error)
and the main thread NULLed curStation.
|
|
|
|
|
|
Time is now counted in milliseconds, not aac frames. Calculations seem
to be inaccurate sometimes (about +-2 seconds).
|
|
Now libfaad and/or libmad are used for playback. There's currently no
remaining time displayed for mp3 playback.
|
|
|
|
Update copyright notices, add my email address, but don't change
libwardrobe (I'm not maintaining it anymore)
|
|
This fixes those my-favorite-song-suddenly-aborted-"bugs", as well as
the pause mode, which was more like a stop mode, because pandora
*always* aborted the transfer after a few minutes.
|
|
Some code restructuring was made, too:
- Move UI functions to ui.c and ui_act.c
- Change default keys for loving and banning to + and -
|
|
It's not necessary to re-compute the scale factor as it will be the same every
time.
|
|
Could be tuned...
|
|
Smarter solution than commit 8421cfd9886ec5ee19cde18b48853c2f9ea60c29.
|
|
|
|
Now unneeded header, linebreaks
|
|
This has two advantages:
1) We can pass the correct amount of bytes to NeAACDecDecode (). This should
fix some decoding error messages. And
2) We can show the length of the song and the remaining (or already played
time) to the user.
Cool, eh?
|
