Menu
▾
▴
gstreamer-embedded — GStreamer on embedded platforms
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(21) |
Mar
(30) |
Apr
(17) |
May
(2) |
Jun
(30) |
Jul
(22) |
Aug
(39) |
Sep
(42) |
Oct
(30) |
Nov
(42) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(31) |
Feb
(44) |
Mar
(33) |
Apr
(26) |
May
(15) |
Jun
(28) |
Jul
(15) |
Aug
(15) |
Sep
|
Oct
(34) |
Nov
(21) |
Dec
(36) |
| 2010 |
Jan
(53) |
Feb
(31) |
Mar
(30) |
Apr
(14) |
May
(12) |
Jun
(6) |
Jul
(5) |
Aug
(9) |
Sep
(10) |
Oct
(3) |
Nov
(1) |
Dec
(16) |
| 2011 |
Jan
(6) |
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: gulshan k. <gul...@gm...> - 2008-08-07 03:08:32
|
Hi All,
I have some questions regarding Gstreamer Based Demuxers used
inside poky for media playback,
1. While using 'avidemux' as a demuxer plugin we get continuous
'Alignment Traps'
which is affecting the audio quality. We have a cmdline option to tell
the kernel to fix these traps and suppress the warning but this could
be just a workaround.
Is this alignment trap caused by demuxer ? Or we need to take care of something
in lower layers ?
Instead of avidemux if we use 'ffdemux_avi' we do not get these traps.
[We use Gst-omx decoders below which are calling ffmpeg for decoding,
ffmpeg has been hardware accelerated].
2. Which are the Stand-alone Aac and mp3 demuxers inside Gstreamer to be used ?
We are trying to use ffdemux_mp3 for mp3 and getting some package
building issues.
While for Aac we tried gst faad but this is being identified as Aac
decoder along with parser. Could we not use this plugin just as a
demuxer ?
Following chains are working for AAC :
"gst-launch filesrc
location=/media/sdmmc0p1/streams/bass47_1_ADTS_LTP.aac ! faad !
alsasink"
"gst-launch omx_filereadersrc
file-name=/media/sdmmc0p1/streams/AAC_TestStreams/al09_44.aac !
omx_aacdec ! omx_audiosink"
While the ones which we want to use and not working are :
"gst-launch filesrc
location=/media/sdmmc0p1/streams/bass47_1_ADTS_LTP.aac ! omx_aacdec !
alsasink"
"gst-launch omx_filereadersrc
file-name=/media/sdmmc0p1/streams/AAC_TestStreams/al09_44.aac !
omx_aacdec ! alsasink"
Thanks for any quick suggestions in this regard.
Best Regards,
Gulshan Karmani
|
|
From: Raj S. <raj...@gm...> - 2008-08-04 21:59:49
|
Thanks for all your help everyone. I have a faint idea of what i need to do based off ur hints .... ill work on it and will keep u posted ... On Sun, Aug 3, 2008 at 8:19 PM, Zhao Liang-E3423C <E3...@mo...>wrote: > so what's the rootcause of stutter? Is it caused by data drop or playing > unsmoothly by audio driver? > > From your test on OSSink, it seems decoder is slower than playback, > and gstaudiosink drop data and always output zero data. I think you need > open some logs (such as ossink) to get accurate information, and find the > rootcause. > > Zhao Liang > ------------------------------ > *From:* gst...@li... [mailto: > gst...@li...] *On Behalf Of *Dennis > Fleming > *Sent:* Saturday, August 02, 2008 4:19 AM > *To:* gst...@li... > *Subject:* Re: [gst-embedded] noise and stuttering > > It's interesting that I am getting the opposite problem. Ie. stutters > for wav and not for MP3. It looks like we were optimizing internal buffers > for 44.1 kHz. However, 22.05kHz had problems with buffer-time=10000 and > latency-time=100. Going back to the defaults 220xkHz worked but 44.1 was > sensitive to activity on the system. I'll try the sync fix to see what > happens on my device. > > Dennis > > ----- Original Message ---- > From: Jan Schmidt <th...@no...> > To: Raj Swaminathan <raj...@gm...> > Cc: gst...@li... > Sent: Friday, August 1, 2008 12:08:27 PM > Subject: Re: [gst-embedded] noise and stuttering > > > On Fri, 2008-08-01 at 13:51 -0500, Raj Swaminathan wrote: > > > > Can u also explain why the async fix helped ? > > It helps because it deactivates the clock-synching in the audiosink, > which means that the file plays at the speed it manages to read, decode > and output the samples -> that's slower than real-time in this case, > which is why you're getting 'stuttering'. > > Measure how long the file takes to play with 'time' compared to the > duration of the file. > > J. > > > > > On Fri, Aug 1, 2008 at 1:23 PM, Raj Swaminathan <raj...@gm...> > > wrote: > > > > Hey Dan, > > > > That worked ... its stuttering .. but keeps playing .... > > thanks a ton ! > > > > osssink: wav file play fine > > mp3 files, http links stutter but output sound > > when buffer-time=1000 latency-time=100 sync=false > > > > > > Is there any such fix for esdsink ?? > > Are there more properties that can be modified to stop the > > stuttering ?? > > > > regards, > > raj > > > > > > > > > > On Fri, Aug 1, 2008 at 12:52 PM, Daniel Charles > > <dch...@gm...> wrote: > > Hi Raj, > > > > Have you tried sync=false in the osssink? I'm not > > sure that this is > > within your purposes but in some cases that removes > > the glitches. > > > > Daniel. > > > > > > On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan > > <raj...@gm...> wrote: > > > > > > Hi everyone, > > > > > > Im having stuttering and stopping issues with > > gstreamer on the OMAP 2430... > > > I am using an NFS mounted file system via > > ethernet ... > > > > > > osssink: WAV files play without an issue. > > > mp3 files output sound and stop after > > a few seconds if i set > > > buffer-time=1000 and latency-time=100 > > > mp3 files do not output sound without > > the settings above. > > > streaming music from http links do not > > work under any > > > setting. > > > > > > esdsink: WAV files do not play. > > > mp3 files play nicely. > > > streaming music from http links output > > sound and stop after a > > > few seconds. > > > > > > My sources: filesrc, souphttpsrc > > > My decoders: wavparse, mad > > > > > > Ive experimented with placing queues before decoding > > and before sending > > > audio to the sink. Trying both ways or either/or, do > > not impact the output > > > signifcantly. > > > Can anyone provide some suggestions? > > > > > > Thanks for your help so far. > > > > > > regards, > > > raj > > > > > > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt > > <th...@no...> wrote: > > >> > > >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming > > wrote: > > >> > First off: Thank to you and Zhoa-Lang for getting > > back so quickly. > > >> > I'm so busy I forgot my manners. > > >> > > > >> > Testing to find the parameters I have I used > > decodebin, but in the > > >> > program itself uses playbin with the same effect. > > The only variation > > >> > is that I set the sink property to alsasink since > > that seems the only > > >> > way to set buffer-time and latency-time > > properties. Also, it seems > > >> > counter-intuitive to me that an uncompressed WAV > > file should have > > >> > problems keeping up while MP3s with the same > > sampling frequency and > > >> > word size have none. And yet the artifacts are > > indicative of dropped > > >> > buffers. > > >> > > >> If the bottleneck is retrieving data from the input > > location, then it's > > >> entirely feasible. What's your data store? SD card, > > NFS? A WAV file > > >> might be 10 or more times more data to read and > > cause read stalls, where > > >> the smaller mp3 can be read in fine and decoded in > > memory with no > > >> further problems. > > >> > > >> J. > > >> > > >> > Dennis > > >> > > > >> > > > >> > ----- Original Message ---- > > >> > From: Thijs Vermeir <thi...@gm...> > > >> > To: Dennis Fleming <ars...@sb...> > > >> > Cc: gst...@li... > > >> > Sent: Tuesday, July 29, 2008 3:59:30 PM > > >> > Subject: Re: [gst-embedded] noise and stuttering > > >> > > > >> > Hi, > > >> > > > >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming > > >> > <ars...@sb...> wrote: > > >> > > The interesting thing is that uncompressed WAV > > files are causing the > > >> > problem > > >> > > while MP3s were fixed by setting the > > buffer-time and latency-time to > > >> > values > > >> > > smaller than found on a desktop. What would > > adding a queue do to > > >> > latency > > >> > > through the system? > > >> > > > >> > There is no latency in this case because there > > are no live-sources. > > >> > [1] > > >> > > > >> > > Also, I suppose, that I will need to break up > > the > > >> > > playbin and create a pipeline myself, yes? > > >> > > > >> > playbin has the queue elements on the correct > > location, no changes > > >> > needed. > > >> > You where already using a custom pipeline, no? > > >> > > > >> > Gr, > > >> > > > >> > [1] > > >> > > > >> > > > > http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup > > >> > > > >> > > > > >> > > Dennis > > >> > > > > >> > > ----- Original Message ---- > > >> > > From: Thijs Vermeir <thi...@gm...> > > >> > > To: Zhao Liang-E3423C <E3...@mo...> > > >> > > Cc: Dennis Fleming <ars...@sb...>; > > >> > > gst...@li... > > >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM > > >> > > Subject: Re: [gst-embedded] noise and > > stuttering > > >> > > > > >> > > Hi, > > >> > > > > >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao > > Liang-E3423C > > >> > <E3...@mo...> > > >> > > wrote: > > >> > >> What's the rootcause of noise and stuttering ? > > >> > > > > >> > > Now you are using only 1 thread for all the > > elements and if the > > >> > > filesrc or the decoder is too slow sometimes > > >> > > you don't have time to catch up. By adding the > > queue you put the > > >> > sink > > >> > > in another thread and now the filesrc+decoder > > can > > >> > > do some decoding in advance. > > >> > > > > >> > > Gr, > > >> > > Thijs > > >> > > > > >> > >> > > >> > >> For normal playback, it should not have > > issues. If decoder didn't > > >> > drop > > >> > >> data, I think alsasink did it. > > >> > >> By gstaudiosink mechanism, it will drop data > > replaced with blank > > >> > data when > > >> > >> data is late. I guess the rootcause is that. > > >> > >> > > >> > >> If that, I have no ideas except adding a queue > > before alsasink, and > > >> > when > > >> > >> queue is empty, pause the pipeline, it will > > not cause dropout, but > > >> > still > > >> > >> discontinous. > > >> > >> > > >> > >> Zhao liang > > >> > >> ________________________________ > > >> > >> From: > > gst...@li... > > >> > >> > > [mailto:gst...@li...] > On Behalf > > >> > Of > > >> > >> Dennis Fleming > > >> > >> Sent: Tuesday, July 29, 2008 4:37 AM > > >> > >> To: gst...@li... > > >> > >> Subject: [gst-embedded] noise and stuttering > > >> > >> > > >> > >> I'm trying to create an audio player on an > > IMX31 target and I've > > >> > found a > > >> > >> discrepancy in the output of various formats. > > If I send MP3 data I > > >> > have > > >> > >> to > > >> > >> set the buffer-time and latency-time to 10000 > > and 100 respectively > > >> > to play > > >> > >> without severe dropouts. However WAV files > > still have drop-out at > > >> > a > > >> > >> consistent rate (about 1 per 10 sec). Are > > there some general > > >> > features I'm > > >> > >> missing or is there some guidance on the > > buffer-time/latency time > > >> > that > > >> > >> would > > >> > >> account for this difference? > > >> > >> > > >> > >> Linux 2.6.22.19 > > >> > >> gstreamer 0.10.17 (open-embedded) > > >> > >> gst-launch filesrc location=<file> ! > > decodebin ! alsasink > > >> > >> buffer-time=10000 > > >> > >> latency-time=100 > > >> > >> > > >> > >> Dennis > > >> > >> > > >> > >> > > >> > > > >> > > > > ------------------------------------------------------------------------- > > >> > >> This SF.Net email is sponsored by the Moblin > > Your Move Developer's > > >> > >> challenge > > >> > >> Build the coolest Linux based applications > > with Moblin SDK & win > > >> > great > > >> > >> prizes > > >> > >> Grand prize is a trip for two to an Open > > Source event anywhere in > > >> > the > > >> > >> world > > >> > >> > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > >> > >> > > _______________________________________________ > > >> > >> Gstreamer-embedded mailing list > > >> > >> Gst...@li... > > >> > >> > > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > >> > >> > > >> > >> > > >> > > > > >> > > > >> > > > >> > > > > ------------------------------------------------------------------------- > > >> > This SF.Net email is sponsored by the Moblin Your > > Move Developer's > > >> > challenge > > >> > Build the coolest Linux based applications with > > Moblin SDK & win great > > >> > prizes > > >> > Grand prize is a trip for two to an Open Source > > event anywhere in the > > >> > world > > >> > > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > >> > _______________________________________________ > > Gstreamer-embedded > > >> > mailing list > > Gst...@li... > > >> > > > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > >> -- > > >> Jan Schmidt <th...@no...> > > >> > > >> > > >> > > > ------------------------------------------------------------------------- > > >> This SF.Net email is sponsored by the Moblin Your > > Move Developer's > > >> challenge > > >> Build the coolest Linux based applications with > > Moblin SDK & win great > > >> prizes > > >> Grand prize is a trip for two to an Open Source > > event anywhere in the > > >> world > > >> > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > >> _______________________________________________ > > >> Gstreamer-embedded mailing list > > >> Gst...@li... > > >> > > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.Net email is sponsored by the Moblin Your > > Move Developer's challenge > > > Build the coolest Linux based applications with > > Moblin SDK & win great > > > prizes > > > Grand prize is a trip for two to an Open Source > > event anywhere in the world > > > > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > _______________________________________________ > > > Gstreamer-embedded mailing list > > > Gst...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ Gstreamer-embedded > mailing list Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > -- > Jan Schmidt <th...@no...> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gstreamer-embedded mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gstreamer-embedded mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > |
|
From: Nie J. <nie...@gm...> - 2008-08-04 02:18:04
|
Dear All,
I am in trouble when we upgrade Linux kernel from 2.6.24 to
2.6.25. It seems that synchronization causes noise when using ALSA as
sink. Moreover, only 44.1K and 48K audio sampling rate has this issue,
22K, 24K, 32K is trouble free. I test osssink, it has not this
problem.
I'm using XSCALE platform with CPU fixed in 624MHz, so resource
should not be the root cause. The following are my experiment:
gst-launch filesrc location=$STR ! qtdemux name=t ! queue ! aacdec ! alsasink
No noise, duration is OK.
gst-launch filesrc location=$STR ! qtdemux name=t ! queue ! aacdec !
alsasink t. ! queue ! h264dec ! overlay2sink
With this command, noise is on, duration is shorter than it should be,
video is 35fps while it should be 30fps. I dump the PCM data to file
when ALSA write API is called, all the data is same with decoder
output.
gst-launch filesrc location=$STR ! qtdemux name=t ! queue ! aacdec !
alsasink t. ! queue ! fakesink sync=1
Noise is on, even video part is dropped.
gst-launch filesrc location=$STR ! qtdemux name=t ! queue ! aacdec !
alsasink t. ! queue ! fakesink sync=0
No noise, duration is OK.
Any idea is welcome, Thanks!
|
|
From: Zhao Liang-E. <E3...@mo...> - 2008-08-04 01:18:59
|
so what's the rootcause of stutter? Is it caused by data drop or playing unsmoothly by audio driver? From your test on OSSink, it seems decoder is slower than playback, and gstaudiosink drop data and always output zero data. I think you need open some logs (such as ossink) to get accurate information, and find the rootcause. Zhao Liang ________________________________ From: gst...@li... [mailto:gst...@li...] On Behalf Of Dennis Fleming Sent: Saturday, August 02, 2008 4:19 AM To: gst...@li... Subject: Re: [gst-embedded] noise and stuttering It's interesting that I am getting the opposite problem. Ie. stutters for wav and not for MP3. It looks like we were optimizing internal buffers for 44.1 kHz. However, 22.05kHz had problems with buffer-time=10000 and latency-time=100. Going back to the defaults 220xkHz worked but 44.1 was sensitive to activity on the system. I'll try the sync fix to see what happens on my device. Dennis ----- Original Message ---- From: Jan Schmidt <th...@no...> To: Raj Swaminathan <raj...@gm...> Cc: gst...@li... Sent: Friday, August 1, 2008 12:08:27 PM Subject: Re: [gst-embedded] noise and stuttering On Fri, 2008-08-01 at 13:51 -0500, Raj Swaminathan wrote: > > Can u also explain why the async fix helped ? It helps because it deactivates the clock-synching in the audiosink, which means that the file plays at the speed it manages to read, decode and output the samples -> that's slower than real-time in this case, which is why you're getting 'stuttering'. Measure how long the file takes to play with 'time' compared to the duration of the file. J. > > On Fri, Aug 1, 2008 at 1:23 PM, Raj Swaminathan <raj...@gm...> > wrote: > > Hey Dan, > > That worked ... its stuttering .. but keeps playing .... > thanks a ton ! > > osssink: wav file play fine > mp3 files, http links stutter but output sound > when buffer-time=1000 latency-time=100 sync=false > > > Is there any such fix for esdsink ?? > Are there more properties that can be modified to stop the > stuttering ?? > > regards, > raj > > > > > On Fri, Aug 1, 2008 at 12:52 PM, Daniel Charles > <dch...@gm...> wrote: > Hi Raj, > > Have you tried sync=false in the osssink? I'm not > sure that this is > within your purposes but in some cases that removes > the glitches. > > Daniel. > > > On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan > <raj...@gm...> wrote: > > > > Hi everyone, > > > > Im having stuttering and stopping issues with > gstreamer on the OMAP 2430... > > I am using an NFS mounted file system via > ethernet ... > > > > osssink: WAV files play without an issue. > > mp3 files output sound and stop after > a few seconds if i set > > buffer-time=1000 and latency-time=100 > > mp3 files do not output sound without > the settings above. > > streaming music from http links do not > work under any > > setting. > > > > esdsink: WAV files do not play. > > mp3 files play nicely. > > streaming music from http links output > sound and stop after a > > few seconds. > > > > My sources: filesrc, souphttpsrc > > My decoders: wavparse, mad > > > > Ive experimented with placing queues before decoding > and before sending > > audio to the sink. Trying both ways or either/or, do > not impact the output > > signifcantly. > > Can anyone provide some suggestions? > > > > Thanks for your help so far. > > > > regards, > > raj > > > > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt > <th...@no...> wrote: > >> > >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming > wrote: > >> > First off: Thank to you and Zhoa-Lang for getting > back so quickly. > >> > I'm so busy I forgot my manners. > >> > > >> > Testing to find the parameters I have I used > decodebin, but in the > >> > program itself uses playbin with the same effect. > The only variation > >> > is that I set the sink property to alsasink since > that seems the only > >> > way to set buffer-time and latency-time > properties. Also, it seems > >> > counter-intuitive to me that an uncompressed WAV > file should have > >> > problems keeping up while MP3s with the same > sampling frequency and > >> > word size have none. And yet the artifacts are > indicative of dropped > >> > buffers. > >> > >> If the bottleneck is retrieving data from the input > location, then it's > >> entirely feasible. What's your data store? SD card, > NFS? A WAV file > >> might be 10 or more times more data to read and > cause read stalls, where > >> the smaller mp3 can be read in fine and decoded in > memory with no > >> further problems. > >> > >> J. > >> > >> > Dennis > >> > > >> > > >> > ----- Original Message ---- > >> > From: Thijs Vermeir <thi...@gm...> > >> > To: Dennis Fleming <ars...@sb...> > >> > Cc: gst...@li... > >> > Sent: Tuesday, July 29, 2008 3:59:30 PM > >> > Subject: Re: [gst-embedded] noise and stuttering > >> > > >> > Hi, > >> > > >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming > >> > <ars...@sb...> wrote: > >> > > The interesting thing is that uncompressed WAV > files are causing the > >> > problem > >> > > while MP3s were fixed by setting the > buffer-time and latency-time to > >> > values > >> > > smaller than found on a desktop. What would > adding a queue do to > >> > latency > >> > > through the system? > >> > > >> > There is no latency in this case because there > are no live-sources. > >> > [1] > >> > > >> > > Also, I suppose, that I will need to break up > the > >> > > playbin and create a pipeline myself, yes? > >> > > >> > playbin has the queue elements on the correct > location, no changes > >> > needed. > >> > You where already using a custom pipeline, no? > >> > > >> > Gr, > >> > > >> > [1] > >> > > >> > > http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup > >> > > >> > > > >> > > Dennis > >> > > > >> > > ----- Original Message ---- > >> > > From: Thijs Vermeir <thi...@gm...> > >> > > To: Zhao Liang-E3423C <E3...@mo...> > >> > > Cc: Dennis Fleming <ars...@sb...>; > >> > > gst...@li... > >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM > >> > > Subject: Re: [gst-embedded] noise and > stuttering > >> > > > >> > > Hi, > >> > > > >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao > Liang-E3423C > >> > <E3...@mo...> > >> > > wrote: > >> > >> What's the rootcause of noise and stuttering ? > >> > > > >> > > Now you are using only 1 thread for all the > elements and if the > >> > > filesrc or the decoder is too slow sometimes > >> > > you don't have time to catch up. By adding the > queue you put the > >> > sink > >> > > in another thread and now the filesrc+decoder > can > >> > > do some decoding in advance. > >> > > > >> > > Gr, > >> > > Thijs > >> > > > >> > >> > >> > >> For normal playback, it should not have > issues. If decoder didn't > >> > drop > >> > >> data, I think alsasink did it. > >> > >> By gstaudiosink mechanism, it will drop data > replaced with blank > >> > data when > >> > >> data is late. I guess the rootcause is that. > >> > >> > >> > >> If that, I have no ideas except adding a queue > before alsasink, and > >> > when > >> > >> queue is empty, pause the pipeline, it will > not cause dropout, but > >> > still > >> > >> discontinous. > >> > >> > >> > >> Zhao liang > >> > >> ________________________________ > >> > >> From: > gst...@li... > >> > >> > [mailto:gst...@li...] On Behalf > >> > Of > >> > >> Dennis Fleming > >> > >> Sent: Tuesday, July 29, 2008 4:37 AM > >> > >> To: gst...@li... > >> > >> Subject: [gst-embedded] noise and stuttering > >> > >> > >> > >> I'm trying to create an audio player on an > IMX31 target and I've > >> > found a > >> > >> discrepancy in the output of various formats. > If I send MP3 data I > >> > have > >> > >> to > >> > >> set the buffer-time and latency-time to 10000 > and 100 respectively > >> > to play > >> > >> without severe dropouts. However WAV files > still have drop-out at > >> > a > >> > >> consistent rate (about 1 per 10 sec). Are > there some general > >> > features I'm > >> > >> missing or is there some guidance on the > buffer-time/latency time > >> > that > >> > >> would > >> > >> account for this difference? > >> > >> > >> > >> Linux 2.6.22.19 > >> > >> gstreamer 0.10.17 (open-embedded) > >> > >> gst-launch filesrc location=<file> ! > decodebin ! alsasink > >> > >> buffer-time=10000 > >> > >> latency-time=100 > >> > >> > >> > >> Dennis > >> > >> > >> > >> > >> > > >> > > ------------------------------------------------------------------------- > >> > >> This SF.Net email is sponsored by the Moblin > Your Move Developer's > >> > >> challenge > >> > >> Build the coolest Linux based applications > with Moblin SDK & win > >> > great > >> > >> prizes > >> > >> Grand prize is a trip for two to an Open > Source event anywhere in > >> > the > >> > >> world > >> > >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> > >> > _______________________________________________ > >> > >> Gstreamer-embedded mailing list > >> > >> Gst...@li... > >> > >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > >> > >> > >> > >> > >> > > > >> > > >> > > >> > > ------------------------------------------------------------------------- > >> > This SF.Net email is sponsored by the Moblin Your > Move Developer's > >> > challenge > >> > Build the coolest Linux based applications with > Moblin SDK & win great > >> > prizes > >> > Grand prize is a trip for two to an Open Source > event anywhere in the > >> > world > >> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> > _______________________________________________ > Gstreamer-embedded > >> > mailing list > Gst...@li... > >> > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > >> -- > >> Jan Schmidt <th...@no...> > >> > >> > >> > ------------------------------------------------------------------------- > >> This SF.Net email is sponsored by the Moblin Your > Move Developer's > >> challenge > >> Build the coolest Linux based applications with > Moblin SDK & win great > >> prizes > >> Grand prize is a trip for two to an Open Source > event anywhere in the > >> world > >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> _______________________________________________ > >> Gstreamer-embedded mailing list > >> Gst...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your > Move Developer's challenge > > Build the coolest Linux based applications with > Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source > event anywhere in the world > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Gstreamer-embedded mailing list > > Gst...@li... > > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded -- Jan Schmidt <th...@no...> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded |
|
From: Felipe C. <fel...@gm...> - 2008-08-03 09:31:46
|
On Sun, Aug 3, 2008 at 11:05 AM, Ling Shi <sh...@gm...> wrote: > Felipe & Bruno, > Thanks, > > TBD, which OMX do you used in test, Bellgio or your companies own OMX? In Nokia we have been testing with TI components, Bellagio components, and some experimental components developed with Bellagio base clases. -- Felipe Contreras |
|
From: Ling S. <sh...@gm...> - 2008-08-03 08:05:37
|
Felipe & Bruno, Thanks, TBD, which OMX do you used in test, Bellgio or your companies own OMX? On Fri, Aug 1, 2008 at 4:03 AM, Felipe Contreras <fel...@gm... > wrote: > Hi, > > On Thu, Jul 31, 2008 at 1:22 PM, Bruno Smets <bru...@nx...> wrote: > > Hi, > > > > Felipe is itegrating the changes ... you need to set up GIT and clone > > > > git://github.com/felipec/gst-openmax.git > > I've finally managed to clean this up. > > The branch is tunneling-v3: > http://github.com/felipec/gst-openmax/commits/tuneling-v3 > > This is not the final version, but it's near it. > > Best regards. > > -- > Felipe Contreras > |
|
From: Ling S. <sh...@gm...> - 2008-08-03 07:47:14
|
Usually, there are two reason to cause shutters in playback.
1) The decoder/demux cannot generate data in time. If the frame is delayed,
the ringbuffer in sink will drop it. To track it, you can add some long in
gstringbuffer.c to monitor "skip".
gst_ring_buffer_commit_full()
{
......
/* segment too far ahead, writer too slow, we need to drop, hopefully
UNLIKELY */
if (G_UNLIKELY (diff < 0)) {
/* we need to drop one segment at a time, pretend we wrote a
* segment. */
skip = TRUE;
break;
}
......
}
If the ringbuffer drop the frame, please check you decoder/demux's speed
firstly.
2) the audio device's buffer is not configure correctly. Of cause, you are
debugging it.
On Sat, Aug 2, 2008 at 4:19 AM, Dennis Fleming <ars...@sb...>wrote:
> It's interesting that I am getting the opposite problem. Ie. stutters for
> wav and not for MP3. It looks like we were optimizing internal buffers for
> 44.1 kHz. However, 22.05kHz had problems with buffer-time=10000 and
> latency-time=100. Going back to the defaults 220xkHz worked but 44.1 was
> sensitive to activity on the system. I'll try the sync fix to see what
> happens on my device.
>
> Dennis
>
> ----- Original Message ----
> From: Jan Schmidt <th...@no...>
> To: Raj Swaminathan <raj...@gm...>
> Cc: gst...@li...
> Sent: Friday, August 1, 2008 12:08:27 PM
> Subject: Re: [gst-embedded] noise and stuttering
>
>
> On Fri, 2008-08-01 at 13:51 -0500, Raj Swaminathan wrote:
> >
> > Can u also explain why the async fix helped ?
>
> It helps because it deactivates the clock-synching in the audiosink,
> which means that the file plays at the speed it manages to read, decode
> and output the samples -> that's slower than real-time in this case,
> which is why you're getting 'stuttering'.
>
> Measure how long the file takes to play with 'time' compared to the
> duration of the file.
>
> J.
>
> >
> > On Fri, Aug 1, 2008 at 1:23 PM, Raj Swaminathan <raj...@gm...>
> > wrote:
> >
> > Hey Dan,
> >
> > That worked ... its stuttering .. but keeps playing ....
> > thanks a ton !
> >
> > osssink: wav file play fine
> > mp3 files, http links stutter but output sound
> > when buffer-time=1000 latency-time=100 sync=false
> >
> >
> > Is there any such fix for esdsink ??
> > Are there more properties that can be modified to stop the
> > stuttering ??
> >
> > regards,
> > raj
> >
> >
> >
> >
> > On Fri, Aug 1, 2008 at 12:52 PM, Daniel Charles
> > <dch...@gm...> wrote:
> > Hi Raj,
> >
> > Have you tried sync=false in the osssink? I'm not
> > sure that this is
> > within your purposes but in some cases that removes
> > the glitches.
> >
> > Daniel.
> >
> >
> > On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan
> > <raj...@gm...> wrote:
> > >
> > > Hi everyone,
> > >
> > > Im having stuttering and stopping issues with
> > gstreamer on the OMAP 2430...
> > > I am using an NFS mounted file system via
> > ethernet ...
> > >
> > > osssink: WAV files play without an issue.
> > > mp3 files output sound and stop after
> > a few seconds if i set
> > > buffer-time=1000 and latency-time=100
> > > mp3 files do not output sound without
> > the settings above.
> > > streaming music from http links do not
> > work under any
> > > setting.
> > >
> > > esdsink: WAV files do not play.
> > > mp3 files play nicely.
> > > streaming music from http links output
> > sound and stop after a
> > > few seconds.
> > >
> > > My sources: filesrc, souphttpsrc
> > > My decoders: wavparse, mad
> > >
> > > Ive experimented with placing queues before decoding
> > and before sending
> > > audio to the sink. Trying both ways or either/or, do
> > not impact the output
> > > signifcantly.
> > > Can anyone provide some suggestions?
> > >
> > > Thanks for your help so far.
> > >
> > > regards,
> > > raj
> > >
> > > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt
> > <th...@no...> wrote:
> > >>
> > >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming
> > wrote:
> > >> > First off: Thank to you and Zhoa-Lang for getting
> > back so quickly.
> > >> > I'm so busy I forgot my manners.
> > >> >
> > >> > Testing to find the parameters I have I used
> > decodebin, but in the
> > >> > program itself uses playbin with the same effect.
> > The only variation
> > >> > is that I set the sink property to alsasink since
> > that seems the only
> > >> > way to set buffer-time and latency-time
> > properties. Also, it seems
> > >> > counter-intuitive to me that an uncompressed WAV
> > file should have
> > >> > problems keeping up while MP3s with the same
> > sampling frequency and
> > >> > word size have none. And yet the artifacts are
> > indicative of dropped
> > >> > buffers.
> > >>
> > >> If the bottleneck is retrieving data from the input
> > location, then it's
> > >> entirely feasible. What's your data store? SD card,
> > NFS? A WAV file
> > >> might be 10 or more times more data to read and
> > cause read stalls, where
> > >> the smaller mp3 can be read in fine and decoded in
> > memory with no
> > >> further problems.
> > >>
> > >> J.
> > >>
> > >> > Dennis
> > >> >
> > >> >
> > >> > ----- Original Message ----
> > >> > From: Thijs Vermeir <thi...@gm...>
> > >> > To: Dennis Fleming <ars...@sb...>
> > >> > Cc: gst...@li...
> > >> > Sent: Tuesday, July 29, 2008 3:59:30 PM
> > >> > Subject: Re: [gst-embedded] noise and stuttering
> > >> >
> > >> > Hi,
> > >> >
> > >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming
> > >> > <ars...@sb...> wrote:
> > >> > > The interesting thing is that uncompressed WAV
> > files are causing the
> > >> > problem
> > >> > > while MP3s were fixed by setting the
> > buffer-time and latency-time to
> > >> > values
> > >> > > smaller than found on a desktop. What would
> > adding a queue do to
> > >> > latency
> > >> > > through the system?
> > >> >
> > >> > There is no latency in this case because there
> > are no live-sources.
> > >> > [1]
> > >> >
> > >> > > Also, I suppose, that I will need to break up
> > the
> > >> > > playbin and create a pipeline myself, yes?
> > >> >
> > >> > playbin has the queue elements on the correct
> > location, no changes
> > >> > needed.
> > >> > You where already using a custom pipeline, no?
> > >> >
> > >> > Gr,
> > >> >
> > >> > [1]
> > >> >
> > >> >
> >
> http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup
> > >> >
> > >> > >
> > >> > > Dennis
> > >> > >
> > >> > > ----- Original Message ----
> > >> > > From: Thijs Vermeir <thi...@gm...>
> > >> > > To: Zhao Liang-E3423C <E3...@mo...>
> > >> > > Cc: Dennis Fleming <ars...@sb...>;
> > >> > > gst...@li...
> > >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM
> > >> > > Subject: Re: [gst-embedded] noise and
> > stuttering
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao
> > Liang-E3423C
> > >> > <E3...@mo...>
> > >> > > wrote:
> > >> > >> What's the rootcause of noise and stuttering ?
> > >> > >
> > >> > > Now you are using only 1 thread for all the
> > elements and if the
> > >> > > filesrc or the decoder is too slow sometimes
> > >> > > you don't have time to catch up. By adding the
> > queue you put the
> > >> > sink
> > >> > > in another thread and now the filesrc+decoder
> > can
> > >> > > do some decoding in advance.
> > >> > >
> > >> > > Gr,
> > >> > > Thijs
> > >> > >
> > >> > >>
> > >> > >> For normal playback, it should not have
> > issues. If decoder didn't
> > >> > drop
> > >> > >> data, I think alsasink did it.
> > >> > >> By gstaudiosink mechanism, it will drop data
> > replaced with blank
> > >> > data when
> > >> > >> data is late. I guess the rootcause is that.
> > >> > >>
> > >> > >> If that, I have no ideas except adding a queue
> > before alsasink, and
> > >> > when
> > >> > >> queue is empty, pause the pipeline, it will
> > not cause dropout, but
> > >> > still
> > >> > >> discontinous.
> > >> > >>
> > >> > >> Zhao liang
> > >> > >> ________________________________
> > >> > >> From:
> > gst...@li...
> > >> > >>
> > [mailto:gst...@li...]
> On Behalf
> > >> > Of
> > >> > >> Dennis Fleming
> > >> > >> Sent: Tuesday, July 29, 2008 4:37 AM
> > >> > >> To: gst...@li...
> > >> > >> Subject: [gst-embedded] noise and stuttering
> > >> > >>
> > >> > >> I'm trying to create an audio player on an
> > IMX31 target and I've
> > >> > found a
> > >> > >> discrepancy in the output of various formats.
> > If I send MP3 data I
> > >> > have
> > >> > >> to
> > >> > >> set the buffer-time and latency-time to 10000
> > and 100 respectively
> > >> > to play
> > >> > >> without severe dropouts. However WAV files
> > still have drop-out at
> > >> > a
> > >> > >> consistent rate (about 1 per 10 sec). Are
> > there some general
> > >> > features I'm
> > >> > >> missing or is there some guidance on the
> > buffer-time/latency time
> > >> > that
> > >> > >> would
> > >> > >> account for this difference?
> > >> > >>
> > >> > >> Linux 2.6.22.19
> > >> > >> gstreamer 0.10.17 (open-embedded)
> > >> > >> gst-launch filesrc location=<file> !
> > decodebin ! alsasink
> > >> > >> buffer-time=10000
> > >> > >> latency-time=100
> > >> > >>
> > >> > >> Dennis
> > >> > >>
> > >> > >>
> > >> >
> > >> >
> >
> -------------------------------------------------------------------------
> > >> > >> This SF.Net email is sponsored by the Moblin
> > Your Move Developer's
> > >> > >> challenge
> > >> > >> Build the coolest Linux based applications
> > with Moblin SDK & win
> > >> > great
> > >> > >> prizes
> > >> > >> Grand prize is a trip for two to an Open
> > Source event anywhere in
> > >> > the
> > >> > >> world
> > >> > >>
> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > >> > >>
> > _______________________________________________
> > >> > >> Gstreamer-embedded mailing list
> > >> > >> Gst...@li...
> > >> > >>
> >
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >> >
> > >> >
> >
> -------------------------------------------------------------------------
> > >> > This SF.Net email is sponsored by the Moblin Your
> > Move Developer's
> > >> > challenge
> > >> > Build the coolest Linux based applications with
> > Moblin SDK & win great
> > >> > prizes
> > >> > Grand prize is a trip for two to an Open Source
> > event anywhere in the
> > >> > world
> > >> >
> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > >> > _______________________________________________
> > Gstreamer-embedded
> > >> > mailing list
> > Gst...@li...
> > >> >
> >
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> > >> --
> > >> Jan Schmidt <th...@no...>
> > >>
> > >>
> > >>
> >
> -------------------------------------------------------------------------
> > >> This SF.Net email is sponsored by the Moblin Your
> > Move Developer's
> > >> challenge
> > >> Build the coolest Linux based applications with
> > Moblin SDK & win great
> > >> prizes
> > >> Grand prize is a trip for two to an Open Source
> > event anywhere in the
> > >> world
> > >>
> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > >> _______________________________________________
> > >> Gstreamer-embedded mailing list
> > >> Gst...@li...
> > >>
> >
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> > >
> > >
> > >
> >
> -------------------------------------------------------------------------
> > > This SF.Net email is sponsored by the Moblin Your
> > Move Developer's challenge
> > > Build the coolest Linux based applications with
> > Moblin SDK & win great
> > > prizes
> > > Grand prize is a trip for two to an Open Source
> > event anywhere in the world
> > >
> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > _______________________________________________
> > > Gstreamer-embedded mailing list
> > > Gst...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> > >
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________ Gstreamer-embedded
> mailing list Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> --
> Jan Schmidt <th...@no...>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Gstreamer-embedded mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Gstreamer-embedded mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>
> |
|
From: Daniel C. <dch...@gm...> - 2008-08-01 22:14:20
|
Removing the clock sync is not an elegant way of fixing this problem, as Jan said, once you get a faster system you will find playing very fast issues. I've investigated this particular problem in a OMAP 3430 some time ago and, under my particular purposes, setting the timestamp did help to avoid the glitches and the stutter. I must say that this could not fix your problem in the long term, but you could try by creating your own audiosink/gstaudioclock depending on your development. Daniel. On Fri, Aug 1, 2008 at 2:08 PM, Jan Schmidt <th...@no...> wrote: > > On Fri, 2008-08-01 at 13:51 -0500, Raj Swaminathan wrote: >> >> Can u also explain why the async fix helped ? > > It helps because it deactivates the clock-synching in the audiosink, > which means that the file plays at the speed it manages to read, decode > and output the samples -> that's slower than real-time in this case, > which is why you're getting 'stuttering'. > > Measure how long the file takes to play with 'time' compared to the > duration of the file. > > J. > >> >> On Fri, Aug 1, 2008 at 1:23 PM, Raj Swaminathan <raj...@gm...> >> wrote: >> >> Hey Dan, >> >> That worked ... its stuttering .. but keeps playing .... >> thanks a ton ! >> >> osssink: wav file play fine >> mp3 files, http links stutter but output sound >> when buffer-time=1000 latency-time=100 sync=false >> >> >> Is there any such fix for esdsink ?? >> Are there more properties that can be modified to stop the >> stuttering ?? >> >> regards, >> raj >> >> >> >> >> On Fri, Aug 1, 2008 at 12:52 PM, Daniel Charles >> <dch...@gm...> wrote: >> Hi Raj, >> >> Have you tried sync=false in the osssink? I'm not >> sure that this is >> within your purposes but in some cases that removes >> the glitches. >> >> Daniel. >> >> >> On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan >> <raj...@gm...> wrote: >> > >> > Hi everyone, >> > >> > Im having stuttering and stopping issues with >> gstreamer on the OMAP 2430... >> > I am using an NFS mounted file system via >> ethernet ... >> > >> > osssink: WAV files play without an issue. >> > mp3 files output sound and stop after >> a few seconds if i set >> > buffer-time=1000 and latency-time=100 >> > mp3 files do not output sound without >> the settings above. >> > streaming music from http links do not >> work under any >> > setting. >> > >> > esdsink: WAV files do not play. >> > mp3 files play nicely. >> > streaming music from http links output >> sound and stop after a >> > few seconds. >> > >> > My sources: filesrc, souphttpsrc >> > My decoders: wavparse, mad >> > >> > Ive experimented with placing queues before decoding >> and before sending >> > audio to the sink. Trying both ways or either/or, do >> not impact the output >> > signifcantly. >> > Can anyone provide some suggestions? >> > >> > Thanks for your help so far. >> > >> > regards, >> > raj >> > >> > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt >> <th...@no...> wrote: >> >> >> >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming >> wrote: >> >> > First off: Thank to you and Zhoa-Lang for getting >> back so quickly. >> >> > I'm so busy I forgot my manners. >> >> > >> >> > Testing to find the parameters I have I used >> decodebin, but in the >> >> > program itself uses playbin with the same effect. >> The only variation >> >> > is that I set the sink property to alsasink since >> that seems the only >> >> > way to set buffer-time and latency-time >> properties. Also, it seems >> >> > counter-intuitive to me that an uncompressed WAV >> file should have >> >> > problems keeping up while MP3s with the same >> sampling frequency and >> >> > word size have none. And yet the artifacts are >> indicative of dropped >> >> > buffers. >> >> >> >> If the bottleneck is retrieving data from the input >> location, then it's >> >> entirely feasible. What's your data store? SD card, >> NFS? A WAV file >> >> might be 10 or more times more data to read and >> cause read stalls, where >> >> the smaller mp3 can be read in fine and decoded in >> memory with no >> >> further problems. >> >> >> >> J. >> >> >> >> > Dennis >> >> > >> >> > >> >> > ----- Original Message ---- >> >> > From: Thijs Vermeir <thi...@gm...> >> >> > To: Dennis Fleming <ars...@sb...> >> >> > Cc: gst...@li... >> >> > Sent: Tuesday, July 29, 2008 3:59:30 PM >> >> > Subject: Re: [gst-embedded] noise and stuttering >> >> > >> >> > Hi, >> >> > >> >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming >> >> > <ars...@sb...> wrote: >> >> > > The interesting thing is that uncompressed WAV >> files are causing the >> >> > problem >> >> > > while MP3s were fixed by setting the >> buffer-time and latency-time to >> >> > values >> >> > > smaller than found on a desktop. What would >> adding a queue do to >> >> > latency >> >> > > through the system? >> >> > >> >> > There is no latency in this case because there >> are no live-sources. >> >> > [1] >> >> > >> >> > > Also, I suppose, that I will need to break up >> the >> >> > > playbin and create a pipeline myself, yes? >> >> > >> >> > playbin has the queue elements on the correct >> location, no changes >> >> > needed. >> >> > You where already using a custom pipeline, no? >> >> > >> >> > Gr, >> >> > >> >> > [1] >> >> > >> >> > >> http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup >> >> > >> >> > > >> >> > > Dennis >> >> > > >> >> > > ----- Original Message ---- >> >> > > From: Thijs Vermeir <thi...@gm...> >> >> > > To: Zhao Liang-E3423C <E3...@mo...> >> >> > > Cc: Dennis Fleming <ars...@sb...>; >> >> > > gst...@li... >> >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM >> >> > > Subject: Re: [gst-embedded] noise and >> stuttering >> >> > > >> >> > > Hi, >> >> > > >> >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao >> Liang-E3423C >> >> > <E3...@mo...> >> >> > > wrote: >> >> > >> What's the rootcause of noise and stuttering ? >> >> > > >> >> > > Now you are using only 1 thread for all the >> elements and if the >> >> > > filesrc or the decoder is too slow sometimes >> >> > > you don't have time to catch up. By adding the >> queue you put the >> >> > sink >> >> > > in another thread and now the filesrc+decoder >> can >> >> > > do some decoding in advance. >> >> > > >> >> > > Gr, >> >> > > Thijs >> >> > > >> >> > >> >> >> > >> For normal playback, it should not have >> issues. If decoder didn't >> >> > drop >> >> > >> data, I think alsasink did it. >> >> > >> By gstaudiosink mechanism, it will drop data >> replaced with blank >> >> > data when >> >> > >> data is late. I guess the rootcause is that. >> >> > >> >> >> > >> If that, I have no ideas except adding a queue >> before alsasink, and >> >> > when >> >> > >> queue is empty, pause the pipeline, it will >> not cause dropout, but >> >> > still >> >> > >> discontinous. >> >> > >> >> >> > >> Zhao liang >> >> > >> ________________________________ >> >> > >> From: >> gst...@li... >> >> > >> >> [mailto:gst...@li...] On Behalf >> >> > Of >> >> > >> Dennis Fleming >> >> > >> Sent: Tuesday, July 29, 2008 4:37 AM >> >> > >> To: gst...@li... >> >> > >> Subject: [gst-embedded] noise and stuttering >> >> > >> >> >> > >> I'm trying to create an audio player on an >> IMX31 target and I've >> >> > found a >> >> > >> discrepancy in the output of various formats. >> If I send MP3 data I >> >> > have >> >> > >> to >> >> > >> set the buffer-time and latency-time to 10000 >> and 100 respectively >> >> > to play >> >> > >> without severe dropouts. However WAV files >> still have drop-out at >> >> > a >> >> > >> consistent rate (about 1 per 10 sec). Are >> there some general >> >> > features I'm >> >> > >> missing or is there some guidance on the >> buffer-time/latency time >> >> > that >> >> > >> would >> >> > >> account for this difference? >> >> > >> >> >> > >> Linux 2.6.22.19 >> >> > >> gstreamer 0.10.17 (open-embedded) >> >> > >> gst-launch filesrc location=<file> ! >> decodebin ! alsasink >> >> > >> buffer-time=10000 >> >> > >> latency-time=100 >> >> > >> >> >> > >> Dennis >> >> > >> >> >> > >> >> >> > >> >> > >> ------------------------------------------------------------------------- >> >> > >> This SF.Net email is sponsored by the Moblin >> Your Move Developer's >> >> > >> challenge >> >> > >> Build the coolest Linux based applications >> with Moblin SDK & win >> >> > great >> >> > >> prizes >> >> > >> Grand prize is a trip for two to an Open >> Source event anywhere in >> >> > the >> >> > >> world >> >> > >> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> > >> >> _______________________________________________ >> >> > >> Gstreamer-embedded mailing list >> >> > >> Gst...@li... >> >> > >> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> >> > >> >> >> > >> >> >> > > >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------- >> >> > This SF.Net email is sponsored by the Moblin Your >> Move Developer's >> >> > challenge >> >> > Build the coolest Linux based applications with >> Moblin SDK & win great >> >> > prizes >> >> > Grand prize is a trip for two to an Open Source >> event anywhere in the >> >> > world >> >> > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> > _______________________________________________ >> Gstreamer-embedded >> >> > mailing list >> Gst...@li... >> >> > >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> >> -- >> >> Jan Schmidt <th...@no...> >> >> >> >> >> >> >> ------------------------------------------------------------------------- >> >> This SF.Net email is sponsored by the Moblin Your >> Move Developer's >> >> challenge >> >> Build the coolest Linux based applications with >> Moblin SDK & win great >> >> prizes >> >> Grand prize is a trip for two to an Open Source >> event anywhere in the >> >> world >> >> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> _______________________________________________ >> >> Gstreamer-embedded mailing list >> >> Gst...@li... >> >> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> > >> > >> > >> ------------------------------------------------------------------------- >> > This SF.Net email is sponsored by the Moblin Your >> Move Developer's challenge >> > Build the coolest Linux based applications with >> Moblin SDK & win great >> > prizes >> > Grand prize is a trip for two to an Open Source >> event anywhere in the world >> > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> > _______________________________________________ >> > Gstreamer-embedded mailing list >> > Gst...@li... >> > >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> > >> > >> >> >> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > -- > Jan Schmidt <th...@no...> > > |
|
From: Dennis F. <ars...@sb...> - 2008-08-01 20:19:00
|
It's interesting that I am getting the opposite problem. Ie. stutters for wav and not for MP3. It looks like we were optimizing internal buffers for 44.1 kHz. However, 22.05kHz had problems with buffer-time=10000 and latency-time=100. Going back to the defaults 220xkHz worked but 44.1 was sensitive to activity on the system. I'll try the sync fix to see what happens on my device. Dennis ----- Original Message ---- From: Jan Schmidt <th...@no...> To: Raj Swaminathan <raj...@gm...> Cc: gst...@li... Sent: Friday, August 1, 2008 12:08:27 PM Subject: Re: [gst-embedded] noise and stuttering On Fri, 2008-08-01 at 13:51 -0500, Raj Swaminathan wrote: > > Can u also explain why the async fix helped ? It helps because it deactivates the clock-synching in the audiosink, which means that the file plays at the speed it manages to read, decode and output the samples -> that's slower than real-time in this case, which is why you're getting 'stuttering'. Measure how long the file takes to play with 'time' compared to the duration of the file. J. > > On Fri, Aug 1, 2008 at 1:23 PM, Raj Swaminathan <raj...@gm...> > wrote: > > Hey Dan, > > That worked ... its stuttering .. but keeps playing .... > thanks a ton ! > > osssink: wav file play fine > mp3 files, http links stutter but output sound > when buffer-time=1000 latency-time=100 sync=false > > > Is there any such fix for esdsink ?? > Are there more properties that can be modified to stop the > stuttering ?? > > regards, > raj > > > > > On Fri, Aug 1, 2008 at 12:52 PM, Daniel Charles > <dch...@gm...> wrote: > Hi Raj, > > Have you tried sync=false in the osssink? I'm not > sure that this is > within your purposes but in some cases that removes > the glitches. > > Daniel. > > > On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan > <raj...@gm...> wrote: > > > > Hi everyone, > > > > Im having stuttering and stopping issues with > gstreamer on the OMAP 2430... > > I am using an NFS mounted file system via > ethernet ... > > > > osssink: WAV files play without an issue. > > mp3 files output sound and stop after > a few seconds if i set > > buffer-time=1000 and latency-time=100 > > mp3 files do not output sound without > the settings above. > > streaming music from http links do not > work under any > > setting. > > > > esdsink: WAV files do not play. > > mp3 files play nicely. > > streaming music from http links output > sound and stop after a > > few seconds. > > > > My sources: filesrc, souphttpsrc > > My decoders: wavparse, mad > > > > Ive experimented with placing queues before decoding > and before sending > > audio to the sink. Trying both ways or either/or, do > not impact the output > > signifcantly. > > Can anyone provide some suggestions? > > > > Thanks for your help so far. > > > > regards, > > raj > > > > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt > <th...@no...> wrote: > >> > >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming > wrote: > >> > First off: Thank to you and Zhoa-Lang for getting > back so quickly. > >> > I'm so busy I forgot my manners. > >> > > >> > Testing to find the parameters I have I used > decodebin, but in the > >> > program itself uses playbin with the same effect. > The only variation > >> > is that I set the sink property to alsasink since > that seems the only > >> > way to set buffer-time and latency-time > properties. Also, it seems > >> > counter-intuitive to me that an uncompressed WAV > file should have > >> > problems keeping up while MP3s with the same > sampling frequency and > >> > word size have none. And yet the artifacts are > indicative of dropped > >> > buffers. > >> > >> If the bottleneck is retrieving data from the input > location, then it's > >> entirely feasible. What's your data store? SD card, > NFS? A WAV file > >> might be 10 or more times more data to read and > cause read stalls, where > >> the smaller mp3 can be read in fine and decoded in > memory with no > >> further problems. > >> > >> J. > >> > >> > Dennis > >> > > >> > > >> > ----- Original Message ---- > >> > From: Thijs Vermeir <thi...@gm...> > >> > To: Dennis Fleming <ars...@sb...> > >> > Cc: gst...@li... > >> > Sent: Tuesday, July 29, 2008 3:59:30 PM > >> > Subject: Re: [gst-embedded] noise and stuttering > >> > > >> > Hi, > >> > > >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming > >> > <ars...@sb...> wrote: > >> > > The interesting thing is that uncompressed WAV > files are causing the > >> > problem > >> > > while MP3s were fixed by setting the > buffer-time and latency-time to > >> > values > >> > > smaller than found on a desktop. What would > adding a queue do to > >> > latency > >> > > through the system? > >> > > >> > There is no latency in this case because there > are no live-sources. > >> > [1] > >> > > >> > > Also, I suppose, that I will need to break up > the > >> > > playbin and create a pipeline myself, yes? > >> > > >> > playbin has the queue elements on the correct > location, no changes > >> > needed. > >> > You where already using a custom pipeline, no? > >> > > >> > Gr, > >> > > >> > [1] > >> > > >> > > http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup > >> > > >> > > > >> > > Dennis > >> > > > >> > > ----- Original Message ---- > >> > > From: Thijs Vermeir <thi...@gm...> > >> > > To: Zhao Liang-E3423C <E3...@mo...> > >> > > Cc: Dennis Fleming <ars...@sb...>; > >> > > gst...@li... > >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM > >> > > Subject: Re: [gst-embedded] noise and > stuttering > >> > > > >> > > Hi, > >> > > > >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao > Liang-E3423C > >> > <E3...@mo...> > >> > > wrote: > >> > >> What's the rootcause of noise and stuttering ? > >> > > > >> > > Now you are using only 1 thread for all the > elements and if the > >> > > filesrc or the decoder is too slow sometimes > >> > > you don't have time to catch up. By adding the > queue you put the > >> > sink > >> > > in another thread and now the filesrc+decoder > can > >> > > do some decoding in advance. > >> > > > >> > > Gr, > >> > > Thijs > >> > > > >> > >> > >> > >> For normal playback, it should not have > issues. If decoder didn't > >> > drop > >> > >> data, I think alsasink did it. > >> > >> By gstaudiosink mechanism, it will drop data > replaced with blank > >> > data when > >> > >> data is late. I guess the rootcause is that. > >> > >> > >> > >> If that, I have no ideas except adding a queue > before alsasink, and > >> > when > >> > >> queue is empty, pause the pipeline, it will > not cause dropout, but > >> > still > >> > >> discontinous. > >> > >> > >> > >> Zhao liang > >> > >> ________________________________ > >> > >> From: > gst...@li... > >> > >> > [mailto:gst...@li...] On Behalf > >> > Of > >> > >> Dennis Fleming > >> > >> Sent: Tuesday, July 29, 2008 4:37 AM > >> > >> To: gst...@li... > >> > >> Subject: [gst-embedded] noise and stuttering > >> > >> > >> > >> I'm trying to create an audio player on an > IMX31 target and I've > >> > found a > >> > >> discrepancy in the output of various formats. > If I send MP3 data I > >> > have > >> > >> to > >> > >> set the buffer-time and latency-time to 10000 > and 100 respectively > >> > to play > >> > >> without severe dropouts. However WAV files > still have drop-out at > >> > a > >> > >> consistent rate (about 1 per 10 sec). Are > there some general > >> > features I'm > >> > >> missing or is there some guidance on the > buffer-time/latency time > >> > that > >> > >> would > >> > >> account for this difference? > >> > >> > >> > >> Linux 2.6.22.19 > >> > >> gstreamer 0.10.17 (open-embedded) > >> > >> gst-launch filesrc location=<file> ! > decodebin ! alsasink > >> > >> buffer-time=10000 > >> > >> latency-time=100 > >> > >> > >> > >> Dennis > >> > >> > >> > >> > >> > > >> > > ------------------------------------------------------------------------- > >> > >> This SF.Net email is sponsored by the Moblin > Your Move Developer's > >> > >> challenge > >> > >> Build the coolest Linux based applications > with Moblin SDK & win > >> > great > >> > >> prizes > >> > >> Grand prize is a trip for two to an Open > Source event anywhere in > >> > the > >> > >> world > >> > >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> > >> > _______________________________________________ > >> > >> Gstreamer-embedded mailing list > >> > >> Gst...@li... > >> > >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > >> > >> > >> > >> > >> > > > >> > > >> > > >> > > ------------------------------------------------------------------------- > >> > This SF.Net email is sponsored by the Moblin Your > Move Developer's > >> > challenge > >> > Build the coolest Linux based applications with > Moblin SDK & win great > >> > prizes > >> > Grand prize is a trip for two to an Open Source > event anywhere in the > >> > world > >> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> > _______________________________________________ > Gstreamer-embedded > >> > mailing list > Gst...@li... > >> > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > >> -- > >> Jan Schmidt <th...@no...> > >> > >> > >> > ------------------------------------------------------------------------- > >> This SF.Net email is sponsored by the Moblin Your > Move Developer's > >> challenge > >> Build the coolest Linux based applications with > Moblin SDK & win great > >> prizes > >> Grand prize is a trip for two to an Open Source > event anywhere in the > >> world > >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> _______________________________________________ > >> Gstreamer-embedded mailing list > >> Gst...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your > Move Developer's challenge > > Build the coolest Linux based applications with > Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source > event anywhere in the world > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Gstreamer-embedded mailing list > > Gst...@li... > > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded -- Jan Schmidt <th...@no...> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded |
|
From: Jan S. <th...@no...> - 2008-08-01 19:08:35
|
On Fri, 2008-08-01 at 13:51 -0500, Raj Swaminathan wrote: > > Can u also explain why the async fix helped ? It helps because it deactivates the clock-synching in the audiosink, which means that the file plays at the speed it manages to read, decode and output the samples -> that's slower than real-time in this case, which is why you're getting 'stuttering'. Measure how long the file takes to play with 'time' compared to the duration of the file. J. > > On Fri, Aug 1, 2008 at 1:23 PM, Raj Swaminathan <raj...@gm...> > wrote: > > Hey Dan, > > That worked ... its stuttering .. but keeps playing .... > thanks a ton ! > > osssink: wav file play fine > mp3 files, http links stutter but output sound > when buffer-time=1000 latency-time=100 sync=false > > > Is there any such fix for esdsink ?? > Are there more properties that can be modified to stop the > stuttering ?? > > regards, > raj > > > > > On Fri, Aug 1, 2008 at 12:52 PM, Daniel Charles > <dch...@gm...> wrote: > Hi Raj, > > Have you tried sync=false in the osssink? I'm not > sure that this is > within your purposes but in some cases that removes > the glitches. > > Daniel. > > > On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan > <raj...@gm...> wrote: > > > > Hi everyone, > > > > Im having stuttering and stopping issues with > gstreamer on the OMAP 2430... > > I am using an NFS mounted file system via > ethernet ... > > > > osssink: WAV files play without an issue. > > mp3 files output sound and stop after > a few seconds if i set > > buffer-time=1000 and latency-time=100 > > mp3 files do not output sound without > the settings above. > > streaming music from http links do not > work under any > > setting. > > > > esdsink: WAV files do not play. > > mp3 files play nicely. > > streaming music from http links output > sound and stop after a > > few seconds. > > > > My sources: filesrc, souphttpsrc > > My decoders: wavparse, mad > > > > Ive experimented with placing queues before decoding > and before sending > > audio to the sink. Trying both ways or either/or, do > not impact the output > > signifcantly. > > Can anyone provide some suggestions? > > > > Thanks for your help so far. > > > > regards, > > raj > > > > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt > <th...@no...> wrote: > >> > >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming > wrote: > >> > First off: Thank to you and Zhoa-Lang for getting > back so quickly. > >> > I'm so busy I forgot my manners. > >> > > >> > Testing to find the parameters I have I used > decodebin, but in the > >> > program itself uses playbin with the same effect. > The only variation > >> > is that I set the sink property to alsasink since > that seems the only > >> > way to set buffer-time and latency-time > properties. Also, it seems > >> > counter-intuitive to me that an uncompressed WAV > file should have > >> > problems keeping up while MP3s with the same > sampling frequency and > >> > word size have none. And yet the artifacts are > indicative of dropped > >> > buffers. > >> > >> If the bottleneck is retrieving data from the input > location, then it's > >> entirely feasible. What's your data store? SD card, > NFS? A WAV file > >> might be 10 or more times more data to read and > cause read stalls, where > >> the smaller mp3 can be read in fine and decoded in > memory with no > >> further problems. > >> > >> J. > >> > >> > Dennis > >> > > >> > > >> > ----- Original Message ---- > >> > From: Thijs Vermeir <thi...@gm...> > >> > To: Dennis Fleming <ars...@sb...> > >> > Cc: gst...@li... > >> > Sent: Tuesday, July 29, 2008 3:59:30 PM > >> > Subject: Re: [gst-embedded] noise and stuttering > >> > > >> > Hi, > >> > > >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming > >> > <ars...@sb...> wrote: > >> > > The interesting thing is that uncompressed WAV > files are causing the > >> > problem > >> > > while MP3s were fixed by setting the > buffer-time and latency-time to > >> > values > >> > > smaller than found on a desktop. What would > adding a queue do to > >> > latency > >> > > through the system? > >> > > >> > There is no latency in this case because there > are no live-sources. > >> > [1] > >> > > >> > > Also, I suppose, that I will need to break up > the > >> > > playbin and create a pipeline myself, yes? > >> > > >> > playbin has the queue elements on the correct > location, no changes > >> > needed. > >> > You where already using a custom pipeline, no? > >> > > >> > Gr, > >> > > >> > [1] > >> > > >> > > http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup > >> > > >> > > > >> > > Dennis > >> > > > >> > > ----- Original Message ---- > >> > > From: Thijs Vermeir <thi...@gm...> > >> > > To: Zhao Liang-E3423C <E3...@mo...> > >> > > Cc: Dennis Fleming <ars...@sb...>; > >> > > gst...@li... > >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM > >> > > Subject: Re: [gst-embedded] noise and > stuttering > >> > > > >> > > Hi, > >> > > > >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao > Liang-E3423C > >> > <E3...@mo...> > >> > > wrote: > >> > >> What's the rootcause of noise and stuttering ? > >> > > > >> > > Now you are using only 1 thread for all the > elements and if the > >> > > filesrc or the decoder is too slow sometimes > >> > > you don't have time to catch up. By adding the > queue you put the > >> > sink > >> > > in another thread and now the filesrc+decoder > can > >> > > do some decoding in advance. > >> > > > >> > > Gr, > >> > > Thijs > >> > > > >> > >> > >> > >> For normal playback, it should not have > issues. If decoder didn't > >> > drop > >> > >> data, I think alsasink did it. > >> > >> By gstaudiosink mechanism, it will drop data > replaced with blank > >> > data when > >> > >> data is late. I guess the rootcause is that. > >> > >> > >> > >> If that, I have no ideas except adding a queue > before alsasink, and > >> > when > >> > >> queue is empty, pause the pipeline, it will > not cause dropout, but > >> > still > >> > >> discontinous. > >> > >> > >> > >> Zhao liang > >> > >> ________________________________ > >> > >> From: > gst...@li... > >> > >> > [mailto:gst...@li...] On Behalf > >> > Of > >> > >> Dennis Fleming > >> > >> Sent: Tuesday, July 29, 2008 4:37 AM > >> > >> To: gst...@li... > >> > >> Subject: [gst-embedded] noise and stuttering > >> > >> > >> > >> I'm trying to create an audio player on an > IMX31 target and I've > >> > found a > >> > >> discrepancy in the output of various formats. > If I send MP3 data I > >> > have > >> > >> to > >> > >> set the buffer-time and latency-time to 10000 > and 100 respectively > >> > to play > >> > >> without severe dropouts. However WAV files > still have drop-out at > >> > a > >> > >> consistent rate (about 1 per 10 sec). Are > there some general > >> > features I'm > >> > >> missing or is there some guidance on the > buffer-time/latency time > >> > that > >> > >> would > >> > >> account for this difference? > >> > >> > >> > >> Linux 2.6.22.19 > >> > >> gstreamer 0.10.17 (open-embedded) > >> > >> gst-launch filesrc location=<file> ! > decodebin ! alsasink > >> > >> buffer-time=10000 > >> > >> latency-time=100 > >> > >> > >> > >> Dennis > >> > >> > >> > >> > >> > > >> > > ------------------------------------------------------------------------- > >> > >> This SF.Net email is sponsored by the Moblin > Your Move Developer's > >> > >> challenge > >> > >> Build the coolest Linux based applications > with Moblin SDK & win > >> > great > >> > >> prizes > >> > >> Grand prize is a trip for two to an Open > Source event anywhere in > >> > the > >> > >> world > >> > >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> > >> > _______________________________________________ > >> > >> Gstreamer-embedded mailing list > >> > >> Gst...@li... > >> > >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > >> > >> > >> > >> > >> > > > >> > > >> > > >> > > ------------------------------------------------------------------------- > >> > This SF.Net email is sponsored by the Moblin Your > Move Developer's > >> > challenge > >> > Build the coolest Linux based applications with > Moblin SDK & win great > >> > prizes > >> > Grand prize is a trip for two to an Open Source > event anywhere in the > >> > world > >> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> > _______________________________________________ > Gstreamer-embedded > >> > mailing list > Gst...@li... > >> > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > >> -- > >> Jan Schmidt <th...@no...> > >> > >> > >> > ------------------------------------------------------------------------- > >> This SF.Net email is sponsored by the Moblin Your > Move Developer's > >> challenge > >> Build the coolest Linux based applications with > Moblin SDK & win great > >> prizes > >> Grand prize is a trip for two to an Open Source > event anywhere in the > >> world > >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> _______________________________________________ > >> Gstreamer-embedded mailing list > >> Gst...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your > Move Developer's challenge > > Build the coolest Linux based applications with > Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source > event anywhere in the world > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Gstreamer-embedded mailing list > > Gst...@li... > > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded -- Jan Schmidt <th...@no...> |
|
From: Raj S. <raj...@gm...> - 2008-08-01 18:51:46
|
Can u also explain why the async fix helped ? On Fri, Aug 1, 2008 at 1:23 PM, Raj Swaminathan <raj...@gm...> wrote: > > Hey Dan, > > That worked ... its stuttering .. but keeps playing .... thanks a ton ! > > osssink: wav file play fine > mp3 files, http links stutter but output sound when > buffer-time=1000 latency-time=100 sync=false > > > Is there any such fix for esdsink ?? > Are there more properties that can be modified to stop the stuttering ?? > > regards, > raj > > > > On Fri, Aug 1, 2008 at 12:52 PM, Daniel Charles <dch...@gm...>wrote: > >> Hi Raj, >> >> Have you tried sync=false in the osssink? I'm not sure that this is >> within your purposes but in some cases that removes the glitches. >> >> Daniel. >> >> On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan <raj...@gm...> >> wrote: >> > >> > Hi everyone, >> > >> > Im having stuttering and stopping issues with gstreamer on the OMAP >> 2430... >> > I am using an NFS mounted file system via ethernet ... >> > >> > osssink: WAV files play without an issue. >> > mp3 files output sound and stop after a few seconds if i >> set >> > buffer-time=1000 and latency-time=100 >> > mp3 files do not output sound without the settings above. >> > streaming music from http links do not work under any >> > setting. >> > >> > esdsink: WAV files do not play. >> > mp3 files play nicely. >> > streaming music from http links output sound and stop after >> a >> > few seconds. >> > >> > My sources: filesrc, souphttpsrc >> > My decoders: wavparse, mad >> > >> > Ive experimented with placing queues before decoding and before sending >> > audio to the sink. Trying both ways or either/or, do not impact the >> output >> > signifcantly. >> > Can anyone provide some suggestions? >> > >> > Thanks for your help so far. >> > >> > regards, >> > raj >> > >> > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt <th...@no...> >> wrote: >> >> >> >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming wrote: >> >> > First off: Thank to you and Zhoa-Lang for getting back so quickly. >> >> > I'm so busy I forgot my manners. >> >> > >> >> > Testing to find the parameters I have I used decodebin, but in the >> >> > program itself uses playbin with the same effect. The only >> variation >> >> > is that I set the sink property to alsasink since that seems the only >> >> > way to set buffer-time and latency-time properties. Also, it seems >> >> > counter-intuitive to me that an uncompressed WAV file should have >> >> > problems keeping up while MP3s with the same sampling frequency and >> >> > word size have none. And yet the artifacts are indicative of dropped >> >> > buffers. >> >> >> >> If the bottleneck is retrieving data from the input location, then it's >> >> entirely feasible. What's your data store? SD card, NFS? A WAV file >> >> might be 10 or more times more data to read and cause read stalls, >> where >> >> the smaller mp3 can be read in fine and decoded in memory with no >> >> further problems. >> >> >> >> J. >> >> >> >> > Dennis >> >> > >> >> > >> >> > ----- Original Message ---- >> >> > From: Thijs Vermeir <thi...@gm...> >> >> > To: Dennis Fleming <ars...@sb...> >> >> > Cc: gst...@li... >> >> > Sent: Tuesday, July 29, 2008 3:59:30 PM >> >> > Subject: Re: [gst-embedded] noise and stuttering >> >> > >> >> > Hi, >> >> > >> >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming >> >> > <ars...@sb...> wrote: >> >> > > The interesting thing is that uncompressed WAV files are causing >> the >> >> > problem >> >> > > while MP3s were fixed by setting the buffer-time and latency-time >> to >> >> > values >> >> > > smaller than found on a desktop. What would adding a queue do to >> >> > latency >> >> > > through the system? >> >> > >> >> > There is no latency in this case because there are no live-sources. >> >> > [1] >> >> > >> >> > > Also, I suppose, that I will need to break up the >> >> > > playbin and create a pipeline myself, yes? >> >> > >> >> > playbin has the queue elements on the correct location, no changes >> >> > needed. >> >> > You where already using a custom pipeline, no? >> >> > >> >> > Gr, >> >> > >> >> > [1] >> >> > >> >> > >> http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup >> >> > >> >> > > >> >> > > Dennis >> >> > > >> >> > > ----- Original Message ---- >> >> > > From: Thijs Vermeir <thi...@gm...> >> >> > > To: Zhao Liang-E3423C <E3...@mo...> >> >> > > Cc: Dennis Fleming <ars...@sb...>; >> >> > > gst...@li... >> >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM >> >> > > Subject: Re: [gst-embedded] noise and stuttering >> >> > > >> >> > > Hi, >> >> > > >> >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao Liang-E3423C >> >> > <E3...@mo...> >> >> > > wrote: >> >> > >> What's the rootcause of noise and stuttering ? >> >> > > >> >> > > Now you are using only 1 thread for all the elements and if the >> >> > > filesrc or the decoder is too slow sometimes >> >> > > you don't have time to catch up. By adding the queue you put the >> >> > sink >> >> > > in another thread and now the filesrc+decoder can >> >> > > do some decoding in advance. >> >> > > >> >> > > Gr, >> >> > > Thijs >> >> > > >> >> > >> >> >> > >> For normal playback, it should not have issues. If decoder didn't >> >> > drop >> >> > >> data, I think alsasink did it. >> >> > >> By gstaudiosink mechanism, it will drop data replaced with blank >> >> > data when >> >> > >> data is late. I guess the rootcause is that. >> >> > >> >> >> > >> If that, I have no ideas except adding a queue before alsasink, >> and >> >> > when >> >> > >> queue is empty, pause the pipeline, it will not cause dropout, but >> >> > still >> >> > >> discontinous. >> >> > >> >> >> > >> Zhao liang >> >> > >> ________________________________ >> >> > >> From: gst...@li... >> >> > >> [mailto:gst...@li...] On >> Behalf >> >> > Of >> >> > >> Dennis Fleming >> >> > >> Sent: Tuesday, July 29, 2008 4:37 AM >> >> > >> To: gst...@li... >> >> > >> Subject: [gst-embedded] noise and stuttering >> >> > >> >> >> > >> I'm trying to create an audio player on an IMX31 target and I've >> >> > found a >> >> > >> discrepancy in the output of various formats. If I send MP3 data >> I >> >> > have >> >> > >> to >> >> > >> set the buffer-time and latency-time to 10000 and 100 respectively >> >> > to play >> >> > >> without severe dropouts. However WAV files still have drop-out at >> >> > a >> >> > >> consistent rate (about 1 per 10 sec). Are there some general >> >> > features I'm >> >> > >> missing or is there some guidance on the buffer-time/latency time >> >> > that >> >> > >> would >> >> > >> account for this difference? >> >> > >> >> >> > >> Linux 2.6.22.19 >> >> > >> gstreamer 0.10.17 (open-embedded) >> >> > >> gst-launch filesrc location=<file> ! decodebin ! alsasink >> >> > >> buffer-time=10000 >> >> > >> latency-time=100 >> >> > >> >> >> > >> Dennis >> >> > >> >> >> > >> >> >> > >> >> > >> ------------------------------------------------------------------------- >> >> > >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> >> > >> challenge >> >> > >> Build the coolest Linux based applications with Moblin SDK & win >> >> > great >> >> > >> prizes >> >> > >> Grand prize is a trip for two to an Open Source event anywhere in >> >> > the >> >> > >> world >> >> > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> > >> _______________________________________________ >> >> > >> Gstreamer-embedded mailing list >> >> > >> Gst...@li... >> >> > >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> >> > >> >> >> > >> >> >> > > >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------- >> >> > This SF.Net email is sponsored by the Moblin Your Move Developer's >> >> > challenge >> >> > Build the coolest Linux based applications with Moblin SDK & win >> great >> >> > prizes >> >> > Grand prize is a trip for two to an Open Source event anywhere in the >> >> > world >> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> > _______________________________________________ Gstreamer-embedded >> >> > mailing list Gst...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> >> -- >> >> Jan Schmidt <th...@no...> >> >> >> >> >> >> >> ------------------------------------------------------------------------- >> >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> >> challenge >> >> Build the coolest Linux based applications with Moblin SDK & win great >> >> prizes >> >> Grand prize is a trip for two to an Open Source event anywhere in the >> >> world >> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> _______________________________________________ >> >> Gstreamer-embedded mailing list >> >> Gst...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> > >> > >> > >> ------------------------------------------------------------------------- >> > This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> > Build the coolest Linux based applications with Moblin SDK & win great >> > prizes >> > Grand prize is a trip for two to an Open Source event anywhere in the >> world >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> > _______________________________________________ >> > Gstreamer-embedded mailing list >> > Gst...@li... >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> > >> > >> > > |
|
From: Raj S. <raj...@gm...> - 2008-08-01 18:23:32
|
Hey Dan,
That worked ... its stuttering .. but keeps playing .... thanks a ton !
osssink: wav file play fine
mp3 files, http links stutter but output sound when
buffer-time=1000 latency-time=100 sync=false
Is there any such fix for esdsink ??
Are there more properties that can be modified to stop the stuttering ??
regards,
raj
On Fri, Aug 1, 2008 at 12:52 PM, Daniel Charles <dch...@gm...> wrote:
> Hi Raj,
>
> Have you tried sync=false in the osssink? I'm not sure that this is
> within your purposes but in some cases that removes the glitches.
>
> Daniel.
>
> On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan <raj...@gm...>
> wrote:
> >
> > Hi everyone,
> >
> > Im having stuttering and stopping issues with gstreamer on the OMAP
> 2430...
> > I am using an NFS mounted file system via ethernet ...
> >
> > osssink: WAV files play without an issue.
> > mp3 files output sound and stop after a few seconds if i
> set
> > buffer-time=1000 and latency-time=100
> > mp3 files do not output sound without the settings above.
> > streaming music from http links do not work under any
> > setting.
> >
> > esdsink: WAV files do not play.
> > mp3 files play nicely.
> > streaming music from http links output sound and stop after
> a
> > few seconds.
> >
> > My sources: filesrc, souphttpsrc
> > My decoders: wavparse, mad
> >
> > Ive experimented with placing queues before decoding and before sending
> > audio to the sink. Trying both ways or either/or, do not impact the
> output
> > signifcantly.
> > Can anyone provide some suggestions?
> >
> > Thanks for your help so far.
> >
> > regards,
> > raj
> >
> > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt <th...@no...>
> wrote:
> >>
> >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming wrote:
> >> > First off: Thank to you and Zhoa-Lang for getting back so quickly.
> >> > I'm so busy I forgot my manners.
> >> >
> >> > Testing to find the parameters I have I used decodebin, but in the
> >> > program itself uses playbin with the same effect. The only variation
> >> > is that I set the sink property to alsasink since that seems the only
> >> > way to set buffer-time and latency-time properties. Also, it seems
> >> > counter-intuitive to me that an uncompressed WAV file should have
> >> > problems keeping up while MP3s with the same sampling frequency and
> >> > word size have none. And yet the artifacts are indicative of dropped
> >> > buffers.
> >>
> >> If the bottleneck is retrieving data from the input location, then it's
> >> entirely feasible. What's your data store? SD card, NFS? A WAV file
> >> might be 10 or more times more data to read and cause read stalls, where
> >> the smaller mp3 can be read in fine and decoded in memory with no
> >> further problems.
> >>
> >> J.
> >>
> >> > Dennis
> >> >
> >> >
> >> > ----- Original Message ----
> >> > From: Thijs Vermeir <thi...@gm...>
> >> > To: Dennis Fleming <ars...@sb...>
> >> > Cc: gst...@li...
> >> > Sent: Tuesday, July 29, 2008 3:59:30 PM
> >> > Subject: Re: [gst-embedded] noise and stuttering
> >> >
> >> > Hi,
> >> >
> >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming
> >> > <ars...@sb...> wrote:
> >> > > The interesting thing is that uncompressed WAV files are causing the
> >> > problem
> >> > > while MP3s were fixed by setting the buffer-time and latency-time to
> >> > values
> >> > > smaller than found on a desktop. What would adding a queue do to
> >> > latency
> >> > > through the system?
> >> >
> >> > There is no latency in this case because there are no live-sources.
> >> > [1]
> >> >
> >> > > Also, I suppose, that I will need to break up the
> >> > > playbin and create a pipeline myself, yes?
> >> >
> >> > playbin has the queue elements on the correct location, no changes
> >> > needed.
> >> > You where already using a custom pipeline, no?
> >> >
> >> > Gr,
> >> >
> >> > [1]
> >> >
> >> >
> http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup
> >> >
> >> > >
> >> > > Dennis
> >> > >
> >> > > ----- Original Message ----
> >> > > From: Thijs Vermeir <thi...@gm...>
> >> > > To: Zhao Liang-E3423C <E3...@mo...>
> >> > > Cc: Dennis Fleming <ars...@sb...>;
> >> > > gst...@li...
> >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM
> >> > > Subject: Re: [gst-embedded] noise and stuttering
> >> > >
> >> > > Hi,
> >> > >
> >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao Liang-E3423C
> >> > <E3...@mo...>
> >> > > wrote:
> >> > >> What's the rootcause of noise and stuttering ?
> >> > >
> >> > > Now you are using only 1 thread for all the elements and if the
> >> > > filesrc or the decoder is too slow sometimes
> >> > > you don't have time to catch up. By adding the queue you put the
> >> > sink
> >> > > in another thread and now the filesrc+decoder can
> >> > > do some decoding in advance.
> >> > >
> >> > > Gr,
> >> > > Thijs
> >> > >
> >> > >>
> >> > >> For normal playback, it should not have issues. If decoder didn't
> >> > drop
> >> > >> data, I think alsasink did it.
> >> > >> By gstaudiosink mechanism, it will drop data replaced with blank
> >> > data when
> >> > >> data is late. I guess the rootcause is that.
> >> > >>
> >> > >> If that, I have no ideas except adding a queue before alsasink, and
> >> > when
> >> > >> queue is empty, pause the pipeline, it will not cause dropout, but
> >> > still
> >> > >> discontinous.
> >> > >>
> >> > >> Zhao liang
> >> > >> ________________________________
> >> > >> From: gst...@li...
> >> > >> [mailto:gst...@li...] On
> Behalf
> >> > Of
> >> > >> Dennis Fleming
> >> > >> Sent: Tuesday, July 29, 2008 4:37 AM
> >> > >> To: gst...@li...
> >> > >> Subject: [gst-embedded] noise and stuttering
> >> > >>
> >> > >> I'm trying to create an audio player on an IMX31 target and I've
> >> > found a
> >> > >> discrepancy in the output of various formats. If I send MP3 data I
> >> > have
> >> > >> to
> >> > >> set the buffer-time and latency-time to 10000 and 100 respectively
> >> > to play
> >> > >> without severe dropouts. However WAV files still have drop-out at
> >> > a
> >> > >> consistent rate (about 1 per 10 sec). Are there some general
> >> > features I'm
> >> > >> missing or is there some guidance on the buffer-time/latency time
> >> > that
> >> > >> would
> >> > >> account for this difference?
> >> > >>
> >> > >> Linux 2.6.22.19
> >> > >> gstreamer 0.10.17 (open-embedded)
> >> > >> gst-launch filesrc location=<file> ! decodebin ! alsasink
> >> > >> buffer-time=10000
> >> > >> latency-time=100
> >> > >>
> >> > >> Dennis
> >> > >>
> >> > >>
> >> >
> >> >
> -------------------------------------------------------------------------
> >> > >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> > >> challenge
> >> > >> Build the coolest Linux based applications with Moblin SDK & win
> >> > great
> >> > >> prizes
> >> > >> Grand prize is a trip for two to an Open Source event anywhere in
> >> > the
> >> > >> world
> >> > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> > >> _______________________________________________
> >> > >> Gstreamer-embedded mailing list
> >> > >> Gst...@li...
> >> > >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >> >
> -------------------------------------------------------------------------
> >> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> > challenge
> >> > Build the coolest Linux based applications with Moblin SDK & win great
> >> > prizes
> >> > Grand prize is a trip for two to an Open Source event anywhere in the
> >> > world
> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> > _______________________________________________ Gstreamer-embedded
> >> > mailing list Gst...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >> --
> >> Jan Schmidt <th...@no...>
> >>
> >>
> >>
> -------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great
> >> prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the
> >> world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Gstreamer-embedded mailing list
> >> Gst...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Gstreamer-embedded mailing list
> > Gst...@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
> >
>
|
|
From: Daniel C. <dch...@gm...> - 2008-08-01 17:52:28
|
Hi Raj, Have you tried sync=false in the osssink? I'm not sure that this is within your purposes but in some cases that removes the glitches. Daniel. On Fri, Aug 1, 2008 at 12:41 PM, Raj Swaminathan <raj...@gm...> wrote: > > Hi everyone, > > Im having stuttering and stopping issues with gstreamer on the OMAP 2430... > I am using an NFS mounted file system via ethernet ... > > osssink: WAV files play without an issue. > mp3 files output sound and stop after a few seconds if i set > buffer-time=1000 and latency-time=100 > mp3 files do not output sound without the settings above. > streaming music from http links do not work under any > setting. > > esdsink: WAV files do not play. > mp3 files play nicely. > streaming music from http links output sound and stop after a > few seconds. > > My sources: filesrc, souphttpsrc > My decoders: wavparse, mad > > Ive experimented with placing queues before decoding and before sending > audio to the sink. Trying both ways or either/or, do not impact the output > signifcantly. > Can anyone provide some suggestions? > > Thanks for your help so far. > > regards, > raj > > On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt <th...@no...> wrote: >> >> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming wrote: >> > First off: Thank to you and Zhoa-Lang for getting back so quickly. >> > I'm so busy I forgot my manners. >> > >> > Testing to find the parameters I have I used decodebin, but in the >> > program itself uses playbin with the same effect. The only variation >> > is that I set the sink property to alsasink since that seems the only >> > way to set buffer-time and latency-time properties. Also, it seems >> > counter-intuitive to me that an uncompressed WAV file should have >> > problems keeping up while MP3s with the same sampling frequency and >> > word size have none. And yet the artifacts are indicative of dropped >> > buffers. >> >> If the bottleneck is retrieving data from the input location, then it's >> entirely feasible. What's your data store? SD card, NFS? A WAV file >> might be 10 or more times more data to read and cause read stalls, where >> the smaller mp3 can be read in fine and decoded in memory with no >> further problems. >> >> J. >> >> > Dennis >> > >> > >> > ----- Original Message ---- >> > From: Thijs Vermeir <thi...@gm...> >> > To: Dennis Fleming <ars...@sb...> >> > Cc: gst...@li... >> > Sent: Tuesday, July 29, 2008 3:59:30 PM >> > Subject: Re: [gst-embedded] noise and stuttering >> > >> > Hi, >> > >> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming >> > <ars...@sb...> wrote: >> > > The interesting thing is that uncompressed WAV files are causing the >> > problem >> > > while MP3s were fixed by setting the buffer-time and latency-time to >> > values >> > > smaller than found on a desktop. What would adding a queue do to >> > latency >> > > through the system? >> > >> > There is no latency in this case because there are no live-sources. >> > [1] >> > >> > > Also, I suppose, that I will need to break up the >> > > playbin and create a pipeline myself, yes? >> > >> > playbin has the queue elements on the correct location, no changes >> > needed. >> > You where already using a custom pipeline, no? >> > >> > Gr, >> > >> > [1] >> > >> > http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup >> > >> > > >> > > Dennis >> > > >> > > ----- Original Message ---- >> > > From: Thijs Vermeir <thi...@gm...> >> > > To: Zhao Liang-E3423C <E3...@mo...> >> > > Cc: Dennis Fleming <ars...@sb...>; >> > > gst...@li... >> > > Sent: Tuesday, July 29, 2008 2:46:42 AM >> > > Subject: Re: [gst-embedded] noise and stuttering >> > > >> > > Hi, >> > > >> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao Liang-E3423C >> > <E3...@mo...> >> > > wrote: >> > >> What's the rootcause of noise and stuttering ? >> > > >> > > Now you are using only 1 thread for all the elements and if the >> > > filesrc or the decoder is too slow sometimes >> > > you don't have time to catch up. By adding the queue you put the >> > sink >> > > in another thread and now the filesrc+decoder can >> > > do some decoding in advance. >> > > >> > > Gr, >> > > Thijs >> > > >> > >> >> > >> For normal playback, it should not have issues. If decoder didn't >> > drop >> > >> data, I think alsasink did it. >> > >> By gstaudiosink mechanism, it will drop data replaced with blank >> > data when >> > >> data is late. I guess the rootcause is that. >> > >> >> > >> If that, I have no ideas except adding a queue before alsasink, and >> > when >> > >> queue is empty, pause the pipeline, it will not cause dropout, but >> > still >> > >> discontinous. >> > >> >> > >> Zhao liang >> > >> ________________________________ >> > >> From: gst...@li... >> > >> [mailto:gst...@li...] On Behalf >> > Of >> > >> Dennis Fleming >> > >> Sent: Tuesday, July 29, 2008 4:37 AM >> > >> To: gst...@li... >> > >> Subject: [gst-embedded] noise and stuttering >> > >> >> > >> I'm trying to create an audio player on an IMX31 target and I've >> > found a >> > >> discrepancy in the output of various formats. If I send MP3 data I >> > have >> > >> to >> > >> set the buffer-time and latency-time to 10000 and 100 respectively >> > to play >> > >> without severe dropouts. However WAV files still have drop-out at >> > a >> > >> consistent rate (about 1 per 10 sec). Are there some general >> > features I'm >> > >> missing or is there some guidance on the buffer-time/latency time >> > that >> > >> would >> > >> account for this difference? >> > >> >> > >> Linux 2.6.22.19 >> > >> gstreamer 0.10.17 (open-embedded) >> > >> gst-launch filesrc location=<file> ! decodebin ! alsasink >> > >> buffer-time=10000 >> > >> latency-time=100 >> > >> >> > >> Dennis >> > >> >> > >> >> > >> > ------------------------------------------------------------------------- >> > >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> > >> challenge >> > >> Build the coolest Linux based applications with Moblin SDK & win >> > great >> > >> prizes >> > >> Grand prize is a trip for two to an Open Source event anywhere in >> > the >> > >> world >> > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> > >> _______________________________________________ >> > >> Gstreamer-embedded mailing list >> > >> Gst...@li... >> > >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> > >> >> > >> >> > > >> > >> > >> > ------------------------------------------------------------------------- >> > This SF.Net email is sponsored by the Moblin Your Move Developer's >> > challenge >> > Build the coolest Linux based applications with Moblin SDK & win great >> > prizes >> > Grand prize is a trip for two to an Open Source event anywhere in the >> > world >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> > _______________________________________________ Gstreamer-embedded >> > mailing list Gst...@li... >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> -- >> Jan Schmidt <th...@no...> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Gstreamer-embedded mailing list >> Gst...@li... >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gstreamer-embedded mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > |
|
From: Raj S. <raj...@gm...> - 2008-08-01 17:41:05
|
Hi everyone,
Im having stuttering and stopping issues with gstreamer on the OMAP 2430...
I am using an NFS mounted file system via ethernet ...
osssink: WAV files play without an issue.
mp3 files output sound and stop after a few seconds if i set
buffer-time=1000 and latency-time=100
mp3 files do not output sound without the settings above.
streaming music from http links do not work under any
setting.
esdsink: WAV files do not play.
mp3 files play nicely.
streaming music from http links output sound and stop after a
few seconds.
My sources: filesrc, souphttpsrc
My decoders: wavparse, mad
Ive experimented with placing queues before decoding and before sending
audio to the sink. Trying both ways or either/or, do not impact the output
signifcantly.
Can anyone provide some suggestions?
Thanks for your help so far.
regards,
raj
On Thu, Jul 31, 2008 at 4:42 AM, Jan Schmidt <th...@no...> wrote:
> On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming wrote:
> > First off: Thank to you and Zhoa-Lang for getting back so quickly.
> > I'm so busy I forgot my manners.
> >
> > Testing to find the parameters I have I used decodebin, but in the
> > program itself uses playbin with the same effect. The only variation
> > is that I set the sink property to alsasink since that seems the only
> > way to set buffer-time and latency-time properties. Also, it seems
> > counter-intuitive to me that an uncompressed WAV file should have
> > problems keeping up while MP3s with the same sampling frequency and
> > word size have none. And yet the artifacts are indicative of dropped
> > buffers.
>
> If the bottleneck is retrieving data from the input location, then it's
> entirely feasible. What's your data store? SD card, NFS? A WAV file
> might be 10 or more times more data to read and cause read stalls, where
> the smaller mp3 can be read in fine and decoded in memory with no
> further problems.
>
> J.
>
> > Dennis
> >
> >
> > ----- Original Message ----
> > From: Thijs Vermeir <thi...@gm...>
> > To: Dennis Fleming <ars...@sb...>
> > Cc: gst...@li...
> > Sent: Tuesday, July 29, 2008 3:59:30 PM
> > Subject: Re: [gst-embedded] noise and stuttering
> >
> > Hi,
> >
> > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming
> > <ars...@sb...> wrote:
> > > The interesting thing is that uncompressed WAV files are causing the
> > problem
> > > while MP3s were fixed by setting the buffer-time and latency-time to
> > values
> > > smaller than found on a desktop. What would adding a queue do to
> > latency
> > > through the system?
> >
> > There is no latency in this case because there are no live-sources.
> > [1]
> >
> > > Also, I suppose, that I will need to break up the
> > > playbin and create a pipeline myself, yes?
> >
> > playbin has the queue elements on the correct location, no changes
> > needed.
> > You where already using a custom pipeline, no?
> >
> > Gr,
> >
> > [1]
> >
> http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup
> >
> > >
> > > Dennis
> > >
> > > ----- Original Message ----
> > > From: Thijs Vermeir <thi...@gm...>
> > > To: Zhao Liang-E3423C <E3...@mo...>
> > > Cc: Dennis Fleming <ars...@sb...>;
> > > gst...@li...
> > > Sent: Tuesday, July 29, 2008 2:46:42 AM
> > > Subject: Re: [gst-embedded] noise and stuttering
> > >
> > > Hi,
> > >
> > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao Liang-E3423C
> > <E3...@mo...>
> > > wrote:
> > >> What's the rootcause of noise and stuttering ?
> > >
> > > Now you are using only 1 thread for all the elements and if the
> > > filesrc or the decoder is too slow sometimes
> > > you don't have time to catch up. By adding the queue you put the
> > sink
> > > in another thread and now the filesrc+decoder can
> > > do some decoding in advance.
> > >
> > > Gr,
> > > Thijs
> > >
> > >>
> > >> For normal playback, it should not have issues. If decoder didn't
> > drop
> > >> data, I think alsasink did it.
> > >> By gstaudiosink mechanism, it will drop data replaced with blank
> > data when
> > >> data is late. I guess the rootcause is that.
> > >>
> > >> If that, I have no ideas except adding a queue before alsasink, and
> > when
> > >> queue is empty, pause the pipeline, it will not cause dropout, but
> > still
> > >> discontinous.
> > >>
> > >> Zhao liang
> > >> ________________________________
> > >> From: gst...@li...
> > >> [mailto:gst...@li...] On Behalf
> > Of
> > >> Dennis Fleming
> > >> Sent: Tuesday, July 29, 2008 4:37 AM
> > >> To: gst...@li...
> > >> Subject: [gst-embedded] noise and stuttering
> > >>
> > >> I'm trying to create an audio player on an IMX31 target and I've
> > found a
> > >> discrepancy in the output of various formats. If I send MP3 data I
> > have
> > >> to
> > >> set the buffer-time and latency-time to 10000 and 100 respectively
> > to play
> > >> without severe dropouts. However WAV files still have drop-out at
> > a
> > >> consistent rate (about 1 per 10 sec). Are there some general
> > features I'm
> > >> missing or is there some guidance on the buffer-time/latency time
> > that
> > >> would
> > >> account for this difference?
> > >>
> > >> Linux 2.6.22.19
> > >> gstreamer 0.10.17 (open-embedded)
> > >> gst-launch filesrc location=<file> ! decodebin ! alsasink
> > >> buffer-time=10000
> > >> latency-time=100
> > >>
> > >> Dennis
> > >>
> > >>
> > -------------------------------------------------------------------------
> > >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> > >> challenge
> > >> Build the coolest Linux based applications with Moblin SDK & win
> > great
> > >> prizes
> > >> Grand prize is a trip for two to an Open Source event anywhere in
> > the
> > >> world
> > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > >> _______________________________________________
> > >> Gstreamer-embedded mailing list
> > >> Gst...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> > >>
> > >>
> > >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________ Gstreamer-embedded
> mailing list Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> --
> Jan Schmidt <th...@no...>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Gstreamer-embedded mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>
|
|
From: Felipe C. <fel...@gm...> - 2008-07-31 20:03:08
|
Hi, On Thu, Jul 31, 2008 at 1:22 PM, Bruno Smets <bru...@nx...> wrote: > Hi, > > Felipe is itegrating the changes ... you need to set up GIT and clone > > git://github.com/felipec/gst-openmax.git I've finally managed to clean this up. The branch is tunneling-v3: http://github.com/felipec/gst-openmax/commits/tuneling-v3 This is not the final version, but it's near it. Best regards. -- Felipe Contreras |
|
From: Jan S. <th...@no...> - 2008-07-31 09:42:38
|
On Wed, 2008-07-30 at 08:50 -0700, Dennis Fleming wrote: > First off: Thank to you and Zhoa-Lang for getting back so quickly. > I'm so busy I forgot my manners. > > Testing to find the parameters I have I used decodebin, but in the > program itself uses playbin with the same effect. The only variation > is that I set the sink property to alsasink since that seems the only > way to set buffer-time and latency-time properties. Also, it seems > counter-intuitive to me that an uncompressed WAV file should have > problems keeping up while MP3s with the same sampling frequency and > word size have none. And yet the artifacts are indicative of dropped > buffers. If the bottleneck is retrieving data from the input location, then it's entirely feasible. What's your data store? SD card, NFS? A WAV file might be 10 or more times more data to read and cause read stalls, where the smaller mp3 can be read in fine and decoded in memory with no further problems. J. > Dennis > > > ----- Original Message ---- > From: Thijs Vermeir <thi...@gm...> > To: Dennis Fleming <ars...@sb...> > Cc: gst...@li... > Sent: Tuesday, July 29, 2008 3:59:30 PM > Subject: Re: [gst-embedded] noise and stuttering > > Hi, > > On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming > <ars...@sb...> wrote: > > The interesting thing is that uncompressed WAV files are causing the > problem > > while MP3s were fixed by setting the buffer-time and latency-time to > values > > smaller than found on a desktop. What would adding a queue do to > latency > > through the system? > > There is no latency in this case because there are no live-sources. > [1] > > > Also, I suppose, that I will need to break up the > > playbin and create a pipeline myself, yes? > > playbin has the queue elements on the correct location, no changes > needed. > You where already using a custom pipeline, no? > > Gr, > > [1] > http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup > > > > > Dennis > > > > ----- Original Message ---- > > From: Thijs Vermeir <thi...@gm...> > > To: Zhao Liang-E3423C <E3...@mo...> > > Cc: Dennis Fleming <ars...@sb...>; > > gst...@li... > > Sent: Tuesday, July 29, 2008 2:46:42 AM > > Subject: Re: [gst-embedded] noise and stuttering > > > > Hi, > > > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao Liang-E3423C > <E3...@mo...> > > wrote: > >> What's the rootcause of noise and stuttering ? > > > > Now you are using only 1 thread for all the elements and if the > > filesrc or the decoder is too slow sometimes > > you don't have time to catch up. By adding the queue you put the > sink > > in another thread and now the filesrc+decoder can > > do some decoding in advance. > > > > Gr, > > Thijs > > > >> > >> For normal playback, it should not have issues. If decoder didn't > drop > >> data, I think alsasink did it. > >> By gstaudiosink mechanism, it will drop data replaced with blank > data when > >> data is late. I guess the rootcause is that. > >> > >> If that, I have no ideas except adding a queue before alsasink, and > when > >> queue is empty, pause the pipeline, it will not cause dropout, but > still > >> discontinous. > >> > >> Zhao liang > >> ________________________________ > >> From: gst...@li... > >> [mailto:gst...@li...] On Behalf > Of > >> Dennis Fleming > >> Sent: Tuesday, July 29, 2008 4:37 AM > >> To: gst...@li... > >> Subject: [gst-embedded] noise and stuttering > >> > >> I'm trying to create an audio player on an IMX31 target and I've > found a > >> discrepancy in the output of various formats. If I send MP3 data I > have > >> to > >> set the buffer-time and latency-time to 10000 and 100 respectively > to play > >> without severe dropouts. However WAV files still have drop-out at > a > >> consistent rate (about 1 per 10 sec). Are there some general > features I'm > >> missing or is there some guidance on the buffer-time/latency time > that > >> would > >> account for this difference? > >> > >> Linux 2.6.22.19 > >> gstreamer 0.10.17 (open-embedded) > >> gst-launch filesrc location=<file> ! decodebin ! alsasink > >> buffer-time=10000 > >> latency-time=100 > >> > >> Dennis > >> > >> > ------------------------------------------------------------------------- > >> This SF.Net email is sponsored by the Moblin Your Move Developer's > >> challenge > >> Build the coolest Linux based applications with Moblin SDK & win > great > >> prizes > >> Grand prize is a trip for two to an Open Source event anywhere in > the > >> world > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> _______________________________________________ > >> Gstreamer-embedded mailing list > >> Gst...@li... > >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > >> > >> > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded -- Jan Schmidt <th...@no...> |
|
From: Dennis F. <ars...@sb...> - 2008-07-30 15:50:21
|
First off: Thank to you and Zhoa-Lang for getting back so quickly. I'm so busy I forgot my manners. Testing to find the parameters I have I used decodebin, but in the program itself uses playbin with the same effect. The only variation is that I set the sink property to alsasink since that seems the only way to set buffer-time and latency-time properties. Also, it seems counter-intuitive to me that an uncompressed WAV file should have problems keeping up while MP3s with the same sampling frequency and word size have none. And yet the artifacts are indicative of dropped buffers. Dennis ----- Original Message ---- From: Thijs Vermeir <thi...@gm...> To: Dennis Fleming <ars...@sb...> Cc: gst...@li... Sent: Tuesday, July 29, 2008 3:59:30 PM Subject: Re: [gst-embedded] noise and stuttering Hi, On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming <ars...@sb...> wrote: > The interesting thing is that uncompressed WAV files are causing the problem > while MP3s were fixed by setting the buffer-time and latency-time to values > smaller than found on a desktop. What would adding a queue do to latency > through the system? There is no latency in this case because there are no live-sources. [1] > Also, I suppose, that I will need to break up the > playbin and create a pipeline myself, yes? playbin has the queue elements on the correct location, no changes needed. You where already using a custom pipeline, no? Gr, [1] http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup > > Dennis > > ----- Original Message ---- > From: Thijs Vermeir <thi...@gm...> > To: Zhao Liang-E3423C <E3...@mo...> > Cc: Dennis Fleming <ars...@sb...>; > gst...@li... > Sent: Tuesday, July 29, 2008 2:46:42 AM > Subject: Re: [gst-embedded] noise and stuttering > > Hi, > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao Liang-E3423C <E3...@mo...> > wrote: >> What's the rootcause of noise and stuttering ? > > Now you are using only 1 thread for all the elements and if the > filesrc or the decoder is too slow sometimes > you don't have time to catch up. By adding the queue you put the sink > in another thread and now the filesrc+decoder can > do some decoding in advance. > > Gr, > Thijs > >> >> For normal playback, it should not have issues. If decoder didn't drop >> data, I think alsasink did it. >> By gstaudiosink mechanism, it will drop data replaced with blank data when >> data is late. I guess the rootcause is that. >> >> If that, I have no ideas except adding a queue before alsasink, and when >> queue is empty, pause the pipeline, it will not cause dropout, but still >> discontinous. >> >> Zhao liang >> ________________________________ >> From: gst...@li... >> [mailto:gst...@li...] On Behalf Of >> Dennis Fleming >> Sent: Tuesday, July 29, 2008 4:37 AM >> To: gst...@li... >> Subject: [gst-embedded] noise and stuttering >> >> I'm trying to create an audio player on an IMX31 target and I've found a >> discrepancy in the output of various formats. If I send MP3 data I have >> to >> set the buffer-time and latency-time to 10000 and 100 respectively to play >> without severe dropouts. However WAV files still have drop-out at a >> consistent rate (about 1 per 10 sec). Are there some general features I'm >> missing or is there some guidance on the buffer-time/latency time that >> would >> account for this difference? >> >> Linux 2.6.22.19 >> gstreamer 0.10.17 (open-embedded) >> gst-launch filesrc location=<file> ! decodebin ! alsasink >> buffer-time=10000 >> latency-time=100 >> >> Dennis >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Gstreamer-embedded mailing list >> Gst...@li... >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> >> > |
|
From: Jan S. <th...@no...> - 2008-07-30 14:15:14
|
On Mon, 2008-07-28 at 13:37 -0700, Dennis Fleming wrote: > I'm trying to create an audio player on an IMX31 target and I've found > a discrepancy in the output of various formats. If I send MP3 data I > have to set the buffer-time and latency-time to 10000 and 100 > respectively to play without severe dropouts. However WAV files still > have drop-out at a consistent rate (about 1 per 10 sec). Are there > some general features I'm missing or is there some guidance on the > buffer-time/latency time that would account for this difference? What if you just use the defaults? By asking for buffer-time=10000, you are only providing 10ms buffering in the audio device - if the audio thread starves for more than 10ms, you are in trouble. Unless you've taken care to ensure that your kernel provides fine-grained timeslices and that the system isn't going to be too busy to service the audio thread, that'll be fine, but unless you really need the low-latency behaviour (you don't for just playing music), why not set it higher? J. > > Linux 2.6.22.19 > gstreamer 0.10.17 (open-embedded) > gst-launch filesrc location=<file> ! decodebin ! alsasink > buffer-time=10000 latency-time=100 > > Dennis > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded -- Jan Schmidt <th...@no...> |
|
From: Ling S. <sh...@gm...> - 2008-07-30 13:15:26
|
Felipe and Bruno, Thank for your reply. We have a very similar idea on how to use OMX in gst. Now, I got more confidence to use, involve, and contribute into this project. Brouno, Could you tell me where can find your change? Is it possible for me to study your code before release? Felipe, TI OMAP 3xxx is just one of our target platform. I just got an TI OMAP 3xxx board in test. I will investigate the OMX IL code from omap zoom. Please check other comments in line. On Wed, Jul 30, 2008 at 4:39 PM, Felipe Contreras < fel...@no...> wrote: > Hi, > > On Wed, 2008-07-30 at 15:00 +0800, ext Ling Shi wrote: > > Hi, all > > I'm in a research project to port gstreamer into embedded system. Now, > > we encounter the issue on how to integrate hardware accelerators > > (DSP/GPU) into gst. After evaluating different solution, we think > > GstOpenMAX project may be the best one for us, because > > > > 1) OpenMAX is an industry standard > > 2) more and more DSP/GPU vendor support OpenMAX > > > > But, I still have several questions on this project. > > 1. Does Nokia N8xx serials use GstOpenMAX? > > I know Nokia engineers lead this project. I also know N8xx serials use > > gstreamer as default playback engine, and it uses TI OMAP 2420, which > > has DSP. Can anyone tell me if N8xx use GstOpenMAX? If no, does N8xx > > plan to use it in the future? > > The current Maemo Products don't use OpenMAX IL, they use TI's DSP > directly through the open source version of the DSP bridge (DSP > gateway). > > The plan is to use OpenMAX IL so we can choose between different > implementations without much effort. > > TI has started to provide their OpenMAX IL source code: > http://omapzoom.org/gf/project/openmax/wiki/ > > > 2. What's GstOpenMAX plan to support DSP/GPU in the future? > > I review several plugins in GstOpenMAX and find current design can > > only support none-tunnel communication. It's not the best solution in > > hardware, because of bad performance. So, we plan to improve it by > > adding tunneled or proprietary communication. Do you have such plan? > > If yes, can we involve in design? > > Indeed, as Bruno mentions, NXP has contributed code that adds support > for tunneled communication. It is maintained in a separate branch and > will soon be merged to the master branch. > > > In addition, most accelerators work as a decoder and a render. It > > means, the encoded data sent to it will directly be decoded and > > rendered, and will not be retrieved back again. How the gst or omx > > organize its pipeline in this situation? We are evaluating two > > solutions. > > > > ===Solution 1=== > > We can design a super omx sink component to cover decoder and render. > > This is the solution is used by N8xx. > > src ! demux ! sink > > | > > super omx sink > > | > > +--------------------------------------------+ > > | hardware accelerator | > > +--------------------------------------------+ > > The disadvantage of this solution is that it requires the creation of > many elements to cover all the possible combination of elements. This > becomes specially a problem when you add for example some filtering, > like a volume control, etc. [Shi Ling] You idea is exaclty same with me. I also think it's not a good solution. > > > > ===Solution 2=== > > We can separate omx decoder, omx post processer, and omx sink > > elements. We enhance decoder, post processor, and sink plugin in > > GstOpenMAX. If GstOpenMAX plugin found its neighborhood are GstOpenMAX > > plugin, it will try to establish tunneled communication or proprietary > > communication firstly. It means, although we have 3 OMX plugin in gst > > pipeline, there is no data in gst pad and omx port. The last two > > gst/omx plugin only provide control function, but not support process > > data flow. Of cause, If the connection is failed, it will use > > none-tunnel communication. > > > > src ! demux ! decoder ! post processor ! sink > > | | | > > omx dec omx pp omx sink > > | | | > > +--------------------------------------------+ > > | hardware accelerator | > > +--------------------------------------------+ > > > > It seems solution 2 is more flexible. How about your suggestion on the > > 2 solutions? Which one is feasible? Do you have other solutions? > > This is exactly how NXP implemented it and seems to be working fine. > > The problem I see with both solutions is that there will be A/V sync > issues when using OMX sinks in tunneling mode. The idea is to solve > these issues by mapping the OMX clock to the GST clock. However, this > hasn't been implemented yet. > [Shi Ling] Yes, so many things need to be improved in the future. > > Best regards. > > -- > Felipe Contreras > > |
|
From: Felipe C. <fel...@no...> - 2008-07-30 08:40:13
|
Hi, On Wed, 2008-07-30 at 15:00 +0800, ext Ling Shi wrote: > Hi, all > I'm in a research project to port gstreamer into embedded system. Now, > we encounter the issue on how to integrate hardware accelerators > (DSP/GPU) into gst. After evaluating different solution, we think > GstOpenMAX project may be the best one for us, because > > 1) OpenMAX is an industry standard > 2) more and more DSP/GPU vendor support OpenMAX > > But, I still have several questions on this project. > 1. Does Nokia N8xx serials use GstOpenMAX? > I know Nokia engineers lead this project. I also know N8xx serials use > gstreamer as default playback engine, and it uses TI OMAP 2420, which > has DSP. Can anyone tell me if N8xx use GstOpenMAX? If no, does N8xx > plan to use it in the future? The current Maemo Products don't use OpenMAX IL, they use TI's DSP directly through the open source version of the DSP bridge (DSP gateway). The plan is to use OpenMAX IL so we can choose between different implementations without much effort. TI has started to provide their OpenMAX IL source code: http://omapzoom.org/gf/project/openmax/wiki/ > 2. What's GstOpenMAX plan to support DSP/GPU in the future? > I review several plugins in GstOpenMAX and find current design can > only support none-tunnel communication. It's not the best solution in > hardware, because of bad performance. So, we plan to improve it by > adding tunneled or proprietary communication. Do you have such plan? > If yes, can we involve in design? Indeed, as Bruno mentions, NXP has contributed code that adds support for tunneled communication. It is maintained in a separate branch and will soon be merged to the master branch. > In addition, most accelerators work as a decoder and a render. It > means, the encoded data sent to it will directly be decoded and > rendered, and will not be retrieved back again. How the gst or omx > organize its pipeline in this situation? We are evaluating two > solutions. > > ===Solution 1=== > We can design a super omx sink component to cover decoder and render. > This is the solution is used by N8xx. > src ! demux ! sink > | > super omx sink > | > +--------------------------------------------+ > | hardware accelerator | > +--------------------------------------------+ The disadvantage of this solution is that it requires the creation of many elements to cover all the possible combination of elements. This becomes specially a problem when you add for example some filtering, like a volume control, etc. > ===Solution 2=== > We can separate omx decoder, omx post processer, and omx sink > elements. We enhance decoder, post processor, and sink plugin in > GstOpenMAX. If GstOpenMAX plugin found its neighborhood are GstOpenMAX > plugin, it will try to establish tunneled communication or proprietary > communication firstly. It means, although we have 3 OMX plugin in gst > pipeline, there is no data in gst pad and omx port. The last two > gst/omx plugin only provide control function, but not support process > data flow. Of cause, If the connection is failed, it will use > none-tunnel communication. > > src ! demux ! decoder ! post processor ! sink > | | | > omx dec omx pp omx sink > | | | > +--------------------------------------------+ > | hardware accelerator | > +--------------------------------------------+ > > It seems solution 2 is more flexible. How about your suggestion on the > 2 solutions? Which one is feasible? Do you have other solutions? This is exactly how NXP implemented it and seems to be working fine. The problem I see with both solutions is that there will be A/V sync issues when using OMX sinks in tunneling mode. The idea is to solve these issues by mapping the OMX clock to the GST clock. However, this hasn't been implemented yet. Best regards. -- Felipe Contreras |
|
From: Ling S. <sh...@gm...> - 2008-07-30 07:04:15
|
---------- Forwarded message ----------
From: Ling Shi <sh...@gm...>
Date: Wed, Jul 30, 2008 at 3:00 PM
Subject: Discussion on the hardware accelerator solution in GstOpenMAX
project.
To: gst...@li...
Hi, all
I'm in a research project to port gstreamer into embedded system. Now, we
encounter the issue on how to integrate hardware accelerators (DSP/GPU) into
gst. After evaluating different solution, we think GstOpenMAX project may be
the best one for us, because
1) OpenMAX is an industry standard
2) more and more DSP/GPU vendor support OpenMAX
But, I still have several questions on this project.
1. Does Nokia N8xx serials use GstOpenMAX?
I know Nokia engineers lead this project. I also know N8xx serials use
gstreamer as default playback engine, and it uses TI OMAP 2420, which has
DSP. Can anyone tell me if N8xx use GstOpenMAX? If no, does N8xx plan to use
it in the future?
2. What's GstOpenMAX plan to support DSP/GPU in the future?
I review several plugins in GstOpenMAX and find current design can only
support none-tunnel communication. It's not the best solution in hardware,
because of bad performance. So, we plan to improve it by adding tunneled or
proprietary communication. Do you have such plan? If yes, can we involve in
design?
In addition, most accelerators work as a decoder and a render. It means, the
encoded data sent to it will directly be decoded and rendered, and will not
be retrieved back again. How the gst or omx organize its pipeline in this
situation? We are evaluating two solutions.
===Solution 1===
We can design a super omx sink component to cover decoder and render. This
is the solution is used by N8xx.
src ! demux ! sink
|
super omx sink
|
+--------------------------------------------+
| hardware accelerator |
+--------------------------------------------+
===Solution 2===
We can separate omx decoder, omx post processer, and omx sink elements. We
enhance decoder, post processor, and sink plugin in GstOpenMAX. If
GstOpenMAX plugin found its neighborhood are GstOpenMAX plugin, it will try
to establish tunneled communication or proprietary communication firstly. It
means, although we have 3 OMX plugin in gst pipeline, there is no data in
gst pad and omx port. The last two gst/omx plugin only provide control
function, but not support process data flow. Of cause, If the connection is
failed, it will use none-tunnel communication.
src ! demux ! decoder ! post processor ! sink
| | |
omx dec omx pp omx sink
| | |
+--------------------------------------------+
| hardware accelerator |
+--------------------------------------------+
It seems solution 2 is more flexible. How about your suggestion on the 2
solutions? Which one is feasible? Do you have other solutions?
Thank you very much.
|
|
From: Thijs V. <thi...@gm...> - 2008-07-29 22:59:22
|
Hi, On Tue, Jul 29, 2008 at 5:43 PM, Dennis Fleming <ars...@sb...> wrote: > The interesting thing is that uncompressed WAV files are causing the problem > while MP3s were fixed by setting the buffer-time and latency-time to values > smaller than found on a desktop. What would adding a queue do to latency > through the system? There is no latency in this case because there are no live-sources. [1] > Also, I suppose, that I will need to break up the > playbin and create a pipeline myself, yes? playbin has the queue elements on the correct location, no changes needed. You where already using a custom pipeline, no? Gr, [1] http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?view=markup > > Dennis > > ----- Original Message ---- > From: Thijs Vermeir <thi...@gm...> > To: Zhao Liang-E3423C <E3...@mo...> > Cc: Dennis Fleming <ars...@sb...>; > gst...@li... > Sent: Tuesday, July 29, 2008 2:46:42 AM > Subject: Re: [gst-embedded] noise and stuttering > > Hi, > > On Tue, Jul 29, 2008 at 11:15 AM, Zhao Liang-E3423C <E3...@mo...> > wrote: >> What's the rootcause of noise and stuttering ? > > Now you are using only 1 thread for all the elements and if the > filesrc or the decoder is too slow sometimes > you don't have time to catch up. By adding the queue you put the sink > in another thread and now the filesrc+decoder can > do some decoding in advance. > > Gr, > Thijs > >> >> For normal playback, it should not have issues. If decoder didn't drop >> data, I think alsasink did it. >> By gstaudiosink mechanism, it will drop data replaced with blank data when >> data is late. I guess the rootcause is that. >> >> If that, I have no ideas except adding a queue before alsasink, and when >> queue is empty, pause the pipeline, it will not cause dropout, but still >> discontinous. >> >> Zhao liang >> ________________________________ >> From: gst...@li... >> [mailto:gst...@li...] On Behalf Of >> Dennis Fleming >> Sent: Tuesday, July 29, 2008 4:37 AM >> To: gst...@li... >> Subject: [gst-embedded] noise and stuttering >> >> I'm trying to create an audio player on an IMX31 target and I've found a >> discrepancy in the output of various formats. If I send MP3 data I have >> to >> set the buffer-time and latency-time to 10000 and 100 respectively to play >> without severe dropouts. However WAV files still have drop-out at a >> consistent rate (about 1 per 10 sec). Are there some general features I'm >> missing or is there some guidance on the buffer-time/latency time that >> would >> account for this difference? >> >> Linux 2.6.22.19 >> gstreamer 0.10.17 (open-embedded) >> gst-launch filesrc location=<file> ! decodebin ! alsasink >> buffer-time=10000 >> latency-time=100 >> >> Dennis >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Gstreamer-embedded mailing list >> Gst...@li... >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded >> >> > |
|
From: Thijs V. <thi...@gm...> - 2008-07-29 09:46:32
|
Hi, On Tue, Jul 29, 2008 at 11:15 AM, Zhao Liang-E3423C <E3...@mo...> wrote: > What's the rootcause of noise and stuttering ? Now you are using only 1 thread for all the elements and if the filesrc or the decoder is too slow sometimes you don't have time to catch up. By adding the queue you put the sink in another thread and now the filesrc+decoder can do some decoding in advance. Gr, Thijs > > For normal playback, it should not have issues. If decoder didn't drop > data, I think alsasink did it. > By gstaudiosink mechanism, it will drop data replaced with blank data when > data is late. I guess the rootcause is that. > > If that, I have no ideas except adding a queue before alsasink, and when > queue is empty, pause the pipeline, it will not cause dropout, but still > discontinous. > > Zhao liang > ________________________________ > From: gst...@li... > [mailto:gst...@li...] On Behalf Of > Dennis Fleming > Sent: Tuesday, July 29, 2008 4:37 AM > To: gst...@li... > Subject: [gst-embedded] noise and stuttering > > I'm trying to create an audio player on an IMX31 target and I've found a > discrepancy in the output of various formats. If I send MP3 data I have to > set the buffer-time and latency-time to 10000 and 100 respectively to play > without severe dropouts. However WAV files still have drop-out at a > consistent rate (about 1 per 10 sec). Are there some general features I'm > missing or is there some guidance on the buffer-time/latency time that would > account for this difference? > > Linux 2.6.22.19 > gstreamer 0.10.17 (open-embedded) > gst-launch filesrc location=<file> ! decodebin ! alsasink buffer-time=10000 > latency-time=100 > > Dennis > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gstreamer-embedded mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > |
|
From: Zhao Liang-E. <E3...@mo...> - 2008-07-29 09:16:43
|
What's the rootcause of noise and stuttering ? For normal playback, it should not have issues. If decoder didn't drop data, I think alsasink did it. By gstaudiosink mechanism, it will drop data replaced with blank data when data is late. I guess the rootcause is that. If that, I have no ideas except adding a queue before alsasink, and when queue is empty, pause the pipeline, it will not cause dropout, but still discontinous. Zhao liang ________________________________ From: gst...@li... [mailto:gst...@li...] On Behalf Of Dennis Fleming Sent: Tuesday, July 29, 2008 4:37 AM To: gst...@li... Subject: [gst-embedded] noise and stuttering I'm trying to create an audio player on an IMX31 target and I've found a discrepancy in the output of various formats. If I send MP3 data I have to set the buffer-time and latency-time to 10000 and 100 respectively to play without severe dropouts. However WAV files still have drop-out at a consistent rate (about 1 per 10 sec). Are there some general features I'm missing or is there some guidance on the buffer-time/latency time that would account for this difference? Linux 2.6.22.19 gstreamer 0.10.17 (open-embedded) gst-launch filesrc location=<file> ! decodebin ! alsasink buffer-time=10000 latency-time=100 Dennis |
|
From: Dennis F. <ars...@sb...> - 2008-07-28 20:37:08
|
I'm trying to create an audio player on an IMX31 target and I've found a discrepancy in the output of various formats. If I send MP3 data I have to set the buffer-time and latency-time to 10000 and 100 respectively to play without severe dropouts. However WAV files still have drop-out at a consistent rate (about 1 per 10 sec). Are there some general features I'm missing or is there some guidance on the buffer-time/latency time that would account for this difference? Linux 2.6.22.19 gstreamer 0.10.17 (open-embedded) gst-launch filesrc location=<file> ! decodebin ! alsasink buffer-time=10000 latency-time=100 Dennis |
10 messages has been excluded from this view by a project administrator.
