Re: [pulseaudio-discuss] Does pulseaudio support HDMI, Wi-Fi Display and USB headset?
On 09/09/2011 04:12 AM, Lin, Mengdong wrote: Does pulse audio have modules to support HDMI, Wi-Fi Display and USB headset? If yes, what are the modules’ names? Can they detect connection/disconnection of these devices? USB and HDMI (on a typical PC) are handled by ALSA and thus module-udev-detect. USB headsets are autodetected in the sense that cards show up and disappear, whereas HDMI codecs are always present (and you need my jack detection patches in order to detect if there's a monitor connected or not). Never heard of sending audio to a "Wi-Fi Display", what protocol does that typically speak? RTP? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] volumes: Implement options to bypass the base volume system.
On 09/08/2011 10:30 PM, Colin Guthrie wrote:
When the underlying hardware (typically ALSA) reports that the dB
volume ranges to to a value>0dB, a 'base volume' is automatically
added. This system allows the user to utilise the full range of the
underlying hardware controls (ranging from PA_VOLUME_MIN to
PA_VOLUME_NORM) but still get informed, via UI clues, as to the point
the hardware reports as 0dB (i.e. the point at which your sound should
be unmodified).
Sadly, this system does not work for some users. Sometimes the range
where the volume remains below the underlying 0dB point is very small
(e.g. from 0 to 20%). In this scenario, things are made very awkward for
users as the active range they typically want to adjust is so small.
Hm. If I understand the problem correctly, the problem is that the user
does not want to see the volume slider ranging from PA_VOLUME_MIN to
PA_VOLUME_NORM, but something different. This sounds very much like the
PA_VOLUME_UI_MAX thing.
Let me suggest a different solution. Drop both this and
PA_VOLUME_UI_MAX, and replace it with something more configurable. For
every port, let the user configure the range they want to be able to
set, so that they can set an arbitrarily range, both within and outside
the limits of what the hardware volume supports.
I'm not sure exactly how to best store this information (udev rules?
gconf? per-user volume database?) but my point is to have this
information on Port level rather than card level or global level.
Added to the above scenario, if the user has flat volumes enabled they
will also get this limited range within application volume controls.
This particular scenario has prompted some applications to implement
their own work arounds to this problem and scale the whole volume range
they expose to the base volume when flat volumes are enabled. This
means that the scale the user sees inside the application will be
different to e.g. the scale given by panel applet volume controls,
OSD displays+volume keys and full blown mixers GUIs.
This inconsistency in applications is what has prompted this feature.
It allows users to choose whether or not they want to expose the base
volume and get the full range of h/w control (as currently), or whether
they would prefer to honour the 0dB of the underlying h/w and set
that to our 0dB point (aka 100%). UIs which honour PA_VOLUME_UI_MAX will
still offer the user some of the additional range their h/w supports
0dB.
The behaviour remains unchanged by default and users will have to set
the feature manually in daemon.conf. The option is split so the user can
choose to apply it separately for sinks (where the problem is most
visible) and sources.
For sources, in particular microphone inputs, the base volume is usually
very low. On a typical HDA the volume might range between -30dB to +60
dB and usually you want to set it to something like +20 dB. My USB
headset actually ranges from +16 dB to +29 dB, so 0 dB is not even
settable through hw controls.
---
src/daemon/daemon-conf.c |6 ++
src/daemon/daemon-conf.h |2 ++
src/daemon/daemon.conf.in |2 ++
src/daemon/main.c |2 ++
src/modules/alsa/alsa-sink.c | 17 -
src/modules/alsa/alsa-source.c | 17 -
src/pulsecore/core.h |2 ++
7 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c
index c4ee544..5fb10a0 100644
--- a/src/daemon/daemon-conf.c
+++ b/src/daemon/daemon-conf.c
@@ -71,6 +71,8 @@ static const pa_daemon_conf default_conf = {
.disallow_module_loading = FALSE,
.disallow_exit = FALSE,
.flat_volumes = TRUE,
+.sink_use_base_volume = TRUE,
+.source_use_base_volume = TRUE,
.exit_idle_time = 20,
.scache_idle_time = 20,
.auto_log_target = 1,
@@ -535,6 +537,8 @@ int pa_daemon_conf_load(pa_daemon_conf *c, const char
*filename) {
{ "disable-shm",pa_config_parse_bool,&c->disable_shm,
NULL },
{ "enable-shm",
pa_config_parse_not_bool,&c->disable_shm, NULL },
{ "flat-volumes",
pa_config_parse_bool,&c->flat_volumes, NULL },
+{ "sink-use-base-volume",
pa_config_parse_bool,&c->sink_use_base_volume, NULL },
+{ "source-use-base-volume",
pa_config_parse_bool,&c->source_use_base_volume, NULL },
{ "lock-memory",pa_config_parse_bool,&c->lock_memory,
NULL },
{ "enable-sync-volume", pa_config_parse_bool,&c->sync_volume,
NULL },
{ "exit-idle-time",
pa_config_parse_int,&c->exit_idle_time, NULL },
@@ -736,6 +740,8 @@ char *pa_daemon_conf_dump(pa_daemon_conf *c) {
pa_strbuf_printf(s, "cpu-limit = %s\n", pa_yes_no(!c->no_cpu_limit));
pa_strbuf_printf(s, "enable-shm = %s\n", pa_yes_no(!c->disable_shm));
pa_strbuf_printf(s, "flat-volumes = %s\n", pa_yes_no
[pulseaudio-discuss] Does pulseaudio support HDMI, Wi-Fi Display and USB headset?
Does pulse audio have modules to support HDMI, Wi-Fi Display and USB headset? If yes, what are the modules' names? Can they detect connection/disconnection of these devices? Many thanks Mengdong ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, Sep 08, 2011 at 02:19:41AM +0800, Arun Raghavan wrote: > On Wed, 2011-09-07 at 11:09 -0700, Arun Raghavan wrote: > > On Wed, 2011-09-07 at 14:20 +0800, Lu Guanqun wrote: > > > Hi Arun, > > > > > > I have several things unclear about passthrough support: > > > > I'm talking about this work at Linux Plumbers' Conference on Friday. If > > videos are available, I'll link to them -- hopefully that should make > > the motivation clear. > > Oh, phew, no video -- I'm still happy to answer any questions you > have. :) Thanks Arun for your info. At least there'll be slides published? -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] volumes: Implement options to bypass the base volume system.
When the underlying hardware (typically ALSA) reports that the dB
volume ranges to to a value >0dB, a 'base volume' is automatically
added. This system allows the user to utilise the full range of the
underlying hardware controls (ranging from PA_VOLUME_MIN to
PA_VOLUME_NORM) but still get informed, via UI clues, as to the point
the hardware reports as 0dB (i.e. the point at which your sound should
be unmodified).
Sadly, this system does not work for some users. Sometimes the range
where the volume remains below the underlying 0dB point is very small
(e.g. from 0 to 20%). In this scenario, things are made very awkward for
users as the active range they typically want to adjust is so small.
Added to the above scenario, if the user has flat volumes enabled they
will also get this limited range within application volume controls.
This particular scenario has prompted some applications to implement
their own work arounds to this problem and scale the whole volume range
they expose to the base volume when flat volumes are enabled. This
means that the scale the user sees inside the application will be
different to e.g. the scale given by panel applet volume controls,
OSD displays+volume keys and full blown mixers GUIs.
This inconsistency in applications is what has prompted this feature.
It allows users to choose whether or not they want to expose the base
volume and get the full range of h/w control (as currently), or whether
they would prefer to honour the 0dB of the underlying h/w and set
that to our 0dB point (aka 100%). UIs which honour PA_VOLUME_UI_MAX will
still offer the user some of the additional range their h/w supports
>0dB.
The behaviour remains unchanged by default and users will have to set
the feature manually in daemon.conf. The option is split so the user can
choose to apply it separately for sinks (where the problem is most
visible) and sources.
---
src/daemon/daemon-conf.c |6 ++
src/daemon/daemon-conf.h |2 ++
src/daemon/daemon.conf.in |2 ++
src/daemon/main.c |2 ++
src/modules/alsa/alsa-sink.c | 17 -
src/modules/alsa/alsa-source.c | 17 -
src/pulsecore/core.h |2 ++
7 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c
index c4ee544..5fb10a0 100644
--- a/src/daemon/daemon-conf.c
+++ b/src/daemon/daemon-conf.c
@@ -71,6 +71,8 @@ static const pa_daemon_conf default_conf = {
.disallow_module_loading = FALSE,
.disallow_exit = FALSE,
.flat_volumes = TRUE,
+.sink_use_base_volume = TRUE,
+.source_use_base_volume = TRUE,
.exit_idle_time = 20,
.scache_idle_time = 20,
.auto_log_target = 1,
@@ -535,6 +537,8 @@ int pa_daemon_conf_load(pa_daemon_conf *c, const char
*filename) {
{ "disable-shm",pa_config_parse_bool,
&c->disable_shm, NULL },
{ "enable-shm", pa_config_parse_not_bool,
&c->disable_shm, NULL },
{ "flat-volumes", pa_config_parse_bool,
&c->flat_volumes, NULL },
+{ "sink-use-base-volume", pa_config_parse_bool,
&c->sink_use_base_volume, NULL },
+{ "source-use-base-volume", pa_config_parse_bool,
&c->source_use_base_volume, NULL },
{ "lock-memory",pa_config_parse_bool,
&c->lock_memory, NULL },
{ "enable-sync-volume", pa_config_parse_bool,
&c->sync_volume, NULL },
{ "exit-idle-time", pa_config_parse_int,
&c->exit_idle_time, NULL },
@@ -736,6 +740,8 @@ char *pa_daemon_conf_dump(pa_daemon_conf *c) {
pa_strbuf_printf(s, "cpu-limit = %s\n", pa_yes_no(!c->no_cpu_limit));
pa_strbuf_printf(s, "enable-shm = %s\n", pa_yes_no(!c->disable_shm));
pa_strbuf_printf(s, "flat-volumes = %s\n", pa_yes_no(c->flat_volumes));
+pa_strbuf_printf(s, "sink-use-base-volume = %s\n",
pa_yes_no(c->sink_use_base_volume));
+pa_strbuf_printf(s, "source-use-base-volume = %s\n",
pa_yes_no(c->source_use_base_volume));
pa_strbuf_printf(s, "lock-memory = %s\n", pa_yes_no(c->lock_memory));
pa_strbuf_printf(s, "enable-sync-volume = %s\n",
pa_yes_no(c->sync_volume));
pa_strbuf_printf(s, "exit-idle-time = %i\n", c->exit_idle_time);
diff --git a/src/daemon/daemon-conf.h b/src/daemon/daemon-conf.h
index 9fd6aba..e1b7804 100644
--- a/src/daemon/daemon-conf.h
+++ b/src/daemon/daemon-conf.h
@@ -75,6 +75,8 @@ typedef struct pa_daemon_conf {
log_meta,
log_time,
flat_volumes,
+sink_use_base_volume,
+source_use_base_volume,
lock_memory,
sync_volume;
pa_server_type_t local_server_type;
diff --git a/src/daemon/daemon.conf.in b/src/daemon/daemon.conf.in
index 6437f8f..dd80cce 100644
--- a/src/daemon/daemon.conf.in
+++ b/src/daemon/daemon.conf.in
@@ -59,6 +59,8 @@ ifelse(@HAVE_DBUS@, 1, [dnl
; enable-lfe-remixing = no
; flat-volumes = yes
+;
Re: [pulseaudio-discuss] [PATCH] module-suspend-on-idle: Move vacuum code to core
'Twas brillig, and Maarten Bosmans at 08/09/11 14:12 did gyre and gimble: > pa_core_maybe_vacuum now vacuums if there are either no streams or all > devices are suspended. > The mempool_vacuum argument to module-suspend-on-idle is gone and defaults to > true now. Awesome. Looks good at first glance. Will take it for a spin tonight :) Now you can get back to the h/w vacuuming you've been avoiding :D 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] module-suspend-on-idle: Move vacuum code to core
pa_core_maybe_vacuum now vacuums if there are either no streams or all devices
are suspended.
The mempool_vacuum argument to module-suspend-on-idle is gone and defaults to
true now.
---
src/modules/module-suspend-on-idle.c | 43 ++---
src/pulsecore/core.c | 27
2 files changed, 24 insertions(+), 46 deletions(-)
diff --git a/src/modules/module-suspend-on-idle.c
b/src/modules/module-suspend-on-idle.c
index e724262..07d937c 100644
--- a/src/modules/module-suspend-on-idle.c
+++ b/src/modules/module-suspend-on-idle.c
@@ -40,13 +40,10 @@ 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= "
-"mempool_vacuum=");
+PA_MODULE_USAGE("timeout=");
static const char* const valid_modargs[] = {
"timeout",
-"mempool_vacuum",
NULL,
};
@@ -73,8 +70,6 @@ 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 {
@@ -85,29 +80,6 @@ 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;
@@ -118,15 +90,13 @@ 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);
+pa_core_maybe_vacuum(d->userdata->core);
}
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);
+pa_core_maybe_vacuum(d->userdata->core);
}
}
@@ -448,7 +418,6 @@ 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;
@@ -465,16 +434,10 @@ 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);
diff --git a/src/pulsecore/core.c b/src/pulsecore/core.c
index 0e53b9d..3822904 100644
--- a/src/pulsecore/core.c
+++ b/src/pulsecore/core.c
@@ -252,12 +252,27 @@ int pa_core_exit(pa_core *c, pa_bool_t force, int retval)
{
void pa_core_maybe_vacuum(pa_core *c) {
pa_assert(c);
-if (!pa_idxset_isempty(c->sink_inputs) ||
-!pa_idxset_isempty(c->source_outputs))
-return;
-
-pa_log_debug("Hmm, no streams around, trying to vacuum.");
-pa_mempool_vacuum(c->mempool);
+if (pa_idxset_isempty(c->sink_inputs) &&
pa_idxset_isempty(c->source_outputs)) {
+pa_log_debug("Hmm, no streams around, trying to vacuum.");
+pa_mempool_vacuum(c->mempool);
+} else {
+pa_sink *si;
+pa_source *so;
+uint32_t idx;
+
+idx = 0;
+PA_IDXSET_FOREACH(si, c->sinks, idx)
+if (pa_sink_get_state(si) != PA_SINK_SUSPENDED)
+return;
+
+idx = 0;
+PA_IDXSET_FOREACH(so, c->sources, idx)
+if (pa_source_get_state(so) != PA_SOURCE_SUSPENDED)
+return;
+
+pa
Re: [pulseaudio-discuss] Bluetooth Headset Problem
Hi, On Sat, Sep 3, 2011 at 5:16 PM, Colin Guthrie wrote: >> 4. Play a WAV with paplay: >> paplay -p -v /afc/Noise.wav >> >> Opening a playback stream with sample specification 's16be 1ch 48000Hz' >> and channel map 'mono'. >> >> Connection established.. >> >> Stream successfully created. >> >> Buffer metrics: maxlength=4194304, tlength=192000, prebuf=190082, >> minreq=1920 >> >> Using sample spec 's16be 1ch 48000Hz', channel map 'mono'. >> >> Connected to device bto (2, not suspended). >> >> Time: 0.000 sec; Latency: 1407895 usec. >> >> Time: 0.000 sec; Latency: 1407895 usec. >> >> Time: 0.000 sec; Latency: 1407895 usec. >> >> Got signal, exiting.ency: 1407895 usec. >> >> >> >> Debug from Pulseaudio: >> >> I: client.c: Created 3 "Native client (UNIX socket client)" >> >> D: protocol-native.c: Protocol version: remote 16, local 16 >> >> I: protocol-native.c: Got credentials: uid=0 gid=0 success=1 >> >> D: protocol-native.c: SHM possible: no >> >> D: protocol-native.c: Negotiated SHM: no >> >> I: resampler.c: Using resampler 'speex-float-3' >> >> I: resampler.c: Using float32be as working format. >> >> I: resampler.c: Choosing speex quality setting 3. >> >> D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0, >> base=2, prebuf=0, minreq=1 maxrewind=0 >> >> D: memblockq.c: memblockq sanitized: maxlength=33554432, >> tlength=33554432, base=2, prebuf=0, minreq=2 maxrewind=0 >> >> I: sink-input.c: Created input 3 "/afc/Noise.wav" on bto with sample >> spec s16be 1ch 48000Hz and channel map mono >> >> I: sink-input.c: media.format = "WAV (Microsoft)" >> >> I: sink-input.c: application.name = "paplay" >> >> I: sink-input.c: media.name = "/afc/Noise.wav" >> >> I: sink-input.c: native-protocol.peer = "UNIX socket client" >> >> I: sink-input.c: native-protocol..version = "16" >> >> I: sink-input.c: application.process.id = "4796" >> >> I: sink-input.c: application.process.user = "root" >> >> I: sink-input.c: application.process.host = "Viper" >> >> I: sink-input.c: application.process.binary = "pacat" >> >> I: sink-input.c: application.language = "C" >> >> I: sink-input.c: application.process.machine_id = >> "d63a8b34983dc07124730b7103f9" >> >> I: protocol-native.c: Requested tlength=2000.00 ms, minreq=20.00 ms >> >> D: protocol-native.c: Traditional mode enabled, modifying sink usec only >> for compat with minreq. >> >> D: memblockq.c: memblockq requested: maxlength=4194304, tlength=192000, >> base=2, prebuf=190082, minreq=1920 maxrewind=0 >> >> D: memblockq.c: memblockq sanitized: maxlength=4194304, tlength=192000, >> base=2, prebuf=190082, minreq=1920 maxrewind=0 >> >> I: protocol-native.c: Final latency 2128.00 ms = 1960.00 ms + 2*20.00 ms >> + 128.00 ms >> >> D: protocol-native.c: Requesting rewind due to end of underrun. >> >> D: core.c: Hmm, no streams around, trying to vacuum. >> >> I: sink-input.c: Freeing input 3 "/afc/Noise.wav" >> >> I: client.c: Freed 3 "paplay" >> >> I: protocol-native.c: Connection died. >> >> >> >> Debug from bluez: >> >> bluetoothd[4776]: audio/headset.c:headset_set_state() State changed >> /org/bluez/4776/hci0/dev_00_07_A4_EE_8F_03: HEADSET_STATE_DISCONNECTED >> -> HEADSET_STATE_CONNECTING >> >> bluetoothd[4776]: plugins/hciops.c:link_key_request() hci0 dba >> 00:07:A4:EE:8F:03 >> >> bluetoothd[4776]: plugins/hciops.c:get_auth_info() hci0 dba >> 00:07:A4:EE:8F:03 >> >> bluetoothd[4776]: plugins/hciops.c:link_key_request() kernel auth >> requirements = 0xff >> >> bluetoothd[4776]: plugins/hciops.c:link_key_request() Matching key found >> >> bluetoothd[4776]: plugins/hciops.c:link_key_request() link key type 0x00 >> >> bluetoothd[4776]: plugins/hciops.c:conn_complete() status 0x00 >> >> bluetoothd[4776]: src/adapter.c:adapter_get_device() 00:07:A4:EE:8F:03 >> >> bluetoothd[4776]: plugins/hciops.c:bonding_complete() status 0x00 >> >> bluetoothd[4776]: src/event.c:btd_event_bonding_complete() status 0x00 >> >> bluetoothd[4776]: src/adapter.c:adapter_get_device() 00:07:A4:EE:8F:03 >> >> bluetoothd[4776]: src/device.c:device_bonding_complete() bonding (nil) >> status 0x00 >> >> bluetoothd[4776]: plugins/hciops.c:remote_features_information() hci0 >> status 0 >> >> bluetoothd[4776]: audio/headset.c:headset_set_channel() Discovered >> Handsfree service on channel 2 >> >> bluetoothd[4776]: audio/headset.c:rfcomm_connect() >> /org/bluez/4776/hci0/dev_00_07_A4_EE_8F_03: Connecting to >> 00:07:A4:EE:8F:03 channel 2 >> >> bluetoothd[4776]: audio/headset.c:headset_connect_cb() >> /org/bluez/4776/hci0/dev_00_07_A4_EE_8F_03: Connected to 00:07:A4:EE:8F:03 >> >> bluetoothd[4776]: audio/headset.c:handle_event() Received AT+BRSF=26 >> >> bluetoothd[4776]: audio/headset.c:print_hf_features() HFP HF features: >> "Call waiting and 3-way calling" "Voice recognition activation" "Remote >> volume control" >> >> bluetoothd[4776]: audio/headset.c:handle_event() Received AT+CIND=? >> >> bluetoothd[4776]: audio/headset.c:handle_event() Received AT
Re: [pulseaudio-discuss] [PATCH v3 2/2] bluetooth: Do not unload module-bluetooth-device on ERR or HUP
Hi Frédéric, On Tue, Sep 6, 2011 at 4:48 PM, Dalleau, Frederic wrote: > Hi Luiz, > >>> An HandsfreeGateway connects RFCOMM and then SCO. A card appears in >>> PA and can be used. If for some reason, SCO is disconnected, >>> module-bluetooth-device is unloaded. The card will disappear, even >>> if RFCOMM is still connected. After that, it is not possible to >>> connect SCO again from PA. > >> IMO in such cases we should set the profile to "Off" to indicate the >> profile is not working properly, then the ui can either retry or >> switch to another profile e.g. A2DP. > > I'm having a look at this part, and it appears that the module is unloaded > from the IO thread. It is not possible to simply call pa_card_set_profile() > from this context. A workaround is to listen to "state" property changes > and change card profile to "Off" in the DBUS handler if state goes to > "Disconnected". This seems to work, but I'm wondering if there is > another solution. > Do you have any suggestions? Good point, I also wonder if there is any way to signal the main thread to switch the profile since the current one stopped working, waiting for a D-Bus signal may take too long so I would try to avoid this workaround. -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Blockers to 1.0
'Twas brillig, and Maarten Bosmans at 08/09/11 09:16 did gyre and gimble: > 2011/9/5 Tanu Kaskinen : >> On Mon, 2011-09-05 at 11:43 +0200, Colin Guthrie wrote: >>> * module-match should require pcre support, not be optional (i.e. it >>> should behave consistently, and not be build-time feature specific >>> (Tanu, you may have comments about this? Want to overrule this >>> recommendation?) >> >> No, I don't really have any opinions regarding this. I don't know why we >> support two regexp libraries. > > After talking with Colin about this on IRC, I now get this point. > > The thing is, the dependency on pcre was added to make regex > functionality available for win32. On all other platforms the posix > regex.h is available and that one is used. (even if pcre is available, > if I'm correct) > > So there is no inconsistent behaviour here, other than a difference > between Linux and Windows, where a regex difference is trivial > compared to other differences. Yup, completely ACK this one. Let's not make any changes here. 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Blockers to 1.0
2011/9/5 Tanu Kaskinen : > On Mon, 2011-09-05 at 11:43 +0200, Colin Guthrie wrote: >> * module-match should require pcre support, not be optional (i.e. it >> should behave consistently, and not be build-time feature specific >> (Tanu, you may have comments about this? Want to overrule this >> recommendation?) > > No, I don't really have any opinions regarding this. I don't know why we > support two regexp libraries. After talking with Colin about this on IRC, I now get this point. The thing is, the dependency on pcre was added to make regex functionality available for win32. On all other platforms the posix regex.h is available and that one is used. (even if pcre is available, if I'm correct) So there is no inconsistent behaviour here, other than a difference between Linux and Windows, where a regex difference is trivial compared to other differences. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
