5 Feb
2007
5 Feb
'07
4:14 p.m.
I've been using rhythmbox for listening to my mp3 files on my Ubuntu
laptop. Mostly this was because it supports daap sharing, and gives me
a nice interface for choosing songs. It works well except I've been
having sound quality problems.
I seem to get some minor distortion, and some pops and cracks when
playing a lot of my mp3 files. I took one especially problematic file
and played it with alsaplayer and had no troubles (at a louder volume
even). I'm about 98% sure that somehow gstreamer is peaking/clipping,
even when the volume is way down.
Banshee, I've noticed, does the same thing.
mpg123 and mpg321 seem to have no problems. xine engine of amarok seems
to work.
Has anyone else noticed anything like this? Is this a problem with
gstreamer in general? What's going on here? What's with the levels
that it would clip when it's not even loud?
(and I really wish there was a jack backend for gstreamer)
Any comments, suggestions? Does anyone here follow gstreamer at all?
--
-= =- vroetman(a)myrealbox.com -= =-
5 Feb
5 Feb
5:09 p.m.
Victor Roetman wrote:
I've been using rhythmbox for listening to my mp3
files on my Ubuntu
laptop. Mostly this was because it supports daap sharing, and gives me
a nice interface for choosing songs. It works well except I've been
having sound quality problems.
I seem to get some minor distortion, and some pops and cracks when
playing a lot of my mp3 files. I took one especially problematic file
and played it with alsaplayer and had no troubles (at a louder volume
even). I'm about 98% sure that somehow gstreamer is peaking/clipping,
even when the volume is way down.
Banshee, I've noticed, does the same thing.
mpg123 and mpg321 seem to have no problems. xine engine of amarok seems
to work.
Has anyone else noticed anything like this? Is this a problem with
gstreamer in general? What's going on here? What's with the levels
that it would clip when it's not even loud?
(and I really wish there was a jack backend for gstreamer)
Any comments, suggestions? Does anyone here follow gstreamer at all?
Hmmm... I would suggest that it was some sort of buffer overrun and
apparently specifically in gstreamer since the xine engine and others
run ok? I run Gstreamer 10 without any problems on a Ubuntu Feisty
Herd 3 system. What are you running for version and distro?
-Jon
--------------------------------------
http://www.linux-studio.org
For the artist in everyone!
6 Feb
6 Feb
11:02 p.m.
oktyabr wrote:
Victor Roetman wrote:
6.10 Edgy, and it's gstreamer 10 because I removed all the gstreamer 8
files.
I seem to get some minor distortion, and some
pops and cracks when
playing a lot of my mp3 files. I took one especially problematic file
and played it with alsaplayer and had no troubles (at a louder volume
even). I'm about 98% sure that somehow gstreamer is peaking/clipping,
even when the volume is way down.
run ok? I run Gstreamer 10 without any problems on a Ubuntu Feisty
Herd 3 system. What are you running for version and distro? 
5 Feb
5 Feb
5:41 p.m.
On Mon Feb 05, 2007 at 01:59:29PM -0600, Victor Roetman wrote:
I've been using rhythmbox for listening to my mp3
files on my Ubuntu
laptop. Mostly this was because it supports daap sharing, and gives me
I seem to get some minor distortion, and some pops and
cracks when
playing a lot of my mp3 files. I took one especially problematic file
Banshee, I've noticed, does the same thing.
mpg123 and mpg321 seem to have no problems. xine engine of amarok seems
to work.
Has anyone else noticed anything like this? Is this a problem with
gstreamer in general?
i guess you could say its a design issue inherent to all of these 'abstract away all
the native APIs' things - theres more parts that can malfunction
i think youre one of the lucky ones. in general, rhythmbox cant even properly skip through
a file for me, using its seekbar. its even worse with DAAP - clicking on the seekbar
usually skips it to the next file oer freezes up the app entirely (the same mt-daapd works
fine with iTunes on the same PC booted into XP). quodlibet refuses to put FLACs in its
supported format list, and using the gstreamer JACK sink to play mp3s, sent its CPU usage
to 94%, with lots of skips. its also really slow to startup (about as slow as amarok which
needs to launch 5 or 6 kde daemons so that the file-pane works or something)
amarok is a similar story. they removed the gstreamer sink, or at least made it really
hard to enable it, leaving one only with XINE. with XINE, if you play FLACs, theres tons
of dropouts, if you use the jack sink. if you use the alsa sink, theres no dropouts. but
then you are using jackplug, which is more prone to freezes/dropouts itself. generlaly
amarok freezes after every 3 tracks here, so ive given up on it as well.
banshee is even worse, generally freezing up while populating the library, let alone
playing a track. but then amarok freezes populating the library until i move
utf-8/shift-jis dirs out of the music directory as well..
audacious has a tendency to leave ghosted jack clients (i think it uses some really old
bio2jack code that they dont bother updating much), and it doesnt have a library anyways.
ive resorted to just using mplayer for everything. and a bash alias to regenerate the
'library' with gnu find. its simply the only player that is anywhere near stable,
dropout/glitch-free playback with JACK. it still freezes up on 0 byte files that rtorrent
recreated after i deleted their directory..but that pales in comparison to trying to get a
XINE or GST player to work right..
What's going on here? What's with the levels
that it would clip when it's not even loud?
(and I really wish there was a jack backend for gstreamer)
there is. it didnt work very well for me (worse than alsa+plug:jack, just like XINE) but
you might want to give it a shot
Any comments, suggestions? Does anyone here follow gstreamer at all?
--
-= =- vroetman(a)myrealbox.com -= =-
5:47 p.m.
ive resorted to just using mplayer for everything. and
a bash alias to regenerate the 'library' with gnu find
alias pl='find /media \( -iregex ".*.flac" -o -iregex ".*.mp3" \)
-not -iregex "/media/samples/.*" > /media/.pls'
alias m=mplayer
alias mp='m -loop 0 -shuffle -playlist /media/.pls'
6:07 p.m.
On Mon, 2007-02-05 at 16:41 -0500, carmen wrote:
On Mon Feb 05, 2007 at 01:59:29PM -0600, Victor
Roetman wrote:
carmen, judging from the rest of your post, CPU usage was the main
issue.
this is actually not a consequence of the JACK sink directly, but the
appalling unoptimized resampling code in gstreamer. if you connect the
JACK sink up to a stream that is already at the JACK sample rate, i have
found you see the expected (low) CPU utilization.
the gstreamer guys know about this, but there is nobody available or
with the know-how to speed it up. libsamplerate is not an option,
apparently, because of the license :((
(and I really wish there was a jack backend for gstreamer)
there is. it didnt work very well for me (worse than alsa+plug:jack, just like XINE) but
you might want to give it a shot 
6:17 p.m.
Paul Davis wrote:
On Mon, 2007-02-05 at 16:41 -0500, carmen wrote:
I've been warned by a number of Linux folk to avoid GStreamer.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
On Mon Feb 05, 2007 at 01:59:29PM -0600, Victor
Roetman wrote:
carmen, judging from the rest of your post, CPU usage was the main
issue.
this is actually not a consequence of the JACK sink directly, but the
appalling unoptimized resampling code in gstreamer. if you connect the
JACK sink up to a stream that is already at the JACK sample rate, i have
found you see the expected (low) CPU utilization.
the gstreamer guys know about this, but there is nobody available or
with the know-how to speed it up. libsamplerate is not an option,
apparently, because of the license :(( (and I really wish there was a jack backend for
gstreamer)
there is. it didnt work very well for me (worse than alsa+plug:jack,
just like XINE) but you might want to give it a shot
6:42 p.m.
On Mon, 2007-02-05 at 12:17 -1000, david wrote:
Paul Davis wrote:
i think thats a mistake. gstreamer has quite a complex API and a very
complex internal design, but it solves a number of problems that nobody
else has bothered to solve.
On Mon, 2007-02-05 at 16:41 -0500, carmen wrote:
I've been warned by a number of Linux folk to avoid GStreamer. On Mon Feb 05, 2007 at 01:59:29PM -0600, Victor
Roetman wrote:
carmen, judging from the rest of your post, CPU usage was the main
issue.
this is actually not a consequence of the JACK sink directly, but the
appalling unoptimized resampling code in gstreamer. if you connect the
JACK sink up to a stream that is already at the JACK sample rate, i have
found you see the expected (low) CPU utilization.
the gstreamer guys know about this, but there is nobody available or
with the know-how to speed it up. libsamplerate is not an option,
apparently, because of the license :(( (and I really wish there was a jack backend for
gstreamer)
there is. it didnt work very well for me (worse than alsa+plug:jack,
just like XINE) but you might want to give it a shot
7:46 p.m.
Paul Davis wrote:
On Mon, 2007-02-05 at 12:17 -1000, david wrote:
Like what? I play media stuff of all kinds without GStreamer even installed.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
Paul Davis wrote:
i think thats a mistake. gstreamer has quite a complex API and a very
complex internal design, but it solves a number of problems that nobody
else has bothered to solve. On Mon, 2007-02-05 at 16:41 -0500, carmen wrote:
I've been warned by a number of Linux
folk to avoid GStreamer. On Mon Feb 05, 2007 at 01:59:29PM -0600, Victor
Roetman wrote:
> (and I really wish there was a jack backend for gstreamer)
there is. it didnt work very well for me (worse than alsa+plug:jack, just like XINE) but
you might want to give it a shot
carmen, judging from the rest of your post, CPU
usage was the main
issue.
this is actually not a consequence of the JACK sink directly, but the
appalling unoptimized resampling code in gstreamer. if you connect the
JACK sink up to a stream that is already at the JACK sample rate, i have
found you see the expected (low) CPU utilization.
the gstreamer guys know about this, but there is nobody available or
with the know-how to speed it up. libsamplerate is not an option,
apparently, because of the license :((
11:34 p.m.
it solves a
number of problems that nobody
else has bothered to solve.
Like what? I play media stuff of all kinds without GStreamer even installed.
11:41 p.m.
On Mon, 2007-02-05 at 22:34 -0500, carmen wrote:
what happens when your card doesn't have dmix, and gstreamer is
already playing a stream at 48khz to hw:0,1, and another app wants to
play a 44.1 khz beep to the same output. does it via some mutex/IPC
magic switch over to software mixing the two streams, without
requiring a resident sound daemon? if so, i'd consider that a solved
problem that nobody else wanted to tackle..
gstreamer doesn't solve that problem. far from it. other than the fact
that it can talk to some audio sinks that do solve it.
the kinds of problem i am referring to have to do mostly with complex
sync cases when an app is playing two streams (e.g. video + audio) and
needs to maintain careful sync no matter what the downstream data
pathway looks like. also, it has some abilities to split and recombine
data streams in ways that are not useful for everyday use but can be
very handy in a toolbox.finally, the existence of *legal* MP3 codecs for
gst from fluendo (with other codecs to come) should not be overlooked.
i am by no means a gstreamer fanboy, but i do think that the gst
architecture has evolved over quite a significant period to be able to
do things that, AFAIK, no other media framework on linux does.
--p
it solves a number of problems that nobody
else has bothered to solve.
Like what? I play media stuff of all kinds without GStreamer even installed.
6 Feb
6 Feb
4:12 a.m.
Paul Davis wrote:
On Mon, 2007-02-05 at 22:34 -0500, carmen wrote:
what happens when your card doesn't have dmix, and
gstreamer is
already playing a stream at 48khz to hw:0,1, and another app wants to
play a 44.1 khz beep to the same output. does it via some mutex/IPC
magic switch over to software mixing the two streams, without
requiring a resident sound daemon? if so, i'd consider that a solved
problem that nobody else wanted to tackle..
gstreamer doesn't solve that problem. far from it. other than the fact
that it can talk to some audio sinks that do solve it.
the kinds of problem i am referring to have to do mostly with complex
sync cases when an app is playing two streams (e.g. video + audio) and
needs to maintain careful sync no matter what the downstream data
pathway looks like. also, it has some abilities to split and recombine
data streams in ways that are not useful for everyday use but can be
very handy in a toolbox.finally, the existence of *legal* MP3 codecs for
gst from fluendo (with other codecs to come) should not be overlooked.
i am by no means a gstreamer fanboy, but i do think that the gst
architecture has evolved over quite a significant period to be able to
do things that, AFAIK, no other media framework on linux does.
ok, sort of sounds like a solution in search of a problem to me. I guess
I've not encountered anything needing it's abilities.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
it solves a number of problems that nobody
else has bothered to solve.
Like what? I play media stuff of all kinds without
GStreamer even installed. 
9:54 a.m.
On Tuesday 06 February 2007, david wrote:
Paul Davis wrote:
Oh well, there are many uses. I.e. writing a video editor and other multimedia
apps should become pretty easy. I.e. there's a gstreamer based hd recording
software (jokosher) and while i haven't tried it in a while it looked quite
promising.
Then there's the whole field of video editing where the sync issues paul
mentioned are extremely important. I think there's evolving video editor
software based on gstreamer. I.e. pitivi.
Thirdly it's a multimedia framework that is very easy usable for custom
application developers. I have written a media player for a client (to be
used in neuroscientific experiments) based on gstreamers playbin element and
XV overlay into a gtk+ window with very little problems (actually most of the
code is logic for the experiments and the gstreamer handling code is very
very small compared to the other stuff)..
If you look at the history of multimedia on linux you will see that every app
basically has reinvented the wheel and since there's a myriad of apps, this
has been done a myriad of times. gstreamer tries to overcome this by
providing a powerful and usable framework. And it's really working pretty
well these days..
Flo
P.S.: try i.e.:
gst-launch-0.10 playbin uri=file:///path/to/some/media/file
on the commandline. Be it video or audio, here on my box this even plays avi's
and wmv's.. And setting up a video for playback from within an application
isn't much harder than that (if you don't need the advanced possibilities
gstreamer offers on top of that)..
It even automagically uses jack if it's running :) (this is on ubuntu feisty
though)
P.P.S.: I'm not a gstreamer fanboy either but looking at it objectively, it's
a big step forward for linux multimedia..
--
Palimm Palimm!
http://tapas.affenbande.org
On Mon, 2007-02-05 at 22:34 -0500, carmen wrote:
gstreamer doesn't solve that problem. far from it. other than the fact
that it can talk to some audio sinks that do solve it.
the kinds of problem i am referring to have to do mostly with complex
sync cases when an app is playing two streams (e.g. video + audio) and
needs to maintain careful sync no matter what the downstream data
pathway looks like. also, it has some abilities to split and recombine
data streams in ways that are not useful for everyday use but can be
very handy in a toolbox.finally, the existence of *legal* MP3 codecs for
gst from fluendo (with other codecs to come) should not be overlooked.
i am by no means a gstreamer fanboy, but i do think that the gst
architecture has evolved over quite a significant period to be able to
do things that, AFAIK, no other media framework on linux does.
ok, sort of sounds like a solution in search of a problem to me. I guess
I've not encountered anything needing it's abilities. > it
solves a number of problems that nobody
> else has bothered to solve.
Like what? I play media stuff of all kinds without GStreamer even
installed.
what happens when your card doesn't have dmix, and gstreamer is
already playing a stream at 48khz to hw:0,1, and another app wants to
play a 44.1 khz beep to the same output. does it via some mutex/IPC
magic switch over to software mixing the two streams, without
requiring a resident sound daemon? if so, i'd consider that a solved
problem that nobody else wanted to tackle..
8 Feb
8 Feb
12:36 a.m.
Florian Schmidt wrote:
gst-launch-0.10 playbin
uri=file:///path/to/some/media/file
So how can I then route this directly to a wav file so I can see what
it's doing?
Also, how can I know exactly which plugin it's using when playing the file?
I still think it's clipping and I want to find out where in the pipeline
this is happening.
It even automagically uses jack if it's running :)
(this is on ubuntu feisty
though)
Wow! That's almost enough for me to move my system forward. Or maybe
try the feisty gstreamer source packages on edgy.
3:20 a.m.
Victor Roetman wrote:
Florian Schmidt wrote:
Try removing one plugin at a time and listening for the clipping. Repeat
until you find which one is doing it.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
gst-launch-0.10 playbin
uri=file:///path/to/some/media/file
So how can I then route this directly to a wav file so I can see what
it's doing?
Also, how can I know exactly which plugin it's using when playing the file?
I still think it's clipping and I want to find out where in the pipeline
this is happening. 
3:48 a.m.
Victor Roetman wrote:
Wow! That's almost enough for me to move my
system forward. Or maybe
try the feisty gstreamer source packages on edgy.
Don't fear Feisty. I upgraded from Dapper to Edgy on my laptop and
Edgy was a complete disaster. I then went to Debian but couldn't
get everything working and ended up trying Feisty instead. For
me, on my hardware, Feisty is as good as Dapper and much better
than Edgy.
Erik
PS : For those unfamiliar with Dapper, Edgy and Feisty, they are
3 different releases of the Ubuntu Linux distribution :-).
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz
10:28 a.m.
On Thursday 08 February 2007, Victor Roetman wrote:
Florian Schmidt wrote:
You can't afaik. The playbin is as automatic as possible. It just offers
playback of most media types gstreamer can handle. If you want finer grained
control you will have to assemble the pipeline yourself.
gst-inspect-0.10 playbin
tells me though that it has an audio-sink property which is set to NULL which
means it uses whatever the default specifies. I suppose you can override
that. Maybe not from gst-launch, but easily enough from within C code (the
audio-sink property takes an audiosink object, not a string)..
If you just run
gst-inspect-0.10
you get a list of plugins which includes a filesink.
gst-launch-0.10 playbin
uri=file:///path/to/some/media/file
So how can I then route this directly to a wav file so I can see what
it's doing? Also, how can I know exactly which plugin it's
using when playing the file?
I'm in no way a gstreamer expert though, so maybe it is possible to get that
info out of the playbin..
But the gst-launch-0.10 command can launch more complex pipelines, too
AH the guys in #gstreamer were nice enough to help me out with a pipeline that
writes into an audio file:
15:09 < MikeS> tapas: but maybe you actually want something more like
"gst-launch file:///path/to/some/media/file ! decodebin !
audioconvert ! audioresample !
"audio/x-raw-int,width=16,depth=16,channels=2,rate=44100" !
filesink location=out.raw
Which writes the audio stream of the media file (be it a movie or a soundfile)
to the out.raw file..
I still think it's clipping and I want to find out where in the pipeline
this is happening.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
It even automagically uses jack if it's
running :) (this is on ubuntu
feisty though)
Wow! That's almost enough for me to move my system forward. Or maybe
try the feisty gstreamer source packages on edgy. 
5 Feb
5 Feb
11:51 p.m.
On 2/5/07, carmen <_(a)whats-your.name> wrote:
what happens when your card doesn't have dmix, and gstreamer is already playing a
stream at 48khz to hw:0,1, and another app wants to play a 44.1 khz beep to the same
output. does it via some mutex/IPC magic switch over to software mixing the two streams,
without requiring a resident sound daemon? if so, i'd consider that a solved problem
that nobody else wanted to tackle..
There's no such thing as a "card that doesn't have dmix" - dmix is
implemented in software anc can work for any device.
If ALSA does not enable it for your device by default that should be
filed as a bug.
Lee
it solves a number of problems that nobody
else has bothered to solve.
Like what? I play media stuff of all kinds without GStreamer even installed.
6 Feb
6 Feb
9:58 a.m.
On Tuesday 06 February 2007, Lee Revell wrote:
BTW: do you know whether ALSA per default uses the dsnop/dmix/asym trinity? Or
does it provide only dmix for the playback direction?
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
what happens
when your card doesn't have dmix, and gstreamer is already
playing a stream at 48khz to hw:0,1, and another app wants to play a 44.1
khz beep to the same output. does it via some mutex/IPC magic switch over
to software mixing the two streams, without requiring a resident sound
daemon? if so, i'd consider that a solved problem that nobody else wanted
to tackle..
There's no such thing as a "card that doesn't have dmix" - dmix is
implemented in software anc can work for any device.
If ALSA does not enable it for your device by default that should be
filed as a bug.
9 Feb
9 Feb
10:57 p.m.
On 2/6/07, Florian Schmidt <mista.tapas(a)gmx.net> wrote:
On Tuesday 06 February 2007, Lee Revell wrote:
Last time I checked it does for everything that needs it, with the big
exception of USB devices.
Lee
There's no such thing as a "card that
doesn't have dmix" - dmix is
implemented in software anc can work for any device.
If ALSA does not enable it for your device by default that should be
filed as a bug.
BTW: do you know whether ALSA per default uses the dsnop/dmix/asym trinity? Or
does it provide only dmix for the playback direction?
6 Feb
6 Feb
4:14 a.m.
carmen wrote:
what happens when your card doesn't have dmix, and gstreamer is
already playing a stream at 48khz to hw:0,1, and another app wants to
play a 44.1 khz beep to the same output. does it via some mutex/IPC
magic switch over to software mixing the two streams, without
requiring a resident sound daemon? if so, i'd consider that a solved
problem that nobody else wanted to tackle..
I don't know. I seem to have no problems hearing beeps from one app
while some other one is playing a video or music ... just using ALSA here.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
it solves a number of problems that nobody else has
bothered to
solve.
Like what? I play media stuff of all kinds without GStreamer even
installed. 
4:27 a.m.
On Tuesday 06 February 2007 10:14, david wrote:
> what happens when your card doesn't have dmix
AFAIK dmix is the software-mixing mechanism used by ALSA when your card
doesn't have hardware mixing (as such isn't hardware dependant :)) - setup by
default in modern Linuxes...
the existence of *legal* MP3 codecs for gst from
fluendo (with other codecs
to come) should not be overlooked.
This interested me... How is it that they have a 'legal' MP3 codec for Linux?-
They paid some royalty?- I doubt it'd be as straight-forward as that.... ??
Is it a commercial codec?? :o Curious.....
-AL.
4:34 a.m.
This interested me... How is it that they have a
'legal' MP3 codec for Linux?-
They paid some royalty?- I doubt it'd be as straight-forward as that.... ??
Is it a commercial codec?? :o Curious.....
Just ask Christian (by nick Uraeus) at irc.freenode.net/#gstreamer.
AFAIK, They stroke a deal, for MP3 codec it was propably easy, because
MP3 patent owners claims you can use MP3 codec for free in open source
apps. For other codecs you must pay 7 Euros or for packages it was
more than that. Check out www.fluendo.com Webshop for prices.
They all are meant to be _legal_ (properly licensed, specifications,
etc.). That is whole catch with Fluendo offer. For anyone living in
software patent regime and dealing with big Linux desktop migrations
it is very good offer, I think.
-AL.
--
mortigi tempo
Pēteris Krišjānis
3:33 a.m.
I've been warned by a number of Linux folk to avoid GStreamer.
Sure, you can avoid Gstreamer, no one will force to use that. What I
am surprised about - and why I write this reply, usually I am in
reading mode of this very useful mailing list - that Gstreamer gets so
much badmouthing not even caring to check out lastest progress.
About using Gstreamer playing music and watching videos - well, I do
this both home and work, and no gliches, no artifacts, no problems
with Dapper, Edgy and Feisty (Using Gstreamer 0.10 and all aviable
plugins). What I love about Gstreamer is that it brings unified way to
"doing things" in multimedia and and it is very easy to structure how
multimedia works in your application (Pipelines owns). Well, of
course, I can play multimedia also without any Gstreamer, but there
must be some reason why Nokia uses Gstreamer for playing their
multimedia on 770 and N800. Why GNOME uses Gstreamer as backend for
multimedia apps. It is not forced for you to use Gstreamer, but I
would suggest to at least try last stable version to judge it.
Gstreamer0.10 even has pitddl and ffmpeg elements aviable for install
in Ubuntu /Debian repositories for those who wants to use 32-bit dll
hacs or ffmpeg library.
For one I can agree that Gstreamer came rather long way. It was very
barerly usable for videos with Totem/Gstreamer0.8, and RB had lot of
quirks with migration over Gstreamer0.10. However, this have changed
very much thanks to hard work of community. In fact, it is second most
active community besides JACK.
So, Gstreamer gets taken seriously more and more each day. It is
suitable for your use? It is your choice. I say - try it, because I
think it is quite changed from the last time guys which gave you their
recomendations tried it.
3:53 a.m.
On Tue Feb 06, 2007 at 09:33:03AM +0200, Peteris Krisjanis wrote:
i actually checked out and built SVN before badmouthing it :)
the jack sink IS welcomed progress. i think we should all embrace it, as a 'desktop
and pro apps can peacefully coexist' solution..
I've been warned by a number of Linux folk to avoid GStreamer.
Sure, you can avoid Gstreamer, no one will force to use that. What I
am surprised about - and why I write this reply, usually I am in
reading mode of this very useful mailing list - that Gstreamer gets so
much badmouthing not even caring to check out lastest progress.
About using Gstreamer playing music and watching videos - well, I do
this both home and work, and no gliches, no artifacts, no problems
with Dapper, Edgy and Feisty (Using Gstreamer 0.10 and all aviable
plugins). What I love about Gstreamer is that it brings unified way to
"doing things" in multimedia and and it is very easy to structure how
multimedia works in your application (Pipelines owns). Well, of
course, I can play multimedia also without any Gstreamer, but there
must be some reason why Nokia uses Gstreamer for playing their
multimedia on 770 and N800. Why GNOME uses Gstreamer as backend for
multimedia apps. It is not forced for you to use Gstreamer, but I
would suggest to at least try last stable version to judge it.
Gstreamer0.10 even has pitddl and ffmpeg elements aviable for install
in Ubuntu /Debian repositories for those who wants to use 32-bit dll
hacs or ffmpeg library.
For one I can agree that Gstreamer came rather long way. It was very
barerly usable for videos with Totem/Gstreamer0.8, and RB had lot of
quirks with migration over Gstreamer0.10. However, this have changed
very much thanks to hard work of community. In fact, it is second most
active community besides JACK.
So, Gstreamer gets taken seriously more and more each day. It is
suitable for your use? It is your choice. I say - try it, because I
think it is quite changed from the last time guys which gave you their
recomendations tried it.
4:01 a.m.
2007/2/6, carmen <_(a)whats-your.name>me>:
On Tue Feb 06, 2007 at 09:33:03AM +0200, Peteris
Krisjanis wrote:
i actually checked out and built SVN before badmouthing it :)
So how it comes that we have totally different expierences with it?
I've been warned by a number of Linux folk to avoid GStreamer.
Sure, you can avoid Gstreamer, no one will force to use that. What I
am surprised about - and why I write this reply, usually I am in
reading mode of this very useful mailing list - that Gstreamer gets so
much badmouthing not even caring to check out lastest progress. the jack sink IS welcomed progress. i think we should
all embrace it, as a 'desktop and pro apps can peacefully coexist' solution..
Highly doubt that, I am using JACK and it rocks on it's own merits,
but it is definetly hard to provide it as usable solution for
non-geeks.
Cheers,
Peter.
7 Feb
7 Feb
1:23 a.m.
On 2/6/07, Peteris Krisjanis <pecisk(a)gmail.com> wrote:
For one I can agree that Gstreamer came rather long
way. It was very
barerly usable for videos with Totem/Gstreamer0.8, and RB had lot of
quirks with migration over Gstreamer0.10. However, this have changed
very much thanks to hard work of community. In fact, it is second most
active community besides JACK.
So, Gstreamer gets taken seriously more and more each day. It is
suitable for your use? It is your choice. I say - try it, because I
think it is quite changed from the last time guys which gave you their
recomendations tried it.
My initial experience with gstreamer was also very bad - I think
because some distros (Ubuntu for one) either shipped
totem/gstreamer0.8 as the default movie player before it was ready, or
shipped an unusable configuration. I'll definitely try again after
Paul's comments.
So what's the relationship between PulseAudio and gstreamer? Are
these projects cooperating at all or being pushed by competing
distros?
Lee
6 Feb
6 Feb
11:24 a.m.
On Mon, 2007-02-05 at 17:05 -0500, Paul Davis wrote:
On Mon, 2007-02-05 at 16:41 -0500, carmen wrote:
Apparently speex now has a resampler. That might be useful:
svn co http://svn.xiph.org/trunk/speex speex
then see libspeex/resample.c
Damon
On Mon Feb 05, 2007 at 01:59:29PM -0600, Victor
Roetman wrote:
carmen, judging from the rest of your post, CPU usage was the main
issue.
this is actually not a consequence of the JACK sink directly, but the
appalling unoptimized resampling code in gstreamer. if you connect the
JACK sink up to a stream that is already at the JACK sample rate, i have
found you see the expected (low) CPU utilization.
the gstreamer guys know about this, but there is nobody available or
with the know-how to speed it up. libsamplerate is not an option,
apparently, because of the license :((
(and I really wish there was a jack backend for gstreamer)
there is. it didnt work very well for me (worse than alsa+plug:jack, just like XINE) but
you might want to give it a shot 
8 Feb
8 Feb
12:27 a.m.
carmen wrote:
banshee is even worse, generally freezing up while
populating the
library, let alone playing a track. but then amarok freezes
populating the library until i move utf-8/shift-jis dirs out of the
music directory as well..
I had lots of problems with utf-8 and Chinese GB encoded id3 tags in my
mp3 files. Even though they were utf-8, lots of the applications still
didn't recognize them as such - amarok and rhythmbox all gave me
problems with them - I guess because they were not marked specifically
as utf-8 in id3v2.
I finally went and compiled Easytag 1.99.13 and needed to find a patched
libid3 (id3lib)
https://launchpad.net/distros/ubuntu/+source/id3lib3.8.3/3.8.3-6
which I build for Ubuntu edgy, since the included id3lib has a nasty
Unicode bug. Then I went through and had it fix all the id3 tags. I
think it puts in a BOM or marks it as UTF-8 somehow (I really don't
understand id3). In a few files I had to tell easytag to read them as
GB encoded, and then it wrote them as utf-8.
Now everything works great in every application that I use, including
iTunes in Windows. (Except XMMS which has always given me problems with
non-roman tags, but is still the most reliable and flexible mp3 mplayer
I have ever used). I even have a file with Unicode Japanese file name
and Japanese id3 tags, and my little iRiver iFP-190TC displayed them
with no problems, kanji and all.
Easytag is, as far as I'm concerned, the best thing to happen for id3
tags since id3v2, and I am sure happy with utf-8 tags.
vic
6649
days inactive
6653
days old
linux-audio-user@lists.linuxaudio.org
29 comments
12 participants
participants (12)
-
Andrew Lewis -
carmen -
Damon Chaplin -
david -
Erik de Castro Lopo -
Florian Schmidt -
Jan Weil -
Lee Revell -
oktyabr -
Paul Davis -
Peteris Krisjanis -
Victor Roetman