'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/]
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
