[pulseaudio-discuss] PulseAudio with Motif?

[Jan-Benedict Glaw]

On Mon, 2008-04-14 14:17:30 +0200, Michel Bardiaux <mbardiaux at mediaxim.be> wrote:
> Jan-Benedict Glaw wrote:
> > On Tue, 2008-04-08 17:58:20 +0200, Michel Bardiaux <mbardiaux at mediaxim.be> 
> > wrote:
> > > Michel Bardiaux wrote:
> > See the point? There's no connection between Pulseaudio (specifically
> > its client library) and a given widget set. 
> 
> Actually, there is. I had done some amount of research, and had looked 
> at the sample clients on pulseaudio.org, and it was clear (eg from 
> paplay.c) that for pulseaudio one has pa_mainloop_run exactly where an 
> Xt application has XtAppMainLoop. In single-thread I can't run both at 
> the same time, which means I have to merge the 2 loops somehow. Your 
> mention of "input loop of my widget" below makes me believe you mean 
> exactly that.

Usually, the widget sets that manage their own input loop offer you
the ability to register some more file descriptors and getting a
callback when one of them is ready. In this callback, you'd call a
single loop for whatever needs to be done for that FD, like processing
PA stuff.

> > And in fact, there
> > shouldn't be any kind of connection to not mix up frontend with
> > backend. 
> 
> In theory, yes. In practice, I am much more interested in robustness and 
> scrutability than in genericity. Eg, for direct DSP sound, initially we 
> were using SDL, but found it more sustainable to "sit on top of the 
> hardware", as my boss if fond of saying.

As long as you plan your application to be extensible to a different
set of hardware I/O, that's fine.

> > You can for sure put pulse into the input loop of your widget
> > set. And you'd also implement it in threads (which may or may not be
> > simpler.)
> 
> No, I very much prefer non-blocking objects and polling. We had tons of 
> problems using SDL just because SDL brought threads in where we didn't 
> expect any.

Where exactly? I for one find it quite easy using blocking I/O and
threads, whereas polling I/O is either slow/CPU-cycle burning or needs
some more cleverness :)

> > I don't think there are Motif or Athena programs around using pulse
> > (hey, one of these is even more dead than the other!) 
> > But you may
> > find pavucontrol etc. interesting, though these are GTK2 based.
> 
> I have, and learned that the integration of pulseaudio with GTK is done 
> not at application level but in a specific library. But it is C++, not 
> exactly my cup of tea.

GTK isn't C++. It's plain C. *The* big difference to the KDE libs.
(Plus is never requires an additional meta compiler...)

> > You should, however, *NOT* only implement a pulse backend in your
> > application. Put an abstraction layer in between to allow to add
> > direct ALSA and ESD access, too.
> 
> If I wanted to do that, I would have kept SDL. Is there some flaw in 
> pulseaudio that makes it less suitable than ALSA or ESD? And IIRC 
> neither has an asynchronous API (admittedly I did not look very hard; I 
> would like to avoid having to master more than 1 sound API).

PA requires a working ALSA, OSS or ESD setup, it doesn't make them
superfluous. It's just another different API that you can use to solve
specific problems.

For an application being flexible, it could use something like SDL, or
implement its own backends. (That would probably be PA, ALSA, OSS,
Windows Sound API, esd, aRTs and Jack. Did I miss an important one?)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of: "Debugging is twice as hard as writing the code in the first place.
the second  :  Therefore, if you write the code as cleverly as possible, you are,
               by definition, not smart enough to debug it." - Brian W. Kernighan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20080414/794b4e80/attachment.pgp>