Re: [pulseaudio-discuss] pa_simple_free

2011-04-08 Thread patrick 
Arun thank you very much for this! It works perfectly, it only means one 
thing, our program is buggy. We are using a thread also (pthread), i am 
not sure why, but PulseAudio stop at pa_mutex_lock. We cannot finish our 
thread before PulseAudio finish his. Any advice is more than welcome.


Pat
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] call-state-tracker: New component.

2011-04-08 Thread Jyri Sarha 

On Tue, 5 Apr 2011, Maarten Bosmans wrote:


What are the users of this state tracker? Is it only some out-of-tree
Meego modules? Are you planning to submit those too? At least a
snippet of how it should be used would be nice.



Hi Maarten,

To answer your question about upstreaming the meego modules or
part of them, I can only say that we had a plan to upstream the
applicable parts. However, now with this new Nokia strategy it
is very hard to predict what is the future of those modules.

The biggest reason why we can not just do it now is how product
specific the code currently is. The driving force have been developing
for a specific product and not so much trying to make a generic
implementations. On the other hand with Intel/Meego cooperation we were
starting to take the steps to the right direction.

Anyway, in this new situation we just plan to upstream everything
that is generic enough. For product specific modules we plan to
open source as much as possible in the out of source tree
compiled modules [1].

Best regards,
Jyri Sarha

[1] The source code for the pulseaudio modules mentioned can be found here:
http://meego.gitorious.org/maemo-multimedia/pulseaudio-modules-meego
The heavily patched pulseaudio tree we are using can be found here:
http://meego.gitorious.org/maemo-multimedia/pulseaudio

Almost all the patches are now part of the pulseaudio upstream.

ps. The above repositories are currently not up to date, but we'll
update them soon gain.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 0/4] Miscellaneous patches from Meamo and Meego development

2011-04-08 Thread oku 
From: Jyri Sarha jyri.sa...@nokia.com

This is a collection of patches which I never got around to try to get
to the upstream before. All but the last one have been in use in
Maemo/Meego for several months without any problems at least in that
context. Anyway, as far as I can see these patches should be fairly
generic.

Cheers,
Jyri

Jyri Sarha (4):
  protocol-native: Stop auto timing updates if connected to suspended
sink or source
  suspend-on-idle: Trigger mempool vacuuming
  core: no rewinding on volume change if the sink does not support it.
  alsa-mixer: Add force-hw-volume flag to alsa profile sets

 src/modules/alsa/alsa-mixer.c|   51 ++
 src/modules/alsa/alsa-mixer.h|3 +
 src/modules/alsa/mixer/profile-sets/default.conf |3 +
 src/modules/module-suspend-on-idle.c |   41 +-
 src/pulse/stream.c   |   28 ++--
 src/pulsecore/sink-input.c   |6 ++-
 src/pulsecore/sink.c |3 +-
 7 files changed, 127 insertions(+), 8 deletions(-)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 1/4] protocol-native: Stop auto timing updates if connected to suspended sink or source

2011-04-08 Thread oku 
From: Jyri Sarha jyri.sa...@nokia.com

This quite is an old patch. It was added to N900 to avoid unnecessary
wake-ups when the phone is in power save mode (= blank screen and
no user interaction). In this situation if the user had a browser
window with flash animation open pulseaudio kept waking up every
10 seconds, causing a severe hit to use times.

Anyway I do not see any reason to send timing updates if the sink or
source where the stream is connected to is suspended.
---
 src/pulse/stream.c |   28 
 1 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/src/pulse/stream.c b/src/pulse/stream.c
index aac18a3..cd33bc1 100644
--- a/src/pulse/stream.c
+++ b/src/pulse/stream.c
@@ -328,12 +328,18 @@ static void request_auto_timing_update(pa_stream *s, 
pa_bool_t force) {
 }
 
 if (s-auto_timing_update_event) {
-if (force)
-s-auto_timing_interval_usec = AUTO_TIMING_INTERVAL_START_USEC;
+if (s-suspended  !force) {
+pa_assert(s-mainloop);
+s-mainloop-time_free(s-auto_timing_update_event);
+s-auto_timing_update_event = NULL;
+} else {
+if (force)
+s-auto_timing_interval_usec = AUTO_TIMING_INTERVAL_START_USEC;
 
-pa_context_rttime_restart(s-context, s-auto_timing_update_event, 
pa_rtclock_now() + s-auto_timing_interval_usec);
+pa_context_rttime_restart(s-context, s-auto_timing_update_event, 
pa_rtclock_now() + s-auto_timing_interval_usec);
 
-s-auto_timing_interval_usec = PA_MIN(AUTO_TIMING_INTERVAL_END_USEC, 
s-auto_timing_interval_usec*2);
+s-auto_timing_interval_usec = 
PA_MIN(AUTO_TIMING_INTERVAL_END_USEC, s-auto_timing_interval_usec*2);
+}
 }
 }
 
@@ -414,6 +420,8 @@ static void check_smoother_status(pa_stream *s, pa_bool_t 
aposteriori, pa_bool_t
  * if prebuf is non-zero! */
 }
 
+static void auto_timing_update_callback(pa_mainloop_api *m, pa_time_event *e, 
const struct timeval *t, void *userdata);
+
 void pa_command_stream_moved(pa_pdispatch *pd, uint32_t command, uint32_t tag, 
pa_tagstruct *t, void *userdata) {
 pa_context *c = userdata;
 pa_stream *s;
@@ -501,6 +509,12 @@ void pa_command_stream_moved(pa_pdispatch *pd, uint32_t 
command, uint32_t tag, p
 
 s-suspended = suspended;
 
+if ((s-flags  PA_STREAM_AUTO_TIMING_UPDATE)  !suspended  
!s-auto_timing_update_event) {
+s-auto_timing_interval_usec = AUTO_TIMING_INTERVAL_START_USEC;
+s-auto_timing_update_event = pa_context_rttime_new(s-context, 
pa_rtclock_now() + s-auto_timing_interval_usec, auto_timing_update_callback, 
s);
+request_auto_timing_update(s, TRUE);
+}
+
 check_smoother_status(s, TRUE, FALSE, FALSE);
 request_auto_timing_update(s, TRUE);
 
@@ -619,6 +633,12 @@ void pa_command_stream_suspended(pa_pdispatch *pd, 
uint32_t command, uint32_t ta
 
 s-suspended = suspended;
 
+if ((s-flags  PA_STREAM_AUTO_TIMING_UPDATE)  !suspended  
!s-auto_timing_update_event) {
+s-auto_timing_interval_usec = AUTO_TIMING_INTERVAL_START_USEC;
+s-auto_timing_update_event = pa_context_rttime_new(s-context, 
pa_rtclock_now() + s-auto_timing_interval_usec, auto_timing_update_callback, 
s);
+request_auto_timing_update(s, TRUE);
+}
+
 check_smoother_status(s, TRUE, FALSE, FALSE);
 request_auto_timing_update(s, TRUE);
 
-- 
1.7.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 2/4] suspend-on-idle: Trigger mempool vacuuming

2011-04-08 Thread oku 
From: Jyri Sarha jyri.sa...@nokia.com

In a setup with one or more filter sinks or sources there is always at
least one stream existing. In such a situation normal mempool
vacuuming never happens. This patch causes suspend-on-idle module to
vacuum memory when ever it notices that all sinks and sources are
suspended. The behavior can be enabled with a module parameter.
---
 src/modules/module-suspend-on-idle.c |   41 +-
 1 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/src/modules/module-suspend-on-idle.c 
b/src/modules/module-suspend-on-idle.c
index 2bc424b..0069270 100644
--- a/src/modules/module-suspend-on-idle.c
+++ b/src/modules/module-suspend-on-idle.c
@@ -41,10 +41,13 @@ PA_MODULE_AUTHOR(Lennart Poettering);
 PA_MODULE_DESCRIPTION(When a sink/source is idle for too long, suspend it);
 PA_MODULE_VERSION(PACKAGE_VERSION);
 PA_MODULE_LOAD_ONCE(TRUE);
-PA_MODULE_USAGE(timeout=timeout);
+PA_MODULE_USAGE(
+timeout=timeout 
+mempool_vacuum=vacuum memory if all sinks and sources are 
suspended?);
 
 static const char* const valid_modargs[] = {
 timeout,
+mempool_vacuum,
 NULL,
 };
 
@@ -71,6 +74,8 @@ struct userdata {
 *source_output_move_finish_slot,
 *sink_input_state_changed_slot,
 *source_output_state_changed_slot;
+
+pa_bool_t mempool_vacuum:1;
 };
 
 struct device_info {
@@ -81,6 +86,29 @@ struct device_info {
 pa_time_event *time_event;
 };
 
+static void check_meempool_vacuum(struct device_info *d) {
+pa_sink *si;
+pa_source *so;
+uint32_t idx;
+
+pa_assert(d);
+pa_assert(d-userdata);
+pa_assert(d-userdata-core);
+
+idx = 0;
+PA_IDXSET_FOREACH(si, d-userdata-core-sinks, idx)
+if (pa_sink_get_state(si) != PA_SINK_SUSPENDED)
+return;
+
+idx = 0;
+PA_IDXSET_FOREACH(so, d-userdata-core-sources, idx)
+if (pa_source_get_state(so) != PA_SOURCE_SUSPENDED)
+return;
+
+pa_log_info(All sinks and sources are suspended, vacuuming memory);
+pa_mempool_vacuum(d-userdata-core-mempool);
+}
+
 static void timeout_cb(pa_mainloop_api*a, pa_time_event* e, const struct 
timeval *t, void *userdata) {
 struct device_info *d = userdata;
 
@@ -91,11 +119,15 @@ static void timeout_cb(pa_mainloop_api*a, pa_time_event* 
e, const struct timeval
 if (d-sink  pa_sink_check_suspend(d-sink) = 0  
!(d-sink-suspend_cause  PA_SUSPEND_IDLE)) {
 pa_log_info(Sink %s idle for too long, suspending ..., 
d-sink-name);
 pa_sink_suspend(d-sink, TRUE, PA_SUSPEND_IDLE);
+if (d-userdata-mempool_vacuum)
+check_meempool_vacuum(d);
 }
 
 if (d-source  pa_source_check_suspend(d-source) = 0  
!(d-source-suspend_cause  PA_SUSPEND_IDLE)) {
 pa_log_info(Source %s idle for too long, suspending ..., 
d-source-name);
 pa_source_suspend(d-source, TRUE, PA_SUSPEND_IDLE);
+if (d-userdata-mempool_vacuum)
+check_meempool_vacuum(d);
 }
 }
 
@@ -417,6 +449,7 @@ int pa__init(pa_module*m) {
 pa_modargs *ma = NULL;
 struct userdata *u;
 uint32_t timeout = 5;
+pa_bool_t mempool_vacuum = FALSE;
 uint32_t idx;
 pa_sink *sink;
 pa_source *source;
@@ -433,10 +466,16 @@ int pa__init(pa_module*m) {
 goto fail;
 }
 
+if (pa_modargs_get_value_boolean(ma, mempool_vacuum, mempool_vacuum)  
0) {
+pa_log(Failed to parse mempool_vacuum boolean parameter.);
+goto fail;
+}
+
 m-userdata = u = pa_xnew(struct userdata, 1);
 u-core = m-core;
 u-timeout = timeout;
 u-device_infos = pa_hashmap_new(pa_idxset_trivial_hash_func, 
pa_idxset_trivial_compare_func);
+u-mempool_vacuum = mempool_vacuum;
 
 for (sink = pa_idxset_first(m-core-sinks, idx); sink; sink = 
pa_idxset_next(m-core-sinks, idx))
 device_new_hook_cb(m-core, PA_OBJECT(sink), u);
-- 
1.7.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 3/4] core: no rewinding on volume change if the sink does not support it.

2011-04-08 Thread oku 
From: Jyri Sarha jyri.sa...@nokia.com

No volume is applied to a stream before pa_sink_render or some
it's siblings is called. Because of this there is no use to
rewind on volume change if the sink does not support it. It is
just a waste of CPU.
---
 src/pulsecore/sink-input.c |6 --
 src/pulsecore/sink.c   |3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
index 46f26f9..28d083d 100644
--- a/src/pulsecore/sink-input.c
+++ b/src/pulsecore/sink-input.c
@@ -1648,14 +1648,16 @@ int pa_sink_input_process_msg(pa_msgobject *o, int 
code, void *userdata, int64_t
 case PA_SINK_INPUT_MESSAGE_SET_SOFT_VOLUME:
 if (!pa_cvolume_equal(i-thread_info.soft_volume, 
i-soft_volume)) {
 i-thread_info.soft_volume = i-soft_volume;
-pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
+if (i-sink  i-sink-thread_info.max_rewind  0)
+pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
 }
 return 0;
 
 case PA_SINK_INPUT_MESSAGE_SET_SOFT_MUTE:
 if (i-thread_info.muted != i-muted) {
 i-thread_info.muted = i-muted;
-pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
+if (i-sink  i-sink-thread_info.max_rewind  0)
+pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
 }
 return 0;
 
diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
index 839b7d4..ebe4c7b 100644
--- a/src/pulsecore/sink.c
+++ b/src/pulsecore/sink.c
@@ -2060,7 +2060,8 @@ static void sync_input_volumes_within_thread(pa_sink *s) {
 continue;
 
 i-thread_info.soft_volume = i-soft_volume;
-pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
+if (s-thread_info.max_rewind  0)
+pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
 }
 }
 
-- 
1.7.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 4/4] alsa-mixer: Add force-hw-volume flag to alsa profile sets

2011-04-08 Thread oku 
From: Jyri Sarha jyri.sa...@nokia.com

Before this patch, if any of the paths in a path set do not
support HW volume then the HW volume is disabled for the whole
set. In some cases this is a bit drastic measure. For instance,
if all but one of the paths support HW volume and dB there no
problem to pretend that we have HW volume for the whole set. The
path without any mixers to control will just always return 0 dB
and the rest is handled by SW volume. This patch adds a flag to
the mapping section of profile set file to enables this behavior.
---
 src/modules/alsa/alsa-mixer.c|   51 ++
 src/modules/alsa/alsa-mixer.h|3 +
 src/modules/alsa/mixer/profile-sets/default.conf |3 +
 3 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index f236da0..027c63a 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -2693,6 +2693,7 @@ pa_alsa_path_set *pa_alsa_path_set_new(pa_alsa_mapping 
*m, pa_alsa_direction_t d
 
 ps = pa_xnew0(pa_alsa_path_set, 1);
 ps-direction = direction;
+ps-force_hw_volume = m-force_hw_volume;
 
 if (direction == PA_ALSA_DIRECTION_OUTPUT)
 pn = m-output_path_names;
@@ -2816,6 +2817,25 @@ static void path_set_unify(pa_alsa_path_set *ps) {
  * means for now we have to have all paths support volume/mute/dB
  * or none. */
 
+if (ps-force_hw_volume) {
+pa_bool_t force_on = TRUE;
+PA_LLIST_FOREACH(p, ps-paths) {
+pa_assert(p-probed);
+if (p-has_volume  !p-has_dB) {
+pa_log_warn(The path %s has hw volume but lacks dB 
information, can not apply force-hw-volume flag.,  p-name);
+force_on = FALSE;
+}
+}
+if (force_on) {
+pa_log_debug(Successful forced HW volume on path set 
containing:);
+PA_LLIST_FOREACH(p, ps-paths) {
+pa_log_debug(%s %s, p-name, p-has_volume ?  : (hw 
volume forced));
+p-has_volume = TRUE;
+p-has_dB = TRUE;
+}
+}
+}
+
 PA_LLIST_FOREACH(p, ps-paths) {
 pa_assert(p-probed);
 
@@ -3188,6 +3208,36 @@ static int mapping_parse_direction(
 return 0;
 }
 
+static int mapping_parse_force_hw_volume(
+const char *filename,
+unsigned line,
+const char *section,
+const char *lvalue,
+const char *rvalue,
+void *data,
+void *userdata) {
+
+pa_alsa_profile_set *ps = userdata;
+pa_alsa_mapping *m;
+int b;
+
+pa_assert(ps);
+
+if (!(m = mapping_get(ps, section))) {
+pa_log([%s:%u] Section name %s invalid., filename, line, section);
+return -1;
+}
+
+if ((b = pa_parse_boolean(rvalue))  0) {
+pa_log([%s:%u] Force hw volume invalid of '%s', filename, line, 
section);
+return -1;
+}
+
+m-force_hw_volume = b;
+
+return 0;
+}
+
 static int mapping_parse_description(
 const char *filename,
 unsigned line,
@@ -3778,6 +3828,7 @@ pa_alsa_profile_set* pa_alsa_profile_set_new(const char 
*fname, const pa_channel
 { element-input,  mapping_parse_element,NULL, NULL },
 { element-output, mapping_parse_element,NULL, NULL },
 { direction,  mapping_parse_direction,  NULL, NULL },
+{ force-hw-volume,mapping_parse_force_hw_volume,NULL, NULL },
 
 /* Shared by [Mapping ...] and [Profile ...] */
 { description,mapping_parse_description,NULL, NULL },
diff --git a/src/modules/alsa/alsa-mixer.h b/src/modules/alsa/alsa-mixer.h
index a29aed1..a80dfc6 100644
--- a/src/modules/alsa/alsa-mixer.h
+++ b/src/modules/alsa/alsa-mixer.h
@@ -199,6 +199,7 @@ struct pa_alsa_path_set {
 PA_LLIST_HEAD(pa_alsa_path, paths);
 pa_alsa_direction_t direction;
 pa_bool_t probed:1;
+pa_bool_t force_hw_volume:1;
 
 /* This is used during parsing only, as a shortcut so that we
  * don't have to iterate the list all the time */
@@ -255,6 +256,8 @@ struct pa_alsa_mapping {
 
 pa_sink *sink;
 pa_source *source;
+
+pa_bool_t force_hw_volume:1;
 };
 
 struct pa_alsa_profile {
diff --git a/src/modules/alsa/mixer/profile-sets/default.conf 
b/src/modules/alsa/mixer/profile-sets/default.conf
index 9f7b5f2..560f930 100644
--- a/src/modules/alsa/mixer/profile-sets/default.conf
+++ b/src/modules/alsa/mixer/profile-sets/default.conf
@@ -55,6 +55,9 @@
 ; priority = ...
 ; direction = any | input | output  # Only useful for?
 ;
+; force-hw-volume = no | yes# Force HW volume on a path sets 
in profile even if all paths do not support
+;   # HW volume. To be able to force 
the HW volume all paths with HW volume
+;   # must have dB info.
 ; [Profile id]
 ;

Re: [pulseaudio-discuss] [PATCH 3/4] core: no rewinding on volume change if the sink does not support it.

2011-04-08 Thread Colin Guthrie 
'Twas brillig, and o...@iki.fi at 08/04/11 15:18 did gyre and gimble:
 From: Jyri Sarha jyri.sa...@nokia.com
 
 No volume is applied to a stream before pa_sink_render or some
 it's siblings is called. Because of this there is no use to
 rewind on volume change if the sink does not support it. It is
 just a waste of CPU.
 ---
  src/pulsecore/sink-input.c |6 --
  src/pulsecore/sink.c   |3 ++-
  2 files changed, 6 insertions(+), 3 deletions(-)
 
 diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
 index 46f26f9..28d083d 100644
 --- a/src/pulsecore/sink-input.c
 +++ b/src/pulsecore/sink-input.c
 @@ -1648,14 +1648,16 @@ int pa_sink_input_process_msg(pa_msgobject *o, int 
 code, void *userdata, int64_t
  case PA_SINK_INPUT_MESSAGE_SET_SOFT_VOLUME:
  if (!pa_cvolume_equal(i-thread_info.soft_volume, 
 i-soft_volume)) {
  i-thread_info.soft_volume = i-soft_volume;
 -pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
 +if (i-sink  i-sink-thread_info.max_rewind  0)
 +pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
  }
  return 0;
  
  case PA_SINK_INPUT_MESSAGE_SET_SOFT_MUTE:
  if (i-thread_info.muted != i-muted) {
  i-thread_info.muted = i-muted;
 -pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
 +if (i-sink  i-sink-thread_info.max_rewind  0)
 +pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
  }
  return 0;
  
 diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
 index 839b7d4..ebe4c7b 100644
 --- a/src/pulsecore/sink.c
 +++ b/src/pulsecore/sink.c
 @@ -2060,7 +2060,8 @@ static void sync_input_volumes_within_thread(pa_sink 
 *s) {
  continue;
  
  i-thread_info.soft_volume = i-soft_volume;
 -pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
 +if (s-thread_info.max_rewind  0)
 +pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
  }
  }
  

Would it not be possible to move this check into the function itself and
just make it a noop?

I appreciate there would be FCO but it would reduce the likelihood of
this check being missed on some other calls... unless that is desirable
sometimes?

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] [PATCH 4/4] alsa-mixer: Add force-hw-volume flag to alsa profile sets

2011-04-08 Thread Colin Guthrie 
'Twas brillig, and o...@iki.fi at 08/04/11 15:18 did gyre and gimble:
 From: Jyri Sarha jyri.sa...@nokia.com
 
 Before this patch, if any of the paths in a path set do not
 support HW volume then the HW volume is disabled for the whole
 set. In some cases this is a bit drastic measure. For instance,
 if all but one of the paths support HW volume and dB there no
 problem to pretend that we have HW volume for the whole set. The
 path without any mixers to control will just always return 0 dB
 and the rest is handled by SW volume. This patch adds a flag to
 the mapping section of profile set file to enables this behavior.

David, this sounds similar to your USB Headset issue from a couple days
ago... or am I just reading too much into the description?

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

[pulseaudio-discuss] starting multiple pulseaudio instances for the same user

2011-04-08 Thread Antoine Martin 
Hi,

How can I start multiple copies of pulseaudio for the same $USER, but in
different contexts?
This was working a while back (last year or so - not sure about version
numbers).. but doesn't any more?

My software starts a virtual X server (xpra, vnc..), dbus and a
dedicated pulseaudio server for each session application it launches.
This allows it to redirect the sound (in and out) to/from remote
machines (potentially multiple at once too, some directly, some via
gstreamer+vorbis over ssh) - all this together with the display. see (1)

Each application session gets its own environment and starts
pulseaudio with:
/usr/bin/pulseaudio --start - --disable-shm=true --daemonize=false
--use-pid-file=false --system=false --exit-idle-time=-1 -n
--load=module-suspend-on-idle --load=module-null-sink
--load=module-native-protocol-unix socket=/tmp/pulse-$DISPLAY/native

A single $USER may start dozens of those sessions, each with a different
(virtual) $DISPLAY.
Now, when I start the second instance I can see that it somehow finds
the previous copy (not the one used by my local X11 session)
[pid  3044]
open(/home/antoine/.pulse/70a1ab2a8c9d6cb7625f1706000d-runtime/autospawn.lock,
O_RDWR|O_CREAT|O_NOCTTY|O_NOFOLLOW, 0600) = 5
[pid  3044] fcntl(5, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0,
len=0}
From that point onwards, nothing happens.

Can you please advise on how to restore this functionality?

Thanks
Antoine

(1)
http://winswitch.org/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense

2011-04-08 Thread pl bossart 
 I've not looked specifically at the code, but I'd have expected that
 jack detection would somehow be built into module-alsa-card or
 module-alsa-source/sink rather than shipped as a separate module (tho'
 I'm maybe not appreciating some intricacy here)... I'll try and review
 the code soon (although others may have beaten me to it anyway :D)


 Well the UCM code corresponding on what to do when jack is plug or
 unplug  its part of module-alsa-card but we had to add first the logic
 in PA to detect the jack insertation/removel  that it is basically a
 listener of /dev/input/eventX, that is used by the kernel to report
 the event. All the logic for jack detection has been added in a new
 module.

 I'll wait your feedback/questions related to UCM integration :)

I have pretty much the same feedback as Colin.
First I cherry-picked the two jack-sensing patch and installed them on
my laptop (68293cd29b1dcb6b555edeaa5d63110164e5c794 and
6c4a7de60040d5dc3d3b44461a7f490e3feba26f). Works fine, the events are
detected. This is something that we've needed for some time. Thanks!

But then I looked a the flows and was confused by the design.
- It's not clear why you would create a new thread using pthreads
rather than pa_create_thread()? Is there any technical reason why the
abstraction isn't enough
- this thread blocks on a read, and whenever a jack insertion/removal
is detected it fires a Hook which is then used by module-alsa-card to
actually switch profiles in two callbacks.
Why not implement this thread as part of module-alsa-card then? What
if the benefits of using the hook as a communication means between two
modules? I can see though the benefit of using a hook for, say, an
effect that is enabled only for a headphone. That is more the intended
use of a hook I believe.
While I am at it, I am not even sure you need a thread for this with
all the event loops, iochannels and stuff that PulseAudio/glib
provide.
We may also want to switch the card profiles even if the card isn't
supported by UCM.

Last, I looked at the two callbacks you implemented, looks to me that
the insert and remove parts do the same thing? Shouldn't you memorize
the current device, switch to the headphone upon jack insertion and
restore the previous device on removal?
Maybe this needs to be linked with how PulseAudio memorizes the
devices or Colin's device-manager?
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss