Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
On 06/30/2012 12:36 PM, Tanu Kaskinen wrote: Hi, We handle booleans with these definitions: /* This type is not intended to be used in exported APIs! Use classic int there! */ #ifdef HAVE_STD_BOOL typedef bool pa_bool_t; #else typedef int pa_bool_t; #endif #ifndef FALSE #define FALSE ((pa_bool_t) 0) #endif #ifndef TRUE #define TRUE (!FALSE) #endif As far as I know, the bool data type is a feature of C99, and we also rely on other other C99 features, so I don't think there's any benefit in having the HAVE_STD_BOOL check, or compatibility problems if we drop the check. We could define pa_bool_t as bool unconditionally. And if we do that, then we could as well start using bool directly instead of wrapping it in pa_bool_t. Therefore, I propose that we deprecate pa_bool_t (I have a feeling that someone has proposed that already before, but that discussion didn't go anywhere). My proposal for the transition strategy is that pa_bool_t is kept for now, but it would always be defined as bool. New boolean variables should not use pa_bool_t. Old pa_bool_t uses would be converted gradually like was done e.g. with pa_streq(). There was recently a patch that changed all remaining strcmp() uses into pa_streq(), and if someone wants to write a patch that converts all pa_bool_t instances into bool in one go, that's fine for me. What do others think? I don't think there is any reason to not do s/pa_bool_t/bool/g. Probably the reason for this might be historical, as some compilers may have supported some C99 features but not all of them (Microsoft compilers come to mind). It might make sense to keep something like #ifndef HAVE_STD_BOOL typedef int bool; ...or just remove all of it, make configure fail if stdbool.h is not present, and insert something like the above if we find we broke a compiler we want to support. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
On Mon, 02 Jul 2012 08:45:42 +0200, David Henningsson david.hennings...@canonical.com wrote: It might make sense to keep something like #ifndef HAVE_STD_BOOL typedef int bool; I sincerely don't recommend that kind of hacks. int and bool are completely different things. The representation in memory may be different depending on the ABI. Furthermore, the conversion rule for the compiler are not the same. That can introduce subtle bugs on old compilers. I think it's best to fail explicitly than to hide bugs. -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] asoundrc, configure one virtual device for both input and output
Thanks for the compilation details, it all compiled in the 1st go, While modifying the code to accept source and sink parameter in the asoundrc, is it advisable to have to 2 snd_pcm_pulse_t *pcm; objects ? Like one for source and one for sink and initialize them the same way, because I can't see any other way to do it. Correct me if I am wrong. Amar. On Sun, Jul 1, 2012 at 4:24 PM, Tanu Kaskinen ta...@iki.fi wrote: On Sun, 2012-07-01 at 09:49 +0300, Tanu Kaskinen wrote: I tried the ./gitcompile --enable-pulseaudio command myself, and had this problem: Making all in pulse make[2]: Entering directory `/home/tanu/dev/alsa-plugins/pulse' /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -Wall -g -I/usr/include/alsa-D_REENTRANT -I/usr/local/include -D_GNU_SOURCE -g -O2 -MT ctl_pulse.lo -MD -MP -MF .deps/ctl_pulse.Tpo -c -o ctl_pulse.lo ctl_pulse.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -g -I/usr/include/alsa -D_REENTRANT -I/usr/local/include -D_GNU_SOURCE -g -O2 -MT ctl_pulse.lo -MD -MP -MF .deps/ctl_pulse.Tpo -c ctl_pulse.c -fPIC -DPIC -o .libs/ctl_pulse.o mv -f .deps/ctl_pulse.Tpo .deps/ctl_pulse.Plo /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -Wall -g -I/usr/include/alsa-D_REENTRANT -I/usr/local/include -D_GNU_SOURCE -g -O2 -MT pulse.lo -MD -MP -MF .deps/pulse.Tpo -c -o pulse.lo pulse.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -g -I/usr/include/alsa -D_REENTRANT -I/usr/local/include -D_GNU_SOURCE -g -O2 -MT pulse.lo -MD -MP -MF .deps/pulse.Tpo -c pulse.c -fPIC -DPIC -o .libs/pulse.o mv -f .deps/pulse.Tpo .deps/pulse.Plo /bin/bash ../libtool --tag=CC --mode=link gcc -Wall -g -I/usr/include/alsa -D_REENTRANT -I/usr/local/include -D_GNU_SOURCE -g -O2 -module -avoid-version -export-dynamic -no-undefined -o libasound_module_ctl_pulse.la -rpath /usr/lib/alsa-lib ctl_pulse.lo pulse.lo -lasound-L/usr/local/lib -lpulse -lasound libtool: link: gcc -shared -fPIC -DPIC .libs/ctl_pulse.o .libs/pulse.o -L/usr/local/lib /usr/local/lib/libpulse.so -lasound -O2 -pthread -Wl,-soname -Wl,libasound_module_ctl_pulse.so -o .libs/libasound_module_ctl_pulse.so /bin/sed: can't read /usr/lib/x86_64-linux-gnu/libsndfile.la: No such file or directory libtool: link: `/usr/lib/x86_64-linux-gnu/libsndfile.la' is not a valid libtool archive make[2]: *** [libasound_module_ctl_pulse.la] Error 1 make[2]: Leaving directory `/home/tanu/dev/alsa-plugins/pulse' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tanu/dev/alsa-plugins' make: *** [all] Error 2 Debian doesn't ship libsndfile.la, so I tried installing libsndfile from source. That didn't help at all. I eventually figured that since the alsa build system doesn't reference libsndfile at all, libpulse must somehow have a reference to /usr/lib/x86_64-linux-gnu/libsndfile.la (even though my system has never had that file installed). I rebuilt pulseaudio and installed it, and now it works (apparently because the rebuilt version references the version of libsndfile that was built from source, which includes libsndfile.la, instead of referencing the system version of libsndfile). Does anyone know if the build system of alsa-plugins could be improved so that it doesn't use any external .la files when linking? Update: now I'm unable to reproduce the problem, even after uninstalling the self-compiled libsndfile instance and rebuilding pulseaudio again... That means that I can't try any fixes, because there's nothing to fix. Sorry for the noise. -- Tanu -- Thank you... Amar Akshat (アマール) Walking on water and developing software from a specification are easy if both are frozen. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/4] alsa-mixer: Add special profiles for some laptops missing speaker and/or internal mic
On 06/28/2012 06:25 PM, Tanu Kaskinen wrote: On Thu, 2012-06-28 at 16:27 +0200, David Henningsson wrote: Several laptops have speaker ports, and/or internal mic ports, but we have no way of detecting that. So we make the port(s) always show up for these devices. BugLink: https://bugs.launchpad.net/bugs/946232 Signed-off-by: David Henningsson david.hennings...@canonical.com +; For devices where a 'Internal Mic' or 'Internal Mic Boost' element exists +; 'Int Mic' and 'Int Mic Boost' are for compatibility with kernels 2.6.38 +; +; See analog-output.conf.common for an explanation on the directives Not really problem with this specific patch, but anyway, I saw analog-output.conf.common, and I didn't find any explanation for the jack state directives (they are completely new to me). analog-output.conf.common needs updating. Otherwise looks good to me. The mostly copy-pasted profile-set files aren't very cool, though, but I don't have any good solution for it right now. Btw, the conf parser supports include files, so if we can verify that overriding something works correctly, we could just override the relevant section - or line - in the special .conf and then include default.conf? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/4] Four unrelated changes to alsa mixer paths
On 06/28/2012 04:26 PM, David Henningsson wrote: Actually, the two first patches are related, so the subject line is slightly lying. :-) Colin Guthrie was the first to notice what is now being fixed by patch 1 and 2. Patch 1 is a short-term workaround for kernels 3.3, 3.4 and 3.5. Patch 2 is the long-term fix for kernels 3.6 and beyond (it's in Takashi's tree currently), but since 3.6 is a while away, I believe it makes sense to commit both fixes. Patches 2, 3 and 4 are stuff recently added to the kernel so we can get more information out of it, and here comes the corresponding PulseAudio fixes that would make use of that information. I don't know if it makes sense to release PulseAudio 2.1 with these fixes in; regardless of which I'm very likely to pull them into Ubuntu 12.10, and possibly also 12.04 (and btw, patch 1 is already in Ubuntu 12.04). I've pushed all but the fourth, for which I'm awaiting some additional testing. I was also bold enough to commit two simple patches that add support for Front Headphone jack, and document state.plugged/state.unplugged. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/4] alsa-mixer: Add special profiles for some laptops missing speaker and/or internal mic
On Mon, 2012-07-02 at 12:27 +0200, David Henningsson wrote: On 06/28/2012 06:25 PM, Tanu Kaskinen wrote: Otherwise looks good to me. The mostly copy-pasted profile-set files aren't very cool, though, but I don't have any good solution for it right now. Btw, the conf parser supports include files, so if we can verify that overriding something works correctly, we could just override the relevant section - or line - in the special .conf and then include default.conf? Sounds good to me. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] asoundrc, configure one virtual device for both input and output
On Mon, 2012-07-02 at 19:10 +0900, Amar Akshat wrote: Thanks for the compilation details, it all compiled in the 1st go, While modifying the code to accept source and sink parameter in the asoundrc, is it advisable to have to 2 snd_pcm_pulse_t *pcm; objects ? Two snd_pcm_pulse_t objects where? I would imagine that you don't have to care about that - when you open both input and output in your application, alsa will automatically create two pulse pcm objects behind the scenes: one for input and one for output. I'm not really an alsa expert, however, so it's possible that I'm wrong. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
On 07/02/2012 09:26 AM, Rémi Denis-Courmont wrote: On Mon, 02 Jul 2012 08:45:42 +0200, David Henningsson david.hennings...@canonical.com wrote: It might make sense to keep something like #ifndef HAVE_STD_BOOL typedef int bool; I sincerely don't recommend that kind of hacks. int and bool are completely different things. The representation in memory may be different depending on the ABI. Furthermore, the conversion rule for the compiler are not the same. That can introduce subtle bugs on old compilers. I think it's best to fail explicitly than to hide bugs. bool / pa_bool_t is not used in the public API/ABI, there we use only ints (for the reasons you claim above, I believe). Does your point still stand even if it is only used internally? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] change pa_bool_t to bool
On Sun, 2012-07-01 at 23:46 +0800, Deng Zhengrong wrote: According to Tanu's suggestion, we should change pa_bool_t to bool. And here are my patches. Now when you do git grep pa_bool_t, here's nothing... Please help to review. :) Thanks a lot! Assuming that you didn't do the changes by hand, could you put the command line that was used to generate the changes to the commit message? Also, could you change TRUE to true and FALSE to false at the same time? And remove the now-unused definitions from src/pulsecore/macro.h. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] 3.0 release schedule
On 06/29/2012 06:43 PM, Tanu Kaskinen wrote: On Mon, 2012-06-11 at 11:06 +0200, David Henningsson wrote: If we had 3-month cycles, the amount of work needed to polish a release should be smaller, I'm not sure that this is correct. But I'm not claiming it's false either :-) I guess it is also depending on the what is a release critical bug question. What release tasks do you think there are that are not directly proportinal in effort to the length of the release cycle? I don't see how the release critical bug criteria question is relevant here: with 3-month cycles, the amount of blocker bugs per release should be half of the amount of blocker bugs per release with 6-month cycles, independently of what the criteria are for blocker bugs. I'm just thinking it's probably more complicated. E g, in a 6-month cycle a bug introduced in month 1 might be discovered during development in month 4, where it would have been otherwise caught during the test cycle. so the delays should be shorter too, and even in case of a badly delayed release, you'd get newer PulseAudio version in Ubuntu than with a badly delayed 6-month cycle. True - but if we end up spending less time testing the every release as a result of releasing more often, would that cause quality to suffer? Or would it lead to more frequent checkpoints; causing errors to be caught earlier? Hard to tell. Getting changes faster to the general public will of course make the bugs in those changes to become visible faster. As for diminished amount of release candidate testing with more frequent releases: at least I don't do any extra testing during release preparations, so more frequent releases wouldn't impact my contribution to the testing. (To be clear, I don't consider my contribution to testing to be zero: I always run a development version of Pulesaudio on my computer, so the features that I need in my limited personal use cases are continuously getting tested.) Are there any people (testers) who regularly run some test set on release candidates? If there are such people, for them more frequent releases would increase the workload, which might lead them to stop doing what they are now doing. I'm not aware of any such people, but maybe they just don't keep much noise about themselves. There are people doing that, otherwise there would be no use pushing the tarballs if nobody was using them :-) I'm thinking people like Liam or Feng Wei would like to test that we don't break UCM for a release candidate. Then there are distributions that might push the release candidates to their users. I think these are the most valuable release candidate testers. For the distribution maintainers, increasing the release frequency would again increase the workload, possibly leading to them to stop caring about the release candidates. I don't have any idea how likely that scenario is. Your experience would be one data point: let's say that the release cycle was 3 months, and PA 4.0 would be released soon after Ubuntu 12.10, would you bother pushing the release candidates for 4.0 to Ubuntu, knowing that 13.04 would probably end up using PA 5.0? It's the other way around actually. In that scenario, I would definitely push 4.0 to Ubuntu 13.04 because that would mean that there was plenty of time to test and sort out bugs from 4.0, which I could then commit upstream for either 4.1 or 5.0. Then I would be anxious about whether to actually push 5.0 or stick with 4.x for the release. I don't really see how the mission could affect the release schedule, unless the mission is something like contribute to distibution X's success by fulfilling all of its sound server needs. If the mission is to cater to some specific distribution, then it of course makes sense to align as well as possible to that distribution's schedule, but I don't think anyone is suggesting such mission. The question is quite relevant IMO. When Lennart ruled the project, I believe the mission was to do just that (for Fedora). And even if we don't target a specific distribution these days, we still have Gnome and KDE releasing on 6-month schedules. On the other side we have Linux, which releases every 2-3 months. Are there more upstream projects that could be beneficial to align with, to make it easier for *any* distribution to get a consistent stack? I don't myself see the point of explicitly aligning to Gnome or KDE or anything else if they don't ask for it themselves. As long as you, as an Ubuntu representative, remain the only person who has opinions about PulseAudio release dates based on hard facts, I don't mind aligning to Ubuntu at all. If other distributions start giving similar input, we can then do a compromise between them and Ubuntu, until there are so many conflicting wishes that a compromise becomes impossible and we can start ignoring everybody. Okay. As another example for aligning with things; I just pushed a patch that will start to have effect with kernel
Re: [pulseaudio-discuss] 3.0 release schedule
On 06/29/2012 07:24 PM, Tanu Kaskinen wrote: There is a class of bugs that are so severe that they just have to be fixed before the release is made, no matter how long it may take, but those are very rare (I can't even think of any real-life examples right now). Certainly. But then it's probably something that hits many, which means you would probably detect them not too late, and be able to fix them before the deadline. I guess those are the only real blocker bugs. Then there's the class of not really a blocker bug, but marked as a blocker anyway bugs. Outside the freeze periods, I generally keep patch review as the top priority of the maintainer duties, For my own part, I see fixing bugs as my top thing in general. Or rather, what would a normal Ubuntu user want? which is, quite often, to have bugs fixed :-) ...and occasionally, new features (e g the jack detection stuff). That, or if it has something to do with machines Canonical wants to certify, that makes it float to the top of my priority list. Maybe I'm strange, but I think a moderate amount of regular meetings might actually make contributing more fun. Good :-) I just wanted to make sure I'm not pushing people to somewhere where they feel bad or bored. It is easy to forget that perspective at times. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] card-restore: Add the ability to save and restore the latency offset.
From: poljar (Damir Jelić) poljari...@gmail.com
module-card-restore now saves the latency offsets.
This change includes a entry version bump.
The entry now consists of a port count and a port name and offset for
every port that belongs to the relevant card.
---
src/modules/module-card-restore.c | 122 ++
1 file changed, 109 insertions(+), 13 deletions(-)
diff --git a/src/modules/module-card-restore.c
b/src/modules/module-card-restore.c
index 1079a72..b21aaae 100644
--- a/src/modules/module-card-restore.c
+++ b/src/modules/module-card-restore.c
@@ -68,11 +68,18 @@ struct userdata {
pa_database *database;
};
-#define ENTRY_VERSION 1
+#define ENTRY_VERSION 2
+
+struct port_info {
+char *name;
+int64_t offset;
+};
struct entry {
uint8_t version;
char *profile;
+uint32_t port_count;
+struct port_info *port_info;
};
static void save_time_callback(pa_mainloop_api*a, pa_time_event* e, const
struct timeval *t, void *userdata) {
@@ -107,6 +114,16 @@ static void entry_free(struct entry* e) {
pa_assert(e);
pa_xfree(e-profile);
+
+if (e-port_count 0) {
+unsigned i;
+for (i = 0; i e-port_count; i++)
+pa_xfree(e-port_info[i].name);
+}
+
+if (e-port_info)
+pa_xfree(e-port_info);
+
pa_xfree(e);
}
@@ -114,6 +131,7 @@ static pa_bool_t entry_write(struct userdata *u, const char
*name, const struct
pa_tagstruct *t;
pa_datum key, data;
pa_bool_t r;
+unsigned i;
pa_assert(u);
pa_assert(name);
@@ -122,6 +140,12 @@ static pa_bool_t entry_write(struct userdata *u, const
char *name, const struct
t = pa_tagstruct_new(NULL, 0);
pa_tagstruct_putu8(t, e-version);
pa_tagstruct_puts(t, e-profile);
+pa_tagstruct_putu32(t, e-port_count);
+
+for (i = 0; i e-port_count; i++) {
+pa_tagstruct_puts(t, e-port_info[i].name);
+pa_tagstruct_puts64(t, e-port_info[i].offset);
+}
key.data = (char *) name;
key.size = strlen(name);
@@ -201,6 +225,30 @@ static struct entry* entry_read(struct userdata *u, const
char *name) {
e-profile = pa_xstrdup(profile);
+if (e-version = 2) {
+const char *port_name = NULL;
+int64_t port_offset = 0;
+unsigned i;
+
+if (pa_tagstruct_getu32(t, e-port_count) 0)
+goto fail;
+
+if (e-port_count 0) {
+e-port_info = pa_xnew(struct port_info, e-port_count);
+
+for (i = 0; i e-port_count; i++) {
+if (pa_tagstruct_gets(t, port_name) 0 ||
+pa_tagstruct_gets64(t, port_offset) 0) {
+e-port_count = i;
+goto fail;
+}
+
+e-port_info[i].name = pa_xstrdup(port_name);
+e-port_info[i].offset = port_offset;
+}
+}
+}
+
if (!pa_tagstruct_eof(t))
goto fail;
@@ -238,6 +286,7 @@ static void subscribe_callback(pa_core *c,
pa_subscription_event_type_t t, uint3
struct userdata *u = userdata;
struct entry *entry, *old;
pa_card *card;
+unsigned i = 0;
pa_assert(c);
pa_assert(u);
@@ -249,15 +298,44 @@ static void subscribe_callback(pa_core *c,
pa_subscription_event_type_t t, uint3
if (!(card = pa_idxset_get_by_index(c-cards, idx)))
return;
+entry = entry_new();
+
if (!card-save_profile)
-return;
+entry-profile = pa_xstrdup();
+else
+entry-profile = pa_xstrdup(card-active_profile-name);
-entry = entry_new();
-entry-profile = pa_xstrdup(card-active_profile-name);
+entry-port_count = pa_hashmap_size(card-ports);
+
+if (entry-port_count 0) {
+void *state;
+pa_device_port *p;
+
+entry-port_info = pa_xnew(struct port_info, entry-port_count);
+
+PA_HASHMAP_FOREACH(p, card-ports, state) {
+entry-port_info[i].name = pa_xstrdup(p-name);
+entry-port_info[i].offset = p-latency_offset;
+i++;
+}
+}
if ((old = entry_read(u, card-name))) {
+bool dirty = false;
-if (pa_streq(old-profile, entry-profile)) {
+if (!pa_streq(old-profile, entry-profile)
+card-save_profile)
+dirty = true;
+
+else
+for (i = 0; i old-port_count; i++)
+if (!pa_streq(old-port_info[i].name,
entry-port_info[i].name) ||
+old-port_info[i].offset != entry-port_info[i].offset) {
+dirty = true;
+break;
+}
+
+if (!dirty) {
entry_free(old);
entry_free(entry);
return;
@@ -266,7 +344,10 @@ static void subscribe_callback(pa_core *c,
pa_subscription_event_type_t t, uint3
entry_free(old);
}
-pa_log_info(Storing profile for card %s., card-name);
+if (!card-save_profile)
+
[pulseaudio-discuss] Echo Cancellation Problems
Hi All, Are there any examples of how to configure the echo cancel module with webrtc for video conferencing? I am using GStreamer and the pulsesrc/pulsesink plugins...thanks in advance. I loaded the echo cancel module with webrtc specified for two machines and ran started up a video conference but I still got feedback/echo. Best Regards, -- Rob Krakora MessageNet Systems 101 East Carmel Dr. Suite 105 Carmel, IN 46032 (317)566-1677 Ext 212 (317)663-0808 Fax ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
