Triode wrote:
> This is probably a reasonable observation as the number of frames played
> will get updated in _output_frames() so it should probably include the
> additional frames in the delay measurement. In practice this is likely
> to add the period size to the measurement, so depending on the period
> size setting it could justify adding 10ms or so to the results. However
> it depends on what else linux is doing as to whether this is a constant
> addition or it varies. (default buffer size of 40ms and period count of
> 4 would mean the period size is 10ms)
>
> Have you measured the effect this has?
It's actually very variable. See the attached log ("delay delta" is the
difference in frames between delay measured before and after
_output_frames() but, as you say, this is just equal to the number of
frames written). I'm running with a buffer size of 160ms which
presumably is amplifying the effect. (Ironically, I probably don't need
the larger buffer - it was an attempt to prevent some stuttering I had
early on when I had some network issues). Anyway, I guess it's the very
fact that it varies which was causing the problem: if it was off by a
constant it wouldn't matter (at least, not for me, since all my clients
are squeezelite).
+-------------------------------------------------------------------+
|Filename: squeezelite.log |
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=16114|
+-------------------------------------------------------------------+
------------------------------------------------------------------------
seberoon's Profile: http://forums.slimdevices.com/member.php?userid=63052
View this thread: http://forums.slimdevices.com/showthread.php?t=97046
_______________________________________________
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
