[Spice-devel] [spice-gtk PATCH v6 2/4] audio: spice-pulse implement async volume-info

[Victor Toso]

Hi,

On Wed, Apr 15, 2015 at 07:29:12PM +0200, Marc-André Lureau wrote:
> On Wed, Apr 15, 2015 at 2:12 PM, Victor Toso <victortoso at redhat.com> wrote:
>
> > > > +
> > > > +    if (info->channel_map.channels == 0) {
> > > > +        SPICE_DEBUG("%s - Number of channels stored is zero. Ignore.
> > > > (%s)", __func__, info->name);
> > > > +        return;
> > > > +
> > >
> > > What if there is already a playing stream, is this going to reset it to
> > > restore value?
> >
> > Sorry, I think I did not understand.
> >
> > This if () is only to avoid issues with restore-info. If the number of
> > channels stored in pulseaudio database is zero, probably we are not
> > interested in the volume-information.
> >
> >
> I'm not sure when I hit this issue, probably when you have a new
> > database and we start the pulseaudio context but do not have any audio
> > stream. I believe it saved the application information in the database,
> > with default values but I'm not sure.
> >
>
> It's not about that if, it's actually about the function and the code after
> that change pstream->info. If there is already a info_cb that did update
> info, you'll reset it here.

I use the pstream->info to keep the volume information from all calls to
get_*_volume_info_async. So, when we already have a playing stream and
request volume info, the callback from pa_context_get_sink_input_info or
pa_context_get_source_output_info will update that as well.

If I understand you right now, the point is that there is no *need* to
update pstream->info *more then once* with pa_ext_stream_restore_read
and I agree with that but did not find harmful to keep this call either.
Maybe if the database is too big this will be a long process and sure,
we should avoid that.

Fixing this in v8.