[gst-devel] mmap support on gstalsasink

[Marco Ballesio]

Hi,

On Thu, Dec 9, 2010 at 3:02 AM, David Schleef <ds at entropywave.com> wrote:
> 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.

The intent of my reply is to understand whether the community has
interest in bringing back the feature or if the "status quo" is
preferred. The tone of the reply makes me understand we're in the
second case.

Sure I (or another spare developer) could write such a patch, but as
long as there's no interest from the community it would be pretty hard
to get anything into the official repositories, especially when we're
talking about gst-plugins-base.

>
> 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.

If modifying the alsasink is somewhere close to the doomsday,  why not
to write a separate element?

> 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.

or c) adding the new element to gst-plugins bad and let nature follow
its own course.

Regards

>
>
>
> David
>
>
>
> ------------------------------------------------------------------------------
> This SF Dev2Dev email is sponsored by:
>
> WikiLeaks The End of the Free Internet
> http://p.sf.net/sfu/therealnews-com
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>