[pulseaudio-discuss] PA and OS X

Colin Guthrie gmane at colin.guthr.ie
Sun Jul 19 06:20:57 PDT 2009


'Twas brillig, and Daniel Mack at 19/07/09 12:26 did gyre and gimble:
> On Sun, Jul 19, 2009 at 12:13:05PM +0100, Colin Guthrie wrote:
>> 'Twas brillig, and Daniel Mack at 18/07/09 13:05 did gyre and gimble:
>>> 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
> 
> For those interested, I've put my tree online:
> 
>   http://github.com/zonque/PulseAudioOSX/tree/master
>  
>>> 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.
> 
> Ah, so you're saying PA doesn't need glib2 at all?

Indeed. It should survive without it. Not sure when this was last tried 
tho' :)

If we depended on glib, there would be a lot of internal code that would 
disappear as we have our own structures for lots of things like hashmaps 
etc. that could instead just be the glib varients. I think the intention 
is to keep the deps down tho'.

>> 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...
> 
> Hmm. Maybe someone can come up with a patch :)

Perhaps :) I'm not really familiar with weak refs and such on OS X (or 
on Linux!).

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/]




More information about the pulseaudio-discuss mailing list