Using playbin2 causes high CPU load on embedded system

[stuart68]

Hi,

Can anyone explain why when I change my pipeline to use playbin2 instead of souphttpsrc, decodebin, queue2, audioconvert, audioresample, alsasink that my CPU load is noticeably higher.

For HD audio formats it is going from around 65% to a constant 99% when using playbin2.

Thanks,
Stuart

[Victor Manuel Jáquez Leal]

On Tue, Oct 11, 2011 at 11:06 AM, stuart68 <[hidden email]> wrote:
> Hi,
>
> Can anyone explain why when I change my pipeline to use playbin2 instead of
> souphttpsrc, decodebin, queue2, audioconvert, audioresample, alsasink that
> my CPU load is noticeably higher.

Because playbin2, being constructed at run time depending of how the
streams are recognized, would adds more elements on the pipeline than
your predefined/optimized pipeline.

You can dump a graph of the generated playbin2 pipeline:

http://gstreamer.freedesktop.org/wiki/DumpingPipelineGraphs

vmjl

>
> For HD audio formats it is going from around 65% to a constant 99% when
> using playbin2.
>
> Thanks,
> Stuart
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-playbin2-causes-high-CPU-load-on-embedded-system-tp3893255p3893255.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Icarus Alive]

2011/10/11 Victor Manuel Jáquez Leal <[hidden email]>:

> On Tue, Oct 11, 2011 at 11:06 AM, stuart68 <[hidden email]> wrote:
>> Hi,
>>
>> Can anyone explain why when I change my pipeline to use playbin2 instead of
>> souphttpsrc, decodebin, queue2, audioconvert, audioresample, alsasink that
>> my CPU load is noticeably higher.
>
> Because playbin2, being constructed at run time depending of how the
> streams are recognized, would adds more elements on the pipeline than
> your predefined/optimized pipeline.
>
> You can dump a graph of the generated playbin2 pipeline:
>
> http://gstreamer.freedesktop.org/wiki/DumpingPipelineGraphs
>
> vmjl
>
>>
>> For HD audio formats it is going from around 65% to a constant 99% when
>> using playbin2.
>>

BTW, I was able to bring down the CPU utilization of my pipeline, down
from around 60% to around 25-30% (single CPU in virtualized mode), by
turning playbin2 into the minimal equivalent with discrete elements,
however that led to audio/video sync issues. Playbin2 somehow manages
to keep audio/video sync, but my own pipeline faces issues, when
erratic network latencies are there (it is a streaming pipeline).

Maybe, someone who has a better understanding of the guts of gstreamer
and esply how gst-launch works could comment here. IMHO, it is
sub-optimal if gst-launch has to do any of these *more than once* for
the pipeline...
1. Parse the pipeline description
2. Create the pipeline, in-memory (unless OS is doing it, in a way --
s.a. by swapping due to low free-memory)
3. typefind
4. capability setting of src/sink pads
5. queue allocation/deallocation (i.e. changing queue-size, other than
just growing to the configured queue-lenght)

If any of those is happening when a pipeline is created
element-by-element and launched using gst-launch, we are better of
optimizing it in command-line.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Soeren Grunewald]

Hi All,

        I had a quite similar problem on a tegra2 based system. The cpu usage
was raising over the time, but also memory usage is growing. After about
5min of playback the cpu usage exceeds the capabilities of the cpu and
the stream starts to stuck.

        Using a similar manually created chain (see attached files) does not
show this behavior.

        I tried various gstreamer versions, to verify that the issue is not
caused by the omx components i us. But the behavior stays the same.
Manual chains work perfectly but using playbin(2) or decodebin(2) the
issue appears.

        In the end i used the manual chain, since my time was limited to work
on this.
--
Regards
Soeren


On 10/11/2011 12:27 PM, Icarus Alive wrote:

> 2011/10/11 Victor Manuel Jáquez Leal<[hidden email]>:
>> On Tue, Oct 11, 2011 at 11:06 AM, stuart68<[hidden email]>  wrote:
>>> Hi,
>>>
>>> Can anyone explain why when I change my pipeline to use playbin2 instead of
>>> souphttpsrc, decodebin, queue2, audioconvert, audioresample, alsasink that
>>> my CPU load is noticeably higher.
>>
>> Because playbin2, being constructed at run time depending of how the
>> streams are recognized, would adds more elements on the pipeline than
>> your predefined/optimized pipeline.
>>
>> You can dump a graph of the generated playbin2 pipeline:
>>
>> http://gstreamer.freedesktop.org/wiki/DumpingPipelineGraphs
>>
>> vmjl
>>
>>>
>>> For HD audio formats it is going from around 65% to a constant 99% when
>>> using playbin2.
>>>
>
> BTW, I was able to bring down the CPU utilization of my pipeline, down
> from around 60% to around 25-30% (single CPU in virtualized mode), by
> turning playbin2 into the minimal equivalent with discrete elements,
> however that led to audio/video sync issues. Playbin2 somehow manages
> to keep audio/video sync, but my own pipeline faces issues, when
> erratic network latencies are there (it is a streaming pipeline).
>
> Maybe, someone who has a better understanding of the guts of gstreamer
> and esply how gst-launch works could comment here. IMHO, it is
> sub-optimal if gst-launch has to do any of these *more than once* for
> the pipeline...
> 1. Parse the pipeline description
> 2. Create the pipeline, in-memory (unless OS is doing it, in a way --
> s.a. by swapping due to low free-memory)
> 3. typefind
> 4. capability setting of src/sink pads
> 5. queue allocation/deallocation (i.e. changing queue-size, other than
> just growing to the configured queue-lenght)
>
> If any of those is happening when a pipeline is created
> element-by-element and launched using gst-launch, we are better of
> optimizing it in command-line.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Stefan Sauer]

On 10/11/2011 12:27 PM, Icarus Alive wrote:

> 2011/10/11 Victor Manuel Jáquez Leal <[hidden email]>:
>> On Tue, Oct 11, 2011 at 11:06 AM, stuart68 <[hidden email]> wrote:
>>> Hi,
>>>
>>> Can anyone explain why when I change my pipeline to use playbin2 instead of
>>> souphttpsrc, decodebin, queue2, audioconvert, audioresample, alsasink that
>>> my CPU load is noticeably higher.
>> Because playbin2, being constructed at run time depending of how the
>> streams are recognized, would adds more elements on the pipeline than
>> your predefined/optimized pipeline.
>>
>> You can dump a graph of the generated playbin2 pipeline:
>>
>> http://gstreamer.freedesktop.org/wiki/DumpingPipelineGraphs
>>
>> vmjl
>>
>>> For HD audio formats it is going from around 65% to a constant 99% when
>>> using playbin2.
>>>
> BTW, I was able to bring down the CPU utilization of my pipeline, down
> from around 60% to around 25-30% (single CPU in virtualized mode), by
> turning playbin2 into the minimal equivalent with discrete elements,
> however that led to audio/video sync issues. Playbin2 somehow manages
> to keep audio/video sync, but my own pipeline faces issues, when
> erratic network latencies are there (it is a streaming pipeline).

You could also use the flags property and specify native-audio |
native-video to forcibly omit the raw-converters.

Stefan

> Maybe, someone who has a better understanding of the guts of gstreamer
> and esply how gst-launch works could comment here. IMHO, it is
> sub-optimal if gst-launch has to do any of these *more than once* for
> the pipeline...
> 1. Parse the pipeline description
> 2. Create the pipeline, in-memory (unless OS is doing it, in a way --
> s.a. by swapping due to low free-memory)
> 3. typefind
> 4. capability setting of src/sink pads
> 5. queue allocation/deallocation (i.e. changing queue-size, other than
> just growing to the configured queue-lenght)
>
> If any of those is happening when a pipeline is created
> element-by-element and launched using gst-launch, we are better of
> optimizing it in command-line.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[stuart68]

Hi

I added the following flags to help, but it was still not enough:

        g_object_set(G_OBJECT(playBin),
                        "buffer-size", 150000,
                        "flags", 0x02,
                        NULL);

This helps to reduce the memory being used, but there is nothing I have found that helps to reduce CPU load.

Stuart

[amirulsyahmi]

Try to play it using Hardware accleration

On Tue, Oct 11, 2011 at 9:17 PM, stuart68 <[hidden email]> wrote:

Hi

I added the following flags to help, but it was still not enough:

       g_object_set(G_OBJECT(playBin),
                       "buffer-size", 150000,
                       "flags", 0x02,
                       NULL);

This helps to reduce the memory being used, but there is nothing I have
found that helps to reduce CPU load.

Stuart

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-playbin2-causes-high-CPU-load-on-embedded-system-tp3893255p3894330.html

Sent from the GStreamer-devel mailing list archive at Nabble.com.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--
Yang Benar

Pekerja Separuh Masa,

Warung Pak Joko (Pecel ayam dan Ayam Penyet)

Relau, Bayan Lepas, Pulau Pinang

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Icarus Alive]

On Tue, Oct 11, 2011 at 6:23 PM, Stefan Sauer <[hidden email]> wrote:

> On 10/11/2011 12:27 PM, Icarus Alive wrote:
>> 2011/10/11 Victor Manuel Jáquez Leal <[hidden email]>:
>>> On Tue, Oct 11, 2011 at 11:06 AM, stuart68 <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> Can anyone explain why when I change my pipeline to use playbin2 instead of
>>>> souphttpsrc, decodebin, queue2, audioconvert, audioresample, alsasink that
>>>> my CPU load is noticeably higher.
>>> Because playbin2, being constructed at run time depending of how the
>>> streams are recognized, would adds more elements on the pipeline than
>>> your predefined/optimized pipeline.
>>>
>>> You can dump a graph of the generated playbin2 pipeline:
>>>
>>> http://gstreamer.freedesktop.org/wiki/DumpingPipelineGraphs
>>>
>>> vmjl
>>>
>>>> For HD audio formats it is going from around 65% to a constant 99% when
>>>> using playbin2.
>>>>
>> BTW, I was able to bring down the CPU utilization of my pipeline, down
>> from around 60% to around 25-30% (single CPU in virtualized mode), by
>> turning playbin2 into the minimal equivalent with discrete elements,
>> however that led to audio/video sync issues. Playbin2 somehow manages
>> to keep audio/video sync, but my own pipeline faces issues, when
>> erratic network latencies are there (it is a streaming pipeline).
> You could also use the flags property and specify native-audio |
> native-video to forcibly omit the raw-converters.

Already doing that. Remove all typefinds, and have minimap caps
matching, using native audio/video devices and most fundamental
converters.

>> Maybe, someone who has a better understanding of the guts of gstreamer
>> and esply how gst-launch works could comment here. IMHO, it is
>> sub-optimal if gst-launch has to do any of these *more than once* for
>> the pipeline...
>> 1. Parse the pipeline description
>> 2. Create the pipeline, in-memory (unless OS is doing it, in a way --
>> s.a. by swapping due to low free-memory)
>> 3. typefind
>> 4. capability setting of src/sink pads
>> 5. queue allocation/deallocation (i.e. changing queue-size, other than
>> just growing to the configured queue-lenght)
>>
>> If any of those is happening when a pipeline is created
>> element-by-element and launched using gst-launch, we are better of
>> optimizing it in command-line.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Icarus Alive]

On Tue, Oct 11, 2011 at 6:56 PM, M. Amirul Syahmi
<[hidden email]> wrote:
> Try to play it using Hardware accleration

That might help, assuming your system has HW-acceleration. Also, I've
found that some non-gst based apps (e.g. vlc) plays a media
file/stream lot more smoothly than a gst pipeline, without
HW-acceleration. Tested in a Virtualbox setup with HW acceleration
disabled in guestOS.

> On Tue, Oct 11, 2011 at 9:17 PM, stuart68 <[hidden email]> wrote:
>>
>> Hi
>>
>> I added the following flags to help, but it was still not enough:
>>
>>        g_object_set(G_OBJECT(playBin),
>>                        "buffer-size", 150000,
>>                        "flags", 0x02,
>>                        NULL);
>>
>> This helps to reduce the memory being used, but there is nothing I have
>> found that helps to reduce CPU load.
>>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[amirulsyahmi]

VLC play movie using hardware acceleration. You also can try to play it using Mplayer -va vaapi -vo vaapi.

On Wed, Oct 12, 2011 at 3:11 AM, Icarus Alive <[hidden email]> wrote:

On Tue, Oct 11, 2011 at 6:56 PM, M. Amirul Syahmi
<[hidden email]> wrote:
> Try to play it using Hardware accleration

That might help, assuming your system has HW-acceleration. Also, I've
found that some non-gst based apps (e.g. vlc) plays a media
file/stream lot more smoothly than a gst pipeline, without
HW-acceleration. Tested in a Virtualbox setup with HW acceleration
disabled in guestOS.

> On Tue, Oct 11, 2011 at 9:17 PM, stuart68 <[hidden email]> wrote:
>>
>> Hi
>>
>> I added the following flags to help, but it was still not enough:
>>
>>        g_object_set(G_OBJECT(playBin),
>>                        "buffer-size", 150000,
>>                        "flags", 0x02,
>>                        NULL);
>>
>> This helps to reduce the memory being used, but there is nothing I have
>> found that helps to reduce CPU load.
>>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--
Yang Benar

Pekerja Separuh Masa,

Warung Pak Joko (Pecel ayam dan Ayam Penyet)

Relau, Bayan Lepas, Pulau Pinang

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Edward Hervey]

Hi,

  Could you profile *where* the extra cpu usage is being consumed ? This
much overhead (2 times) is unusual.

  You can use "valgrind --tool=callgrind" for example (with
synchronization disabled on the sinks so as to not have the pipeline
have QoS kick in).

  Also, what audio/video sinks are being selected by playbin2 ? (you can
see it with gst-launch-0.10 -v playbin2 ....).

  What does your 'non-playbin' pipeline look like ?

  Finally ... the VM might also be introducing some side effects

On Wed, 2011-10-12 at 00:41 +0530, Icarus Alive wrote:

> On Tue, Oct 11, 2011 at 6:56 PM, M. Amirul Syahmi
> <[hidden email]> wrote:
> > Try to play it using Hardware accleration
>
> That might help, assuming your system has HW-acceleration. Also, I've
> found that some non-gst based apps (e.g. vlc) plays a media
> file/stream lot more smoothly than a gst pipeline, without
> HW-acceleration. Tested in a Virtualbox setup with HW acceleration
> disabled in guestOS.
>
> > On Tue, Oct 11, 2011 at 9:17 PM, stuart68 <[hidden email]> wrote:
> >>
> >> Hi
> >>
> >> I added the following flags to help, but it was still not enough:
> >>
> >>        g_object_set(G_OBJECT(playBin),
> >>                        "buffer-size", 150000,
> >>                        "flags", 0x02,
> >>                        NULL);
> >>
> >> This helps to reduce the memory being used, but there is nothing I have
> >> found that helps to reduce CPU load.
> >>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Icarus Alive]

On Wed, Oct 12, 2011 at 1:03 PM, Edward Hervey <[hidden email]> wrote:
>  Could you profile *where* the extra cpu usage is being consumed ? This
> much overhead (2 times) is unusual.

Thinking again (harder this time), those nos. were for a test I did
over 4-5 months back, and there is a chance of misreporting the exact
difference, as there were quite a few tests we did. However, the diff
was still significant (at least 10-20%).

>  You can use "valgrind --tool=callgrind" for example (with
> synchronization disabled on the sinks so as to not have the pipeline
> have QoS kick in).

Not sure how to disable sync on the sinks. Is it one of the properties ?

>  Also, what audio/video sinks are being selected by playbin2 ? (you can
> see it with gst-launch-0.10 -v playbin2 ....).
>
>  What does your 'non-playbin' pipeline look like ?

Will share the graph when I have access to the test-bed again.

>  Finally ... the VM might also be introducing some side effects

This is indeed what I'd suspected. Had tried to minimise use of host
machine, and apart from possibly a notepad being open and background
services, the VM was pretty much all that was running.

> On Wed, 2011-10-12 at 00:41 +0530, Icarus Alive wrote:
>> On Tue, Oct 11, 2011 at 6:56 PM, M. Amirul Syahmi
>> <[hidden email]> wrote:
>> > Try to play it using Hardware accleration
>>
>> That might help, assuming your system has HW-acceleration. Also, I've
>> found that some non-gst based apps (e.g. vlc) plays a media
>> file/stream lot more smoothly than a gst pipeline, without
>> HW-acceleration. Tested in a Virtualbox setup with HW acceleration
>> disabled in guestOS.
>>
>> > On Tue, Oct 11, 2011 at 9:17 PM, stuart68 <[hidden email]> wrote:
>> >>
>> >> Hi
>> >>
>> >> I added the following flags to help, but it was still not enough:
>> >>
>> >>        g_object_set(G_OBJECT(playBin),
>> >>                        "buffer-size", 150000,
>> >>                        "flags", 0x02,
>> >>                        NULL);
>> >>
>> >> This helps to reduce the memory being used, but there is nothing I have
>> >> found that helps to reduce CPU load.
>> >>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Edward Hervey]

Hi,

On Fri, 2011-10-14 at 08:56 +0530, Icarus Alive wrote:
> On Wed, Oct 12, 2011 at 1:03 PM, Edward Hervey <[hidden email]> wrote:
> >  Could you profile *where* the extra cpu usage is being consumed ? This
> > much overhead (2 times) is unusual.
>
> Thinking again (harder this time), those nos. were for a test I did
> over 4-5 months back, and there is a chance of misreporting the exact
> difference, as there were quite a few tests we did. However, the diff
> was still significant (at least 10-20%).

  It's getting a bit more acceptable though (reasons below). I'd expect
the overhead of using playbin2 over hardcoded pipelines to be in the low
single-digit percent overhead. That overhead would be due to having a
bit more elements/pads involved, but which should all be configured to
pass-through data when transformation/processing isn't required.

>
> >  You can use "valgrind --tool=callgrind" for example (with
> > synchronization disabled on the sinks so as to not have the pipeline
> > have QoS kick in).
>
> Not sure how to disable sync on the sinks. Is it one of the properties ?

  Yes, all sinks have a 'sync' property that you can set to False. With
playbin2 you can specify what audio/video sink you want along with
properties (pay attention to the quotes if setting properties on those).

  Ex : playbin2 uri=file://... audio-sink=fakesink
video-sink="xvimagesink sync=False"

>
> >  Also, what audio/video sinks are being selected by playbin2 ? (you can
> > see it with gst-launch-0.10 -v playbin2 ....).
> >
> >  What does your 'non-playbin' pipeline look like ?
>
> Will share the graph when I have access to the test-bed again.
>
> >  Finally ... the VM might also be introducing some side effects
>
> This is indeed what I'd suspected. Had tried to minimise use of host
> machine, and apart from possibly a notepad being open and background
> services, the VM was pretty much all that was running.

  My experience has generally been that developing in VMs is fine ...
until you start using synchronization and audio/video outputs.
  There's too many unknown kicking in (you're no longer doing 'pure' cpu
processing which is executed without any overhead, but using the VM's
guest 'devices' which translate/forward data and instructions between
your guest and host).
  The situation might have improved since...

>
> > On Wed, 2011-10-12 at 00:41 +0530, Icarus Alive wrote:
> >> On Tue, Oct 11, 2011 at 6:56 PM, M. Amirul Syahmi
> >> <[hidden email]> wrote:
> >> > Try to play it using Hardware accleration
> >>
> >> That might help, assuming your system has HW-acceleration. Also, I've
> >> found that some non-gst based apps (e.g. vlc) plays a media
> >> file/stream lot more smoothly than a gst pipeline, without
> >> HW-acceleration. Tested in a Virtualbox setup with HW acceleration
> >> disabled in guestOS.
> >>
> >> > On Tue, Oct 11, 2011 at 9:17 PM, stuart68 <[hidden email]> wrote:
> >> >>
> >> >> Hi
> >> >>
> >> >> I added the following flags to help, but it was still not enough:
> >> >>
> >> >>        g_object_set(G_OBJECT(playBin),
> >> >>                        "buffer-size", 150000,
> >> >>                        "flags", 0x02,
> >> >>                        NULL);
> >> >>
> >> >> This helps to reduce the memory being used, but there is nothing I have
> >> >> found that helps to reduce CPU load.
> >> >>
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> [hidden email]
> >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[stuart68]

Going back to the flags used by playbin2 I now have:

flags=0x122               // I decode audio only

As suggested in an earlier post by stopping playbin2 doing the audioconvert and audioresample the CPU load is now directly comparable to that of the manually configured pipeline.

The flags that made the big difference are:

GST_PLAY_FLAG_NATIVE_AUDIO
GST_PLAY_FLAG_NATIVE_VIDEO

I still have issues with audio formats of 24bit\88.2khz and above. These are not played back gaplessly.

My audio sink is external to playbin2 and sync is set to false.

Stuart

[Stefan Sauer]

On 10/18/2011 03:35 AM, stuart68 wrote:

> Going back to the flags used by playbin2 I now have:
>
> flags=0x122               // I decode audio only
>
> As suggested in an earlier post by stopping playbin2 doing the audioconvert
> and audioresample the CPU load is now directly comparable to that of the
> manually configured pipeline.
>
> The flags that made the big difference are:
>
> GST_PLAY_FLAG_NATIVE_AUDIO
> GST_PLAY_FLAG_NATIVE_VIDEO
>
> I still have issues with audio formats of 24bit\88.2khz and above. These are
> not played back gaplessly.

Which file format do they use?

Stefan

> My audio sink is external to playbin2 and sync is set to false.
>
> Stuart
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-playbin2-causes-high-CPU-load-on-embedded-system-tp3893255p3914011.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel