Re: [pulseaudio-discuss] ORC buildsystem problems
Am Dienstag, den 03.05.2011, 08:39 +0530 schrieb Arun Raghavan: On Mon, 2011-05-02 at 11:52 +0200, Maarten Bosmans wrote: Recently, I encountered some problems when enabling orc in some less usual situations. When compiling with --enable-orc from a tarball generated from a --disable-orc configured tree, the following error occurs. make[2]: *** No rule to make target `pulsecore/svolume-orc-gen.c', needed by `all'. Stop I haven't really looked at a solution. Perhaps the nodist_ prefix for some files inside if HAVE_ORC in src/Makefile.am should be dropped? May be Colin needs to do his make distchecks with this situation, in order to catch it earlier. There should not be a dist'ed tarball without those generated files. Whether they are used or not is a configure-time option, then. Secondly, there is a problem when cross-compiling. The pkg-config check for ORC is used to find the usual include files and linking flags, but also to find the location of orcc. This is a problem, because when configure is run with the correct configuration, such that pkg-config finds the host package, it also finds the host orcc (in the case of my mingw32 test, it finds orcc.exe), which is of course useless in the build environment. Why is it useless in your environment? The files generated by orcc are architecture-neutral. For your second issue please take a look at the thread on the gstreamer-devel list [1]. Thanks, Paul [1] http://lists.freedesktop.org/archives/gstreamer-devel/2011-March/030983.html signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] filter-apply: Mark modules as being autoloaded
'Twas brillig, and Arun Raghavan at 02/05/11 05:41 did gyre and gimble: (Based on Colin's review) We mark modules as being autoloaded so that they can handle this as a special case if needed (which is required by module-echo-cancel for now). This inverts how things were done and makes using these modules manually less error-prone. Thanks :) Yeah, although this pushed a convention to filter module, I think this is a better approach than getting people loading things manually to do something special :) In ma tree! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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] review+pull-request: Passthrough support
'Twas brillig, and Arun Raghavan at 02/05/11 07:49 did gyre and gimble: In e193c2bf55326a48e2297bcacadc9d1848a40d7d and 948d0f19bef353208ffb5b1b8c520b6b489b94a6 Can you make sure that pactl and pacmd stay as in-sync as possible? I held off because I thought that pacmd was going to be dropped before too long. Is this not the case? Sink port information seems to have not been added, I'll sync that as well if required. Hmm, not sure. Ideally I'd prefer to just have one tool and only add to pacmd the things that cannot easily be done via the protocol, but I'm not sure of the overall strategy. I'll add this to the discussion points for Saturday's chat. In bb7cc499f1815de1c90b0ef1850152224df96ff9 I don't see why this asserts in the current form nor what has actually changed. It should not assert since we want to gracefully fail (that is the original code should not have been an assert). I still don't see any asserts in the original code. The only difference I can see is that a pa_log_debug() is not printed... (the log message says the word Assertion but it doesn't actually assert AFAICT...) This might be intended (i.e. don't print the log message), but if that's the case the commit message is still wrong to mention asserts... General Question: Has this broken tunnels? (we manage to do this quite often with stream protocol changes... Indeed, it does. I've put fixing this on my TODO list. Will try to get to it soon. Cool, thanks :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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] rewind and underrun issues on start of playback
'Twas brillig, and Baek Chang at 02/05/11 04:52 did gyre and gimble: Also, if i revert to pulseaudio 0.9.14, i do not see this issue happening. I can hear the very short samples in the beginning fine. I think generally that the rewinding should work, and that by reverting you are just bypassing a bug at (perhaps) the alsa level which should really be fixed. I suspect if you can create a (very simple) alsa test application that exhibits the problem (by using rewinds) then this can be taken to the alsa-devel list in order to fix the underlying problem. That's my take on it anyway, and I could of course be wrong! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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] ORC buildsystem problems
2011/5/3 Paul Menzel paulepan...@users.sourceforge.net: Am Dienstag, den 03.05.2011, 08:39 +0530 schrieb Arun Raghavan: On Mon, 2011-05-02 at 11:52 +0200, Maarten Bosmans wrote: Recently, I encountered some problems when enabling orc in some less usual situations. When compiling with --enable-orc from a tarball generated from a --disable-orc configured tree, the following error occurs. make[2]: *** No rule to make target `pulsecore/svolume-orc-gen.c', needed by `all'. Stop I haven't really looked at a solution. Perhaps the nodist_ prefix for some files inside if HAVE_ORC in src/Makefile.am should be dropped? May be Colin needs to do his make distchecks with this situation, in order to catch it earlier. There should not be a dist'ed tarball without those generated files. Whether they are used or not is a configure-time option, then. Right. Any idea on how to fix that then? Secondly, there is a problem when cross-compiling. The pkg-config check for ORC is used to find the usual include files and linking flags, but also to find the location of orcc. This is a problem, because when configure is run with the correct configuration, such that pkg-config finds the host package, it also finds the host orcc (in the case of my mingw32 test, it finds orcc.exe), which is of course useless in the build environment. Why is it useless in your environment? The files generated by orcc are architecture-neutral. The binary that make ends up trying to use (orcc.exe) is useless, because it's a win32 binary on a Linux platform. So the architecture-neutral files can't even be generated. For your second issue please take a look at the thread on the gstreamer-devel list [1]. Ah, yes. It seems that my workaround of setting ORCC= is the advised solution. Still it would be better to autodetect a broken return value of pkg-config. I could make a patch to orc.m4 that does just that, but I can't seem to find the file in the orc git repo. Is orc.m4 managed locally in the pulse tree, or is there some upstream that improvements should also be submitted to? Thanks, Paul [1] http://lists.freedesktop.org/archives/gstreamer-devel/2011-March/030983.html Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ORC buildsystem problems
Am Dienstag, den 03.05.2011, 10:40 +0200 schrieb Maarten Bosmans: 2011/5/3 Paul Menzel paulepan...@users.sourceforge.net: Am Dienstag, den 03.05.2011, 08:39 +0530 schrieb Arun Raghavan: On Mon, 2011-05-02 at 11:52 +0200, Maarten Bosmans wrote: […] Secondly, there is a problem when cross-compiling. The pkg-config check for ORC is used to find the usual include files and linking flags, but also to find the location of orcc. This is a problem, because when configure is run with the correct configuration, such that pkg-config finds the host package, it also finds the host orcc (in the case of my mingw32 test, it finds orcc.exe), which is of course useless in the build environment. Why is it useless in your environment? The files generated by orcc are architecture-neutral. The binary that make ends up trying to use (orcc.exe) is useless, because it's a win32 binary on a Linux platform. So the architecture-neutral files can't even be generated. For your second issue please take a look at the thread on the gstreamer-devel list [1]. Ah, yes. It seems that my workaround of setting ORCC= is the advised solution. Still it would be better to autodetect a broken return value of pkg-config. I could make a patch to orc.m4 that does just that, but I can't seem to find the file in the orc git repo. Is orc.m4 managed locally in the pulse tree, or is there some upstream that improvements should also be submitted to? As far as I know `orc.m4` is managed locally by all projects depending on Orc like PulseAudio, Gstreamer or Schroedinger. I guess you or I (if your are not subscribed) could forward your patch to the gstreamer-devel list. Thanks, Paul [1] http://lists.freedesktop.org/archives/gstreamer-devel/2011-March/030983.html signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rewind and underrun issues on start of playback
I think you are correct in that there is an alsa bug. It seems that pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio 0.9.22 does. It seems like the rewind is causing the driver to not have data in its first hw buffer, the dropout in the beginning is a hw buffer size. Thanks On Tue, May 3, 2011 at 1:36 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Baek Chang at 02/05/11 04:52 did gyre and gimble: Also, if i revert to pulseaudio 0.9.14, i do not see this issue happening. I can hear the very short samples in the beginning fine. I think generally that the rewinding should work, and that by reverting you are just bypassing a bug at (perhaps) the alsa level which should really be fixed. I suspect if you can create a (very simple) alsa test application that exhibits the problem (by using rewinds) then this can be taken to the alsa-devel list in order to fix the underlying problem. That's my take on it anyway, and I could of course be wrong! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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 -- -baeksanchang ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rewind and underrun issues on start of playback
On Tue, May 03, 2011 at 11:09:56AM -0700, Baek Chang wrote: I think you are correct in that there is an alsa bug. It seems that pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio 0.9.22 does. It seems like the rewind is causing the driver to not have data in its first hw buffer, the dropout in the beginning is a hw buffer size. I frequently recommend PulseAudio as a test suite for driver DMA implementations :) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rewind and underrun issues on start of playback
I think you are correct in that there is an alsa bug. It seems that pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio 0.9.22 does. I asked before, but for some reason never got an answer from this list: is there a simple way to disable rewinds? They seem to be related to excessive real-time CPU usage, causing rlimit_rttime to be exceeded (and pulse to be KILL'ed by the kernel). -- Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rewind and underrun issues on start of playback
Hi, 'Twas brillig, and Dan Muresan at 03/05/11 19:51 did gyre and gimble: I think you are correct in that there is an alsa bug. It seems that pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio 0.9.22 does. I asked before, but for some reason never got an answer from this list: is there a simple way to disable rewinds? They seem to be related to excessive real-time CPU usage, causing rlimit_rttime to be exceeded (and pulse to be KILL'ed by the kernel). From earlier in this thread: 'Twas brillig, and Tanu Kaskinen at 01/05/11 08:22 did gyre and gimble: On Sat, 2011-04-30 at 15:38 -0700, Baek Chang wrote: Is there a way to prevent these rewinds/underruns when starting playback? Not to my knowledge, except by changing the code. I'm pretty sure that's correct (tho' I won't pretend to know the alsa code in very much depth). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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
