On Fri, Jun 29, 2012 at 11:02 AM, Matthias Clasen
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 to bump the re
On Thu, Jun 28, 2012 at 4:48 PM, 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?
>
> Actually even trickier, can yo
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
On Thu, Jun 28, 2012 at 5:00 PM, David Henningsson
wrote:
> I have not "built pulseaudio from jhbuild", but just to complicate matters,
> Ubuntu 12.04 runs PulseAudio 1.1 with the jack detection patches backported.
>
> So for a standard installation of Ubuntu 12.04, insta
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 :)
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
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 releas
gt;
> 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, please update the wiki page and the jh
on to ignore 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
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
http://mail.gnome.org/mailman/l
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
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
> 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...) th
Frederic Crozat wrote:
>> So, for the time being until we can replace the esd-specific code in
>> libgnome libesd will continue to be shiped, although the rest of ESD
>> is not.
>
> Hmm, unless I'm mistaken, I think we have a problem here : esound is
> part of the GNOME platform, which means we ar
;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 to libesd.so.0.
> > Pulseaudio doesn't seem to provide a replacement for that lib.
>
> Correct. Until libcanbe
ng everything go through PA, so that we can treat
> > > > 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.
>
rything go through PA, so that we can treat
> > > > 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.
>
> S
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:
> > ho
r, 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 d
t;
> 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 of libgnome linking against libesd?
>
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:
stable. Stable enough for us to push it into F8. The only reason I
> didn't release this as 0.9.7 yet
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:
> > > http://0pointer.net/lennart/ GnuPG 0x1A015CC4
___
desktop-devel-list mailing l
Le lundi 15 octobre 2007 à 13:23 +0100, Colin Guthrie a écrit :
> Frederic Crozat wrote:
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Frederic Crozat wrote:
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
y tried (I probably
> 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 u
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 n
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 curre
[ 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
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 a
t that point, we can
focus 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 20
soon. (Perhaps I should have a go at it if I find 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 jus
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
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, 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
A's defense and replying more quickly than I did. Thanks,
> dudes!
>
> > 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
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'
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
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
on in this thread.
Considering all the questions asked 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
i
> (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 impro
> 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 emerging,
and you have the opt
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:
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 v
most 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 x86 and PPC, and
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
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
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 jo
eams to that process 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 bu
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
tating because ALSA's solution for mixing on
>>> > > the
>>> > > vast majority of modern sound hardware is to have to use dmix, and
>>> > > *dmix is
>>> > > a sound daemon* - it's fundamentally doing *exactly* the same thing that
cess 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
On Thu, 2007-10-11 at 09:42 -0400, Ronald S. Bultje wrote:
> Sound daemons are old-fashioned, unnecessary and unwanted. We have
> better solutions and should use them instead.
Except that basically all consumer hardware today relies on software
mixing [1]. So "just use ALSA", basically means "use
;. It's so irritating because ALSA's solution for mixing on the
> > > vast majority of modern sound hardware is to have to use dmix, and *dmix
> > > is
> > > a sound daemon* - it's fundamentally doing *exactly* the same thing that
> > > pulseaudio do
Hi Jeff,
On 10/11/07, Jeff Waugh wrote:
>
> > 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 d
ern sound 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 separat
> 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
t; do it all!". It's so irritating because ALSA's solution for mixing on the
> vast majority of modern sound 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 wh
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: http://www.chaoticmind
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.
Plus, it traditionally hasn't even done a v
On Thu, 2007-10-11 at 07:34 +1000, Jeff Waugh wrote:
>
>
> > 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 v
> 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
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 r
> 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
th
rstand correctly, this project exists 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 ad
und server. While it would of
> > course be nice to have one that nicely interoperates with the GNOME
> > desktop, 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 libgnome
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 applic
direct ALSA access cannot get along.
You tried 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
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 pu
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
default with
> > > Fedora 8.
> > >
> >
> > 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 re
default with
> > > Fedora 8.
> > >
> >
> > 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, j
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
> &g
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.
--
Bastien Nocera <[EMAI
n 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 with Arts for
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 :-)
___
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
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?
> hardware mixing, *and* PulseAudio provides many more features and benefits
> to users than just audio mixing, particularly with regards to programmatic
> volume control and plug-n-play hardware integration. Audio mixing is *NOT*
> the #1 feature opportunity here by a long shot!
Simple a
> 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 features and benefits
to user
er
> perfectly well 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
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 will take years before that happens. I remember
> perfect
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 s
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 depe
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 f
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
> interru
ved 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 mon
ying multiple sounds, 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
FS
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
&
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 s
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
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
&
e were to re-implement
> 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 correctl
On Mon, 2007-10-08 at 23:19 +0100, Gustavo J. A. M. Carneiro wrote:
> 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
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 is
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, i
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
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..
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 see
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
qu
1 - 100 of 113 matches
Mail list logo
