[gst-devel] mmap support on gstalsasink

[Wim Taymans]

On Thu, 2010-12-09 at 11:45 +0200, Marco Ballesio wrote:
> Hi,
> 
> On Thu, Dec 9, 2010 at 3:02 AM, David Schleef <ds at entropywave.com> wrote:

<snip>

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

Most distros and embedded devices go to pulseaudio nowadays. Plain alsa
has very few use cases left.

One of the reasons mmap support was removed is because it didn't work so
well on too many cards back in the day. Now that pulseaudio has tried to
shake out most of the bugs it might work a bit better.

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

I guess a good patch would be accepted.

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

You can actually just implement the ringbuffer and keep extending from
GstAudioSink. The existing code path is not modified when you don't
provide a ringbuffer. You would always need the existing code as a
fallback because some devices can't be opened in mmap mode at all.

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

You don't have to. Writing a new element would be painful because then
you would need to copy existing alsasink code for the fallback and then
you can just as well add the new code to existing alsasink. 

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

That would cause more trouble than needed.

Wim

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