Re: pulseaudio vs gnome

2007-02-02 Thread Sean Kelley

On 1/20/07, Marc-André Lureau [EMAIL PROTECTED] wrote:




On 1/20/07, Ronald S. Bultje [EMAIL PROTECTED] wrote:

 On Sat, 2007-01-20, Damon chaplin wrote:
  Before it goes in I'd like to see a clear roadmap for audio in GNOME,
  with support for things from simple beeps up to pro-audio apps.
 
  I guess this means gstreamer, PulseAudio and JACK. Is that the plan?


esd is in the platform because it already is. Realistically, it doesn't
 belong here. Any replacement technology _to have complete feature
 equiality with esd_ should be completely optional and a user should be


snip!


That probably means something like GStreamer to make it bearable for
 applications that really don't care and just want to play song.mp3 or
 beeps. And that should suffice.


This remark pops up an interesting question: do we really want gnome apps
linked to GStreamer to play bling? Furthermore, is GStreamer  API suitable
for a simple desktop applications (nautilus, mozilla, notify, bling API...)
? I have posted a proposal to define an API for desktop sound on
freedesktop/dapi/gnome-media mailing lists (without much success) - but once
again, we don't care about implementation at this stage (wether it uses a
daemon or not, if it use GStreamer or Pulse or anything else). I really
think we need to discuss such idea to replace the libgnome sound API. Of
course, it would be good to have people from GStreamer/DBus/PulseAudio
discuss such idea also.




Just an fyi, but In embedded systems running Gtk+, you don't want to have to
spend the time to initialize/start up Gstreamer just to play bling.  The
time lag is far too great.  You limit Gstreamer use to items like movie and
music playback - not system pings.

Sean


If you look at the code that use esd directly, its only because libgnome

doesn't provide a simple/complete sound API. And now its time to fix
libgnome sound to get rid of esd.  At the same time, lets bring some new
cool things like theming/positionning/introspection  control... But that is
probably not the good place to discuss this in detail.

After FOMS and DAM3, one has said that new mailing lists will be created
to discuss desktop audio API. I would like to define also a *sound desktop*
API. Where are those mailing lists? anyone?
enough for now,

best regards,
--
Marc-André Lureau, GSmartMix
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: pulseaudio vs gnome

2007-02-02 Thread Murray Cumming


 Just an fyi, but In embedded systems running Gtk+, you don't want to
 have to spend the time to initialize/start up Gstreamer just to play
 bling.  The time lag is far too great.  You limit Gstreamer use to
 items like movie and music playback - not system pings. 

But on systems that will want to do more impressive audio/visual stuff
sometimes anyway, such as the Nokia N770/N800, wouldn't you want
gstreamer to be loaded and initialized already anyway? Then there
shouldn't (theoretically) be any delay in playing a system beep.

Obviously, for very simple systems even this would be excessive.

-- 
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: pulseaudio vs gnome

2007-02-02 Thread Gustavo J. A. M. Carneiro
On Sex, 2007-02-02 at 14:19 +0100, Murray Cumming wrote:
 
  Just an fyi, but In embedded systems running Gtk+, you don't want to
  have to spend the time to initialize/start up Gstreamer just to play
  bling.  The time lag is far too great.  You limit Gstreamer use to
  items like movie and music playback - not system pings. 
 
 But on systems that will want to do more impressive audio/visual stuff
 sometimes anyway, such as the Nokia N770/N800, wouldn't you want
 gstreamer to be loaded and initialized already anyway? Then there
 shouldn't (theoretically) be any delay in playing a system beep.

  Systems do not want to do impressive audio/visual stuff; it's
applications that want that.  It makes no sense for all applications
to initialize GStreamer if only one or two of them need to do audio or
multimedia stuff.

  If you want to avoid delay when playing a beep, then all apps will
have to initialize GStreamer and precache an audio sample.  Startup time
and memory costs pile up.  It's much better to have a simple sound
server (which can use GStreamer) and a simple client API; a full fledged
GStreamer library is overkill for most apps IMHO.

-- 
Gustavo J. A. M. Carneiro
[EMAIL PROTECTED] [EMAIL PROTECTED]
The universe is always one step beyond logic.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: pulseaudio vs gnome

2007-02-02 Thread Murray Cumming
On Fri, 2007-02-02 at 13:40 +, Gustavo J. A. M. Carneiro wrote:
 On Sex, 2007-02-02 at 14:19 +0100, Murray Cumming wrote:
  
   Just an fyi, but In embedded systems running Gtk+, you don't want to
   have to spend the time to initialize/start up Gstreamer just to play
   bling.  The time lag is far too great.  You limit Gstreamer use to
   items like movie and music playback - not system pings. 
  
  But on systems that will want to do more impressive audio/visual stuff
  sometimes anyway, such as the Nokia N770/N800, wouldn't you want
  gstreamer to be loaded and initialized already anyway? Then there
  shouldn't (theoretically) be any delay in playing a system beep.
 
   Systems do not want to do impressive audio/visual stuff; it's
 applications that want that.  It makes no sense for all applications
 to initialize GStreamer if only one or two of them need to do audio or
 multimedia stuff.

If _even one_ of them wants to do it then it may make sense to have it
pre-initialized, just as you'd expect esd to be initialized after
logging into GNOME now. Assuming that initialization is actually slow. 

I had not considered per-application memory costs, which is indeed worth
worrying about.

   If you want to avoid delay when playing a beep, then all apps will
 have to initialize GStreamer and precache an audio sample.  Startup time
 and memory costs pile up.  It's much better to have a simple sound
 server (which can use GStreamer) and a simple client API; a full fledged
 GStreamer library is overkill for most apps IMHO.

-- 
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: pulseaudio vs gnome

2007-02-02 Thread Nickolay V. Shmyrev

If you want to avoid delay when playing a beep, then all apps will
  have to initialize GStreamer and precache an audio sample.  Startup time
  and memory costs pile up.  It's much better to have a simple sound
  server (which can use GStreamer) and a simple client API; a full fledged
  GStreamer library is overkill for most apps IMHO.
 

There is a patch to notification-daemon to play sound on events with
gstreamer. Of course it needs support for caching right now and for
selection of different sounds, but it can be considered already as a
sound server. Thanks a lot to lack for writing the patch.

http://trac.galago-project.org/ticket/111


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: pulseaudio vs gnome

2007-01-24 Thread Damon Chaplin
On Wed, 2007-01-24 at 21:48 +0900, Davyd Madeley wrote:
 On Fri, 2007-01-19 at 23:36 +, Damon Chaplin wrote:
  On Fri, 2007-01-19 at 11:36 -0500, Matthias Clasen wrote:
   Hey, I just wondered what the current state of affairs is in the
   esound - pulseaudio transition. I found a wiki page
   (http://live.gnome.org/PulseAudio?highlight=%28pulse%29),
   but I'm not sure how uptodate it is.
   
   Is this something that we can still complete for 2.18 ?
   Is anybody working on this ?
  
  Before it goes in I'd like to see a clear roadmap for audio in GNOME,
  with support for things from simple beeps up to pro-audio apps.
  
  I guess this means gstreamer, PulseAudio and JACK. Is that the plan?
 
 Lennart, who develops PulseAudio, recently spoke about it at
 linux.conf.au:
 
   http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/211.ogg
 
 (disclaimer, I don't know what the video quality is like)
 
 He speaks about what PulseAudio can do, why you'd chose it over
 technology X and how it might integrate with specific problem domain
 technologies, such as Jack. Might clear some things up.

Yes, thanks. It's a very good talk.

Lennart agrees that JACK is still needed for pro-audio apps, and that
PulseAudio should work alongside it in some way (or possibly even merge
with it in the future). Though the details were a bit sketchy.

Hopefully we can get him to clarify it a bit more at some point.

Damon


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: pulseaudio vs gnome

2007-01-21 Thread Damon Chaplin
On Sat, 2007-01-20 at 16:26 -0500, Ronald S. Bultje wrote:
 On Sat, 2007-01-20, Damon chaplin wrote:
  Before it goes in I'd like to see a clear roadmap for audio in GNOME,
  with support for things from simple beeps up to pro-audio apps.
  
  I guess this means gstreamer, PulseAudio and JACK. Is that the plan?
 
 Wait wait wait wait wait. Are you suggesting that all this will be GNOME
 technology? I thought the whole idea was to say that audio is a system
 thing? Because it is! On Linux, there is alsa, and if you need
 software-mixing, then there is dmix, and I'm sure stuff doesn't work for
 non-Linux, thin clients and some hardcore dudes and those that
 apparently can't even get their audio working (and then they blame
 dmix), so there's jack or pulse (and/or both?) for them. So GNOME should
 include all of that? Please no!

I just want it to be possible to use  develop audio applications on top
of GNOME (without fiddling about to make it all work).

I'm not saying JACK should be part of GNOME, though maybe it should
become a dependency - it does seem to be used by most audio apps. 

We have all the technology to produce a decent audio platform. Why not
just connect it all together and get it to work out-of-the-box?

Damon


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: pulseaudio vs gnome

2007-01-20 Thread Ronald S. Bultje
On Sat, 2007-01-20, Damon chaplin wrote:
 Before it goes in I'd like to see a clear roadmap for audio in GNOME,
 with support for things from simple beeps up to pro-audio apps.
 
 I guess this means gstreamer, PulseAudio and JACK. Is that the plan?

Wait wait wait wait wait. Are you suggesting that all this will be GNOME
technology? I thought the whole idea was to say that audio is a system
thing? Because it is! On Linux, there is alsa, and if you need
software-mixing, then there is dmix, and I'm sure stuff doesn't work for
non-Linux, thin clients and some hardcore dudes and those that
apparently can't even get their audio working (and then they blame
dmix), so there's jack or pulse (and/or both?) for them. So GNOME should
include all of that? Please no!

esd is in the platform because it already is. Realistically, it doesn't
belong here. Any replacement technology _to have complete feature
equiality with esd_ should be completely optional and a user should be
able to use GNOME without needing to use it and without needing to even
have it installed. Why? Because the whole soundserver for mixing concept
is pointless for many people with a decent soundcard, and for the
majority of the remainder, alsa/dmix should suffice.
Pulse / jack are undoubtedly really cool techniques on which a whole lot
of effort was spent, but they don't belong in GNOME, as part of GNOME or
anything like that. We're not networked thin clients, most of us run
GNOME on a desktop or laptop, and most of us run a recent Linux distro
with a 2.6 kernel. The audience requiring alternate technologies is too
small and too varied to justify putting all those technologies in GNOME.
They would, at best, be recommended technologies to get audio working
in some specific situations (e.g. thin clients, or audio applications
with certain low-latency requirements) in a howto or in the GNOME
documentation. Other than that, it really isn't our problem.

That probably means something like GStreamer to make it bearable for
applications that really don't care and just want to play song.mp3 or
beeps. And that should suffice.

Ronald

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: pulseaudio vs gnome

2007-01-20 Thread Alex Jones
I think that bells and whistles belong in a model similar to Freedesktop
Notifications, but all other multimedia functionality should be done
with GStreamer directly.

On Sun, 2007-01-21 at 00:17 +0200, Marc-André Lureau wrote:
 
 
 On 1/20/07, Ronald S. Bultje [EMAIL PROTECTED] wrote:
 On Sat, 2007-01-20, Damon chaplin wrote:
  Before it goes in I'd like to see a clear roadmap for audio
 in GNOME,
  with support for things from simple beeps up to pro-audio
 apps.
 
  I guess this means gstreamer, PulseAudio and JACK. Is that
 the plan?
 
 
 esd is in the platform because it already is. Realistically,
 it doesn't 
 belong here. Any replacement technology _to have complete
 feature
 equiality with esd_ should be completely optional and a user
 should be
 
 I started to write the l.g.o/PulseAudio page just to track the
 progress and see who is interested to make this happen. Now, its
 getting interesting and hopefully good thing will happen soon. 
 
 I agree with what Ronald wrote. Those are technologies that should not
 be *part of* GNOME. And unfortunately, the dependency GNOME have on
 esd (which is not really that important btw) is due to the broken API
 of libgnome. Straight to the point, that is clear that no application
 should use directly PulseAudio/Jack if they want to be *GNOME
 compliant* (even if I don't really know what *compliant* mean :). 
 
 But note that PulseAudio is a bit more than a esd replacement. And we
 probably have to think how we will provide/export its goodness 
 internal state/parameters/configuration to GNOME. Just take a look at
 all the cool apps that comes with PulseAudio. Of course, they are a
 bit complicated, but we can write a simplified preference applet. That
 makes me slightly think that PulseAudio *might* be part of GNOME
 anyway, but this should be discussed in the future. Make the sound
 server choosable/transparent is enough for now. 
 
 That probably means something like GStreamer to make it
 bearable for
 applications that really don't care and just want to play
 song.mp3 or
 beeps. And that should suffice.
 
 This remark pops up an interesting question: do we really want gnome
 apps linked to GStreamer to play bling? Furthermore, is GStreamer
 API suitable for a simple desktop applications (nautilus, mozilla,
 notify, bling API...) ? I have posted a proposal to define an API for
 desktop sound on freedesktop/dapi/gnome-media mailing lists (without
 much success) - but once again, we don't care about implementation at
 this stage (wether it uses a daemon or not, if it use GStreamer or
 Pulse or anything else). I really think we need to discuss such idea
 to replace the libgnome sound API. Of course, it would be good to have
 people from GStreamer/DBus/PulseAudio discuss such idea also. 
  
 If you look at the code that use esd directly, its only because
 libgnome doesn't provide a simple/complete sound API. And now its time
 to fix libgnome sound to get rid of esd.  At the same time, lets bring
 some new cool things like theming/positionning/introspection 
 control... But that is probably not the good place to discuss this in
 detail. 
 
 After FOMS and DAM3, one has said that new mailing lists will be
 created to discuss desktop audio API. I would like to define also a
 *sound desktop* API. Where are those mailing lists? anyone?
 enough for now,
 
 best regards,
 
 -- 
 Marc-André Lureau, GSmartMix 
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: pulseaudio vs gnome

2007-01-19 Thread Damon Chaplin
On Fri, 2007-01-19 at 11:36 -0500, Matthias Clasen wrote:
 Hey, I just wondered what the current state of affairs is in the
 esound - pulseaudio transition. I found a wiki page
 (http://live.gnome.org/PulseAudio?highlight=%28pulse%29),
 but I'm not sure how uptodate it is.
 
 Is this something that we can still complete for 2.18 ?
 Is anybody working on this ?

Before it goes in I'd like to see a clear roadmap for audio in GNOME,
with support for things from simple beeps up to pro-audio apps.

I guess this means gstreamer, PulseAudio and JACK. Is that the plan?

Damon


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list