On Fri, 2016-11-11 at 18:02 +, Frediano Ziglio wrote:
> Reduce SpiceVolumeState structure size on 64 architectures
> swapping the order of two fields.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/sound.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/server/so
On Fri, 2016-11-11 at 18:02 +, Frediano Ziglio wrote:
> These function were really similar.
> Factor out a new snd_get_best_rate to avoid code duplication.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/sound.c | 27 +--
> 1 file changed, 9 insertions(+), 18 deleti
On Fri, 2016-11-11 at 18:02 +, Frediano Ziglio wrote:
> This field is common to SpicePlaybackState and SpiceRecordState
> which are based on SndWorker.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/sound.c | 45 +++--
> 1 file changed, 23 insertion
Hi,
On Fri, Nov 11, 2016 at 04:05:21PM -0600, Jonathon Jongsma wrote:
> On Fri, 2016-11-11 at 14:27 +0100, Victor Toso wrote:
> > From: Victor Toso
> >
> > This fixes the situation when VDAgent receives 0 byte message
> > regarding a file-transfer operation that was terminated in the
> > previou
Acked-by: Jonathon Jongsma
On Fri, 2016-11-11 at 18:02 +, Frediano Ziglio wrote:
> Reuse more code in snd_send_volume and snd_send_mute.
> Reduce conversions in on_new_playback_channel and
> on_new_record_channel.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/sound.c | 89
Pass the new sound channel to these functions rather than setting
worker->connection before calling the function and expecting it to be
set when the function is called. The fewer unenforced assumptions that
must be true for a function to work properly, the easier it will be to
maintain.
---
Propose
Acked-by: Jonathon Jongsma
On Fri, 2016-11-11 at 18:02 +, Frediano Ziglio wrote:
> This field is common to SpicePlaybackState and SpiceRecordState
> which are based on SndWorker.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/sound.c | 39 +++
> 1 f
On Fri, 2016-11-11 at 14:27 +0100, Victor Toso wrote:
> From: Victor Toso
>
> This fixes the situation when VDAgent receives 0 byte message
> regarding a file-transfer operation that was terminated in the
> previous message.
>
> This makes the VDAgent to send a STATUS_ERROR after STATUS_SUCCESS
On Fri, 2016-11-11 at 13:22 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/red-channel-client.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/server/red-channel-client.h b/server/red-channel-
> client.h
> index 862d1c9..fe3096b 100644
> -
Acked-by: Jonathon Jongsma
On Fri, 2016-11-11 at 12:06 +, Frediano Ziglio wrote:
> Function just return the command, has no ext_cmd parameter to fill.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/red-replay-qxl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -
Reuse more code in snd_send_volume and snd_send_mute.
Reduce conversions in on_new_playback_channel and
on_new_record_channel.
Signed-off-by: Frediano Ziglio
---
server/sound.c | 89 ++
1 file changed, 34 insertions(+), 55 deletions(-)
dif
This field is common to SpicePlaybackState and SpiceRecordState
which are based on SndWorker.
Signed-off-by: Frediano Ziglio
---
server/sound.c | 45 +++--
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/server/sound.c b/server/sound.c
inde
Why I was looking at the way to remove the Dummy* objects
I found some duplication and some way to reuse some
similar code. Record and playback are quite similar.
Frediano Ziglio (5):
sound: Move volume field to SndWorker
sound: Minor simplification due to volume move
sound: Move frequency f
These function were really similar.
Factor out a new snd_get_best_rate to avoid code duplication.
Signed-off-by: Frediano Ziglio
---
server/sound.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/server/sound.c b/server/sound.c
index 80b0e03..1572
Reduce SpiceVolumeState structure size on 64 architectures
swapping the order of two fields.
Signed-off-by: Frediano Ziglio
---
server/sound.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/sound.c b/server/sound.c
index 1572019..ccbf6f4 100644
--- a/server/sound.c
++
This field is common to SpicePlaybackState and SpiceRecordState
which are based on SndWorker.
Signed-off-by: Frediano Ziglio
---
server/sound.c | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/server/sound.c b/server/sound.c
index be9a
From: Victor Toso
This fixes the situation when VDAgent receives 0 byte message
regarding a file-transfer operation that was terminated in the
previous message.
This makes the VDAgent to send a STATUS_ERROR after STATUS_SUCCESS to
client.
Resolves: https://bugs.freedesktop.org/show_bug.cgi?id=9
Signed-off-by: Frediano Ziglio
---
server/red-channel-client.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/red-channel-client.h b/server/red-channel-client.h
index 862d1c9..fe3096b 100644
--- a/server/red-channel-client.h
+++ b/server/red-channel-client.h
@@ -83,7 +
>
> On Fri, 2016-11-04 at 13:16 +, Frediano Ziglio wrote:
> > This patch allow to record playback and replay with spice-server-
> > replay
> > utility using the a new --audio option.
> > The main concern I have is the way the sound is reproduced.
> > The audio is correctly passed to the client
...
>
>
> Sorry, just replied to the old version of this patch before I saw that
> you had sent a new series. But it looks like my comments still apply to
> this patch.
>
> Jonathon
>
No problem, there were no changes for this patch, just rebased.
Frediano
Avoid not constant globals.
Signed-off-by: Frediano Ziglio
---
server/dummy-channel.c | 5 ++-
server/event-loop.c | 23 ++-
server/red-channel-client.c | 32 +++
server/red-common.h | 17
server/reds-private.h | 2 +-
Function just return the command, has no ext_cmd parameter to fill.
Signed-off-by: Frediano Ziglio
---
server/red-replay-qxl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/red-replay-qxl.c b/server/red-replay-qxl.c
index 3dd1517..e531114 100644
--- a/server/red-
>
> > I'll also note that the h264 encoder automatically uses multiple
> > threads already so this patch only brings vp8enc in line with it.
>
> After a quick look at x264, it seems to be using more threads than
> physiical CPUs. Is it ok too with vp8enc? I'd really like that we don't
> have that
23 matches
Mail list logo
