Commit Briefs


Omar Polo

inline player_enqueue


Omar Polo

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.


Omar Polo

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.


Omar Polo

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)


Omar Polo

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.


Omar Polo

don't send the song' path to the player process

we're not relying anymore on the file extension, so this information is useless for the player.


Omar Polo

don't call player_sendeof on IMSG_STOP

the refactoring introduced this error where we call report an EOF upon IMSG_STOP, making the player infinitely loop.


Omar Polo

add a simple filetype detector instead of relying on file extension

just a bit of "magic" :) Flac are easy, they always start with "fLaC". mp3 are weird because they either start with "ID3" (but this theoretically only ensures that's a tagged file, not an mp3) or 0xFF 0xFB. Ogg Opus should have a magic sequence "OpusHead" somewhere near the start of the file but also have the ogg' "OggS" magic bytes. I hope it's enough to distinguish between Ogg Opus and Vorbis. Another option would be to refactor play_oggvorbis/opus to not close the file on failure and try in cascade the play_* functions, but it's more complex and this solution seems to be enough.



Omar Polo

refactor player_playnext: return status code

let the caller decide to call senderr or sendeof.



Omar Polo

pledge audio too

while for my particular use-case this has always worked with only "stdio recvfd", sio_open(3) mentions that if no further sio_open calls are made all pledges can be dropped except for "audio", so let's keep it.


Omar Polo

remove the got_stop hack

now player_playnext has enough information to decide wheter to call player_senderr or player_sendeof.