From Gnash Project Wiki
Draft1: only virtualize the output device
In this draft, sound handling for gnash would be all internal to the core lib, with the hosting application being in charge for fetching samples from it.
We should provide handy 'fetchers' (or virtual sound output devices, or audio sinks) for use by hosting applications, which would likely include an SDL-based and a Gstreamer-based one.
The "sinks" would basically pull samples of a given size from the corelib at a given sample rate and send them up the system mixer path.
The pulling function should be thread-safe so that the hosting application has the ability to run in a real-time thread, but it should NOT be a requirement to do so. In particular, we may want to be in full control of the bits flow for automated testing. In that case we might want to manually fetch arbitrary amount of samples from the core lib at an arbitrary sample rate.
What libcore needs to know about the sink
The corelib will need to know what's the sample size expected by the sink, which will pull samples (not bytes, not seconds).
The corelib 'might' need to also know how many samples the sink is planning to fetch per second (sample rate). It might be just an hint to optimize size of internal queues, or might be a required information (can anyone see why it would be required ? resampling ?).