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.
is not the current playing item.
This happens if the input already switched to the next item in the queue
starting to stream it to the outputs (2 second buffer) while the outputs
are still playing the last seconds of the old item.
The current logic in httpd_dacp.c cannot handle non persistent items
correctly. The items are always shown with the dummy_mfi with "unkown
artist" etc.
Ommits useless update query for playcount for items that are not in the
library. Also avoids trying to scrobble these items (fixes error log
message "lastfm: Scrobble failed, track id 9999999 is unknown")
Changing a speaker volume in a DACP clients results in two dacp requests
(at least in Retune):
setproperty?include-speaker-id=0&dmcp.volume=41
setproperty?speaker-id=198018693182577&dmcp.volume=43
The first request sets the absolute volume for the speaker (player.c -
volume_setabs_speaker). The second request is only triggered if the
volume from the first one is not the new master volume. This second
requests adjusts the relativ volume based on the loudest device (new
master volume) (player.c - volume_setrel_speaker). After the second
request the master volume and the relative volumes are correct (range
from 0 - 100 percent and master volume is 100 percent).
MPD and JSON API clients only set the absolute volume which results in
inconsistent master_volume and relative volumes. The added option to
update the master volume in volume_setabs_speaker/volume_setrel_speaker
makes sure the master volume and the relative volumes are correctly set.
Implements Active-Remote, which is sent to the speaker, so it can use this
to tell us who it is when it makes dacp request with a device-volume update.
