[pulseaudio-discuss] PulseAudio with Motif?

[Michel Bardiaux]

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
> buy?"

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 
exactly that.


> 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.

> 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.
> 
> 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).

Greetings,
-- 
Michel Bardiaux
http://www.mediaxim.com/