[pulseaudio-discuss] PulseAudio with Motif?
mbardiaux at mediaxim.be
Mon Apr 14 05:17:30 PDT 2008
Jan-Benedict Glaw wrote:
> On Tue, 2008-04-08 17:58:20 +0200, Michel Bardiaux <mbardiaux at mediaxim.be> wrote:
>> Michel Bardiaux wrote:
>>> Any example using PulseAudio for sound and Motif (or Athena) for GUI?
>> I would really like to add networked audio capability to my
>> applications, but finding one's way between NAS, ESD, ARTS, JACK, etc is
>> hard going. Currently, PULSE looks very attractive because it does not
>> insist on threads, using an asynchronous model instead. Since Motif (and
>> Athena) do the same, the match should be good, but I havent found any
>> example yet. Just a liiiitle pointer would help a lot.
> There's a good reason nobody answered by now: You didn't specify
> enough to help you in any way. It's like "I'd like to buy a new car.
> Preferred colour is red. Could you advise me which type of car to
Actually, your reply is very constructive, which seems to show I was not
as vague as that.
> 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
> And in fact, there
> shouldn't be any kind of connection to not mix up frontend with
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.
> 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
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
> 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.
> 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).
More information about the pulseaudio-discuss