#719: Pulseaudio interacts poorly with non-pulse apps
-----------------------+----------------------------------------------------
Reporter: p-static | Owner: lennart
Type: defect | Status: new
Milestone: | Component: daemon
Resolution: | Keywords:
-----------------------+----------------------------------------------------
Comment(by coling):
I don't think it's possible to make pulse signal apps about dummy devices.
The loading of the null sink when no real sinks are available is done by
module-always-sink and is therefore not something that works at the
protocol level - it's just another module. Therefore to let apps know
about this, they would have to support a given protocol extension and
listen specifically for this. We would then have to write support into all
the various applications that implement PA and all the abstraction
libraries too. For the abstraction library case, this may require writing
a new API in that system to receive this new signal and let the
application know. Again, the applications would then have to be updated.
Add to this that the UI each app uses to notify the user would be
different and custom and you end up with a very expensive and inconsistent
solution.
The right way is to do it centrally, but like I say there are a few
blockers for that. My notifications branch does indeed hook into
libnotify, but due to the lack of integration into the glib mainloop for
modules, I cannot really control things properly, and cannot deal with
e.g. action callbacks. Until such times as I can support the glib main
loop properly, I don't want to merge this to master.
--
Ticket URL: <http://pulseaudio.org/ticket/719#comment:3>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
_______________________________________________
pulseaudio-tickets mailing list
pulseaudio-tickets@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
