[Spice-devel] [spice-gtk v1] channel-main: demote log level from warning to debug

[Christophe Fergeau]

On Thu, Dec 01, 2016 at 05:06:42PM +0100, Victor Toso wrote:
> Hi,
> 
> On Thu, Dec 01, 2016 at 04:33:36PM +0100, Christophe Fergeau wrote:
> > On Thu, Dec 01, 2016 at 02:15:49PM +0100, Victor Toso wrote:
> > > On Thu, Dec 01, 2016 at 11:37:32AM +0100, Christophe Fergeau wrote:
> > > > On Wed, Nov 30, 2016 at 06:50:39PM +0100, Victor Toso wrote:
> > > > > From: Victor Toso <me at victortoso.com>
> > > > >
> > > > > Failing to get playback or record volume async on startup is very
> > > > > common making this warning too worrisome for users.
> > > > >
> > > >
> > > > Looked quickly at the code, and this seems to be getting the volume info
> > > > from pulseaudio. What is special at startup that makes this not work?
> > >
> > > As mentioned in the commit log below:
> > >
> > > > > If the audio back-end does not cache the last volume used or if this
> > > > > is the first time the application is launched, this message will be
> > > > > seen.
> > >
> > > With pulseaudio back-end, the playback/record volume is cached in user
> > > file with the application name as reference. The volume info should
> > > fail:
> > >
> > > 1-) For playback, in the first time a spice client is launched
> > > 2-) For record, always till the first it is used and, furthermore,
> > >     cached.
> >
> > It seems obvious to you that in this case retrieving the volume is going
> > to fail, and that it's normal, but it's not obvious at all to me.
> > The application is running, so it should be able to retrieve some kind
> > of volume?
> 
> Ah, I thought that how to get the volume was understood and the problem
> was understanding when the warning is showed, sorry.

Thanks for the detailed explanation below, the big thing that I
was missing is:
> Now, the volume-sync happens when agent announce its capabilities. It is
> common that we don't have a playback stream being played at this time,
> and it is even harder for a record stream.

With that in mind, it makes sense that our only fallback is the cached
info, which might be missing in the cases that you outline, which
triggers the warning. If you can mention this bit in the commit log,

Acked-by: Christophe Fergeau <cfergeau at redhat.com>

Thanks,

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20161201/15d52723/attachment.sig>