On Wed, Jan 18, 2017 at 03:25:09AM -0500, Frediano Ziglio wrote: > > > > Hey, > > > > On Fri, Jan 13, 2017 at 05:47:13AM -0500, Frediano Ziglio wrote: > > > You are right. Surprisingly if the network queue was full the old code > > > just ignored the request not sending/setting any command. > > > After your code you don't schedule a send any volume/mute changes. > > > Maybe nothing change as will be send after/before next audio frame. > > > Maybe this patch should be partially merged to "sound: Use RedChannelClient > > > to receive/send data" ? > > > Maybe in the loop volume/mute flags should be checked before the frames? > > > > Hmm, good point that changing this is going to potentially change the > > order in which the volume/mute/... messages are going to be sent, and > > delay them a bit. It will also cause less messages to be sent if the > > user keeps calling spice_server_playback_set_volume() (for example). > > > > I don't think the messages are going to be delayed for a long time > > though, so this should not really cause an issue (ie we should be fine > > making that change without trying to get the exact same message order as > > before) > > > > Christophe > > > > I think it's not a bit problem for playback but could be an issue for > record. While on playback we'll have samples to send with volume with > record is possible that guest wants to reduce the recording volume > but if you are not pushing the volume the record will keep to arrive > at the same volume. > Note that snd_set_command just set a field. Indeed, this could be problematic, I'll try moving this change _after_ the introduction of snd_send(). Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel