[pulseaudio-tickets] [PulseAudio] #719: Pulseaudio interacts poorly with non-pulse apps

PulseAudio trac-noreply at tango.0pointer.de
Mon Nov 16 01:18:14 PST 2009


#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


More information about the pulseaudio-bugs mailing list