long time no responses on this thread. actually Venemo's idea sounds great, has anyone checked this option?

I'm still waiting for the N900 to become available here in Australia, so I can't try it for myself, but here are a couple of ideas that might be worth experimenting with:

1) Select an mp3 as the default ring tone that is actually a symlink (or replace the already chosen ring tone with a symlink). Use the dbus approach to rewrite said symlink for each incoming call. This will only work if dbus sends the notification before the phone app starts playing the ring tone, doesn't cache the ring tone data, and doesn't do fancy stuff like resolving the symlink early when you configure the ring tone. If there's a race condition between the dbus event and the phone opening the ring tone file, renice(1)'ing the script to a better priority might work.

2) Instead of a symlink, try to make it a named pipe or unix domain socket, and have a daemon listening to the dbus messages and provide the appropriate audio data for the current caller. This requires more work, but would have the advantage of being able to provide silence up until the point where the caller info becomes available, so even if the dbus notification comes late, the right ring tone would be chosen (but you'd be perceived as being a tiny bit slower in answering your phone).

If anyone is able to test any of the two approaches, I'd love to hear the result. I only recently discovered that the N900 lacked this feature, and I'm thinking it might be a deal-breaker for me as I'm quite married to it on my old Palm...

EDIT: Argh, only now saw the later responses. Replace "mp3" above with the location of the converted wav file.

I think that your solution would be too expensive in terms of cpu/battery and disk operations (solid state disks are capable of a limited number of writing operations).
We need a linux way for this, for example substituting the .local/share/sounds/Terrestial.aac.wav file with a FIFO file that is feeded by a fast mp3player (like mplayer) controlled by a daemon.

just checked that mkfifo is provided by maemo default.

just to laydown some steps:

1) preliminar operations (to do only once)
mv /home/user/.local/share/sounds/Terrestial.aac.wav /home/user/.local/share/sounds/Terrestial.aac.wav.bak
mkfifo /home/user/.local/share/sounds/fiforingtone.wav

2) when someone is calling
mplayer -ao pcm:file=/home/user/.local/share/sounds/fiforingtone.wav ringtone.mp3 &
PIDMPLAYER=$!

3) after answering or closing the call
kill $PIDMPLAYER

It's been a long time since I worked with named pipes, but if memory serves me a reader of a pipe will get an EOF (end-of-file) for any read if there is no writer attached, which would prevent the phone application from getting any data if it tries to read before the dbus notification has propagated to us. If that's the case, we'll need to have the perl script open the pipe for writing (and keep it open all the time), and simply funnel pcm data into it from mplayer when needed.

See
http://talk.maemo.org/showthread.php?t=52646

Seems to work at least for some

Maybe if some bright guy could make sure that the phone app never starts playing a ringtone before the script changed the symlink....

Oh, and of course a GUI would be nice

I added it as a solution to the original brainstorm proposal to get the whole thing into "under consideration" status.