On Fri, Jun 29, 2012 at 11:02 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
But we do have pulseaudio in the modulesets, and build it in jhbuild.
So maybe this is not that big of an issue ?
Subsequent irc discussion on #release-team ended with the conclusion
that it is probably fine
On Thu, 2012-06-28 at 15:37 -0400, Matthias Clasen wrote:
We have a nice sound panel simplification incoming in
https://bugzilla.gnome.org/show_bug.cgi?id=674831 which relies on pa
2.0 api to get rid of the 'Hardware' tab.
I propose that we bump the pulseaudio requirement to 2.0 so we can
On Thu, Jun 28, 2012 at 4:48 PM, Colin Walters walt...@verbum.org wrote:
The main issue is the impact on people using jhbuild on last stable
distribution such as Ubuntu 12.04 or Fedora 17. Does pulseaudio build
from jhbuild on those systems?
Actually even trickier, can you build programs
We have a nice sound panel simplification incoming in
https://bugzilla.gnome.org/show_bug.cgi?id=674831 which relies on pa
2.0 api to get rid of the 'Hardware' tab.
I propose that we bump the pulseaudio requirement to 2.0 so we can
land this nice improvement. Pulseaudio 2.0 was released 2 month
On Thu, 2012-06-28 at 15:37 -0400, Matthias Clasen wrote:
We have a nice sound panel simplification incoming in
https://bugzilla.gnome.org/show_bug.cgi?id=674831 which relies on pa
2.0 api to get rid of the 'Hardware' tab.
I propose that we bump the pulseaudio requirement to 2.0 so we can
On Thu, Jun 28, 2012 at 04:48:18PM -0400, Colin Walters wrote:
The main issue is the impact on people using jhbuild on last stable
distribution such as Ubuntu 12.04 or Fedora 17. Does pulseaudio build
from jhbuild on those systems?
Mageia 2 has Pulseaudio 2 :)
--
Regards,
Olav
the procedure
detailed in http://live.gnome.org/TwoPointThirtyone/ExternalDependencies
Seriously I have no objection against bumping the required PulseAudio
version but the release team work is made much easier when people play
according to the rules.
Thank you module maintainers for hearing this.
Anyway
PulseAudio
version but the release team work is made much easier when people play
according to the rules.
Thank you module maintainers for hearing this.
Anyway, please update the wiki page and the jhbuild moduleset to match
your change.
I've updated the wiki page and filed bugs against jhbuild
Hey,
Because I don't want nasty ifdef in gnome-volume-control, I'm upping the
minimum required version of PA to 0.9.16 (from 0.9.15) in gnome-media.
Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
Hi,
Most of the recent gnome-volume-control work by Bastien and Lennart is
using PulseAudio API = 0.9.15. However, 0.9.14 is the current min
dependency version
(http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies).
I'd like to update the minimum required version to 0.9.15
On Sun, 2009-06-14 at 22:37 +0300, Marc-André Lureau wrote:
Hi,
Most of the recent gnome-volume-control work by Bastien and Lennart is
using PulseAudio API = 0.9.15. However, 0.9.14 is the current min
dependency version
(http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies
, but really a new module of GNOME? Probably not.
Regarding replacing esd. Currently a lot of apps link to libesd.so.0.
Pulseaudio doesn't seem to provide a replacement for that lib.
Correct. Until libcanberra comes into place, we have to rely on libesd.
I assume this is because
Asking for hw mixing in PA is like asking
for support for MPEG decoder cards in GST.
GStreamer actually has support for dxr3 cards :)
My sound cards at home all have hardware mixing; it's in my experience
only embedded sound cards (laptops, dell boards, the crap-in-many-ways
ICH series...)
. Currently a lot of apps link to libesd.so.0.
Pulseaudio doesn't seem to provide a replacement for that lib.
Correct. Until libcanberra comes into place, we have to rely on libesd.
I assume this is because of libgnomesomething linking against libesd?
So if those functions are replaced the apps (after
setting up PulseAudio a real pain though.
The idea is that your distribution does this for you.
So, if I get it, one day the whole distribution is using ALSA, and the
day after it should start using PA instead? How do you expect people to
achieve such a miracle without a transition
On Mon, 15.10.07 02:24, Federico Mena Quintero ([EMAIL PROTECTED]) wrote:
As soon as I have a version of this library I will write a small
module for gtk (the kind of you can load into every gtk app with
--gtk-module) which will basically do what libgnome currently does:
hooking
the same. However, since there are some APIs that are
It makes setting up PulseAudio a real pain though.
The idea is that your distribution does this for you.
So, if I get it, one day the whole distribution is using ALSA, and the
day after it should start using PA instead? How do you
everything the same. However, since there are some APIs that are
It makes setting up PulseAudio a real pain though.
The idea is that your distribution does this for you.
So, if I get it, one day the whole distribution is using ALSA, and the
day after it should start using PA instead
On Fri, 2007-10-12 at 21:20 +0200, Lennart Poettering wrote:
[on sounds generated by user events]
As soon as I have a version of this library I will write a small
module for gtk (the kind of you can load into every gtk app with
--gtk-module) which will basically do what libgnome
Le vendredi 12 octobre 2007 à 21:20 +0200, Lennart Poettering a écrit :
Hi Lennart,
I'm sorry I couldn't grab a lock on you at last GUADEC to discuss about
using PA in our distribution (Mandriva)..
Frederic still loves ESD. ESD is bad, in latency, in features, in
code, in everything. I am
pushed for it too early), but that was before Avahi. PulseAudio improved
*massively* after you took the Avahi vacation. ;-)
It's on the list again for 8.04 -- though I don't suppose you're able to
get to FOSSCamp to chat about it? (Having you tell us how Avahi should
be done was very useful g
Frederic Crozat wrote:
hat vendor=Mandriva
As a side note, there are discussions about using PA by default on next
MandrivaLinux release but I'm not sold to the idea yet, for the reasons
stated above. Maybe PA 0.9.7 will make me change my mind, who knows :)
/hat
Fred, Lennart's 0.9.7 branch
Le lundi 15 octobre 2007 à 13:23 +0100, Colin Guthrie a écrit :
Frederic Crozat wrote:
hat vendor=Mandriva
As a side note, there are discussions about using PA by default on next
MandrivaLinux release but I'm not sold to the idea yet, for the reasons
stated above. Maybe PA 0.9.7 will
On Mon, 15.10.07 15:57, Frederic Crozat ([EMAIL PROTECTED]) wrote:
Le lundi 15 octobre 2007 à 13:23 +0100, Colin Guthrie a écrit :
Frederic Crozat wrote:
hat vendor=Mandriva
As a side note, there are discussions about using PA by default on next
MandrivaLinux release but I'm not sold
Lennart Poettering wrote:
On Mon, 15.10.07 15:57, Frederic Crozat ([EMAIL PROTECTED]) wrote:
Le lundi 15 octobre 2007 à 13:23 +0100, Colin Guthrie a écrit :
Frederic Crozat wrote:
hat vendor=Mandriva
As a side note, there are discussions about using PA by default on next
MandrivaLinux
[ Currently trying pulseaudio... ]
On Fri, Oct 12, 2007 at 09:20:36PM +0200, Lennart Poettering wrote:
I am not sure that PA should become part of GNOME. A blessed
dependency sure, but really a new module of GNOME? Probably not.
Regarding replacing esd. Currently a lot of apps link
David Schleef wrote:
On Fri, Oct 12, 2007 at 01:33:29AM +1000, Robert Moonen wrote:
But to get back to the original point of allowing hardware mixing if it
exists on the sound card, I for one want this, it would definitely be
abysmal if I couldn't use the hardware mixer on my au8830 and alsa
at the GNOME wiki, it seems that Pulseaudio
is the stronger candidate between alternatives, and that it allows for
quite a lot of nifty things.
I'm running pulseaudio since four or five months now on two of my
desktop systems, both x86 and PPC, and I must say that I'm really
satisfied
Hi,
On 10/12/07, Lennart Poetering wrote:
Ronald, you claim: sound daemon is the right solution _only_ for
networked audio. This is also bogus. There's a lot of stuff you want
to do in a sound server. For example: policy decisions like everytime
I plug in my USB headset in I want all voip
Hi,
On 10/12/07, Lennart Poettering [EMAIL PROTECTED] wrote:
I am not sure what I should make of this. Do you want to tell me to
go to hell because you know everything better without even reading my
response to your FUD? Or maybe just that you don't want to take part
on this discussion
On Fri, 12.10.07 17:46, Ronald S. Bultje ([EMAIL PROTECTED]) wrote:
On 10/12/07, Lennart Poettering wrote:
Ronald, you claim: sound daemon is the right solution _only_ for
networked audio. This is also bogus. There's a lot of stuff you want
to do in a sound server. For example: policy
quote who=Lennart Poettering
(Of the big distros only that spaceboy distro doesn't love us anymore as
it seems, as I haven't heard from them in a while)
I imagine they're still a bit raw about the last time they tried (I probably
pushed for it too early), but that was before Avahi. PulseAudio
and general concerns brought up in
this thread and how technical in nature they have been the reply was
bound to be long. You are, of course, free to not read it.
I bet Lennart could write less then 10 lines to describe why PulseAudio
is a must-have, that was however not at all the meaning
quote who=Lennart Poettering
Dude, what's wrong with you? The solution I presented allows you to run
GNOME without PA, and even removes the hard ESD dependency. You should be
happy with such a solution, and not insulting me.
At this point Lennart, I think there's a pretty clear consensus
2007/10/12, Ronald S. Bultje [EMAIL PROTECTED]:
Hi,
On 10/12/07, Lennart Poettering [EMAIL PROTECTED] wrote:
I am not sure what I should make of this. Do you want to tell me to
go to hell because you know everything better without even reading my
response to your FUD? Or maybe just
On Fri, 12.10.07 18:21, Ronald S. Bultje ([EMAIL PROTECTED]) wrote:
I am not sure what I should make of this. Do you want to tell me to
go to hell because you know everything better without even reading my
response to your FUD? Or maybe just that you don't want to take part
on this
I have followed rather heated discussions in blog post comments and
mailing list archives about PulseAudio and GNOME and I must say I am
not impressed. Why?
There are many reasons why I think that PA is cool, but I also think
that somehow there is no way, no progression out of it and it's
On Sat, 13.10.07 02:21, Peteris Krisjanis ([EMAIL PROTECTED]) wrote:
Hi!
There are many reasons why I think that PA is cool, but I also think
that somehow there is no way, no progression out of it and it's not
right way to solve GNOME audio problems. Also there is feeling in the
air that is
some attention - releases
are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio
is the stronger candidate between alternatives, and that it allows for
quite a lot of nifty things.
I'm running pulseaudio since four or five months now on two of my
desktop systems, both
On Sat, 13.10.07 00:23, Gustavo J. A. M. Carneiro ([EMAIL PROTECTED]) wrote:
Hi!
But I would be interested to know why PA hogs the sound device. No
one explained this yet, and is the #1 question in my mind. As far as I
can tell, though I admit I'm no expert and could be wrong, PA should
On Sat, 2007-10-13 at 02:21 +0300, Peteris Krisjanis wrote:
2. Device addition/removal - just question - why this should be in PA?
Shouldn't it have to be handled in HAL/ALSA/GNOME level? Why not fix
device selection for ALSA and current GNOME Sound capplet?
PA already listen to events from
the
time.)
Of course dmix adds yet another layer of latency but the most important
thing to me for now is that it works.
By the way, Lennart: I think PulseAudio kicks ass. With all the bad
experiences with ESD we had to endure for years, it is just hard to
believe that a user-space piece of software
on the more complicated use cases.
The important point is that building our audio integration strategy around
PulseAudio *now* doesn't stop us from handling the pro audio case in the
future.
- Jeff
--
linux.conf.au 2008: Melbourne, Australiahttp://lca2008.linux.org.au
Am Dienstag, den 09.10.2007, 10:45 + schrieb Sam Morris:
It still hasn't happened. Proprietary games all still use OSS... even
Teamspeak, which you would think would be designed to function at the
same time as other sound-using programs, uses OSS... meaning that it's
impossible to
quote who=Nickolay V. Shmyrev
I also don't like Pulseaudio for exactly same reasons as Gustavo and
Ronald. I don't see how this will improve our desktop or will help our
users.
I'd like our music or video players to turn down and/or pause when I receive
a VoIP call. I'd like delicious plug
On Thu, 2007-10-11 at 07:34 +1000, Jeff Waugh wrote:
quote who=Nickolay V. Shmyrev
I also don't like Pulseaudio for exactly same reasons as Gustavo and
Ronald. I don't see how this will improve our desktop or will help our
users.
I'd like our music or video players to turn down
*exactly* the same thing that
pulseaudio does, except that it forks whichever process happens to open the
audio device first instead of being an explicit separate binary.
Plus, it traditionally hasn't even done a very good job of being a sound
mixer. It does crappy resampling, gives poor feedback
On Wed, 2007-10-10 at 15:46 +0200, Matteo Settenvini wrote:
Anyway, even if PA isn't *THE* answer, ALSA isn't, either, for the
reasons already expressed in this thread. So, what do you purpose?
IMHO Helge Bahmann got it right: he designed an AUDIO extension for X
Window:
is to have to use dmix, and *dmix is
a sound daemon* - it's fundamentally doing *exactly* the same thing that
pulseaudio does, except that it forks whichever process happens to open the
audio device first instead of being an explicit separate binary.
You are mistaken. ALSA dmix does not require any
Hi Jeff,
On 10/11/07, Jeff Waugh wrote:
quote who=Nickolay V. Shmyrev
I also don't like Pulseaudio for exactly same reasons as Gustavo and
Ronald. I don't see how this will improve our desktop or will help our
users.
I'd like our music or video players to turn down and/or pause when I
to use dmix, and *dmix is
a sound daemon* - it's fundamentally doing *exactly* the same thing that
pulseaudio does, except that it forks whichever process happens to open the
audio device first instead of being an explicit separate binary.
You are mistaken. ALSA dmix does not require any
correctly*. As it is now, maybe it isn't PA's fault, maybe it's the
linux kernel's fault for not having a good enough process scheduler, but
the sad truth is that PA's sound skips (I mean I hear audio clicks when
switching workspaces). I believe when people say it doesn't skip for
their
programs requiring access to mixing services then deliver
their streams to that process via a shared memory mapping. It ends up being
fundamentally the same as pulseaudio or esd with autolaunching.
OK, I see a fork() call in the source code. You're right. There's only
one minor difference here
hardware is to have to use dmix, and
*dmix is
a sound daemon* - it's fundamentally doing *exactly* the same thing that
pulseaudio does, except that it forks whichever process happens to open
the
audio device first instead of being an explicit separate binary.
You are mistaken
On Fri, 2007-10-12 at 01:20 +1000, Jan Schmidt wrote:
Yes, that's the general case, and the way (for example) Jack does it too.
Both Jackd and PA are very careful to drop the root privilege first thing on
startup. Nevertheless, even that is no longer necessary - on recent kernels,
non-root
via a shared memory mapping. It ends up being
fundamentally the same as pulseaudio or esd with autolaunching.
AFAIK this deamon doesn't do mixing. It only manages connection to alsa
device. dmix uses one shared buffer and each application writes their
own samples to buffer using lock free algorithm
On Fri, Oct 12, 2007 at 01:33:29AM +1000, Robert Moonen wrote:
But to get back to the original point of allowing hardware mixing if it
exists on the sound card, I for one want this, it would definitely be
abysmal if I couldn't use the hardware mixer on my au8830 and alsa does
a wonderful job
On Thu, 2007-10-11 at 10:47 -0400, David Zeuthen wrote:
I'm not sure you want to build your case of PA is not right for
GNOME based on Pro audio users.
This came up during the PulseAudio session at Boston Summit, and it was
notable that the conversation went something like:
Person B
On Tue, Oct 09, 2007 at 10:52:14AM +0100, Gustavo J. A. M. Carneiro wrote:
Is there any good reason why Pulse Audio explicitly locks the audio
device, unlike any other normal ALSA client? And no, making every app
use Pulse Audio by force, just because you can, is not a good reason.
If
On Ter, 2007-10-09 at 09:49 -0400, Matthias Clasen wrote:
On 10/9/07, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote:
I am not saying Pulse Audio has these problems. I simply don't know
That can easily be helped. Just try gnome 2.20 with pulseaudio in Fedora 8.
It works beautifully
and you found it doesn't work for you, and that's fine -- I'm
happy to hear your opinion, _expecially_ because it is different than
mine.
I can say only that passing from ALSA to Pulseaudio *for me*:
- decreased overall latency
- meant I didn't have to configure it at all, except modifying my
Hi,
On 10/10/07, Gustavo J. A. M. Carneiro wrote:
I tried and I'm still not convinced. Unless there are some special
kernel patches in fedora making a big difference, I still hate sound
routed through a userspace daemon. I would willingly tolerate it for
sound coming from network
, it would be a shame if you couldn't run GNOME without running a
sound server.
It's already a dependency, as it's used in libgnomeui and exported from
that API. You can already run GNOME without esound or Pulseaudio, and
that's not changing.
Given that libgnomeui is on it's way out, where does
and is called SALSA
(ironically, another ALSA library for embedded environment exists,
with the same name). see
http://www.4front-tech.com/forum/viewtopic.php?t=1887
IMHO, I would rather just drop the mandatory GNOME esound dependency
instead of trying to add PulseAudio as a dependency for 2.22. See
You're not the bad guy. The point is: are you the *only* guy, even if
very vocal? I'd like to hear some more opinions from other people that
*don't* like Pulseaudio.
Others are too patient and avoid /me too but if you like, let me state
that
I also don't like Pulseaudio for exactly same
I disagree with your assertion that userspace audio services are
wrong. How about userspace USB drivers or scanner drivers? Is SANE
completely the wrong approach to scanning?
Gnome has ambitions of being cross-desktop. It can NEVER do that if
apps are connecting directly to Alsa, just like apps
Hi,
Matteo Settenvini wrote:
I'm running pulseaudio since four or five months now on two of my
desktop systems, both x86 and PPC, and I must say that I'm really
satisfied by it.
...
Can it be eligible for inclusion in GNOME 2.22?
GNOME seems like it's far too high in the stack to include
Hi,
On Tue, 2007-10-09 at 10:04 +0200, Dave Neary wrote:
GNOME seems like it's far too high in the stack to include a sound
server API - shouldn't we simply depend on it, rather than integrating
it into the GNOME platform?
Could you perhaps consider to integrate it nicely but not to depend
On Ter, 2007-10-09 at 01:17 +0200, Matteo Settenvini wrote:
Il giorno lun, 08/10/2007 alle 23.19 +0100, Gustavo J. A. M. Carneiro ha
scritto:
Last time I tried PulseAudio (over a year ago) it hogged the sound
device and did not let any other ALSA client produce sound.
Can someone
how much time it took for applications to switch from OSS
to ALSA, after Linux declared ALSA the official blessed Linux sound
API.
Pulseaudio does enable also to use applications still tied to OSS, btw.
It's good that there's an ALSA plugin to redirect sounds to the Pulse
Audio daemon
quote who=Gustavo J. A. M. Carneiro
Why be forced to use a userspace mixing program when hardware mixing would
work equally well (or better) in most situations?
Because the vast majority of audio hardware available today does not *do*
hardware mixing, *and* PulseAudio provides many more
On Tue, 2007-10-09 at 10:45 +, Sam Morris wrote:
On Tue, 09 Oct 2007 10:52:14 +0100, Gustavo J. A. M. Carneiro wrote:
I don't care only about proprietary applications. You think for example
that Second Life Linux client (which is open source) will use Pulse
Audio API directly? It
On 10/9/07, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote:
I am not saying Pulse Audio has these problems. I simply don't know
That can easily be helped. Just try gnome 2.20 with pulseaudio in Fedora 8.
It works beautifully.
And once you tried, you don't have to spread FUD anymore
El lun, 08-10-2007 a las 22:26 +0200, Matteo Settenvini escribió:
It also seems to be actively developed, and is shipped by default with
Fedora 8.
Also will be the default in upcoming Mandriva 2008
Can it be eligible for inclusion in GNOME 2.22?
+1
Thanks a lot :-)
.
It's already a dependency, as it's used in libgnomeui and exported from
that API. You can already run GNOME without esound or Pulseaudio, and
that's not changing.
--
Bastien Nocera [EMAIL PROTECTED]
___
desktop-devel-list mailing list
desktop-devel
On Mon, 2007-10-08 at 19:20 -0500, Travis Watkins wrote:
On 10/8/07, Bastien Nocera [EMAIL PROTECTED] wrote:
That's a bug in ALSA, and it's getting fixed (in ALSA) for when playing
sounds, and more recent Pulseaudio will release the device when no
streams are playing (thus avoiding ALSA
.
Also will be the default in upcoming Mandriva 2008
This is absolutely false.
We have not changed sound servers for Mandriva 2008.0, simply because,
from a cross desktop distribution point of view, just replacing esound
by PulseAudio wouldn't fix the entire problem (we would still have to
deal
Hi,
I'm new to this list, so sorry if I ask something already discussed.
It has been a while since esound has received some attention - releases
are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio
is the stronger candidate between alternatives, and that it allows for
quite
On Mon, 2007-10-08 at 22:26 +0200, Matteo Settenvini wrote:
Hi,
I'm new to this list, so sorry if I ask something already discussed.
It has been a while since esound has received some attention - releases
are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio
I agree that PulseAudio is quite nice, I use it on my amd64 system. It
has some GTK gui config tools which are nice, but I feel like they
would need to be a little simpler if they were going to be included in
Gnome. It's pretty powerful and flexible from what I've seen. That
part aside...
I would
Hi,
is a sound server such as esd or pulseaudio still needed at all? As far
as I understand, ALSA allows access from multiple applications. It
supports hardware mixing and provides dmix as a fallback on systems
where hardware mixing is not available. For the casual user, this should
be sufficient
Hi,
On Mon, 2007-10-08 at 22:26 +0200, Matteo Settenvini wrote:
Hi,
I'm new to this list, so sorry if I ask something already discussed.
It has been a while since esound has received some attention - releases
are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio
Last time I tried PulseAudio (over a year ago) it hogged the sound
device and did not let any other ALSA client produce sound.
Can someone confirm the bug is still there? Just (e.g.) play some music
with PulseAudio and then start an ALSA client, check that mixing is
being done.
If the bug
the esound API to simply pipe the sound into gstreamer? Is that
possible?
Pulseaudio isn't a GStreamer contender. In fact, it exists a pulsesink
component for gstreamer, very much like there exist a alsasink, an
osssink, a esdsink...
If I understand correctly, you'd like to have esound be a wrapper
On Mon, 2007-10-08 at 23:55 +0200, Sven Neumann wrote:
Hi,
is a sound server such as esd or pulseaudio still needed at all? As far
as I understand, ALSA allows access from multiple applications. It
supports hardware mixing and provides dmix as a fallback on systems
where hardware mixing
Il giorno lun, 08/10/2007 alle 23.19 +0100, Gustavo J. A. M. Carneiro ha
scritto:
Last time I tried PulseAudio (over a year ago) it hogged the sound
device and did not let any other ALSA client produce sound.
Can someone confirm the bug is still there? Just (e.g.) play some music
On 10/8/07, Matteo Settenvini [EMAIL PROTECTED] wrote:
Hi,
I'm new to this list, so sorry if I ask something already discussed.
It has been a while since esound has received some attention - releases
are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio
is the stronger
On Mon, 2007-10-08 at 23:55 +0200, Sven Neumann wrote:
Hi,
is a sound server such as esd or pulseaudio still needed at all? As far
as I understand, ALSA allows access from multiple applications. It
supports hardware mixing and provides dmix as a fallback on systems
where hardware mixing
, on
a IBM Thinkpad four-years-old 2.4Ghz P4 laptop. I don't know what
version you use, or if it is an issue specific of your system, but I
never noticed slowdowns due to pulseaudio.
Moreover, a lot of videos lagging with esd now play fine.
Cheers,
--
Matteo Settenvini
FSF Associated Member
Email
On 10/8/07, Bastien Nocera [EMAIL PROTECTED] wrote:
That's a bug in ALSA, and it's getting fixed (in ALSA) for when playing
sounds, and more recent Pulseaudio will release the device when no
streams are playing (thus avoiding ALSA generating all those
interrupts).
Exact same problem would
.
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
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
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
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
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
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
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
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
:
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
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
1 - 100 of 101 matches
Mail list logo
