GStreamer-devel

mmap support on gstalsasink

Classic

List

Threaded

7 messages Options

Hector Barajas

mmap support on gstalsasink

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 ?

Thanks for your feedback.

Regards,

Hector Barajas

------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Marco Ballesio

Re: mmap support on gstalsasink

Hi,

On Tue, Dec 7, 2010 at 1:34 AM, Hector Barajas <[hidden email]> 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)?

Regards

> Thanks for your feedback.
>
> Regards,
> Hector Barajas
> ------------------------------------------------------------------------------
> What happens now with your Lotus Notes apps - do you make another costly
> upgrade, or settle for being marooned without product support? Time to move
> off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
> use, and manage than apps on traditional platforms. Sign up for the Lotus
> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

David Schleef-2

Re: mmap support on gstalsasink

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 <[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Marco Ballesio

Re: mmap support on gstalsasink

Hi,

On Thu, Dec 9, 2010 at 3:02 AM, David Schleef <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

Wim Taymans

Re: mmap support on gstalsasink

On Thu, 2010-12-09 at 11:45 +0200, Marco Ballesio wrote:
> Hi,
>
> On Thu, Dec 9, 2010 at 3:02 AM, David Schleef <[hidden email]> 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
> > [hidden email]
> > 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Marco Ballesio

Re: mmap support on gstalsasink

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 <[hidden email]> 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 <[hidden email]> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

Hector Barajas

Re: mmap support on gstalsasink

Thank you all for your comments

I think I could start a patch on this that does not mess with default functionality and follows the recommendations given here, and then share it to you guys to get feedback from the experts, maybe the patch can be base for having this feature on gst base again, please let me know if you have any other points/considerations for the implementation.