On Wed, Apr 27, 2022 at 10:48:42PM +0200, Caspar Schutijser wrote:
> Hi,
>
> On Thu, Mar 24, 2022 at 07:11:42AM +0100, Alexandre Ratchov wrote:
> > Most audio/video players do a stop/start cycle whenever the play
> > position is changed, track is changed, etc. Currently, stopping drains
> > the pl
Hi,
On Thu, Mar 24, 2022 at 07:11:42AM +0100, Alexandre Ratchov wrote:
> Most audio/video players do a stop/start cycle whenever the play
> position is changed, track is changed, etc. Currently, stopping drains
> the play buffer, which by default is very large (to workaround very
> long kernel non
On Thu, Mar 24, 2022 at 07:11:42AM +0100, Alexandre Ratchov wrote:
> Most audio/video players do a stop/start cycle whenever the play
> position is changed, track is changed, etc. Currently, stopping drains
> the play buffer, which by default is very large (to workaround very
> long kernel non-pree
Most audio/video players do a stop/start cycle whenever the play
position is changed, track is changed, etc. Currently, stopping drains
the play buffer, which by default is very large (to workaround very
long kernel non-preemptive code-paths). This makes player controls
sluggish.
This diff adds a