[gst-devel] mmap support on gstalsasink

[David Schleef]

On Wed, Dec 08, 2010 at 11:38:31PM +0200, Marco Ballesio wrote:
> Hi,
> 
> On Tue, Dec 7, 2010 at 1:34 AM, Hector Barajas <abarajase at gmail.com> wrote:
> > Hi everyone,
> > Im trying to run and audio device with mmap support, I already did that with
> > pulseaudio but it adds overheads and therefore I still need to reuse the cpu
> > consumption.
> >
> > By looking at the cvs repository it does look like mmap was an option in
> > gstreamer several years ago, and it disappeared in version 1.40 of
> > gstalsasink.c. Does anyone know why this support was removed ? And how
> > difficult it would be to add it again ?
> >
> 
> interesting question, imo worth a discussion. Digging in
> gst-plugins-base, mmap support for ALSA has been removed with commit:
> 
> 851547e3212a49fd60e86cd8707e06ecbaed22ee
> 
> With the rationale "Implement alsasink with simple open/write/close API".
> 
> As, on one hand, I can understand the improved simplicity of the
> element, I think on the other that we've lost a premium feature
> especially for embedded devices where, for one reason or another, we
> want to reduce the memory footprint and/or latencies to the bare bone
> but we want to still use GStreamer.
> 
> Does anybody agree with me? Is this the case to file a bug/enhancement
> request or do we have a replacement element hidden somewhere (I didn't
> find any)?

If you want it, it would be better to write a patch than file an
enhancement request.

Implementing it would require implementing an alsa ring buffer to
use in the mmap case, switching alsasink to the GstBaseAudioSink
class, and copying over the software ring buffer code from
GstAudioSink class for the non-mmap case.  And then either a) testing
the hell out of it, or b) writing the patches in such a way that
it's obvious that no bugs are being introduced for the default case.



David