Hi devel list, the following is part of an exchange between myself and Bill where we were talking about possible future scenarios for audio output and input being refactored into a single API (in the current Tuxpaint there is SDL_mixer and optionally SDL_audioin as separate). I was hoping to attract more free criticism and idea generation from others on the list who may (or may not) care where this goes. Thoughts??
I have no problem with the current audio implementation. SDL and SDL_mixer
have served us well. The ability to RECORD audio, while not exactly
a necessity, would be a very fun thing to have... and you've acheived this,
to a near-complete degree, using SDL_audioin.
I admittedly don't know much about that library, but since it doesn't
require any weird hacks to SDL itself, and seems to be compatible with
an app that uses SDL_mixer for output, it seems like no 'refactoring'
would be necessary. Certainly not something _I_ ever suggested.
Now, I've heard that PortAudio might be a more robust and portable solution
to audio recording in an SDL-app (or just in general), but I haven't
So if we can figure out what:
(1) works without hassling Tux Paint itself (as your memo magic tool does,
by using SDL_audioin)
(2) is as portable as possible (at a minimum: Linux (whatever audio driver(s)
is/are common and popular today... is it PulseAudio nowadays?),
modern Windows (95/98/ME would be a bonus, but not _required), and
Mac OS X)
then that'd be good. Keeping in mind, of course, that SDL 1.3 claims it
will have audio input support. That throws a wrench into things.
If 1.3 is as portable as 1.2 has been, and it's relatively easy to update
Tux Paint to use SDL 1.3, then writing against a 3rd party audio input
layer might be redundant.
However, if any of the following are true for 1.3:
* not released soon
* not easy to port Tux Paint to it quickly
* not portable across all major platforms Tux Paint supports
then we can safely ignore SDL 1.3, for the time being.
Little anecdote: When I added SVG support to Tux Paint, I was using
some packages that been backported to Debian Stable, or somesuch.
Then when Debian updated, those packages dind't actually become
available, and some OTHER, BETTER ones did.
So before I even had the chance to release "Tux Paint: now with SVG support!",
I ended up writing the SVG code twice, once against each set of libs.
This wasn't a _terrible_ waste of time, because a lot of older platforms
(older RedHat & older Windows) ended up benefiting, since the newer, better
SVG libs don't work on them.
Whew! Hope that all makes sense. It's late. :)
Feel free to share any of the above thoughts with GSOC student,
any mentors, or even the tuxpaint-devel mailing list.