On Thu, 2017-02-16 at 13:10 +0100, Georg Chini wrote:
> On 16.02.2017 12:59, Tanu Kaskinen wrote:
> > On Fri, 2017-02-10 at 14:38 +0100, Georg Chini wrote:
> > > Hi,
> > >
> > > during my work on module-loopback I came upon an issue regarding the
> > > handling
> > > of the port latency offsets.
> > > The functions pa_{source,sink}_get_latency_within_thread() return the
> > > latencies
> > > including the offset. Those functions are used to determine the amount
> > > that has
> > > to be rewound during a sink move and also to calculate the time a volume
> > > change
> > > is delayed.
> > >
> > > I think it is wrong in those situations to include the offset,
> > > especially if a user sets
> > > very large or very negative offsets. If you have a large negative offset
> > > for example,
> > > the sink will never be rewound on a move because get_latency_in_thread()
> > > always
> > > returns 0. If the offset is large and positive, you might end up
> > > rewinding too much,
> > > although this is limited by max_rewind.
> > > A similar thought applies to the delay of the volume changes, although
> > > it is surely
> > > less critical there.
> > >
> > > Am I right or do I miss something?
> >
> > You're right. The total latency is not the same thing as the rewindable
> > amount. I think there's a FIXME comment about this somewhere in the
> > stream moving code.
>
> Could this not be fixed quite easily by subtracting the offset again
> in these places? Should I send a patch?
Even if we ignore the offsets, the total latency is still not the same
thing as the rewindable amount. Bluetooth devices aren't rewindable at
all (and I think we should make it possible to disable rewinding for
alsa devices too), and even with alsa devices we have a rewind safety
margin, which prevents rewinding the whole buffer, and even if we did
always rewind the whole buffer, the device can have other things
contributing to the latency than just the buffer where pulseaudio
writes.
--
Tanu
https://www.patreon.com/tanuk
