Re: Pulseaudio
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 and play experience with audio hardware (be it USB, bluetooth, whatever). PulseAudio provides a solid infrastructure to provide those features to our users. It's not *just* about audio mixing. - Jeff -- GNOME.conf.au 2008: Melbourne, Australia http://live.gnome.org/Melbourne2008 We've got a great drummer and a great singer. Those are the key positions. When you find a singer and a drummer this good, you don't leave them. - Stone Gossard, Pearl Jam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
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 and/or pause when I receive a VoIP call. I'd like delicious plug and play experience with audio hardware (be it USB, bluetooth, whatever). PulseAudio provides a solid infrastructure to provide those features to our users. It's not *just* about audio mixing. It's also about power saving (especially with the ongoing work in ALSA's hrtimer support), legacy applications support (ie. all the GNOME apps), pure bug fixing (esound has architectural issues that are unfixable), actually working for video playback (synchronisation actually works). And it has fun bits like simultaneous multiple sound cards output (output to both your streaming device and your actual speakers), on-the-fly output switching (try that with esd...), and remote output integration with avahi (select the other outputs on your local network easily). It also works on FreeBSD, and Solaris. -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Ronald S. Bultje Daemons for sound routing are not just suboptimal, they are wrong. We have better ways (at least on Linux) nowadays. Any solution based on the idea of a userspace daemon is wrong. Not just suboptimal (which is unacceptable, because ALSA directly is - for Linux users - very much so optimal, and that's 90% of your userbase), not just still somewhat acceptable (because it isn't, we've ditched esound for that very reason) and definitely not required because a small subgroup of your user population needs it (crippling for the sake of network users - yeah right). I get so sick of people saying but I don't *want* a sound daemon, ALSA can 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 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 the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion * Decent OSS emulation that doesn't cut software-mixing out of the loop * Drop in esd replacement for backwards compatibility. And last, and actually one of the minor features: networked audio. Jan. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
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.net/~hcb/murx/xaudio Being in the X server, you gain network transparency and A/V sync. There's no reason PA or gstreamer couldn't have a sink for that. Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: quote who=Ronald S. Bultje Daemons for sound routing are not just suboptimal, they are wrong. We have better ways (at least on Linux) nowadays. Any solution based on the idea of a userspace daemon is wrong. Not just suboptimal (which is unacceptable, because ALSA directly is - for Linux users - very much so optimal, and that's 90% of your userbase), not just still somewhat acceptable (because it isn't, we've ditched esound for that very reason) and definitely not required because a small subgroup of your user population needs it (crippling for the sake of network users - yeah right). I get so sick of people saying but I don't *want* a sound daemon, ALSA can 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 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 daemon. I suspect it uses SYSV IPC to make all processes do some kind of distributed mixing, with no daemon required. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. But most importantly, I wouldn't mind PulseAudio too much *if it worked 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 hardware, but I expect people to believe me when I say it does skip for me. And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion Those are nice features, but all summed together they don't come near to skipless sound that raw ALSA provides. * Decent OSS emulation that doesn't cut software-mixing out of the loop OSS is deprecated. * Drop in esd replacement for backwards compatibility. I already do not use esd. And last, and actually one of the minor features: networked audio. That should be an extra layer *on top of* basic sound, not a replacement layer. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] a11y module proposal: MouseTweaks (i.e.: software click)
Hello, First of all, I would like to thanks all the people that participated in the discussion of MouseTweaks during the accessibility summit, and especially those that made it possible to have it demoed during that event. At 2:24 PM -0400 10/8/07, Willie Walker wrote: We discussed MouseTweaks at the summit at think it definitely looks like it provides great functionality for the intended users. Overall, we support the module proposal, though we also recommend working with the GNOME Usablity folks (http://developer.gnome.org/projects/gup/) on any user interface improvements that would make its configuration and use better for the target user base. When working with them, I think it will be very important to remind them who the target users are and what the typical user interaction model will be. Do I get it right? Does the fact, that you support the module proposal, mean that the aim is to ship it with the next GNOME release (GNOME 2.22)? If so, could you please tell me what are the steps that MouseTweaks will have to do in order to get it into GNOME, and especially the date limits for each step? (Telling me where I can find that information may also suffice.) I will very soon begin the discussion with the people of GUP in order to get a user interface that corresponds more to the HIG of GNOME. But do we have to host MouseTweaks on GNOME's site to get it shipped with GNOME? What about the versioning scheme? Currently MouseTweaks is at version 0.2.2. Do we have to adapt it to the GNOME version; in other words change it to mousetweaks-2.21.n? Do we have to submit the source to a build system in some determined format? Sorry if my questions may be a bit basic, but I am new to this. As an aside, did you give consideration to making the mouse handling portions of this an X Server Extension? The reason I ask is that when developing AccessX many years ago, we originally did it as a client instead of an extension. At the time, we were encouraged to merge with the XKB Server Extension. We did that, and the result is that AccessX functionality pretty much ubiquitous now (yeah!). Times were different back then, however. Today, it seems like getting an X Server Extension accepted and deployed might be more arduous and take a bit longer. So, if MouseTweaks works great as a client-only solution, then perhaps the server extension idea is not that important. Yes, the ideal would have been to implement it directly into X and I have been told that this was also adressed. But it has been decided to develop it as a client mainly for two reasons: - the development took place as a GSoC 2007 project for ubuntu and it was the more direct way to get to the users - the developer (who will continue to do the necessary coding) did not have the necessary knowledge to develop it as an X server extension. (to be complete, nor do I) Of course, if some day, the fonctionalities provided by mousetweaks will be available directly from X, that would probably be better as they would be pretty much ubiquitous. (to quote your words ;) ) Cheers Francesco ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio
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 receive a VoIP call. I'd like delicious plug and play experience with audio hardware (be it USB, bluetooth, whatever). PulseAudio provides a solid infrastructure to provide those features to our users. It's not *just* about audio mixing. I know most people don't read emails (I got this same reply like 10 times over private email), but like I said in my earlier email, I like all these too, they are very cool, and should be integrated into GNOME, rather today than tomorrow, but without the sound daemon part. The original GNOME SoC project (GSmartMix) did that the right way, and could be used as a basis for this part. Sound daemons are old-fashioned, unnecessary and unwanted. We have better solutions and should use them instead. Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Gustavo J. A. M. Carneiro On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: I get so sick of people saying but I don't *want* a sound daemon, ALSA can 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 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 daemon. I suspect it uses SYSV IPC to make all processes do some kind of distributed mixing, with no daemon required. The first process to open the sound device is forked in alsalib and *becomes* the dmix mixing daemon. Check it out in your ps listings. All the other 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. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. By separating the dmix piece from alsalib, I believe we can do better and provide more. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. I think you are most likely wrong here. Every motherboard I've seen in the past 4 years with built-in sound has used AC97 with a codec chip, and none of them have provided hardware mixing support. You're probably using dmix and just don't realise. But most importantly, I wouldn't mind PulseAudio too much *if it worked 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 hardware, but I expect people to believe me when I say it does skip for me. The most likely reason is that you need to give pulseaudio the ability to acquire real-time scheduling privileges, like you do for jackd, because it operates with smaller hardware buffers to achieve lower latency. On a distro that provides PulseAudio integrated, this should happen by default. And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion Those are nice features, but all summed together they don't come near to skipless sound that raw ALSA provides. See the real-time privs point above, or modify the PA config to have bigger buffers. * Decent OSS emulation that doesn't cut software-mixing out of the loop OSS is deprecated. There are plenty of apps that use it though. That may not matter to you, but backward compatibility is important. * Drop in esd replacement for backwards compatibility. I already do not use esd. You must have the Gnome desktop sounds turned off then. And last, and actually one of the minor features: networked audio. That should be an extra layer *on top of* basic sound, not a replacement layer. If you want to do it so that the apps don't have to know about it, it has to integrate underneath them somewhere. But again, I don't see this as PA's major appeal, it's just a neat side-benefit of building things this way. Jan. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
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 hardware, but I expect people to believe me when I say it does skip for me. If you've got VIA video I bet it does. But thats a VIA X problem. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] a11y module proposal: MouseTweaks (i.e.: software click)
Hi Francesco: You're welcome! Thanks for your work on MouseTweaks. :-) The module proposing guidelines are here, with the main timeframes being listed under the Decision Making section: http://live.gnome.org/ReleasePlanning/ModuleProposing (the 2.22 schedule is here: http://live.gnome.org/TwoPointTwentyone). It looks like Gerd is on top of a fair amount of this, and I suspect one bottleneck right now is getting someone set up with a GNOME SVN account and an SVN home for the source. Information about GNOME SVN can be found here: http://svn.gnome.org/. For development purposes, I think the main thing you need to do is track down the people who've commented on your proposal (the thread starts with http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00489.html) and work to come to a resolution with them. If you need help with the HIG work, I can ask one of our friendly Sun folks if they have time to take a look. Will Francesco Fumanti wrote: Hello, First of all, I would like to thanks all the people that participated in the discussion of MouseTweaks during the accessibility summit, and especially those that made it possible to have it demoed during that event. At 2:24 PM -0400 10/8/07, Willie Walker wrote: We discussed MouseTweaks at the summit at think it definitely looks like it provides great functionality for the intended users. Overall, we support the module proposal, though we also recommend working with the GNOME Usablity folks (http://developer.gnome.org/projects/gup/) on any user interface improvements that would make its configuration and use better for the target user base. When working with them, I think it will be very important to remind them who the target users are and what the typical user interaction model will be. Do I get it right? Does the fact, that you support the module proposal, mean that the aim is to ship it with the next GNOME release (GNOME 2.22)? If so, could you please tell me what are the steps that MouseTweaks will have to do in order to get it into GNOME, and especially the date limits for each step? (Telling me where I can find that information may also suffice.) I will very soon begin the discussion with the people of GUP in order to get a user interface that corresponds more to the HIG of GNOME. But do we have to host MouseTweaks on GNOME's site to get it shipped with GNOME? What about the versioning scheme? Currently MouseTweaks is at version 0.2.2. Do we have to adapt it to the GNOME version; in other words change it to mousetweaks-2.21.n? Do we have to submit the source to a build system in some determined format? Sorry if my questions may be a bit basic, but I am new to this. As an aside, did you give consideration to making the mouse handling portions of this an X Server Extension? The reason I ask is that when developing AccessX many years ago, we originally did it as a client instead of an extension. At the time, we were encouraged to merge with the XKB Server Extension. We did that, and the result is that AccessX functionality pretty much ubiquitous now (yeah!). Times were different back then, however. Today, it seems like getting an X Server Extension accepted and deployed might be more arduous and take a bit longer. So, if MouseTweaks works great as a client-only solution, then perhaps the server extension idea is not that important. Yes, the ideal would have been to implement it directly into X and I have been told that this was also adressed. But it has been decided to develop it as a client mainly for two reasons: - the development took place as a GSoC 2007 project for ubuntu and it was the more direct way to get to the users - the developer (who will continue to do the necessary coding) did not have the necessary knowledge to develop it as an X server extension. (to be complete, nor do I) Of course, if some day, the fonctionalities provided by mousetweaks will be available directly from X, that would probably be better as they would be pretty much ubiquitous. (to quote your words ;) ) Cheers Francesco ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: linuxMint's gnome-menu
I would really go with this design, I don't know why very few other alternative menus follow this concept. Denis, which design are you referring to here? I meant the concept of multiple smaller menus instead of one big one, like now with Applications/Places/System. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: linuxMint's gnome-menu
I see now, thanks for clarifying. On Thu, 2007-10-11 at 16:48 +0200, Denis Washington wrote: I would really go with this design, I don't know why very few other alternative menus follow this concept. Denis, which design are you referring to here? I meant the concept of multiple smaller menus instead of one big one, like now with Applications/Places/System. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Gustavo J. A. M. Carneiro On Thu, 2007-10-11 at 23:28 +1000, Jan Schmidt wrote: quote who=Gustavo J. A. M. Carneiro The first process to open the sound device is forked in alsalib and *becomes* the dmix mixing daemon. Check it out in your ps listings. All the other 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 which is that dmix uses shared memory, while esd uses unix socket. No idea about PA. PA uses shared memory segments by default. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. By separating the dmix piece from alsalib, I believe we can do better and provide more. Except hardware mixing. Except clickless audio. PA currently doesn't pass streams through to hardware that supports mixing, I think. There has been talk about having it do so though, and there's no reason why a separate daemon can't provide that. Are you still unclear on the 2 options for making PulseAudio click-free? Either increase the hardware buffers it uses so that it acts like ALSA, or set it up so it can get real-time privs. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. I think you are most likely wrong here. Every motherboard I've seen in the past 4 years with built-in sound has used AC97 with a codec chip, and none of them have provided hardware mixing support. You're probably using dmix and just don't realise. If what you say above about forking is true, then I definitely am using hardware mixing (VIA High Definition Audio Controller (rev 10), though this is not the same harware I tried PA on, the one that produced audio clicks). That may be (regarding hardware mixing). Google isn't being helpful in finding me information about that controller and how many input streams it supports. See the real-time privs point above, or modify the PA config to have bigger buffers. I thought real-time required root privs or a suid root daemon... 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 daemons can be configured to be allowed RT privileges using rtlimits/PAM [1] I already do not use esd. You must have the Gnome desktop sounds turned off then. I do. Yet another feature I don't need and which was getting in the way of perfect sound, so I just disabled it. I turn it off because I find most of the desktop sounds annoying, but I still want the feature to work with whatever solution we end up with, and as you point out - it doesn't at the moment. Jan [1] http://lau.linuxaudio.org/faq/index.php/Capabilities ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio
quote who=Gustavo J. A. M. Carneiro On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: I get so sick of people saying but I don't *want* a sound daemon, ALSA can 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 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 daemon. I suspect it uses SYSV IPC to make all processes do some kind of distributed mixing, with no daemon required. The first process to open the sound device is forked in alsalib and *becomes* the dmix mixing daemon. Check it out in your ps listings. All the other 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. Unless you have hardware mixing. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. By separating the dmix piece from alsalib, I believe we can do better and provide more. Get hardware mixing and don't use dmix at all. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. I think you are most likely wrong here. Every motherboard I've seen in the past 4 years with built-in sound has used AC97 with a codec chip, and none of them have provided hardware mixing support. You're probably using dmix and just don't realise. Which means dmix isn't all that bad after all. 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 of supporting it. But most importantly, I wouldn't mind PulseAudio too much *if it worked 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 hardware, but I expect people to believe me when I say it does skip for me. The most likely reason is that you need to give pulseaudio the ability to acquire real-time scheduling privileges, like you do for jackd, because it operates with smaller hardware buffers to achieve lower latency. On a distro that provides PulseAudio integrated, this should happen by default. Yes, there also are specific distributions finetuned for realtime work, but they are not always useful for normal work. And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion Those are nice features, but all summed together they don't come near to skipless sound that raw ALSA provides. See the real-time privs point above, or modify the PA config to have bigger buffers. * Decent OSS emulation that doesn't cut software-mixing out of the loop OSS is deprecated. There are plenty of apps that use it though. That may not matter to you, but backward compatibility is important. * Drop in esd replacement for backwards compatibility. I already do not use esd. You must have the Gnome desktop sounds turned off then. Who wants to hear all those sounds while listening to your favourite music anyway, I for one never have the desktop sounds turned on. And last, and actually one of the minor features: networked audio. That should be an extra layer *on top of* basic sound, not a replacement layer. If you want to do it so that the apps don't have to know about it, it has to integrate underneath them somewhere. But again, I don't see this as PA's major appeal, it's just a neat side-benefit of building things this way. -- regards Robert G. Moonen registered Linux user number 298132 All truth passes through
Re: Pulseaudio
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 daemons can be configured to be allowed RT privileges using rtlimits/PAM [1] There's also the thing that a real-time process needs to be written in an extremely careful way; basically if it spins it's game over for your system. I know Lennart is doing this the right way in PA by having a baby sitter process (also RT, higher priority) looking after PA. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Thu, 2007-10-11 at 23:28 +1000, Jan Schmidt wrote: The first process to open the sound device is forked in alsalib and *becomes* the dmix mixing daemon. Check it out in your ps listings. All the other 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. 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 and is fundamentally different as pulseaudio or esd. http://lkml.org/lkml/2006/1/8/81 Peter Zubaj ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio
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 of supporting it. How, exactly, would it be abysmal? dave... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio
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: This should be proposed for 2.22 Person A: Someone objected last time Person C: Well I was the one who objected, and my concern has largely been addressed by the discussion we've had already This was followed by a fairly widespread discussion about pro needs and how basically the people doing the hacking are trying to focus on the baseline case for most desktop users' needs first, and after a few goes around pretty much everyone agreed that this made sense. I know nothing of audio issues, but it seemed to me a very positive meeting, and I hope that GNOME will be able to leverage the hard work these hackers are putting in. Cheers, AfC Sydney signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
