[pulseaudio-discuss] RFC: New volume functionality for PulseAudio

[Tanu Kaskinen]

On Fri, 2014-02-14 at 02:49 +0600, Alexander E. Patrakov wrote:
> I have also reread the API page, and I think that it would be nice to 
> specify event ordering and/or introduce a Sync event that is fired after 
> a group of related changes (the idea comes from the SYN_REPORT event in 
> the input subsystem).
> 
> Suppose that there is a mixer interface that wants (independently of any 
> policy module) to display all volume controls, grouping them into two 
> tabs: "routing nodes" and "everything else" (just for illustration). To 
> do so, it would listen for RoutingNodeAddedEvent and 
> VolumeControlAddedEvent (and the corresponding removals). On getting a 
> VolumeControlAddedEvent, there is no way to decide on which tab to put 
> this control. One solution would be to always put it onto the 
> "everything else" tab, and move it if the corresponding 
> RoutingNodeAddedEvent is emitted. But that is not flicker-free. With the 
> Sync event, one would be able to avoid updating the GUI until getting it.

I like the sync event idea. It's not possible to implement it optimally
with the current PulseAudio client API, because PulseAudio doesn't send
such sync events, but I think it should be added to the web API anyway.
Actually, even without sync events in PulseAudio, it's already possible
to know that you have a consistent state in case of new object and
object change situations, only object removal is problematic.

The problem of inconsistent state occurs when a PulseAudio client
receives an event, but actually multiple things happened that are part
of the same "logical event", so there are more events queued. The
PulseAudio client doesn't know anything about those queued events.
Luckily, in case of new object and object change events, this is not a
problem, because the client will anyway have to query the object state,
because the events don't contain that information. If there are queued
events, the client will process them before it gets the answer to its
query operation. The client knows that it has consistent state
information when there are no query operations in flight. The web
browser can issue the Sync event at this point. The exception is the
object removal event: that doesn't require the client to do any
querying, so the client doesn't know if there are more change events
queued after the object removal event. The web browser will have to
issue the Sync event blindly after each object removal event. This is
probably not a huge problem, but we could fix this anyway by adding a
sync event to the PulseAudio API (it should be pretty simple to
implement: modify defer_cb() in core-subscribe.c so that it sends a sync
event after it has drained the event queue).

-- 
Tanu