Re: [pulseaudio-discuss] Example using async API
'Twas brillig, and Nix at 14/10/09 00:24 did gyre and gimble: That requires me to be permanently present on IRC. I'm stuck commuting and have to sleep so this is impractical. I'm on IRC 24/7 and yet I do both of those things too. It's not impractical, but I don't think it should be seen as a primary source of info either. This list is that. IRC is just convenient. The current system works quite well I'd say -- for the distros. You for the distros *you choose to communicate with*, and we don't even know who they are: it may even be a matter of whim. Everyone else is screwed. Well FWIW, the current system works fine for me too. Sure Lennart may ping me on IRC but all the info is on the list too. think there's more than distros that matters. I don't. So why should I do the additional work and you don't? One Cc:? 'Additional work'? I'm sorry, I assumed that running a very-low-volume one-posting-subscriber mailing list was essentially no work if you were already running several higher-volume ones. I didn't realise it was immensely difficult. Pulseaudio is not a simple app and when people see an announce list they may be tempted to think: ahh new version, upgrade time \o/. It's deeply integrated into stack, and synced with various other components including the kernel and udev. An announce list would just encourage people to bash on and try and upgrade without understanding things fully. This list is not particularly high traffic and I think a separate list would only encourage these drive by experiences which we should be discouraging (as someone who often advices people on IRC and this list, I'd say it's one of the most frustrating things I have to deal with). Also, Colin maintains a -stable branch, which also includes the security fixes -- not sure what more you need? Aha. I didn't notice that these were still active: indeed the recent security fix doesn't seem to have gone into the older one. I guess this means that what I'm hoping for *is* there... except that it's not publicised anywhere. It's been announced on this list and the git tree speaks for itself. All the distros know it's there. Aha. From your phrasing I thouht it was being sent *only* to distributors, not to distributors and this list. (I can't recall any security-related announcements ever being made to this list. Certainly the patching of the recent actively-exploited PA hole wasn't announced here.) What recent actively-exploited PA hole that wasn't announced do you refer to? The only one I know off was announced on this list, so this is slightly concerning to me and I'd agree that this is an issue if there is something not actively discussed/announced here. Doesn't mean there should be a separate list tho', and if this list hasn't had mention of this issue, then it's highly likely that this other new list would have either! This is the biggest problem in the free software world, really: responding to criticisms of major flaws with utterly trivial fixes with 'oh, you do that then'. Adding one email address to a Cc: to help all users of your software avoid security problems is not rocket science and takes zero effort as far as I can see, but you responded like I was suggesting you paint the ceiling of the Sistine Chapel, with proposed fixes which involved *insane* amounts of effort (24x7 presence on an IRC channel come-what-may and scanning all the traffic on that channel to spot a non-automatically-detectable notice which might come up once in six months, if that? Come on!) You're comments above assumes that such a list should be encouraged in the first place OK a security-only list would not encourage bad behaviour like an announce list would, but to be honest, the one or two posts on it in the last four years probably wouldn't encourage people to sign up to such a list anyway. I'm on enough lists. I'd rather just use this one personally. If you really think that upstream PA is only usable by distributors, that's fine: everyone else should for security's sake drop it and encourage every program that currently uses it to drop support for it as well (otherwise they are opening all their users who do not use your preferred distros to potential security threats). A shame. It's fine software, better than any other desktop sound system I've ever used, but it seems it's not safe to use unless I'm in the right club or have infinite amounts of free time to use to follow everything you do in micrometric detail. You're totally overreacting. Are you really going to stop using a piece of software because one or two emails were not sent to a specific list designed specifically to receive this handful of email? This list serves me and others perfectly well, so your opinions are not shared by everyone. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor
Re: [pulseaudio-discuss] Example using async API
On Wed, 2009-10-14 at 00:24 +0100, Nix wrote: A shame. It's fine software, better than any other desktop sound system I've ever used, but it seems it's not safe to use unless I'm in the right club or have infinite amounts of free time to use to follow everything you do in micrometric detail. If you want to continue this one man war against pulseaudio, kindly start a new thread. It has nothing to do with my questions about the async API any more PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Fri, 09.10.09 23:14, Nix (n...@esperi.org.uk) wrote: On 7 Oct 2009, Lennart Poettering said: Security updates is the job of distributions. If we encounter a security issue I contact the packagers I know and tell them which patch to backport. The problem here is that you cannot know everyone on earth who pulls down PA and builds it, nor can you know why people might need to do so (so 'use your distributor's copy' won't always fly: some distributions have terribly old PAs, and the user may need features from a newer one). Any system requiring you to notify individuals simply doesn't scale (although it probably *is* a good idea to notify major distros explicitly in any case). I am sorry. I believe in distros. If some people don't then it's their own fault, but I will not and cannot care about that. This is free software, it's fine if you want to shoot yourself in the foot. But don't expect to be particularly welcome if you do that. So... it might be a good idea simply to have a pulseaudio-security mailing list or even blog or something to which you post the git commit IDs of known security fixes (or whatever it is you tell the distributors: I presume it's something like that). ## Sure. I can do a lot of things. But how about *you* do these things? I announce those things on IRC, so you are welcome to hang around there and forward it to some blog. The current system works quite well I'd say -- for the distros. You think there's more than distros that matters. I don't. So why should I do the additional work and you don't? Also, Colin maintains a -stable branch, which also includes the security fixes -- not sure what more you need? One extra Cc: on emails you already send and everyone is happy. Uh? It's all on the ML or on IRC. There's nothing private here. (the kernel already does something like this with the -stable tree. udev doesn't do anything like this and I bloody wish it did: it tends to intermingle major rules-breaking config changes and critical security fixes in releases, and keeps security fixes quiet. That's *exactly* the wrong thing to do... but you know that.) Dude, nothing hinders you to maintain your own udev-stable tree. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Wed, 07.10.09 19:01, Jeremy Visser (jer...@visser.name) wrote: On Tue, 2009-10-06 at 00:37 +0200, Lennart Poettering wrote: If you are a user then you should use tha PA version that is shipped with your distro. If you want a newer version, then upgrade your distro. If you are a developer who writes third party apps then you should stick to a released distro, too. But of course you should really make sure to run the latest one. You know as well as I do that not everybody can run the latest bleeding-edge distro. The reasons are the same as why you would not recommend end-users make everyday use of the git version of Pulse. A released distro such as F11 is not bleeding-edge. A development distro such as Rawhide is. F11 is tested and released, and not at all comparable to a git version of an upstream project. For a developer there is really no excuse in running anything but the latest released distro or current development distro, sorry. My main concern is that of security, which is the main scenario where you would want to update to a recent version of Pulse in a stable environment. PulseAudio has not been free of security issues, and yet I don't know of any security-only releases. (Please correct me if I am wrong.) Security updates is the job of distributions. If we encounter a security issue I contact the packagers I know and tell them which patch to backport. It's the job of the distro packagers to then apply that to their packages and pass it on to the users. A user should not have to deal with upstream PA, ever. If he had to deal with every single upstream project to have a secure system he'd go crazy. If a security issue is discovered in Pulse, affecting several of the latest versions, and a new version is released to correct the security hole (as of the time of writing, that would be 0.9.19.1 or 0.9.20), then what should those running stable distros do? I am sorry, but you are seriously misunderstanding the roles of distributions. It's the distributor's job to provide you with fixed packages, not upstream! It is upstream's job to come up with a fix or bless it, but not to update the packages for you. Obviously we can't update system libraries such as udev, BlueZ, etc. when we just want the security fix. At the same time, Pulse's current attitude towards dependencies means running the latest Pulse on the system without upgrading much of the core will be problematic. Of course you can update udev, BlueZ, etc.! And that happened a couple of times in the past. Just check out the security mailing lists the distros maintain. For example, this is the one of Fedora: https://www.redhat.com/archives/fedora-package-announce/ Look for all those mails marked as [SECURITY]. They inform you about security updates of distro packages. PA falls under exactly the same category as udev, BlueZ. While it is run under a normal user id it still is kind of a system-level daemon that integrates closely with kernel, udev, bluez. If you do a feature upgrade of PA you hence need to do a full udev/kernel/bluez update too. If you do a security upgrade of PA you don't need to upgrade anything else, since security updates are minimal in nature. On Mon, 2009-10-05 at 23:04 +0200, Lennart Poettering wrote: PA is pretty tightly integrated into the system. Consider it part of the the OS itself. So it is only feasible to update the entire OS or nothing at all. ...does not address the security implications of not updating, in which not updating would lead to compromised systems (e.g. if an Adobe Flash animation could exploit PulseAudio by playing the audio of a Vista install disc backwards). A security upgrade is a completely different beast than a feature upgrade. Is there a best practice or other tip you can give us to prepare for these situations in which we really do need to upgrade? Yes, listen to your distributor. He will provide you with packages if you are a user. Upstream packages are only interesting for developers and packagers. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Fri, 02.10.09 18:30, Peter Onion (peter.on...@btinternet.com) wrote: It seems a bit fussy about how much data you write with each pa_stream_write, but it might be my code that is generating the samples that is wrong! It's up to you how much your write. However, it is definitely a good idea to write at least what has been requested (or is reqturned by pa_stream_get_writable_size()). If you write less you won't get another request callback for that, so you might experience drop outs. You may also write more, which often makes a lot of sense, i.e. if your app works with a different block size. If you write more than requested it will be buffered on the server side. Summary: writing less: seldomly makes sense writing exactly what requested: makes sense if your app's block size is 1 sample writing more: makes sense if your app's block size is 1 sample. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Fri, 02.10.09 21:24, Peter Onion (peter.on...@btinternet.com) wrote: On Fri, 2009-10-02 at 18:30 +0100, Peter Onion wrote: Next thing is to try and control the sound with some glade widgets to see it the latency is going to be a problem doing things this way. Things are looking good :-) Latency is OK and only a very occasional dropout. It was ok when pulseaudio was using ~8% of one core but it seems to have jumped up to 20%, dropouts are happening every couple of seconds and these messages are appearing in /var/log/messages Oct 2 21:20:47 NewHP pulseaudio[4492]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. What do you need to know ? How did you configure the buffer_attr struct? did you set it at all? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Sun, 04.10.09 09:34, Peter Onion (peter.on...@btinternet.com) wrote: On Fri, 2009-10-02 at 23:40 +0100, Colin Guthrie wrote: 'Twas brillig, and Peter Onion at 02/10/09 21:24 did gyre and gimble: It was ok when pulseaudio was using ~8% of one core but it seems to have jumped up to 20%, dropouts are happening every couple of seconds and these messages are appearing in /var/log/messages Oct 2 21:20:47 NewHP pulseaudio[4492]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. IIRC that message was changed in 0.9.15... So I suspect you're using a pretty old PA. It's a 0.9.14 on a Fedora 10 machine. Are there any newer rpm's about for F10 X86_64 ? I think the current pulse releases need a newer libtool than is current with F10 ? This might just be a good enough reason for me to jump up to F11. Uh. F10. That's quite old. PA is very much in flux, I'd not suggest users using old versions like that. If you ask me, especially developers should live on the bleeding edge, so if you don't want to go all the way to rawhide (what I'd recommend), then at least make sure to run the latest released version. I know that some peope think it is a good idea to run distros in releases that are a year old or two, under the assumption they'd be better tested and more stable. That assumption is wrong. They are bitrotten and developers tend to fix bugs much more frequently in newer software. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Sun, 04.10.09 15:44, Peter Onion (peter.on...@btinternet.com) wrote: So, what are the steps to upgrade my pulseaudio to the latest version ? I assume I can't just remove the pulseaudio rpm as that will break dependencies ? PA is pretty tightly integrated into the system. Consider it part of the the OS itself. So it is only feasible to update the entire OS or nothing at all. Upgrading PA alone would also require you to update the kernel, udev and other things. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Mon, 2009-10-05 at 23:04 +0200, Lennart Poettering wrote: On Sun, 04.10.09 15:44, Peter Onion (peter.on...@btinternet.com) wrote: So, what are the steps to upgrade my pulseaudio to the latest version ? I assume I can't just remove the pulseaudio rpm as that will break dependencies ? PA is pretty tightly integrated into the system. Consider it part of the the OS itself. So it is only feasible to update the entire OS or nothing at all. Upgrading PA alone would also require you to update the kernel, udev and other things. Lennart I didn't read this until I had sent my previous reply. Are you saying it's actually impossible to upgrade pulseaudio to anything newer than the current version in Fedora 11 ? This seems to make it hard for people trying to write real applications to get any support as they can't use the latest released versions. PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Mon, 05.10.09 22:38, Peter Onion (peter.on...@btinternet.com) wrote: Upgrading PA alone would also require you to update the kernel, udev and other things. Lennart I didn't read this until I had sent my previous reply. Are you saying it's actually impossible to upgrade pulseaudio to anything newer than the current version in Fedora 11 ? Not sure if impossible is the right word. But it's certainly not easy. And not recommended either. It's a job for a distributor, not a user. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On 10/06/2009 08:30 AM, Peter Onion wrote: On Mon, 2009-10-05 at 23:01 +0200, Lennart Poettering wrote: Uh. F10. That's quite old. PA is very much in flux, I'd not suggest users using old versions like that. If you ask me, especially developers should live on the bleeding edge, But that doesn't make sense if you are developing real applications. Real users are seldom on the edge and if your code has to work for them being a bit behind the curve makes more sense I think. Anyway I'm now on F11 . so if you don't want to go all the way to rawhide (what I'd recommend), then at least make sure to run the latest released version. I'm just building 0.9.19, but it's failed on the version of sndfile. Requested 'sndfile= 1.0.20' but version of sndfile is 1.0.17 If I'm going to have to upgrade lots of other packages I'm afraid it's a show stopper for my attempt to integrate with pulseaudio properly. I've got people lined up to test my applications and I can't expect them to manually upgrade their machines if the current versions of packages in their chosen distribution are too old. Fair point. For that issues above I just compiled libsndfile from source. I think it was the only dep that had changed from the standard Fedora packages. Cheers. Patrick Shirkey Boost Hardware Ltd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On 10/06/2009 08:48 AM, Lennart Poettering wrote: On Mon, 05.10.09 22:38, Peter Onion (peter.on...@btinternet.com) wrote: Upgrading PA alone would also require you to update the kernel, udev and other things. Lennart I didn't read this until I had sent my previous reply. Are you saying it's actually impossible to upgrade pulseaudio to anything newer than the current version in Fedora 11 ? Not sure if impossible is the right word. But it's certainly not easy. And not recommended either. It's a job for a distributor, not a user. I can't tell if you are referring to only users here or if you are saying it is not easy for anyone including developers? Either way the situation could be improved for genuinely interested developers by providing the complete build instructions which are currently missing from the docs online and in the package. On my F11 I have libsndfile-1.20 installed manually with ./configure --libdir=/usr/lib64; make; make install I then compile PA with ./configure --libdir=/usr/lib64; make; make install I would certainly appreciate someone providing explicit steps for building the 32 bit chroot on f11. It doesn't sound particularly hard but I haven't got round to figuring out the exact steps myself yet. Everything else on F11 meets the dep requirements for building the source. Cheer.s Patrick Shirkey Boost Hardware Ltd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Tue, 06.10.09 06:49, Ng Oon-Ee (ngoo...@gmail.com) wrote: On Tue, 2009-10-06 at 00:37 +0200, Lennart Poettering wrote: If you are a user then you should use tha PA version that is shipped with your distro. If you want a newer version, then upgrade your distro. If you are a developer who writes third party apps then you should stick to a released distro, too. But of course you should really make sure to run the latest one. Sorry to interrupt, but it seems to me developers have the (unfortunate?) necessity of their software working with the latest 'stable' version of a distro, which would necessitate (especially in extreme cases like debian) that they use a kernel, udev, and thus pulse many versions behind? What do you expect? You cannot have it both ways: have the newest code and have it totally stable. That is impossible. And that Debian is an extreme case is certainly true. But take that criticism to the Debian developers. It is not particularly surprising that most developers work on other distros that have a much faster development cycle than Debian, or if the do choose Debian then they stick to the 'testing' or even 'unstable' distribution. Using Debian 'stable' for developing appears very unwordly to me. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On 10/06/2009 09:49 AM, Ng Oon-Ee wrote: On Tue, 2009-10-06 at 00:37 +0200, Lennart Poettering wrote: If you are a user then you should use tha PA version that is shipped with your distro. If you want a newer version, then upgrade your distro. If you are a developer who writes third party apps then you should stick to a released distro, too. But of course you should really make sure to run the latest one. Sorry to interrupt, but it seems to me developers have the (unfortunate?) necessity of their software working with the latest 'stable' version of a distro, which would necessitate (especially in extreme cases like debian) that they use a kernel, udev, and thus pulse many versions behind? There is also the murky middle area. Testers, advanced users and developers who would like to have an fully integrated system and are prepared to wrangle with yum and overwrite /usr/lib64 as it often is easier to work with than building into /usr/local which creates a whole new set of problems to overcome. Uninstalling PA from the packaging system completely can lead to a heap of manual installation and env var tweaking of the required deps when installing into /usr/local. So while you are correct that best practice is to install in /usr/local it is also necessary in some cases to be able to build and install over existing packages to get the fastest return on time invested in corralling the system to a workable state. it also solves the hassle of occasionally getting double ups when continuing to use the packaging system that bring in dep updates you have forgotten about when doing manual installs. Therefore preventing the ensuing headaches. Alternatively there could be a more explicit set of steps provided for running PA from the build dir recommended specifically for devs/interested parties to work with... Patrick Shirkey Boost Hardware Ltd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Tue, 06.10.09 09:59, Patrick Shirkey (pshir...@boosthardware.com) wrote: Alternatively there could be a more explicit set of steps provided for running PA from the build dir recommended specifically for devs/interested parties to work with... As mentioned: $ ./bootstrap.sh $ make -j4 $ cd src $ ./pulseaudio And of course one should be able to read the output of configure and be able to install the missing deps. All the lines above should be pretty standard and are basically the same for every Linux package. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Fri, 2009-10-02 at 23:40 +0100, Colin Guthrie wrote: 'Twas brillig, and Peter Onion at 02/10/09 21:24 did gyre and gimble: It was ok when pulseaudio was using ~8% of one core but it seems to have jumped up to 20%, dropouts are happening every couple of seconds and these messages are appearing in /var/log/messages Oct 2 21:20:47 NewHP pulseaudio[4492]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. IIRC that message was changed in 0.9.15... So I suspect you're using a pretty old PA. It's a 0.9.14 on a Fedora 10 machine. Are there any newer rpm's about for F10 X86_64 ? I think the current pulse releases need a newer libtool than is current with F10 ? This might just be a good enough reason for me to jump up to F11. PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On 10/04/2009 07:34 PM, Peter Onion wrote: On Fri, 2009-10-02 at 23:40 +0100, Colin Guthrie wrote: 'Twas brillig, and Peter Onion at 02/10/09 21:24 did gyre and gimble: It was ok when pulseaudio was using ~8% of one core but it seems to have jumped up to 20%, dropouts are happening every couple of seconds and these messages are appearing in /var/log/messages Oct 2 21:20:47 NewHP pulseaudio[4492]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. IIRC that message was changed in 0.9.15... So I suspect you're using a pretty old PA. It's a 0.9.14 on a Fedora 10 machine. Are there any newer rpm's about for F10 X86_64 ? I think the current pulse releases need a newer libtool than is current with F10 ? This might just be a good enough reason for me to jump up to F11. Do the upgrade to F11 and then you can also compile the latest git as F11 is only upto 0.9.15 and now PA is upto 0.9.18. Cheers. Patrick Shirkey Boost Hardware Ltd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On 10/05/2009 01:02 AM, Peter Onion wrote: On Sun, 2009-10-04 at 21:50 +1100, Patrick Shirkey wrote: Do the upgrade to F11 and then you can also compile the latest git as F11 is only upto 0.9.15 and now PA is upto 0.9.18. OK, this now coming from an upgraded to F11 box... However no sound working as yet so it's been one step forward, two steps back... Did you check all the output levels are unmuted for your card? Try running alsamixer from the commandline. Cheers. Patrick Shirkey Boost Hardware Ltd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Mon, 2009-10-05 at 01:17 +1100, Patrick Shirkey wrote: Did you check all the output levels are unmuted for your card? Try running alsamixer from the commandline. FIxed. Output was being sent to the sound device on my Radeon graphics card (which I assume comes out the HDMI connector ?) Anyway all going now. So, what are the steps to upgrade my pulseaudio to the latest version ? I assume I can't just remove the pulseaudio rpm as that will break dependencies ? PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Wed, 30.09.09 21:18, Peter Onion (peter.on...@btinternet.com) wrote: I've been looking at the tests in the source distribution to get some more ideas on how things fit together. BUT, I still can't figure out how to use the threaded mainloop. There are some examples of using bits of it, but at the moment I can't see how to put them together in a coherent way. A very brief intro how to use the threaded mainloop you may find in the doxygen docs. In case you haven't had a look yet: http://0pointer.de/lennart/projects/pulseaudio/doxygen/threaded_mainloop.html Take it with a grain of salt. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Thu, 01.10.09 23:29, Peter Onion (peter.on...@btinternet.com) wrote: On Wed, 2009-09-30 at 21:18 +0100, Peter Onion wrote: I've been looking at the tests in the source distribution to get some more ideas on how things fit together. BUT, I still can't figure out how to use the threaded mainloop. There are some examples of using bits of it, but at the moment I can't see how to put them together in a coherent way. After some more study of the gstreamer pulse plugin sources things have started to fall into place. A question for Lennart... In the gstreamer plugin the write callback just calls pa_threaded_mainloop_signal() and the data is written from the other thread. Is it OK to actually call pa_stream_write() in the callback if the sample data is to hand ? Yes, absolutely. In fact this is actually the intended way. Doing things indirectly by synching with things like p_t_m_signal() should only be done if it really doesn't make sense to do it otherwise. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Fri, 2009-10-02 at 10:18 +0200, Lennart Poettering wrote: A very brief intro how to use the threaded mainloop you may find in the doxygen docs. In case you haven't had a look yet: http://0pointer.de/lennart/projects/pulseaudio/doxygen/threaded_mainloop.html That was one of the first things I read, but I found that unless you know how it works it leaves you with more questions than answers ! Take it with a grain of salt. I did ! The gst source code was much more useful as it is complete. I've actually worked enough out to get a very simple make a tone for a while programme working with a threaded main loop. It seems a bit fussy about how much data you write with each pa_stream_write, but it might be my code that is generating the samples that is wrong! Next thing is to try and control the sound with some glade widgets to see it the latency is going to be a problem doing things this way. I did read a bit about making a plugin for the pulse demon so if latency is a problem that might be another solution. PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Fri, 2009-10-02 at 18:30 +0100, Peter Onion wrote: Next thing is to try and control the sound with some glade widgets to see it the latency is going to be a problem doing things this way. Things are looking good :-) Latency is OK and only a very occasional dropout. It was ok when pulseaudio was using ~8% of one core but it seems to have jumped up to 20%, dropouts are happening every couple of seconds and these messages are appearing in /var/log/messages Oct 2 21:20:47 NewHP pulseaudio[4492]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. What do you need to know ? PeterO I did read a bit about making a plugin for the pulse demon so if latency is a problem that might be another solution. PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
'Twas brillig, and Peter Onion at 02/10/09 21:24 did gyre and gimble: It was ok when pulseaudio was using ~8% of one core but it seems to have jumped up to 20%, dropouts are happening every couple of seconds and these messages are appearing in /var/log/messages Oct 2 21:20:47 NewHP pulseaudio[4492]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. IIRC that message was changed in 0.9.15... So I suspect you're using a pretty old PA. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
I've been looking at the tests in the source distribution to get some more ideas on how things fit together. BUT, I still can't figure out how to use the threaded mainloop. There are some examples of using bits of it, but at the moment I can't see how to put them together in a coherent way. PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Tue, 29.09.09 20:45, Peter Onion (peter.on...@btinternet.com) wrote: Has anyone got some example code which uses the GLIB Main Loop Bindings ? I was trying to get some of my old computer emulation applications (*) working with PA about a year ago, but at the time I just side stepped pulse as I had a multi channel sound card so software mixing wasn't essential. However I now have a nice new laptop running Fedora 11 and I've got to sort out using pulse correctly. So I'm looking for an example of using pa with a gtk+ (libglade) application. pavumeter uses it. It's not exactly a nice example, but it is one. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Tue, 2009-09-29 at 22:07 +0200, Lennart Poettering wrote: On Tue, 29.09.09 20:45, Peter Onion (peter.on...@btinternet.com) wrote: Has anyone got some example code which uses the GLIB Main Loop Bindings ? So I'm looking for an example of using pa with a gtk+ (libglade) application. pavumeter uses it. It's not exactly a nice example, but it is one. Thanks. I was actually after some C code for a an output application, but that does show how to set up the event loop callbacks etc. so it's a good place to start for me. I'm sure I did have something that nearly worked about a year ago, but I think it's on an old hard disk which isn't installed in a machine anymore PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Example using async API
On Tue, 2009-09-29 at 22:44 +0200, Lennart Poettering wrote: If you write output applications it is not recommended to use the glib glue coe because you don't want to run the audio IO stuff in the same event loop as the slow X stuff. The glib glue code is only useful for control applications and for applications where dropouts don't matter (such as pavumeter). If you want to use the PA for audio IO in a gtk app it is recommended to use the trheaded mainloop api to spawn a seperate event loop thread. Oh ! :-( I think that's going to mean a major rewrite of my code because it is currently uses the glib event loop and adds an event source that checks the alsa device and then creates the required number of samples. I've not written any threaded code before so that's another learning curve ! So my next question is Can you point me to a gtk app example (preferably in C rather than C++) that woks in this threaded way ? Thanks, PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
