Re: pulseaudio vs gnome
> > 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: An idea about a webcam....
Man with that subject line I thought for sure this was a spam message. I was thinking "damn spamassassin, why have you forsaken me!" Sorry random thought. -Rob On Fri, 2007-02-02 at 20:32 +0200, Jason Brower wrote: > I wanted a unified way of communicating with video with as many people > in as many technologies as possible. > I found this very hard so came to the idea of working around technology > that almost everyone has on their computers. This came to 2 things > A browser and JAVA. > With that I was able to create a webcam web-page and people where able > to see me without any problem. I can talk with my family and they can > see me. Even a novice can use my webcam. They just click with a mouse. > Of course there are better technologies. But google video has sucky > video, we still use it because it is so easy to use. > I use a combination of the following...(with notes) > Camserv > Works rather well considering it hasn't been developed sinces > 2003. Very well built and able to do exactly what I want. > Apache > I am sure I could use something smaller and more streamlined for > this use. All it has to do is provide at most maybe five > connections and run under a designated port. > CamServFront > This is a Python, GTK, Glade Program I have made this last week > that is a simple front end to camserv. It provides a nice way > to turn of and on the cam and adjust a few settings to meet the > needs of the you and the client. > > Here is why I am here... > I want this to be a part of gnome. So that people that want to > communicate with a webcam don't have to screw around with msn, aol, > ekiga, or any other protocals or programs. The people that want to see > your webcam can simply use it. Nothing more. Just a click. > We have see these all the time, webcams online, but none of been > streamlined for the personal desktop use. > What do you think? > IF you would like... add me to your gtalk/jabber I am "encompass at > gmail" and I can show you a demo of my idea. I use it all the time and > I think many others will too. > > Hope to get lots of feed back on this. > Jason Brower > > ___ > 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
An idea about a webcam....
I wanted a unified way of communicating with video with as many people in as many technologies as possible. I found this very hard so came to the idea of working around technology that almost everyone has on their computers. This came to 2 things A browser and JAVA. With that I was able to create a webcam web-page and people where able to see me without any problem. I can talk with my family and they can see me. Even a novice can use my webcam. They just click with a mouse. Of course there are better technologies. But google video has sucky video, we still use it because it is so easy to use. I use a combination of the following...(with notes) Camserv Works rather well considering it hasn't been developed sinces 2003. Very well built and able to do exactly what I want. Apache I am sure I could use something smaller and more streamlined for this use. All it has to do is provide at most maybe five connections and run under a designated port. CamServFront This is a Python, GTK, Glade Program I have made this last week that is a simple front end to camserv. It provides a nice way to turn of and on the cam and adjust a few settings to meet the needs of the you and the client. Here is why I am here... I want this to be a part of gnome. So that people that want to communicate with a webcam don't have to screw around with msn, aol, ekiga, or any other protocals or programs. The people that want to see your webcam can simply use it. Nothing more. Just a click. We have see these all the time, webcams online, but none of been streamlined for the personal desktop use. What do you think? IF you would like... add me to your gtalk/jabber I am "encompass at gmail" and I can show you a demo of my idea. I use it all the time and I think many others will too. Hope to get lots of feed back on this. Jason Brower ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
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
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
> 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
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
