[Spice-devel] [PATCH spice-gtk] gst-audio: Do not update mmtime without real audio channel

[Victor Toso]

Hi,

On Tue, Jul 18, 2017 at 06:55:12PM +0200, Christophe de Dinechin wrote:
> Interestingly, I just discovered something I did not really expect: a
> hot CPU is more than enough to make the spice client lack “oxygen”,
> even if nothing else is running.
>
> If I start under light load and keep running that way, it can run a
> long time without a problem. The queue length typically runs up and
> down a little, but it does not diverge. See
> http://blackbox.dinechin.org/images/170718-NotDiverging.png.
>
> There is even plenty of CPU left to converge back if we temporarily
> accumulate things in the queue:
> http://blackbox.dinechin.org/images/170718-Reconverge.png.
>
> However, if the machine gets hot, then it does not reconverge, because
> the machine spends over 50% “in the kernel” just trying to cool down.
> Starting the client under these conditions, it rapidly diverges:
> http://blackbox.dinechin.org/images/170718-WithHotCPU.png.

Isn't it expected as the CPU lost 50% of its processing time in order to
cool down? We can think about different ways to workaround this kind of
issue. Dropping the queue as you did in a different patch is a good
approach for peaks like this, I think.

If those situations happens too often it would be a good signal that
current stream is too much for the client to handle and we could lower
quality/fps, increase I-FRAME, etc. in order to make it less demanding
for the client.

Still, it should be much better if you were doing hw decoding, I guess.

> Also, without enough I-frames to recover, when this starts happening,
> we are a bit stuck.  This is all documented in more details here:
> http://blackbox.dinechin.org/170718.html.

Cool charts

> Tons of messages that look like:
>
> channel-display-gst.c:266: [783802 1768.364819] spice_warning: got an
> unexpected decoded buffer!

First time seeing it, cool!

> So I think we will need the mechanism we discussed with Uri, where we
> send something back to tell the server we need an I-frame. Or we
> close/reopen the channel.

Definitely! We should start discussing about it... I think it will
require a new/improved protocol.

Cheers,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170719/6d4fbdd1/attachment.sig>