[pulseaudio-discuss] PA and OS X

[Colin Guthrie]

'Twas brillig, and Daniel Mack at 18/07/09 13:05 did gyre and gimble:
> On Fri, Jul 17, 2009 at 09:12:58PM +0200, Daniel Mack wrote:
>>   http://pulseaudio.org/wiki/BuildingOnMacOSX
>>
>> I thought about the necessary steps a little more and will see how much
>> I can do over the weekend. I'll get back to you as soon as I got
>> something.
> 
> I've put some pieces together now and what I got is
> 
> - a kernel module that loads and unloads fine and offers a virtual
>   stereo soundcard which can be selected by any CoreAudio application.
> - a user space interface to share the ring buffers with application so
>   that audio can be transported in and out.
> - a skeleton for an
>   application that connects to that interface and maps the shared memory
>   buffers.
> - a PreferencePane which has no function yet but can be used later to
>   control setting for the virtual audio device and the local sound server.
> 
> Sounds like a lot, but there's still a long way to go until we'll hear
> anything.

That's still a million times further on than last week! Awesome work :D

> There are a number of issues I'm struggling with and I would
> like to get some help or input for.

I'll try....

> 1. When PA is build using the instructions I posted, the executables are
> linked fine, but they won't run. The error I'm getting is
> 
> $ ./pulseaudio 
> dyld: Symbol not found: _g_get_application_name
>   Referenced from: /Users/daniel/src/pa/pulseaudio/src/.libs/libpulsecommon-0.9.16.dylib
>   Expected in: dynamic lookup
> 
> (otool -L is similar to ldd on Linux)
> 
> $ otool -L /Users/daniel/src/pa/pulseaudio/src/.libs/libpulsecommon-0.9.16.dylib
> /Users/daniel/src/pa/pulseaudio/src/.libs/libpulsecommon-0.9.16.dylib:
> 	/usr/local/lib/libpulsecommon-0.9.16.dylib (compatibility version 0.0.0, current version 0.0.0)
> 	/opt/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
> 	/usr/lib/libwrap.7.dylib (compatibility version 7.0.0, current version 7.6.0)
> 	/opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
> 	/opt/local/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.20.0)
> 	/opt/local/lib/libFLAC.8.dylib (compatibility version 11.0.0, current version 11.0.0)
> 	/opt/local/lib/libvorbisenc.2.dylib (compatibility version 3.0.0, current version 3.3.0)
> 	/opt/local/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.0.0)
> 	/opt/local/lib/libogg.0.dylib (compatibility version 6.0.0, current version 6.3.0)
> 	/opt/local/lib/libgdbm.3.dylib (compatibility version 4.0.0, current version 4.0.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> 
> 
> So it seams that libglib2 is missing in the linker list. Haven't
> debugged any further, hoping that someone has a solution already :)

Hmmm. This is some sort of over/under linking issue I think. The place 
where this is defined is based on a weak reference, which means that if 
it doesn't exist, it should allow the app to continue.

I suspect that the clue to fixing this would be in the PA_GCC_WEAKREF 
macro. I suspect this is simply not working on OSX.

It's probably quite a trivial patch in src/pulsecore/proplist-util.c

It checks for and defines _g_get_application_name, but if the 
PA_GCC_WEAKREF macro is not defined we don't do anything... I'd imagine 
a simple #else and a dummy implementation of _g_get_application_name() 
that returns NULL.

Now interestingly, pulse does check for it via "if 
(_g_get_application_name)" so it should handle this already... Hmmm. I 
guess the dynamic linker isn't loading the library needed for the 
weakref for you. I'm not really sure now I've gone through this :s

Check first if the PA_GCC_WEAKREF macro is defined and tyr and get some 
more info and follow it through is my recommendation for now.

Whatever you do, you may have to do the same for 
_gtk_window_get_default_icon_name and _gdk_display...


> 2. The CoreAudio backend needs a clock for the internal ring buffer
> motor. There are two different possible aproaches. Either the audio
> driver clocks itself using a timer and then is the clock master to the
> user space. Or the user space appliction obtains the clock from PA and
> clocks the kernel module. I'm sure there is a clearly preferred way to
> go for PA, but I'm uncertain which one that is. And how is that handled
> for both directions?

I'm afraid I really don't know about this stuff. Hopefully someone else 
can help here!


> 3. Once the linker problem is solved, is anyone willing and able to care
> for the implementation of the CoreAudio source/sink modules (iow, using
> CoreAudio devices from PA)?

I may take a look, but I've got a lot on my plate just now with various 
projects and I've got a fair few things to do on the OSX side of things 
first too. So if some other keen people are about (Kim?) then perhaps 
this is a good project for them!

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]