[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