[gst-devel] mmap support on gstalsasink

[Marco Ballesio]

Hi,

thanks for the comments, they definitely give me good hints for the
right direction to take. A few words below.

On Thu, Dec 9, 2010 at 11:58 AM, Wim Taymans <wim.taymans at gmail.com> wrote:
> 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.

I would say that some _really_ embedded, single-task devices (classes
fairly lower than, e.g., an N900) may still not be able to deal with
pulseaudio. Even though we may address them as "niche products", the
market is still full of those.

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

"good" is subjective ;). Even if it may sound the same, I would better
say "properly reviewed and agreed", where the process involves a
discussion on Bugzilla -or wherever else-. Unfortunately or luckily,
for such a delicate component certain activities are required from
people who could not have time to follow the issue, so this may
require a really long time to get the patches accepted (the
"hardiness" of above).

This is why I'm searching for community involvement before me/whoever
else starts with the actual development. Comments from both Wim and
David are an excellent starting point in giving me the pulse (thank
you guys).

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

Roget that :).

Regards

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