Looking over the stock N900 binaries, I see the following binaries that reference PulseAudio functions (specifically any function starting with pa_)
closed:
/usr/bin/maemo-xinput-sounds
/usr/bin/pasr
/usr/bin/volume_backup
/usr/lib/browser/plugins/libflashplayer.so
/usr/lib/hildon-control-panel/libcpprofiles.so
/usr/lib/libhildon-plugins-notify-sv.so
/usr/lib/volume_status_menu_item.so
/usr/lib/microb-engine/components/libatlas.so
/usr/lib/pulse-0.9.15/modules/libnokia-common.so
/usr/lib/pulse-0.9.15/modules/module-nokia-music.so
/usr/lib/pulse-0.9.15/modules/module-nokia-record.so
/usr/lib/pulse-0.9.15/modules/module-nokia-voice.so
/usr/lib/libsystemuiplugin_emergency.so

open:
/usr/bin/pulseaudio
/usr/bin/tonegend
/usr/lib/alsa-lib/libasound_module_conf_pulse.so
/usr/lib/alsa-lib/libasound_module_ctl_pulse.so
/usr/lib/alsa-lib/libasound_module_pcm_pulse.so
/usr/lib/gstreamer-0.10/libgstpulse.so
/usr/lib/libcanberra-gstreamer.so
/usr/lib/libcanberra-pulse.so
/usr/lib/mafw-plugin/mafw-gst-renderer.so
/usr/lib/pulse-0.9.15/modules/libcli.so
/usr/lib/pulse-0.9.15/modules/module-simple-protocol-unix.so
/usr/lib/pulse-0.9.15/modules/libalsa-util.so
/usr/lib/pulse-0.9.15/modules/module-alsa-sink.so
/usr/lib/pulse-0.9.15/modules/module-native-protocol-unix.so
/usr/lib/pulse-0.9.15/modules/module-position-event-sounds.so
/usr/lib/pulse-0.9.15/modules/module-remap-sink.so
/usr/lib/pulse-0.9.15/modules/module-alsa-sink-old.so
/usr/lib/pulse-0.9.15/modules/module-combine.so
/usr/lib/pulse-0.9.15/modules/module-device-restore.so
/usr/lib/pulse-0.9.15/modules/module-match.so
/usr/lib/pulse-0.9.15/modules/module-card-restore.so
/usr/lib/pulse-0.9.15/modules/libprotocol-simple.so
/usr/lib/pulse-0.9.15/modules/module-alsa-source.so
/usr/lib/pulse-0.9.15/modules/module-stream-restore.so
/usr/lib/pulse-0.9.15/modules/module-suspend-on-idle.so
/usr/lib/pulse-0.9.15/modules/module-alsa-sink-volume.so
/usr/lib/pulse-0.9.15/modules/module-null-source.so
/usr/lib/pulse-0.9.15/modules/module-augment-properties.so
/usr/lib/pulse-0.9.15/modules/module-rescue-streams.so
/usr/lib/pulse-0.9.15/modules/module-alsa-card.so
/usr/lib/pulse-0.9.15/modules/module-null-sink.so
/usr/lib/pulse-0.9.15/modules/module-always-sink.so
/usr/lib/pulse-0.9.15/modules/libprotocol-native.so
/usr/lib/pulse-0.9.15/modules/module-alsa-source-old.so
/usr/lib/pulse-0.9.15/modules/libprotocol-cli.so
/usr/lib/pulse-0.9.15/modules/module-esound-protocol-unix.so
/usr/lib/pulse-0.9.15/modules/libprotocol-esound.so
/usr/lib/pulse-0.9.15/modules/module-esound-compat-spawnpid.so
/usr/lib/pulse-0.9.15/modules/module-esound-protocol-tcp.so
/usr/lib/pulse-0.9.15/modules/module-esound-compat-spawnfd.so
/usr/lib/pulse-0.9.15/modules/module-hal-detect.so
/usr/lib/pulse-0.9.15/modules/module-gconf.so
/usr/lib/pulse-0.9.15/modules/module-bluetooth-device.so
/usr/lib/pulse-0.9.15/modules/module-bluetooth-proximity.so
/usr/lib/pulse-0.9.15/modules/libbluetooth-ipc.so
/usr/lib/pulse-0.9.15/modules/libbluetooth-util.so
/usr/lib/pulse-0.9.15/modules/module-bluetooth-discover.so
/usr/lib/pulse-0.9.15/modules/libbluetooth-sbc.so
/usr/lib/pulse-0.9.15/modules/module-policy-enforcement.so
/usr/lib/pulseaudio/pulse/gconf-helper
/usr/lib/qt4/plugins/audio/libn900audio.so
/usr/lib/libpulse-mainloop-glib.so.0.0.4
/usr/lib/libpulse-simple.so.0.0.2
/usr/lib/libpulse.so.0.8.0
/usr/lib/libpulsecommon-0.9.15.so
/usr/lib/libpulsecore-0.9.15.so
/usr/lib/libsdl-1.2.so.0.11.1
/usr/sbin/fmtxd

Now I am not sure if this captures everything that is tied to the specific pulseaudio version the N900 has or not but lets assume it is (for the purposes of this discussion)

What we have on the Neo900 is a chip containing sound hardware that is compatible with the one in the Nokia N9. We also have (courtesy of the N9 SDK) pulseaudio blobs for the N9 that are not only a lot smaller than those the N900 is using but also have debug packages (that make them a LOT easier to reverse engineer)

My random thought is this:
Could we do the following as a solution to audio on the Neo900:
1.Copy the N9 audio hardware instead of the N900 (use the TPS6595x that we already have on the PCB just like the N9 uses and wire it up to the audio stuff just like the N9)
2.Use the pulseaudio open bits from the Harmattan SDK (pulseaudio, pulseaudio-meego etc) ported to satisfy the Neo900 hardware.
3.Reverse engineer/clone/whatever the closed N9 pulseaudio blobs (the ones with the nice debugging packages)
4.Port the "open" stuff from the above list of pulseaudio users to the new PulseAudio version
5.Clone those items on the "closed" list above that its possible to clone then port those to the new PulseAudio version
and 6.For those items that we cant clone use LD_PRELOAD to write a thunk library that basically does the "porting" for us (i.e. it exports the functions as expected by the old pulseaudio stuff and does whatever is necessary to make it work against the newer stuff) or otherwise find a way to make them work against the newer pulseaudio.

From where I sit, the advantages of this idea (if its fesable) is that we don't need the extra N900 audio chip, that we have direct access to the cellular call audio bits (as part of the open Harmattan stuff) and that we have much smaller binary blobs that are much easier to reverse engineer/clone.

I dont know anything about pulseaudio, audio hardware or how this all works (or even if my grep through the binaries missed some important closed binary that links to PulseAudio functions that dont begin with pa_), I am just throwing this random idea out there.

I get where you are going with this. Recently I took a look at the /usr/lib/pulse-0.9.15/modules/* files with the aim of trying to work out how it works, to see if we can bring it to a recent pulseaudio version for use with debian jessie. I have no experience at RE, so I'm not getting very far at the moment, if anywhere.

Same day fmg posted to say he might take a look, but like you he has little pulseaudio experience, so he was looking for help if he decided to tackle it. He suggested IIRC using the pulseaudio-meego bits and adding in the missing xprot functionality from RE the N900 libraries. You may want to message him to see if he's made any progress. I think xprot was removed due to incompatibilities with meego version, way to much reading this week so may be wrong.

I think from an overall standpoint, for both N900 and Neo900, it would still be beneficial to RE the N900 files as much as possible, even if its just for xprot. There may be some shared code between N900 and N9 blobs, so If it means first using the N9 SDK to see what we find there, and then use that help with N900 files so be it.

Actually there is a bit of progress on that, me and jonwil will "cooperate" this time, as there is lots of stuff to be done. Check the logs on #neo900 for the last couple of days.