inline player_enqueue

s/audio_init/player_init was the only function to disrespect the player_* namespace (well, excepting play). while here also don't mark those two as static, they were the only static functions in the file. I'm not trying to enforcing private symbols here.

no need to sio_setpar during initialization we don't know what format the music will be so we have to stop and set the parameters in player_setup. there's no point in setting bogus parameter in audio_init.

drop a local variable don't need to keep `files' around, res->files is enough. it would have prevented the previous bug (probably.)

fix `amused add' failure introduced in previous commit don't advance the files pointer, we need the original pointer when receiving the replies.

refactor: group imsg handling the approach with one-function-per-imsg leads to too much code splatted across the file.

try to recover from mp3 decoding errors

bump version number

CHANGES for 0.7

tweak -d description

typo

consume all enqueued messages before calling imsg_read player_dispatch reads only one imsg from the ibuf. Next time it's called, the other messages on the ibuf (if any) are discarded and new ones are read. This can cause the player process to go out-of-sync with the main process if multiple messages were "bundled" in the same chunk. To avoid this, always try to imsg_read before. If it succeedes, we read process the equeued messages one by one, if it fails then we poll for new data and call imsg_read to process them and retry. This fixes a bug where amused could be "confused" by running $ amused pause ; amused stop ; amused play in a loop a few times. This bug and the repro were reported two months ago by Dirk-Wilhelm Peters, thanks! (and sorry it took so long to understand and fix the issue)

don't set the imsg fd as blocking mode just do a poll before imsg_read in player_disptach to wait for data to read. It's not performance-critical code, so this is fine. If it were important not to do an extra poll(2), for example when we're called is called after player_pendingimsg we already know there's something to read, we could move the polling in the case `n == 0' below.

amused monitor: allow to pass a list of event as filter it's easier / simpler for scripts to do $ amused monitor next,prev,jump rather than $ amused monitor | egrep --line-buffered 'next|prev|jump'

use normal width for listing