Re: Pulseaudio problem with xine, xmms and mplayer
On Sat, 19.12.09 18:33, Paul (p...@all-the-johnsons.co.uk) wrote: Hi, Heya, Whenever I try to run xine, xmms or mplayer from the command line, I keep getting an error from pulseaudio Assertion 'pthread_mutex_unlock(m-mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. It makes no difference if I try to use ogg, mp3 or wav files, they all fail and die with the same error. I'm using pulseaudio-0.9.21-3.fc13 and the 2.6.32-0.65.rc8.git5.fc13.i686.PAE kernel PAM fires up and reports all the audio devices are running fine. Any ideas? Yes. Firstly, next time please report bugs to bugzilla, that's why we have it. https://bugzilla.redhat.com/show_bug.cgi?id=548989 Secondly, this is not a PA problem. The RT folks broke PI mutexes again, this is a kernel/glibc problem. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Wed, 09.12.09 13:51, Christof Damian (chris...@damian.net) wrote: On Tue, Dec 8, 2009 at 12:59, Tomasz Torcz to...@pipebreaker.pl wrote: On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: pavucontrol is regarded as advance tool, but also partly obsolete. Current gnome-volume-control superseded most of its functionality: controlling different streams volume, switching profile, outputs, fallback devices. I am curious: If pavucontrol is obsolete, is there some other tool to tell skype to use headsets, while rhythmbox uses the speakers? This is about the only feature still only available in pavucontrol, that we'd like to support in g-v-c as well. During GUADEC we discussed a few possible designs for this, so hopefully this will come soon. pavucontrol currently crashes (and pulseaudio) for me on one machine and I need this functionality. File a bug. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio in F12
On Sun, 29.11.09 12:58, Paulo Cavalcanti (pro...@gmail.com) wrote: Hi, I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess. http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ... That is not true, unless you reconfigured PA in some way... Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Status of HAL
On Tue, 10.11.09 08:45, Rahul Sundaram (sunda...@fedoraproject.org) wrote: On 11/10/2009 08:43 AM, Orion Poplawski wrote: On Mon, November 9, 2009 1:28 pm, Bill Nottingham wrote: - It's so deprecated that one of its replacements (HAL) has since been frozen and deprecated Okay, I really can't keep up with Linux development these days. What has replaced HAL? It hasn't yet but DeviceKit will over a period of time. There is no such thing as DeviceKit (anymore), there are only two independant projects DeviceKit-power and DeviceKit-disks. Most other things the old HAL did have been migrated into various other packages, such as udev/libudev and more. The Ubuntu folks have a nice overview of what moved where and how things were updated: https://wiki.ubuntu.com/Halsectomy Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wed, 30.09.09 15:41, Thomas Janssen (thom...@fedoraproject.org) wrote: Haha. So the major 'advantage' of Phonon that it would allow replacing the backends as time progresses without breaking the KDE apps using them now officially is proven to be bogus. The KDE/Qt folks were so afraid of a media engine breaking API so that they created their abstraction thing and now break API of that one more often then the media engines themselves do. Do I hear an I told you so!? Abstractionitis is an illness, not a remedy. People who live in a glass houses shouldn't throw stones. Are you suggesting PA was an abstraction layer? Maybe it can act as one, but that is only a side effect, not its only purpose. Unlike for example Phonon. An abstraction layer's main purpose it to abstract differences of what is below, and as hence usually is a least common denominator of what is below, but certainly nothing that adds features. PA OTOH extends what is below, it adds features. But heck, this discussion is pretty academic and off-topic. Let's end this here. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wed, 30.09.09 10:15, Jaroslav Reznik (jrez...@redhat.com) wrote: So where's the problem? There are two Phonons - one in Qt, one in KDE. I don't like this schizophrenia. This should be solved but now we have to live with one or another - that's why we brought this issue to the world. Maybe KDE should add another abstraction layer on top of the various Phonons which abstracts the differences between them! [1] But I'm happy you have joined this discussion as PA developer. How do you see PA support in GStreamer and Xine? Functionality, features, support - regarding to Fedora development as this could influence our final decision. Isn't it obvious where the good stuff is? Just compare how many commits happened in the last months to the xine-lib hg and how many to the gst git trees. gst has a much much larger developer community and multiple companies backing it. It's the only practical way to get licenses MP3 codecs for Linux. And it is more powerful than xine in many ways. Also, my cooperation with the gst devs is much closer. I have contributed some patches to xine a while back too, but since I don't use it it is much more lacking. Finally, Gst is used by Gnome. Would be great if this could be another place were we could not only cooperate on specs but also actually share code. Another interesting thing is PA Phonon integration work by Colin Guthrie (see the link in my first message). Phonon just as wrapper/thin client for PA with nicer Qt like API. I like this idea. Uh, PA is a PCM sound server. Phonon an abstraction layer for general media streaming. Those are different things. Yu can wrap PA and gstreamer in phonon, but just wrapping PA alone won't fly. Lennart [1] That was a joke. -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wed, 30.09.09 13:53, Rahul Sundaram (sunda...@fedoraproject.org) wrote: On 09/30/2009 01:45 PM, Jaroslav Reznik wrote: So where's the problem? There are two Phonons - one in Qt, one in KDE. I don't like this schizophrenia. This should be solved but now we have to live with one or another - that's why we brought this issue to the world. The problem is that Nokia now seems to be developing yet another abstraction layer. So we will have to be dealing the Phonon in KDE, Phonon in Qt and whatever Nokia brings up next and all the possible backends. The number of different paths that requires comprehensive testing has exploded. We are also debating which backend to use as the default for a long time and as usual, switching backends is exchanging one set of bugs with another so neither is going to be ideal. I would prefer Gstreamer as the backend simply because users can install a set of plugins (third party repo or Fluendo) and have their content play in all the different desktop environments. We can fix bugs once in Gstreamer and be done with it. However that depends on how much testing this backend has received and what bugs have been found and how severe they are. This is a bit of a chicken-and-egg problem: if you don't activate gst noone will test it. But you don't want to activate it by default without testing. We're Fedora, the distro which is always a bit ahead of the other distributions, aren't we? So I think it would make a lot of sense to switch to make our distro Gst-only asap. Eventually this move will have to happen anyway. And if it's not us who does the switch first, who will? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Tue, 29.09.09 18:23, Kevin Kofler (kevin.kof...@chello.at) wrote: Jaroslav Reznik wrote: GStreamer backend facts: * now default one in Fedora (F12, rawhide) * GStreamer is Fedora's default multimedia framework - better support from Fedora side? (PA, releases) * Phonon backend not as mature as Xine one - missing functionality More bugs too. * Maybe more support from upstream developers in the future? [1] * Nokia is upstream But nobody knows for how long because Nokia is working on an alternative multimedia framework for Qt as part of the Qt Mobility project. Uh. Nokia stands pretty firmly behind gst. As do most embedded folks. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Audio broken in F11
On Mon, 21.09.09 01:09, Devrim GÜNDÜZ (dev...@gunduz.org) wrote: On Sun, 2009-09-20 at 14:21 -0400, Mark Bidewell wrote: owever early returns point to a kernel bug. 2.6.29.6-217.2.16 works fine but 2.6.30.5-43 does not and neither does a custom built 2.6.31. Same here on an HP Pavilion dv5 Notebook. However, I'm tired enough trying to fix/report sound issues on Fedora for a long time. Sorry guys, Pulseaudio is broken -- or say, what should I do if sound is broken on a desktop machine? I sometimes have to reboot to get the sound again. This has nothing to do with PA. That said, you are wetting my appetite for another flamewar about this, ... not! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Tue, 08.09.09 10:33, Michel Alexandre Salim (michael.silva...@gmail.com) wrote: The latest Rawhide llvm build: http://koji.fedoraproject.org/koji/buildinfo?buildID=130997 -- which you'd probably have to install manually until it hits the Rawhide mirrors -- have clang's analyzer packaged. Once it lands properly you can have llvm, llvm-clang (the compiler) and llvm-clang-analyzer installed by simply doing yum install llvm-clang-analyzer Thanks for packaging this. Unfortunately it doesn't really work: Whatever I try to use scan-build on I get: Can't exec clang-cc: No such file or directory at /usr/lib64/clang-analyzer/libexec/ccc-analyzer line 216. readline() on closed filehandle FROM_CHILD at /usr/lib64/clang-analyzer/libexec/ccc-analyzer line 222. Adding /usr/libexec/ to the $PATH seems to fix this. However, it still can't find any standard C includes then. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Tue, 08.09.09 19:52, Lennart Poettering (mzerq...@0pointer.de) wrote: On Tue, 08.09.09 10:33, Michel Alexandre Salim (michael.silva...@gmail.com) wrote: The latest Rawhide llvm build: http://koji.fedoraproject.org/koji/buildinfo?buildID=130997 -- which you'd probably have to install manually until it hits the Rawhide mirrors -- have clang's analyzer packaged. Once it lands properly you can have llvm, llvm-clang (the compiler) and llvm-clang-analyzer installed by simply doing yum install llvm-clang-analyzer Thanks for packaging this. Unfortunately it doesn't really work: Whatever I try to use scan-build on I get: Can't exec clang-cc: No such file or directory at /usr/lib64/clang-analyzer/libexec/ccc-analyzer line 216. readline() on closed filehandle FROM_CHILD at /usr/lib64/clang-analyzer/libexec/ccc-analyzer line 222. Adding /usr/libexec/ to the $PATH seems to fix this. However, it still can't find any standard C includes then. Hmm, I need to correct myself, this seems to work fine: CFLAGS=-I/usr/lib/gcc/x86_64-redhat-linux/4.4.1/include/ scan-build ./autogen.sh CFLAGS=-I/usr/lib/gcc/x86_64-redhat-linux/4.4.1/include/ scan-build make Thanks again for packaging. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: pulseaudio 0.9.15 for F10?
On Sat, 08.08.09 12:10, Roberto Ragusa (m...@robertoragusa.it) wrote: Hi all, are there pulseaudio 0.9.15 rpms for F10? Nothing in koji, the F11 rpms have no easily solvable dependencies, even an attempt to rebuild the src.rpm on F10 failed because it needs libtool-2.2, if I understand correctly. I am certainly one of those people who think that released distributions should only receive security fixes and small other bug fixes. Upgrading PA like this involves big changes and does not qualify as either security nor as small other bug fixes. If you want a newer PA I'd recommend doing the upgrade from F10 to F11. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: pulseaudio 0.9.15 for F10?
On Sat, 08.08.09 18:56, Kevin Kofler (kevin.kof...@chello.at) wrote: Lennart Poettering wrote: Upgrading PA like this involves big changes and does not qualify as either security nor as small other bug fixes. Well, then you could backport at least the bugfixes. It's pretty bad that known bugs, even pretty bad ones, are staying unfixed on the still-supported F10. So why don't you backport the fix in question here then if you consider this issue so important? I am not the only one with CVS access here, am I? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
eOn Sat, 01.08.09 00:41, Doug Ledford (dledf...@redhat.com) wrote: - and the killer argument: we don't even ship a CD player app that could make use of the analog CDDA playback path. To my konwledge there is none in the default install, nor in the entire distro. And this has nothing to do with whether or not the mixer should be able to deal with analog in to analog out directly, which was my complaint. The CD portion of it was just one instance, the other being my use of line in for my iPhone. Assuming that because you don't have access to a CD player that does CDDA based playing today means that it simply doesn't work in the hardware is just silly. And assuming that because your CD in path doesn't work that no analog input path should be redirected in hardware to speakers is also just as silly. In three ways you seem very confused. Firstly, analog path CDDA playback is a feature that got removed from Fedora long before PA/g-v-c decided to hide the CD volume slider. There is no CD player supporting the analog path in Fedora. So _I_am_not_the_one_you_should_be_complaining_to_. Secondly, PA doesn't even take away the ability to control the CD slider, at all. In contrast to analog path CDDA playback where we don't ship any tool that supports this anymore, we do ship numerous alternative ALSA mixers, for the UI and for the terminal which expose the CD slider. So, PA does not take anything away from you. And so again, _I_am_not_the_one_you_should_be_complaining_to_. Thirdly, you are conflating CDDA playback with support analog input/output in some way that makes no sense at all. Of course we support analog input and output. After all this is software for sound cards! Claiming we would be dropping support for analog audio input/output is as stupid as claiming Obama wasn't born in the US. All PA does here is hiding a few obsolete ports, such as CDDA, which as mentioned above, isn't otherwise supported anymore anyway. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Installing glibc 2.10.90-10 hosed my system last night
On Thu, 30.07.09 21:25, Richard W.M. Jones (rjo...@redhat.com) wrote: On Thu, Jul 30, 2009 at 01:12:25PM +0200, nicolas.mail...@laposte.net wrote: but X / GNOME is still severely broken. GNOME has been broken in rawhide for a week now https://www.redhat.com/archives/fedora-devel-list/2009-July/msg01500.html It was pulseaudio BTW. Oh my. PA's not at fault here. PI mutexes are broken in the rawhide kernel/glibc. It's simply PA which triggers that. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Thu, 30.07.09 17:09, Matthew Woehlke (mw_tr...@users.sourceforge.net) wrote: Lennart Poettering wrote: Modern sound card designs don't do hw mixing anymore, it's like fm synthesis or wavetable audio. /me misses fm synth :-) (At least, I'm still looking for something that will turn a MIDI into a .wav/.ogg/etc that sounds like an SB16... DOS MIDI player in dosbox is the closest I've found so far, but it sucks for batch processing.) Try timidity. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Thu, 30.07.09 16:53, Matthew Woehlke (mw_tr...@users.sourceforge.net) wrote: Doug Ledford wrote: Every system I build still keeps the analog signal cable between the CD/DVD and the soundcard. This doesn't help if I try to watch a movie as that signal has to be decoded and then played, but for audio CDs it is still a perfectly acceptable means of playing the music. So I'm not sure where this CD in is obsolete comes from. Even the motherboard I bought about 2 months ago still has a CD in port and the CD/DVD in that machine still has an analog output. CD is digital and can be read in digital format by your CPU and sent in digital to the sound device. This is lossless. Adding here: The analog path for CDDA is completely broken and obsolete: - It doesn't work with USB cd drives - It doesn't work with USB sound cards - It doesn't work with Bluetooth headsets - It doesn't work with SPDIF out - It doesn't work if you have more than one cd drive - It doesn't work if you have more than one audio device - Modern cards don't even have the connector anymore - There is no way to get acces to the PCM data before playing it, meaning no equalizers applied, no visualizations, no signal meters, no suurrround upmixing, no nothing. - There is no way to figure out if it is actually connected, so exposing it would more often than not show something that doesn't work at all. - and the killer argument: we don't even ship a CD player app that could make use of the analog CDDA playback path. To my konwledge there is none in the default install, nor in the entire distro. Doing digital grabbing of is very reliable these days. The analog path is just completely obsolete. Every time someone brings the analog cd playback path he's just making a complete fool out of himself because it is so very obvious that the issue is made up and even he himself hasn't used that feature for years. Because otherwise he'd know how broken it is. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Installing glibc 2.10.90-10 hosed my system last night
On Thu, 30.07.09 15:40, Adam Williamson (awill...@redhat.com) wrote: On Thu, 2009-07-30 at 23:00 +0200, Lennart Poettering wrote: On Thu, 30.07.09 21:25, Richard W.M. Jones (rjo...@redhat.com) wrote: On Thu, Jul 30, 2009 at 01:12:25PM +0200, nicolas.mail...@laposte.net wrote: but X / GNOME is still severely broken. GNOME has been broken in rawhide for a week now https://www.redhat.com/archives/fedora-devel-list/2009-July/msg01500.html It was pulseaudio BTW. Oh my. PA's not at fault here. PI mutexes are broken in the rawhide kernel/glibc. It's simply PA which triggers that. This would explain why I'm not seeing it - I'm still on kernel 2.6.30, as my wireless driver won't build with 2.6.31. This is supposed to be fixed now in glibc 2.10.90-10 and later. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Thu, 30.07.09 19:37, Jeff Garzik (jgar...@pobox.com) wrote: Lennart Poettering wrote: On Thu, 30.07.09 19:06, Jeff Garzik (jgar...@pobox.com) wrote: Lennart Poettering wrote: Doing digital grabbing of is very reliable these days. The analog path is just completely obsolete. I guess it's an open question why HDA touts multi-analog and hw mixing as modern features, then :) Oh does it? How about adding some references to this claim? Might be actually convincing then. http://www.intel.com/design/chipsets/hdaudio.htm Where do you see hardware mixing mentioned there? Or multi-analog? I certainly cannot see that mentioned directly or indirectly in any way on that page. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Thu, 30.07.09 20:07, Jeff Garzik (jgar...@pobox.com) wrote: Lennart Poettering wrote: On Thu, 30.07.09 19:37, Jeff Garzik (jgar...@pobox.com) wrote: Lennart Poettering wrote: On Thu, 30.07.09 19:06, Jeff Garzik (jgar...@pobox.com) wrote: Lennart Poettering wrote: Doing digital grabbing of is very reliable these days. The analog path is just completely obsolete. I guess it's an open question why HDA touts multi-analog and hw mixing as modern features, then :) Oh does it? How about adding some references to this claim? Might be actually convincing then. http://www.intel.com/design/chipsets/hdaudio.htm Where do you see hardware mixing mentioned there? Or multi-analog? I certainly cannot see that mentioned directly or indirectly in any way on that page. Try the programmer's guide, for one. If you are going to whine about googling, don't expect to be spoonfed knowledge you should already know. Sorry, still don't see anything regarding touted hw mixing. Page number please! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Wed, 29.07.09 12:33, Michal Hlavinka (mhlav...@redhat.com) wrote: This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm l PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. First, I like pulseaudio, especially the ability of moving streams from one sink to another is awesome for laptops with external sound card :o) But imo hw mixer (or other hw parts) are not that bad... we still have hw accelerated graphic, math,... why not sound? Also this remains me that pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1 which (I suppose) some hw mixer could do while letting cpu free for other tasks. If PA eats a lot of CPU this can have many reasons, most of them have to do with the latency settings requested by the applications or that have been configured due to frequent underruns. However the actual mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. But then again, I am happy to take patches. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Wed, 29.07.09 09:46, Karel Zak (k...@redhat.com) wrote: On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote: On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: Please note that it is our intention not to wrap obsolete mixer controls such as CD, PC Speaker, MIDI and so on. If you file a bug asking for those to be wrapped we will disappoint you and close the bug WONTFIX. When you mean 'not wrap them', do you mean they're no longer selectable as a record source, if the hardware exports them? Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It's my opinion. Which is based on not being blind to what's happening around me. It seems that HW companies still produce the obsolete technology. Modern sound card designs don't do hw mixing anymore, it's like fm synthesis or wavetable audio. It's simply not done in hw anymore. The only exceptions are cards for gamers, i.e. Creative cards. And uh, quite frankly those cards probably only have it because they need at least something that distuingishes them from normal HDA cards. In my little array of sound cards I have here not a single one still does hw mixing. So even if I wanted to add hw mixing support to PA I couldn't because I have nothing to test with. Also given that these days you find that feature only in Creative cards and Creative is mostly anti-Free-Software I really see no point in spending a minute on adding support for this to PA even if it would make technical sense, which it doesn't. Also, let's not forget smething: DirectSound in Vista does not support hw acceleration for audio at all anymore: http://connect.creativelabs.com/openal/OpenAL%20Wiki/OpenAL%C2%AE%20and%20Windows%20Vista%E2%84%A2.aspx And CoreAudio never did either. Creative is now pushing OpenAL since they apparently believe that hw mixing just for hw mixing's sake is something that makes sense to gamers -- even though it makes no sense at all to me. But than again, if hw mixing is that important to you, I am happy to merge patches if they are clean. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Wed, 29.07.09 06:48, Jeff Garzik (jgar...@pobox.com) wrote: Karel Zak wrote: On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote: On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. Quite agreed [says a former kernel audio driver maintainer], and I will go even farther: Maybe since the times you worked on audio drivers the design of the sound cards changed a little and stuff like SSE became largely available? It is completely stupid to waste host CPU on a task that can be offloaded in parallel to dedicated audio hardware. If the user intentionally purchased expensive audio hardware with nice hardware mixing, do not subvert the user's intentions by ignoring such nice hardware. Any developer who claims always use software mixing or always use hardware mixing is a young, inexperienced fool. There are valid situations for both choices. Hear hear, Mr. Garzik is the the old experienced wise man of audio, who knows so much more about audio than any of the audio guys at Microsoft or Apple. Happy to take patches. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Wed, 29.07.09 20:20, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: Le mercredi 29 juillet 2009 à 17:49 +0100, Bastien Nocera a écrit : On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote: Problem is... removing or disabling PA often -does- solve a problem. Rather, it works around it. The problems in the kernel drivers are usually still there... Before PA a sound problem didn't freeze the GUI (effectively bricking the system for normal users). Now it can. In my case, a few months ago, it was doing so because a new PA version could not parse a manual config change advertised in Fedora's own Glitch-free audio feature page a release before. Lennart stated that all this (PA being able to pull the GUI down, PA not being able to parse what was a correct config file a version before, PA rpm performing an unsafe upgrade) was NOTABUG. Twisting my words Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Tue, 28.07.09 16:06, Pierre-Yves (pin...@pingoured.fr) wrote: On Tue, 2009-07-28 at 15:59 +0200, Lennart Poettering wrote: When you test this, please make sure to run version 0.9.16-4.test3 of PA and 2.27.5 of gnome-media at least. Both are still stuck in Koji, aren't in Rawhide yet. Any plan to push this in F11 at some point ? (even if it stays in testing ?) No. This change is very invasive. (Also, I always considered a pretty bad idea to updated already released distros for anything but security fixes and bugfixes.) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Tue, 28.07.09 14:32, Ben Boeckel (maths...@gmail.com) wrote: Lennart Poettering wrote: Please note that it is our intention not to wrap obsolete mixer controls such as CD, PC Speaker, MIDI and so on. If you file a bug asking for those to be wrapped we will disappoint you and close the bug WONTFIX. Curious: would patches be accepted if someone else did it or is there just no support at all? Let me stress that we explicitly decided not to expose those controls. This has nothing to do with whether there are patches for that or not. So yeah, if you file a bug with a patch this will most likely be treated the same as a bug without a patch and closed WONTFIX. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: Please note that it is our intention not to wrap obsolete mixer controls such as CD, PC Speaker, MIDI and so on. If you file a bug asking for those to be wrapped we will disappoint you and close the bug WONTFIX. When you mean 'not wrap them', do you mean they're no longer selectable as a record source, if the hardware exports them? Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. If you want to control them you can always install alsamixer or gst-mixer or whatever. But really, this controls are obsolete. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ck-list-sessions shows active = false
On Mon, 06.07.09 09:54, darrell pfeifer (darrel...@gmail.com) wrote: Using rawhide and gdm-2.26.1-13.fc12.i586 when I do a ck-list-sessions I see Session4: unix-user = '500' realname = 'darrell pfeifer' seat = 'Seat5' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-07-06T15:56:08.908744Z' login-session-id = '' Currently almost all my device-related functionality is not working (including pulseaudio, mounting usb sticks, starting virtual machines). In addition, polkit-gnome-authorization and polkit-gnome-authorization are crashing. Am I on the right track thinking that the problem is gdm related? We are currently in the process of moving the device ACL management from HAL to udev. This is not finished yet, at least for the PA case I know that that there is some work left to do to fix udev/ck to make things completely race-free. A temporary work-around for the PA case is to make yourself a member of the audio group which then gives you device access regardless if ACLs are set up and work correctly. This will break audio if you have multiple simultaneous session of different users. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rawhide pulseaudio manager problem
LOn Sat, 27.06.09 13:59, Paul (p...@all-the-johnsons.co.uk) wrote: Hi, Despite the packagekit updates, I've still not got any sound on my rawhide box. Please file bug reports if you run into bugs. fedora-devel is not the appropriate place to discuss bugs, especially not those in Rawhide. When I've run from the command line pulseaudio --start or pulseaudio -D it returns E: main.c: Daemon startup failed When you file that bug report, please include a dump of pulseaudio -v When I run PulseAudio Manager, I'm seeing something which may explain things a bit (though it could just be the manager app being odd!) paman is obsolete. Don't use it. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, 17.06.09 13:51, Kjartan Maraas (kmar...@broadpark.no) wrote: ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera: On Mon, 2009-06-15 at 13:09 +0100, Paul wrote: Hi, Prior to the big push to f12, my system had full audio. No problems. Lovely, lovely sounds. For some reason, alsa and pulseaudio are completely failing to pick up my sound card (either the onboard one or my soundblaster). This is despite them both being listed on lspci and lsmod. Any ideas on getting this to work again? As per usual, pulseaudio debug output is a requirement. I found that pulseaudio -k pulseaudio fixed it for me after chown on /dev/snd/* which had root.audio ownership. I see this error when starting pulseaudio though: Hmm, if the permissions aren't set up correctly then this is some HAL ACL handling brokeness. Wouldn't be the first one. [kmar...@nc6400 ~]$ pulseaudio E: bluetooth-util.c: Error from ListAdapters reply:org.freedesktop.DBus.Error.ServiceUnknown That's a missing bluetoothd. This shouldn't be fatal though, or is it? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Mon, 15.06.09 12:41, Thomas Woerner (twoer...@redhat.com) wrote: So, what should happen here? Should we leave the firewall enabled in these cases* by default and require admins to open them? If so, is there any way that we can make this easier in some Packagekit-oriented manner? If not, how should we define that packages indicate that they need ports opened? Should this be handled at install time or run time? Gah. Allowing packages to pierce the firewall just makes the firewall redundant. I still think that the current firewall situation on Fedora is pretty much broken. It's a bit like SELinux: it's one of the first features most people disable. SELinux and the firewall configuration are trying to make the system secure before something happens. If your system is compromised, then it is far too late to react. If you do not care about security, then disable it and have fun with the results. You know, there is one big difference between SELinux and the default Firewall. The former doesn't inhibit the use of an application (at least if the policy is written correctly) because it whitelists every operation an application should be able to use but nothing else. OTOH the default firewall actively breaks a lot of applications we ship by default. It most of the time it even does that silently, without reporting EPERM or suchlike back to the application. Really, if SELinux is set up properly nobody should notice it. However the default firewall breaks a lot of services, and is hence very much noticeable. I wonder why other systems are getting more restrictive and secure over time and for Linux people request the opposite direction. Oh my. I wonder why other systems work by default and Fedora doesn't. Fedora is the only big distro that enables a firewall by default and thus creates a lot of trouble for many users. I think I mentioned that before, and I can only repeat it here: we should not ship a firewall enabled by default, like we currently do. If an application cannot be trusted then it should not be allowed to listen on a port by default in the first place. A firewall is an extra layer of security that simply hides the actual problem. How do you want to get to it should not be allowed to listen on a port by default? Maybe with SELinux? Yes, SELinux is fine for that. Or simply by not shipping the app at all if it's shit. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: iptables/firewall brainstorming
On Sun, 14.06.09 15:09, Chuck Anderson (c...@wpi.edu) wrote: I think this is actually a problem that needs solving. We have several network services that are either installed by default or might be expected to be part of a standard setup, but which don't work because of the default firewall rules. The Anaconda people have (sensibly, IMHO) refused to simply add further exceptions to the firewall policy. So, what should happen here? Should we leave the firewall enabled in these cases* by default and require admins to open them? If so, is there any way that we can make this easier in some Packagekit-oriented manner? If not, how should we define that packages indicate that they need ports opened? Should this be handled at install time or run time? * The case that I keep hitting is mDNS resolution, which requires opening a hole in the firewall For the case of mDNS resolution, we should create a nf_conntrack module to track outbound requests and allow the related replies back in. This case is identical to the Samba browsing case where we created nf_conntrack_netbios_ns [1]. We need a nf_conntrack_mdns too. No. Absolutely not. Firstly, mDNS is not a client/server protocol where you just send out a query and then wait for one response. Instead mDNS is about minimizing traffic by having an elaborate caching logic. And that logic is based on learning from other machine's queries, from gratuitious announcement and goodbye packets. mDNS is genuinly peer-to-peer and it needs the whole traffic that goes on the mdns multicast group on the local LAN segment. Secondly, connection tracking is not a magic wand. It creates almost as many problems as it solves. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Mon, 15.06.09 09:15, James Morris (jmor...@namei.org) wrote: On Sun, 14 Jun 2009, Lennart Poettering wrote: much broken. It's a bit like SELinux: it's one of the first features most people disable. False. Most people leave SELinux enabled, according to the smolt stats which have been collecting since the F8 era. Are you speaking of the same smolt that lists es1371 as most popular sound card? i.e. a sound card that has been out of production since about 10 years now? Somehow I have serious doubts about the validity of the smolt data. Also, isn't the smolt data generated as part of the installation process, i.e. at a time where people haven't yet had the time to disable SELinux? Anyway, please don't think I was anti-SELinux, I am not. Just wanted to state what I observed. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Sun, 14.06.09 16:11, Jeff Spaleta (jspal...@gmail.com) wrote: On Sun, Jun 14, 2009 at 3:36 PM, Lennart Poetteringmzerq...@0pointer.de wrote: Are you speaking of the same smolt that lists es1371 as most popular sound card? i.e. a sound card that has been out of production since about 10 years now? Somehow I have serious doubts about the validity of the smolt data. You might have found a bug in the tallying there in how cards are self-identifying product strings. ci devices identify them via numeric ids only, the strings come from the hwdata databases. You'll notice the same exact entry is listed twice in the Audio device table. Are cards using the ENS1371 driver misreporting their vendor/card version info? There are only 5 listings in the table for the ENS1371 driver. There are dozens listed for the Intel ICH driver. I bet if you totalled up counts by driver, things would look more sensible to you with intel being a reasonably large percentage of the drivers in use. It's not just that ens1371 is shown as unrealistically popular, it's also that it doesn't know a single HDA device. I mean, seriously... what will smolt claim next? that santa claus exists? To me it appears that the data shown on this smolt web thingy originates from /dev/random. Unrelated to this, it's fun to see what happens when one accesses http://smolt.fedoraproject.org/static/stats or a similar URL... ;-) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: bluetoothd on-demand startup
On Fri, 12.06.09 19:26, Bastien Nocera (bnoc...@redhat.com) wrote: Every time there's an add action for a Bluetooth device, udev will run bluetoothd --udev. bluetoothd will fail with an error if D-Bus isn't started (on bootup), and the udev coldplug (done in udev-post) will run the rule again. bluetoothd will silently fail when it's already running. bluetoothd will exit itself after 30 seconds when no adapters are present. There's a potential race if the udev add event happens in between the time the time the running bluetoothd reliquinshes its D-Bus service, and the new one starts up. This could be fixed by first releasing the service name synchronously, then processing all queued requests and only then closing/exiting. Hmm, will bluetoothd also be started via bus activation? If so, it wuld probably make sense to issue a StartByName D-Bus request from the udev rule and let dbus handle all the ordering/synchronization issues with starting up bluetoothd. I know at least one application (PA) that wouldn't reconnect to coming and going bluetoothd's, that's why I am asking. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: bluetoothd on-demand startup
On Fri, 12.06.09 20:10, Bastien Nocera (bnoc...@redhat.com) wrote: This could be fixed by first releasing the service name synchronously, then processing all queued requests and only then closing/exiting. Hmm, will bluetoothd also be started via bus activation? If so, it wuld probably make sense to issue a StartByName D-Bus request from the udev rule and let dbus handle all the ordering/synchronization issues with starting up bluetoothd. No, there's no service activation support. Would it be useful? I think it would. Seems to me as if some of the BT functionality (org.bluez.Manager, ...) might be useful even without having hw plugged in. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Fri, 05.06.09 00:21, Jon Masters (jonat...@jonmasters.org) wrote: Folks, Anyone want to clarify my understanding of PA's use of mlock/posix_madvise? From looking over the code - in particular pa_will_need, and its callsites - it looks like PA doesn't really use this support that it has for locking pages. Which seems weird. mlock() is not actually used anymore by PA on modern kernels. The longer story goes like this: Text book RT applications use mlock()/mlockall() to lock themselves into memory and make sure they never are swapped out. This is something we cannot really do for PA given that map a *lot* of stuff into our address space: libraries, SHM segments for communications with other clients, cached samples, and so on. If we'd lock all that into memory there wouldn't be any memory left for much else, i.e. all other programs would have to share what is remaining and would have to swap all the time. Given that PA is just an auxiliary tool and not the main reason people run computers this is hence not an option. Due to that PA doesn't use mlock()/mlockall() like textbooks suggest, and it never did. Now, just ignoring the whole locking issue is also not an option. So I tried to find a compromise: try my best to make sure that the data accessed by the RT threads is available in memory but ignore the rest of the memory. To achieve that I needed a way to safely swap in memory when *I* need it to instead of letting the kernel to do as it as late as possible. Then, whenever the non-RT threads in PA pass off data to the RT threads I first swap the data in explicitly. That way I hope that the RT threads never need to wait for swapping in and can continue to loop in their little loops and continue to do whatever else they might want to do, but not wait for disks spinning. There is a system call for requesting swapping in of memory: posix_madvise(POSIX_MADV_WILLNEED). A few kernel releases ago this didn't work for anonymous memory, only for file-backed memory. (But on my request this was then changed in the kernel). Now, to support older kernels I added a dirty dirty hack: I try to lock those pages into memory and then unlock them right away, which should have about the same effect as the madvise() call. On current kernels that mlock() is never tried however, because WILLNEEED works fine anyway. And it's a horrible hack. And I probably should remove this from PA now. I'll admit I'm about ready to hack in some horrible mlockall hacks to see if that'll stop the poppy/skippyness on this box. I doubt that locking PA into memory will fix your issues. If PA drops out often this might have various reasons, but probably not swapping. Often the timing calls of your sound driver are inaccurate and cause PA to miss its deadlines. To work around that you could try disabling timer-based scheduling mode and revert to sound card IRQ scheduled playback. For that try passing tsched=0 to module-hal-detect in /etc/pulse/default.pa. Then restart PA. Another issue might be that PA does not actually get scheduled often enough by the kernel. Might be caused by a bad driver (nvidia closed source). You can run PA as RT if you wish (which we hopfully will be able to enable by default in F12). For that increase RLIMIT_RTPRIO to 10 or so in /etc/security/limits.conf and login again. Usually running pulseaudio -v in a terminal might give you a hint what might be going wrong. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
