Created attachment 90860 [details]
Header file for an implementation

Created attachment 90861 [details]
Source file for an implementation

Here is the Makefile I use :
all: portaudio_pwplugin.so

portaudio_pwplugin.so: sound_portaudio.cxx sound_portaudio.h
        g++ -Wextra -shared -o $@ $< -DPTRACING -I/usr/include -lportaudio

It compiles and doesn't seem to make ekiga too crashy, but doesn't work yet.

Notice that I use my header file from bug #332442.

Created attachment 90932 [details]
Source file for an implementation

This one can actually play sound events. For some reason, my usb webcam mic cannot be properly detected by portaudio, and my sound chipset's input is detected but won't work...

It would be nice if someone else could have a look :-)

Created attachment 90939 [details]
Source file for an implementation

Ok, I dumbed it down, and it works better.

I couldn't really test since portaudio really doesn't like my webcam mic, and since my other mics don't seem to work (even with the ALSA plugin)...

Created attachment 90942 [details]
Source file for an implementation

Ok, next iteration : little change.

I unstuck my alsa installation, and can run the druid audio test and sound events. 

Calling 500@ekiga.net doesn't work yet, though...

Let me try to pinpoint the main difference between the different uses :
- for sound events, the plugin just takes the data and uses it
- for audio test, the plugin takes the data and pushes it to itself
- for a call, on one side the plugin takes data which comes from outside, and on the other side pushes data to outside

So could in fact, the only time my plugin really seriously exchanges data with outside of itself is during a call -- and this is precisely when it fails.

I played with pcss.cpp, and could check that audio input with portaudio works during calls : only audio output is broken during calls.

Sigh... gstreamer won't have portaudio inside, and if I find the time to work, it will be to add gstreamer, not portaudio.