Re: Python and GStreamer

[Jeffrey Barish]

Austin Che wrote:

> So I went ahead and ported mpd and mpg321 to maemo. In
> case anyone else wants these packages as I couldn't find them
> already out there: http://austin.mit.edu/maemo

I'm having trouble installing mpd.  I installed all the packages that mpd
requires.  When I try to install mpd, I get:

/media/mmc1 # dpkg -i mpd_0.13.0-1_armel.deb
Selecting previously deselected package mpd.
(Reading database ... 15122 files and directories currently installed.)
Unpacking mpd (from mpd_0.13.0-1_armel.deb) ...
Setting up mpd (0.13.0-1) ...
chage: can't open shadow password fileStopped: `/usr/bin/chage -M 9 mpd'
returned error code 1. Exiting.

Removing user `mpd' ...
dpkg: error processing mpd (--install):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 mpd


I tried shadowconfig on, but then I get "bash: not found".  Installing bash
would change everything.

I tried creating the mpd user by running adduser manually, but then I get
segmentation fault whenever I run mpd.

Hints?
-- 
Jeffrey Barish

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Stefan Kost]

Hi,
Jesse Guardiani wrote:
> Tony Maro wrote:
>> On 8/27/07, *Leonardo Sobral Cunha* <[EMAIL PROTECTED]
>> > wrote:
>>
>> hi tony,
>>
>> there is a bug in your code, you dont need to call createGSTPlayer in
>> the start method, so you will reuse the pipeline that is already
>> created in the constructor (__init__).
>>
>>
>> Interesting - every implementation I've looked at appears to recreate
>> the pipeline for every song instead of reusing the old one.  I'll give
>> that a shot and see what happens.  Let me qualify that statement: The
>> two similar implementations I've looked at both seemed to do that.
>>
>> I guess what's most frustrating is it happens randomly, one out of every
>> 20 to 50 executions of the program.  It's not every time.  Kind of makes
>> it hard to track down specifics.
> 
> 
> gstreamer is poo. plain and simple. Yes, you need to recreate the
> pipeline. If you don't, bad things happen, like hanging and such after
> EOS. And no, EOS detection still doesn't work well in that class despite
> my many tries. We abandoned gstreamer support in Kagu for a reason. It's
> poo. It's much easier to just use OSSO Media Server via dbus and let
> *it* deal with gstreamer for us.
That is not wise. Its not a public API. It will change and maybe disappear. 2nd
I wouldn't conclude in the quality of gstreamer from how it behaves on the
device. Non working EOS detections could also be a bug in the dsp sinks, which
are not under quality control of the open-source project.

> 
> Just the opinion of a developer who hung out on the #gstreamer IRC
> channel while writing gstplayer.py and saw every suggestion by the folks
> on that channel go up in smoke under one condition or another until the
> API was so riddled with inconsistencies that it was a smoking pile of
> garbage.
> 
> And no, before you ask, I don't think it's not Nokia's fault. gstreamer
> is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3
> decoders... life would be easier for all of us...
> 
Now you've lost me. I don't think GStreamer is that buggy. Unfortunately the
GSTreamer in the current SDK is not exactly new. Second you want a mp3 decoder
for ALSA? Imho that is not a good idea either.

My recommandation. Nail down bugs to reproducable testcases and file bugs. Is a
good idea to post bug-number here as a reminder.

Stefan


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Austin Che]

Jesse Guardiani <[EMAIL PROTECTED]> wrote:

> Austin Che wrote:
>> Ok thanks. So I went ahead and ported mpd and mpg321 to maemo. In
>> case anyone else wants these packages as I couldn't find them
>> already out there: http://austin.mit.edu/maemo
>> mpd uses about 10% of the cpu and mpg321 uses about 20% of
>> the CPU
>> even though they should be both using libmad. mpg321 seems to skip
>> a bit just switching apps but renicing it a bit appeared to get
>> rid of the skipping. I'm not sure why mpd seemed to do better in
>> general. Also, for some reason, using alsa output with mpd didn't
>> work (apparently segfaults) while libao output worked fine.
>
> Is that on the n800 or 770? My experience has been that mplayer with
> ffmp3 typically gets about 16% CPU during playback on an n800 while
> playing back a very high quality VBR mp3.

n800
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Jesse Guardiani]

Austin Che wrote:
> Koen Kooi <[EMAIL PROTECTED]> wrote:
>
>   
>> Jesse Guardiani schreef:
>>
>> 
 And the related question is: given an existing program that sends
 stuff out to ALSA and doesn't use gstreamer, how difficult is it
 generally to port it so that it works properly?
 
>>> No porting necessary, really. mplayer comes with a decoder called 
>>> libmp3. It's not optimized for ARM or anything, and it compiles without 
>>> any problems. We don't use it in Kagu for A2DP though because there is 
>>> another decoder out there called ffmp3 which doesn't use floating point 
>>> math, so it's a little more efficient on ARM.
>>>   
>> use libmad (-ac mad), that works great on arm and x86.
>> 
>
> Ok thanks. So I went ahead and ported mpd and mpg321 to maemo. In
> case anyone else wants these packages as I couldn't find them
> already out there: http://austin.mit.edu/maemo
> 
> mpd uses about 10% of the cpu and mpg321 uses about 20% of the CPU
> even though they should be both using libmad. mpg321 seems to skip
> a bit just switching apps but renicing it a bit appeared to get
> rid of the skipping. I'm not sure why mpd seemed to do better in
> general. Also, for some reason, using alsa output with mpd didn't
> work (apparently segfaults) while libao output worked fine. 
>   

Is that on the n800 or 770? My experience has been that mplayer with 
ffmp3 typically gets about 16% CPU during playback on an n800 while 
playing back a very high quality VBR mp3.

-- 
Jesse Guardiani
Programmer/Sys Admin
[EMAIL PROTECTED]

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Siarhei Siamashka]

On 30 August 2007, Jesse Guardiani wrote:
> Koen Kooi wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Jesse Guardiani schreef:
> >>> And the related question is: given an existing program that sends
> >>> stuff out to ALSA and doesn't use gstreamer, how difficult is it
> >>> generally to port it so that it works properly?
> >>
> >> No porting necessary, really. mplayer comes with a decoder called
> >> libmp3. It's not optimized for ARM or anything, and it compiles without
> >> any problems. We don't use it in Kagu for A2DP though because there is
> >> another decoder out there called ffmp3 which doesn't use floating point
> >> math, so it's a little more efficient on ARM.
> >
> > use libmad (-ac mad), that works great on arm and x86.
>
> Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3
> is the best choice on ARM.

Just for the sake of correctness, I did not quite say that :) This is what 
I replied to you earlier when we were discussing A2DP performance issues:

"Software MP3 (-ac ffmp3) and OGG/Vorbis (don't remember exact '-ac' option
for it, but you don't need it anyway as this decoder is used by default)
decoders are already enabled in mplayer. If we want the best MP3 decoding
performance, libmad (-ac mad) is the best choice, but it is an external
dependency and is not used right now. The worst option for software MP3
decoding on ARM is mp3lib (-ac mp3), it uses floating point math and is a lot
slower than other (fixed point) MP3 decoders even on N800 which supports
floating point math in hardware.

You can try to test all these decoders yourself to figure out which one 
works the best for you."


Just ffmp3 is a part of ffmpeg library and is bundled with mplayer by default
and libmad is an external dependency which may make packaging a bit more
complicated. That's the only reason why libmad support is not enabled in 
maemo build of mplayer yet.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Austin Che]

Koen Kooi <[EMAIL PROTECTED]> wrote:

> Jesse Guardiani schreef:
>
>>> And the related question is: given an existing program that sends
>>> stuff out to ALSA and doesn't use gstreamer, how difficult is it
>>> generally to port it so that it works properly?
>> 
>> No porting necessary, really. mplayer comes with a decoder called 
>> libmp3. It's not optimized for ARM or anything, and it compiles without 
>> any problems. We don't use it in Kagu for A2DP though because there is 
>> another decoder out there called ffmp3 which doesn't use floating point 
>> math, so it's a little more efficient on ARM.
>
> use libmad (-ac mad), that works great on arm and x86.

Ok thanks. So I went ahead and ported mpd and mpg321 to maemo. In
case anyone else wants these packages as I couldn't find them
already out there: http://austin.mit.edu/maemo

mpd uses about 10% of the cpu and mpg321 uses about 20% of the CPU
even though they should be both using libmad. mpg321 seems to skip
a bit just switching apps but renicing it a bit appeared to get
rid of the skipping. I'm not sure why mpd seemed to do better in
general. Also, for some reason, using alsa output with mpd didn't
work (apparently segfaults) while libao output worked fine. 

I'll try using mpd with glurp, mmpc, or some other client for a
bit and see if I can get a feel for whether the battery usage is
substantially worse than using canola. But so far, this setup with
mpd is more like how I want my music player to be and fixes some
of the annoyances I've had with all the other music players I've
tried: no unnecessary scanning for new songs and no unexplainable
errors that stop or freeze the playing of the music some of the
time.

All that is needed is a good client. glurp seems a bit
unresponsive but mmpc isn't too bad. If anyone knows of any other
good mpd client (there is a ridiculously large number of clients
http://mpd.wikia.com/wiki/Clients) or one that could be easily
ported, please let me know. I was looking at the sonata client
which requires pygtk 2.6 and gtk 2.6 but I'm not sure if maemo
supports these versions as I couldn't get it to install:
http://mpd.wikia.com/wiki/Client:Sonata

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Jesse Guardiani]

Koen Kooi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jesse Guardiani schreef:
>   
>> Koen Kooi wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Jesse Guardiani schreef:
>>>
>>>  
>>>   
> And the related question is: given an existing program that sends
> stuff out to ALSA and doesn't use gstreamer, how difficult is it
> generally to port it so that it works properly?
>   
>   
 No porting necessary, really. mplayer comes with a decoder called
 libmp3. It's not optimized for ARM or anything, and it compiles
 without any problems. We don't use it in Kagu for A2DP though because
 there is another decoder out there called ffmp3 which doesn't use
 floating point math, so it's a little more efficient on ARM.
 
 
>>> use libmad (-ac mad), that works great on arm and x86.
>>>   
>>>   
>> Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3
>> is the best choice on ARM.
>> 
>
> No idea on that, but I'm wary of anything starting with 'ff' that pretends to 
> be a shared lib.
>   

OK I don't follow your logic there.

-- 
Jesse Guardiani
Programmer/Sys Admin
[EMAIL PROTECTED]

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Koen Kooi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jesse Guardiani schreef:
> Koen Kooi wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Jesse Guardiani schreef:
>>
>>  
 And the related question is: given an existing program that sends
 stuff out to ALSA and doesn't use gstreamer, how difficult is it
 generally to port it so that it works properly?
   
>>> No porting necessary, really. mplayer comes with a decoder called
>>> libmp3. It's not optimized for ARM or anything, and it compiles
>>> without any problems. We don't use it in Kagu for A2DP though because
>>> there is another decoder out there called ffmp3 which doesn't use
>>> floating point math, so it's a little more efficient on ARM.
>>> 
>>
>> use libmad (-ac mad), that works great on arm and x86.
>>   
> 
> Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3
> is the best choice on ARM.

No idea on that, but I'm wary of anything starting with 'ff' that pretends to 
be a shared lib.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG1sOIMkyGM64RGpERAle/AKCUUMw9FYl0qjbSSuPKI3pYb9MqDgCgj/pC
ulYpOJKsqKpSvGgoJlOYLo8=
=JzqT
-END PGP SIGNATURE-
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Jesse Guardiani]

Koen Kooi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jesse Guardiani schreef:
>
>   
>>> And the related question is: given an existing program that sends
>>> stuff out to ALSA and doesn't use gstreamer, how difficult is it
>>> generally to port it so that it works properly?
>>>   
>> No porting necessary, really. mplayer comes with a decoder called 
>> libmp3. It's not optimized for ARM or anything, and it compiles without 
>> any problems. We don't use it in Kagu for A2DP though because there is 
>> another decoder out there called ffmp3 which doesn't use floating point 
>> math, so it's a little more efficient on ARM.
>> 
>
> use libmad (-ac mad), that works great on arm and x86.
>   

Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3 
is the best choice on ARM.


-- 
Jesse Guardiani
Programmer/Sys Admin
[EMAIL PROTECTED]

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Koen Kooi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jesse Guardiani schreef:

>> And the related question is: given an existing program that sends
>> stuff out to ALSA and doesn't use gstreamer, how difficult is it
>> generally to port it so that it works properly?
> 
> No porting necessary, really. mplayer comes with a decoder called 
> libmp3. It's not optimized for ARM or anything, and it compiles without 
> any problems. We don't use it in Kagu for A2DP though because there is 
> another decoder out there called ffmp3 which doesn't use floating point 
> math, so it's a little more efficient on ARM.

use libmad (-ac mad), that works great on arm and x86.

regards,

Koen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG1sERMkyGM64RGpERAsWdAJ4+hsMXCDH8eiyMDPVbJfjBknDLMACbBvuf
qoDtnZ5HfdOlgxxZommHfNc=
=5/O8
-END PGP SIGNATURE-
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Jesse Guardiani]

Austin Che wrote:
> Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>
>   
>> And no, before you ask, I don't think it's not Nokia's fault. gstreamer
>> is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3
>> decoders... life would be easier for all of us...
>> 
>
> I've been wondering: what is the performance hit for not going
> through gstreamer? So based on my understanding, going through
> gstreamer, the mp3 is decoded on the DSP. Supposing it was decoded
> on the cpu and sent out through alsa, which of the following is
> likely to be true:
> 
> - The CPU wouldn't be able to handle it (playback would skip)
>   

No, not even close. It doesn't use anywhere near that much CPU. Even 
with a separate process running transcoding the decoded mp3 into SBC 
packets (think a2dpd from the bluetooth-alsa package) we still don't get 
skipping, though doing other things at the same time will cause skipping 
sometimes.

> - The CPU could handle it just as well as the DSP but the rest of
> the system might be less usable
> - The battery life would decrease (how much?)
>   


Yes, mostly it's a battery life issue. But decoding mp3 in software does 
take a bit of available CPU, so you can't do quite as much simultaneously.


> - some other reason this wouldn't work well?
>   

Nah. Battery and multi-tasking. Those are the primary concerns, I think.

> And the related question is: given an existing program that sends
> stuff out to ALSA and doesn't use gstreamer, how difficult is it
> generally to port it so that it works properly?

No porting necessary, really. mplayer comes with a decoder called 
libmp3. It's not optimized for ARM or anything, and it compiles without 
any problems. We don't use it in Kagu for A2DP though because there is 
another decoder out there called ffmp3 which doesn't use floating point 
math, so it's a little more efficient on ARM.


>  By this, I'm
> thinking of a typical C program that plays mp3 files. Would it
> likely require a complete rework of the code structure or is it
> probably a "trivial" replacement of function calls?
>   

Trivial. You could always optimize it by re-writing it to do everything 
with fixed point math, but it's not strictly necessary, at least on the 
n800.

-- 
Jesse Guardiani
Programmer/Sys Admin
[EMAIL PROTECTED]

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Tony Maro]

On 8/30/07, Austin Che <[EMAIL PROTECTED]> wrote:
>
>
> I've been wondering: what is the performance hit for not going
> through gstreamer? So based on my understanding, going through
> gstreamer, the mp3 is decoded on the DSP. Supposing it was decoded
> on the cpu and sent out through alsa, which of the following is
> likely to be true:



Well I can only say this - my experience now using osso media player instead
of gstreamer is that I can play, pause, start and stop my MP3 media stream
without affecting the frame rate of my game, and if it's not affecting my
frame rate, I'm unconcerned with if it happens in the DSP or not ;-)

Also, Kagu is very good on battery life when using it, so I'm not too
concerned about battery suck with it.

 But obviously I'm no expert - I've only used it for a day.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Austin Che]

Jesse Guardiani <[EMAIL PROTECTED]> wrote:

> And no, before you ask, I don't think it's not Nokia's fault. gstreamer
> is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3
> decoders... life would be easier for all of us...

I've been wondering: what is the performance hit for not going
through gstreamer? So based on my understanding, going through
gstreamer, the mp3 is decoded on the DSP. Supposing it was decoded
on the cpu and sent out through alsa, which of the following is
likely to be true:

- The CPU wouldn't be able to handle it (playback would skip)
- The CPU could handle it just as well as the DSP but the rest of
the system might be less usable
- The battery life would decrease (how much?)
- some other reason this wouldn't work well?

And the related question is: given an existing program that sends
stuff out to ALSA and doesn't use gstreamer, how difficult is it
generally to port it so that it works properly? By this, I'm
thinking of a typical C program that plays mp3 files. Would it
likely require a complete rework of the code structure or is it
probably a "trivial" replacement of function calls?
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Jesse Guardiani]

Zeeshan Ali wrote:
> Hello again!
> 
>> Why would I file a bug? I need something that works on all firmwares.
>> Filing a bug won't help that. Besides, I'm sure Nokia's developers
>> couldn't help noticing that gstreamer was broken when they wrote OSSO
>> Media Server. Why didn't *they* file a bug, eh?
> 
>I wouldn't know, i am not a MediaServer developer but I don't see
> them saying 'gstreamer is poo' or moving to some other framework so
> that is why *you* need to file a bug, not them.

I just don't have any interest in filing a bug. Sorry. I already
explained that.


>> In addition, why don't you file a bug for me if it bothers you? I do
>> that for Kagu's users all the time. I'm not really sure why everyone in
>> the open source world expects end-users to file their own bugs.
> 
>   If i find a bug in gstreamer (or any software), *I* will file a bug
> but it was you who found the bug so why am *i* supposed to file it?

Because you seem to be the one who cares about filing a bug. I don't.


>> Back on the subject of whether or not gstreamer is useful: Perhaps it's
>> just a broken version of gstreamer that maemo uses, or perhaps the bug
>> is elsewhere. It's just that it's broken for me/Kagu/us/maemo-users, so
>> it isn't very useful to Kagu in it's current state and probably not very
>> useful to Tony.
> 
>  Concidering all these possibilities, I ask you again, is it
> reasonable to conclude "gstreamer is poo" and advertising that to
> others as a fact?

Well, considering that this is a maemo list, yes, I think it's fair to
declare that "gstreamer is poo", and everyone should automatically
assume that I mean "gstreamer on maemo is poo". I'm not writing this on
any other list, and you shouldn't assume that I mean any other platform
other than maemo.


-- 
Jesse Guardiani
Programmer/Sys Admin
[EMAIL PROTECTED]

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Zeeshan Ali]

Hello again!

> Why would I file a bug? I need something that works on all firmwares.
> Filing a bug won't help that. Besides, I'm sure Nokia's developers
> couldn't help noticing that gstreamer was broken when they wrote OSSO
> Media Server. Why didn't *they* file a bug, eh?

   I wouldn't know, i am not a MediaServer developer but I don't see
them saying 'gstreamer is poo' or moving to some other framework so
that is why *you* need to file a bug, not them.

> In addition, why don't you file a bug for me if it bothers you? I do
> that for Kagu's users all the time. I'm not really sure why everyone in
> the open source world expects end-users to file their own bugs.

  If i find a bug in gstreamer (or any software), *I* will file a bug
but it was you who found the bug so why am *i* supposed to file it?

> Back on the subject of whether or not gstreamer is useful: Perhaps it's
> just a broken version of gstreamer that maemo uses, or perhaps the bug
> is elsewhere. It's just that it's broken for me/Kagu/us/maemo-users, so
> it isn't very useful to Kagu in it's current state and probably not very
> useful to Tony.

 Concidering all these possibilities, I ask you again, is it
reasonable to conclude "gstreamer is poo" and advertising that to
others as a fact?

> Ultimately, I'm a selfish software developer and I've found my solution
> elsewhere. That's the extent of my interest. I have to move on to other
> things or else I'll never get anything done.

   That is fine, you should use whatever works for you. Nobody is
forcing you to use gstreamer.

-- 
Regards,

Zeeshan Ali
FSF member#5124
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Jesse Guardiani]

Zeeshan Ali wrote:
> Hi!
> 
>> gstreamer is poo. plain and simple. Yes, you need to recreate the
>> pipeline. If you don't, bad things happen, like hanging and such after
>> EOS. And no, EOS detection still doesn't work well in that class despite
>> my many tries.
> 
>That sounds like a bug, have you cared to file it? Does the same
> happen when you try the same pipeline on a PC?

Why would I file a bug? I need something that works on all firmwares.
Filing a bug won't help that. Besides, I'm sure Nokia's developers
couldn't help noticing that gstreamer was broken when they wrote OSSO
Media Server. Why didn't *they* file a bug, eh?

In addition, why don't you file a bug for me if it bothers you? I do
that for Kagu's users all the time. I'm not really sure why everyone in
the open source world expects end-users to file their own bugs. That
doesn't seem very practical. You should consider this email a bug
report, and you can consider the link to gstplayer.py in the previous
email my test case. And if you need additional information, this thread
will do nicely.

Back on the subject of whether or not gstreamer is useful: Perhaps it's
just a broken version of gstreamer that maemo uses, or perhaps the bug
is elsewhere. It's just that it's broken for me/Kagu/us/maemo-users, so
it isn't very useful to Kagu in it's current state and probably not very
useful to Tony.

Ultimately, I'm a selfish software developer and I've found my solution
elsewhere. That's the extent of my interest. I have to move on to other
things or else I'll never get anything done.


-- 
Jesse Guardiani
Programmer/Sys Admin
[EMAIL PROTECTED]
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Zeeshan Ali]

Hi!

> gstreamer is poo. plain and simple. Yes, you need to recreate the
> pipeline. If you don't, bad things happen, like hanging and such after
> EOS. And no, EOS detection still doesn't work well in that class despite
> my many tries.

   That sounds like a bug, have you cared to file it? Does the same
happen when you try the same pipeline on a PC?

>We abandoned gstreamer support in Kagu for a reason. It's
> poo. It's much easier to just use OSSO Media Server via dbus and let
> *it* deal with gstreamer for us.

   OSSO Media Player is there for a reason and that is to save you
from gstreamer coding but that doesn't transate to 'gstreamer is a
poo'. Gstreamer attacks a very complicated problem domain (much larger
than just playing an mp3) and the current API provides the simplest
possible solution for it. Concluding that the whole API (and even the
project) is 'poo' looking at a bug, isn't very reasonable IMHO.

> Just the opinion of a developer who hung out on the #gstreamer IRC
> channel while writing gstplayer.py and saw every suggestion by the folks
> on that channel go up in smoke under one condition or another until the
> API was so riddled with inconsistencies that it was a smoking pile of
> garbage.

   I don't exactly see what you mean by " API was so riddled with
inconsistencies", API of what? your application?  What you are trying
to do *should* really be simple and if it isn't, you've found a bug
(not necessarily in gstreamer even).

> And no, before you ask, I don't think it's not Nokia's fault. gstreamer
> is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3
> decoders... life would be easier for all of us...

   That might be because ALSA developers realize that decoding mp3
doesn't lie under the domain of ALSA project and that if it doesn't
work in gstreamer, it's a bug we need to file and fix.

-- 
Regards,

Zeeshan Ali
FSF member#5124
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Tony Maro]

On 8/28/07, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>
> gstreamer is poo. plain and simple. Yes, you need to recreate the
> pipeline. If you don't, bad things happen, like hanging and such after
> EOS. And no, EOS detection still doesn't work well in that class despite
> my many tries. We abandoned gstreamer support in Kagu for a reason. It's
> poo. It's much easier to just use OSSO Media Server via dbus and let
> *it* deal with gstreamer for us.





I'm beginning to realize this about gstreamer as well.  EOS detection seems
to only work about 95% of time, and when it does work you get something like
5 messages thrown at you - so why can't it get just one through on those
5%???

Anyway, can you point me to any docs on using dbus to control OSSO with
Python?  The whole dbus concept is still alien to me.  The only dbus I've
done is the launching with a desktop icon and then using it to get the
screen status (which I copied and pasted from Kagu.)

Wait, I bet the next comment from someone will be "Why don't you take a look
at Kagu"...  lol.

Okay so I agree gstreamer is out.  Now to get a replacement working...
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Jesse Guardiani]

Tony Maro wrote:
> 
> On 8/27/07, *Leonardo Sobral Cunha* <[EMAIL PROTECTED]
> > wrote:
> 
> hi tony,
> 
> there is a bug in your code, you dont need to call createGSTPlayer in
> the start method, so you will reuse the pipeline that is already
> created in the constructor (__init__).
> 
> 
> Interesting - every implementation I've looked at appears to recreate
> the pipeline for every song instead of reusing the old one.  I'll give
> that a shot and see what happens.  Let me qualify that statement: The
> two similar implementations I've looked at both seemed to do that.
> 
> I guess what's most frustrating is it happens randomly, one out of every
> 20 to 50 executions of the program.  It's not every time.  Kind of makes
> it hard to track down specifics.


gstreamer is poo. plain and simple. Yes, you need to recreate the
pipeline. If you don't, bad things happen, like hanging and such after
EOS. And no, EOS detection still doesn't work well in that class despite
my many tries. We abandoned gstreamer support in Kagu for a reason. It's
poo. It's much easier to just use OSSO Media Server via dbus and let
*it* deal with gstreamer for us.

Just the opinion of a developer who hung out on the #gstreamer IRC
channel while writing gstplayer.py and saw every suggestion by the folks
on that channel go up in smoke under one condition or another until the
API was so riddled with inconsistencies that it was a smoking pile of
garbage.

And no, before you ask, I don't think it's not Nokia's fault. gstreamer
is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3
decoders... life would be easier for all of us...


-- 
Jesse Guardiani
Programmer/Sys Admin
[EMAIL PROTECTED]
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Tony Maro]

On 8/27/07, Leonardo Sobral Cunha <[EMAIL PROTECTED]> wrote:
>
> hi tony,
>
> there is a bug in your code, you dont need to call createGSTPlayer in
> the start method, so you will reuse the pipeline that is already
> created in the constructor (__init__).


Interesting - every implementation I've looked at appears to recreate the
pipeline for every song instead of reusing the old one.  I'll give that a
shot and see what happens.  Let me qualify that statement: The two similar
implementations I've looked at both seemed to do that.

I guess what's most frustrating is it happens randomly, one out of every 20
to 50 executions of the program.  It's not every time.  Kind of makes it
hard to track down specifics.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and GStreamer

[Leonardo Sobral Cunha]

hi tony,

there is a bug in your code, you dont need to call createGSTPlayer in
the start method, so you will reuse the pipeline that is already
created in the constructor (__init__).

I have tested your code (without the createGSTPlayer in the start
method) with the test code below and it worked fine.

if __name__ == '__main__':
argv = os.sys.argv
argc = len(argv)

if argc != 2:
print 'Pass filename as parameter'
exit

filename = argv[1]

sc = SoundControl()
sc.start(filename)
time.sleep(2)

print "restarting"
sc.stop()
sc.start(filename)
time.sleep(2)
print "end"

BR,
-- 
// leo
---
Leonardo Sobral Cunha
INdT - Instituto Nokia de Tecnologia
PGP: 0x5751676C @ wwwkeys.pgp.net
---

On 8/26/07, Tony Maro <[EMAIL PROTECTED]> wrote:
> I've been trying to figure out how to use gstreamer to play audio.  It
> works, but sometimes it will randomly freeze my application when I try to
> start an mp3 file playing.  I'm only using two mp3 files and they both work
> at other times (like after a reboot) so I know it's not specifically the
> file.
>
> Sometimes I'll start my application which calls the start method of the
> SoundControl class below - and no sound starts.  Then, when my app tries to
> stop the music, everything freezes up.  It always seems to freeze things
> when I call "stop"
>
> After doing this, my application refuses to work at all (always freezes)
> until I reboot my n800.
>
> If anyone has any ideas, I'd greatly appreciate it.  Yes, I know there's
> probably more optimized ways to do some of what I have in this class, but
> it's grown as I've learned gstreamer, and I haven't stopped to refactor it
> yet.
>
> I've gleaned most of this code by looking at ukmp:
>
> class SoundControl(object):
> def __init__(self):
> print "Creating music player"
> self.createGSTPlayer()
>
> def createGSTPlayer(self):
> print "Creating player"
> self.player = gst.parse_launch( "gnomevfssrc name=source !
> dspmp3sink name=sink" ) # id3lib name=id3 !
>  self.source = self.player.get_by_name( "source" )
> self.sink = self.player.get_by_name( "sink" )
> self.player.set_name("player")
> bus = self.player.get_bus ()
> bus.add_signal_watch()
> bus.connect('message', self.on_message)
> print "Player created"
>
> def start(self, filename, newVolume = 80, repeat=-1):
> if filename == None: return
> self.stop()
> time.sleep(0.10)
>
> self.createGSTPlayer()
>
> self.filename = filename
> self.repeat = repeat
> self.paused = False
> if newVolume < 0: newVolume = 0
> if newVolume > 100: newVolume = 100
> # self.player.set_property('uri','file://' + filename)
> print "Setting player location"
> self.source.set_property ("location", filename)
> self.sink.set_property('volume',  newVolume*65535/100)
> self.player.set_state(gst.STATE_PLAYING)
> print "Player should be playing"
>
> def stop(self):
> print "stopping player"
> self.player.set_state(gst.STATE_NULL)
>
> def pause(self, state=None):
> print "Pause toggle"
> if state == None:
> if self.paused == True:
> self.paused = False
> self.player.set_state(gst.STATE_PLAYING)
> return
> self.paused = True
> self.player.set_state (gst.STATE_PAUSED)
> return
> if state == True:
> self.player.set_state(gst.STATE_PAUSED)
> else:
> self.player.set_state(gst.STATE_PLAYING)
>
> def on_message(self, bus, message):
> t = message.type
> if t == gst.MESSAGE_EOS:
> if self.repeat == -1:
> print "Repeat enabled"
> time_format = gst.Format(gst.FORMAT_TIME)
> self.player.seek_simple(time_format, gst.SEEK_FLAG_FLUSH, 0)
> self.player.set_state(gst.STATE_PLAYING)
> return
> if self.repeat > 0:
> print "Repeat enabled"
> self.repeat = self.repeat - 1
> time_format = gst.Format(gst.FORMAT_TIME)
> self.player.seek_simple(time_format, gst.SEEK_FLAG_FLUSH, 0)
> self.player.set_state (gst.STATE_PLAYING)
> return
> print "No repeat, stopping"
> self.player.set_state(gst.STATE_NULL)
> elif t == gst.MESSAGE_ERROR:
> print "Streamer error"
> self.player.set_state(gst.STATE_NULL)
>
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>


-- 
// leo

Re: Python and GStreamer

[Kemal Hadimli]

You could try some code from Kagu again :P

https://www.guardiani.us/projects/kagu/browser/trunk/src/kagu/gstplayer.py?rev=255

We removed it because of the EOS detection problems.


On 8/26/07, Tony Maro <[EMAIL PROTECTED]> wrote:
> I've been trying to figure out how to use gstreamer to play audio.  It
> works, but sometimes it will randomly freeze my application when I try to
> start an mp3 file playing.  I'm only using two mp3 files and they both work
> at other times (like after a reboot) so I know it's not specifically the
> file.
>
> Sometimes I'll start my application which calls the start method of the
> SoundControl class below - and no sound starts.  Then, when my app tries to
> stop the music, everything freezes up.  It always seems to freeze things
> when I call "stop"
>
> After doing this, my application refuses to work at all (always freezes)
> until I reboot my n800.
>
> If anyone has any ideas, I'd greatly appreciate it.  Yes, I know there's
> probably more optimized ways to do some of what I have in this class, but
> it's grown as I've learned gstreamer, and I haven't stopped to refactor it
> yet.


-- 
Kemal
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Python and GStreamer

[Tony Maro]

I've been trying to figure out how to use gstreamer to play audio.  It
works, but sometimes it will randomly freeze my application when I try to
start an mp3 file playing.  I'm only using two mp3 files and they both work
at other times (like after a reboot) so I know it's not specifically the
file.

Sometimes I'll start my application which calls the start method of the
SoundControl class below - and no sound starts.  Then, when my app tries to
stop the music, everything freezes up.  It always seems to freeze things
when I call "stop"

After doing this, my application refuses to work at all (always freezes)
until I reboot my n800.

If anyone has any ideas, I'd greatly appreciate it.  Yes, I know there's
probably more optimized ways to do some of what I have in this class, but
it's grown as I've learned gstreamer, and I haven't stopped to refactor it
yet.

I've gleaned most of this code by looking at ukmp:

class SoundControl(object):
def __init__(self):
print "Creating music player"
self.createGSTPlayer()

def createGSTPlayer(self):
print "Creating player"
self.player = gst.parse_launch( "gnomevfssrc name=source !
dspmp3sink name=sink" ) # id3lib name=id3 !
self.source = self.player.get_by_name( "source" )
self.sink = self.player.get_by_name( "sink" )
self.player.set_name("player")
bus = self.player.get_bus()
bus.add_signal_watch()
bus.connect('message', self.on_message)
print "Player created"

def start(self, filename, newVolume = 80, repeat=-1):
if filename == None: return
self.stop()
time.sleep(0.10)

self.createGSTPlayer()

self.filename = filename
self.repeat = repeat
self.paused = False
if newVolume < 0: newVolume = 0
if newVolume > 100: newVolume = 100
# self.player.set_property('uri','file://' + filename)
print "Setting player location"
self.source.set_property("location", filename)
self.sink.set_property('volume',  newVolume*65535/100)
self.player.set_state(gst.STATE_PLAYING)
print "Player should be playing"

def stop(self):
print "stopping player"
self.player.set_state(gst.STATE_NULL)

def pause(self, state=None):
print "Pause toggle"
if state == None:
if self.paused == True:
self.paused = False
self.player.set_state(gst.STATE_PLAYING)
return
self.paused = True
self.player.set_state(gst.STATE_PAUSED)
return
if state == True:
self.player.set_state(gst.STATE_PAUSED)
else:
self.player.set_state(gst.STATE_PLAYING)

def on_message(self, bus, message):
t = message.type
if t == gst.MESSAGE_EOS:
if self.repeat == -1:
print "Repeat enabled"
time_format = gst.Format(gst.FORMAT_TIME)
self.player.seek_simple(time_format, gst.SEEK_FLAG_FLUSH, 0)
self.player.set_state(gst.STATE_PLAYING)
return
if self.repeat > 0:
print "Repeat enabled"
self.repeat = self.repeat - 1
time_format = gst.Format(gst.FORMAT_TIME)
self.player.seek_simple(time_format, gst.SEEK_FLAG_FLUSH, 0)
self.player.set_state(gst.STATE_PLAYING)
return
print "No repeat, stopping"
self.player.set_state(gst.STATE_NULL)
elif t == gst.MESSAGE_ERROR:
print "Streamer error"
self.player.set_state(gst.STATE_NULL)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers