Also changes relative seeking behavior:
- seeking behind the the current track only switches to the previous
track, if we are not more than 3 seconds into the current track,
otherwise starts current track from the beginning
- seeking beyond the current track will start the next track from the
beginning
pb_suspend() + pb_resume() during track changes made the playback status
incorrect, i.e. pb_session.source_list/playing_now would not match what the
input was actually writing. This attempts to solve it by resetting the
session when pb_suspend() is called, so that the input, input_buffer and
source_list come into sync.
The fix in commit 3928ab6 broke resuming from an underrun, since it meant that
pb_resume() would flush the input buffer. With this fix it is possible to call
input_resume(), which will not flush the buffer if the source is already open.
Also renamed some functions in player.c for consistency.
Replace reading_next and reading_prev with a list of sources, so that we can
deal with short tracks, i.e. tracks where reading ends before playback starts.
With short tracks reading ends before playback starts, so event_read_eof comes
before event_play_start, which causes playing_now to point to a null
reading_now.
With this change it will point to a non-null reading_prev, but note that in the
hopefully rare case of multiple short tracks, the playing_now pointer will
still be incorrect.
In the output implementations playback_stop() was somewhat redundant,
since device_stop() does the same.
The timer should make sure that we always close outputs (previously
they were in some cases kept open).
The commit also includes some renaming.
+ remember to flush in source_start(), since the input won't do it if
input_now_reading has already been closed (e.g. if starting a new track
while playback is at the end of another track)
* Also call full_cb() from input_wait if buffer is full
* Make read_deficit count missing bytes instead of clock ticks
* Make read_deficit a part of the playback session
The time stamp was getting set too late, because if pos was zero the first
reads then it would be overwritten, but it shouldn't because the loop will
catch up even if the initial reads have zero samples.
outputs_playback_start() had the problem that was not consistently invoked: If
for instance local audio playback was running and a Airplay device was then
activated, the raop's playback_start would never be invoked (and vice versa,
of course).
Instead, the player now writes the presentation timestamp every time to the
output, so it doesn't need to keep track of it from the start.
* Untie Airtunes stuff further from player and non-Airplay outputs
* Change raop.c to use rtp_common.c (step 1)
* Change heartbeat of player to 100 ticks/sec, since we have untied from
Airtunes 352 samples per packet (which equals 126 ticks/sec at 44100)
Still a lot to be done in the player, since the rtptime's in it don't
are probably broken.
