Re: [pulseaudio-discuss] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.
On 10/19/2011 12:11 AM, Pierre-Louis Bossart wrote: Did you miss my previous explanation, or did you find it insufficient? I'm repeating it below: "The protocol skew in Ubuntu 11.10 was actually a mistake on my part. Since the UI changes that would depend on this information being available was backed out, I probably should have backed the actual protocol change out as well. Anyway, here is the patch that forms one of the base features for jack detection, and brings upstream out of protocol skew with Ubuntu 11.10." I honestly did not understand the explanation, most likely because I use Fedora for historical reasons and have no idea about the content of Ubuntu 11.10...What type of client will make use of this information? My use case is volume control UIs (pavucontrol, gnome volume control, etc) - they can use the information to hide three of the four HDMI ports, keeping only the right one. Or hide headphones when they are not plugged in. But in Ubuntu 11.10 no client actually uses this information, which is why the protocol skew was a mistake. -- 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
[pulseaudio-discuss] Pulse and audio settings
Hello, With the new version of pulse (1.0-4) I hoped that pulse will somehow take care of my alsa settings which still is not the case. All settings, for example set with alsamixer, are discarded after reboot. Now I wonder what's the best way to define some settings such as mic and PCM level with pulse when pavucontrol does not offer such possibilities? Regards, Robert ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.
> Did you miss my previous explanation, or did you find it insufficient? > I'm repeating it below: > > "The protocol skew in Ubuntu 11.10 was actually a mistake on my part. > Since the UI changes that would depend on this information being > available was backed out, I probably should have backed the actual > protocol change out as well. > > Anyway, here is the patch that forms one of the base features for jack > detection, and brings upstream out of protocol skew with Ubuntu 11.10." I honestly did not understand the explanation, most likely because I use Fedora for historical reasons and have no idea about the content of Ubuntu 11.10...What type of client will make use of this information? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.
On 10/18/2011 10:44 PM, Pierre-Louis Bossart wrote: Subject: [pulseaudio-discuss] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24. --- PROTOCOL| 10 configure.ac|2 +- src/modules/module-tunnel.c | 91 +-- src/pulse/def.h | 15 ++ src/pulse/introspect.c | 16 +++ src/pulse/introspect.h |2 + src/pulsecore/protocol-native.c |4 ++ src/pulsecore/sink.h|1 + 8 files changed, 88 insertions(+), 53 deletions(-) Bear with my late feedback, but how exactly is this used by clients?I only see the context information being changed? Or did you mean this information is provided mainly to configuration clients/user interfaces for port selection? Did you miss my previous explanation, or did you find it insufficient? I'm repeating it below: "The protocol skew in Ubuntu 11.10 was actually a mistake on my part. Since the UI changes that would depend on this information being available was backed out, I probably should have backed the actual protocol change out as well. Anyway, here is the patch that forms one of the base features for jack detection, and brings upstream out of protocol skew with Ubuntu 11.10." -- 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] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.
> Subject: [pulseaudio-discuss] [PATCH] Introduce "available" concept for > ports, and communicate that to clients. Bump protocol version to 24. > --- > PROTOCOL| 10 > configure.ac|2 +- > src/modules/module-tunnel.c | 91 +-- > > src/pulse/def.h | 15 ++ > src/pulse/introspect.c | 16 +++ > src/pulse/introspect.h |2 + > src/pulsecore/protocol-native.c |4 ++ > src/pulsecore/sink.h|1 + > 8 files changed, 88 insertions(+), 53 deletions(-) Bear with my late feedback, but how exactly is this used by clients? I only see the context information being changed? Or did you mean this information is provided mainly to configuration clients/user interfaces for port selection? Thanks -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.
Note: There is still no notification when status availability changes.
Signed-off-by: David Henningsson
---
PROTOCOL| 10
configure.ac|2 +-
src/modules/module-tunnel.c | 91 +--
src/pulse/def.h | 15 ++
src/pulse/introspect.c | 16 +++
src/pulse/introspect.h |2 +
src/pulsecore/protocol-native.c |4 ++
src/pulsecore/sink.h|1 +
8 files changed, 88 insertions(+), 53 deletions(-)
diff --git a/PROTOCOL b/PROTOCOL
index 8c69190..8b2f81f 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -278,6 +278,16 @@ New field in PA_COMMAND_UNDERFLOW:
int64_t index
+## v24, implemented by >= 2.0
+
+New field in all commands that send/receive port introspection data
+(PA_COMMAND_GET_(SOURCE|SINK)_OUTPUT_INFO,
+PA_COMMAND_GET_(SOURCE|SINK)_OUTPUT_INFO_LIST):
+
+uint32_t available
+
+The field is added once for every port.
+
If you just changed the protocol, read this
## module-tunnel depends on the sink/source/sink-input/source-input protocol
## internals, so if you changed these, you might have broken module-tunnel.
diff --git a/configure.ac b/configure.ac
index 0bf40a8..d57dbc5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,7 +36,7 @@ AC_SUBST(PA_MINOR, pa_minor)
AC_SUBST(PA_MAJORMINOR, pa_major.pa_minor)
AC_SUBST(PA_API_VERSION, 12)
-AC_SUBST(PA_PROTOCOL_VERSION, 23)
+AC_SUBST(PA_PROTOCOL_VERSION, 24)
# The stable ABI for client applications, for the version info x:y:z
# always will hold y=z
diff --git a/src/modules/module-tunnel.c b/src/modules/module-tunnel.c
index faee995..0422c87 100644
--- a/src/modules/module-tunnel.c
+++ b/src/modules/module-tunnel.c
@@ -996,6 +996,41 @@ fail:
pa_module_unload_request(u->module, TRUE);
}
+static pa_bool_t read_ports(struct userdata *u, pa_tagstruct *t)
+{
+if (u->version >= 16) {
+uint32_t n_ports;
+const char *s;
+
+if (pa_tagstruct_getu32(t, &n_ports)) {
+pa_log("Parse failure");
+return FALSE;
+}
+
+for (uint32_t j = 0; j < n_ports; j++) {
+uint32_t priority;
+
+if (pa_tagstruct_gets(t, &s) < 0 || /* name */
+pa_tagstruct_gets(t, &s) < 0 || /* description */
+pa_tagstruct_getu32(t, &priority) < 0) {
+
+pa_log("Parse failure");
+return FALSE;
+}
+if (u->version >= 24 && pa_tagstruct_getu32(t, &priority) < 0) {
/* available */
+pa_log("Parse failure");
+return FALSE;
+}
+}
+
+if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
+pa_log("Parse failure");
+return FALSE;
+}
+}
+return TRUE;
+}
+
#ifdef TUNNEL_SINK
/* Called from main context */
@@ -1066,32 +1101,8 @@ static void sink_info_cb(pa_pdispatch *pd, uint32_t
command, uint32_t tag, pa_t
}
}
-if (u->version >= 16) {
-uint32_t n_ports;
-const char *s;
-
-if (pa_tagstruct_getu32(t, &n_ports)) {
-pa_log("Parse failure");
-goto fail;
-}
-
-for (uint32_t j = 0; j < n_ports; j++) {
-uint32_t priority;
-
-if (pa_tagstruct_gets(t, &s) < 0 || /* name */
-pa_tagstruct_gets(t, &s) < 0 || /* description */
-pa_tagstruct_getu32(t, &priority) < 0) {
-
-pa_log("Parse failure");
-goto fail;
-}
-}
-
-if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
-pa_log("Parse failure");
-goto fail;
-}
-}
+if (!read_ports(u, t))
+goto fail;
if (u->version >= 21) {
uint8_t n_formats;
@@ -1318,32 +1329,8 @@ static void source_info_cb(pa_pdispatch *pd, uint32_t
command, uint32_t tag, pa
}
}
-if (u->version >= 16) {
-uint32_t n_ports;
-const char *s;
-
-if (pa_tagstruct_getu32(t, &n_ports)) {
-pa_log("Parse failure");
-goto fail;
-}
-
-for (uint32_t j = 0; j < n_ports; j++) {
-uint32_t priority;
-
-if (pa_tagstruct_gets(t, &s) < 0 || /* name */
-pa_tagstruct_gets(t, &s) < 0 || /* description */
-pa_tagstruct_getu32(t, &priority) < 0) {
-
-pa_log("Parse failure");
-goto fail;
-}
-}
-
-if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
-pa_log("Parse failure");
-goto fail;
-}
-}
+if (!read_ports(u, t))
+goto fail;
if (!pa_tagstruct_eof(t)) {
pa_log("Packet too long");
diff --git a/src/pulse/def.h b/src/pulse/def.h
index f43e864..8a74fad 100644
--- a/src/pulse/def.h
+++ b/src/pulse/def.h
@@ -967,6 +967,21 @@ typedef void (*pa_free_cb_t)(void *p);
* pla
Re: [pulseaudio-discuss] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.
On 10/18/2011 07:16 PM, Tanu Kaskinen wrote:
Hi,
Looks quite good to me. Some review comments below.
Thanks for the review.
On Wed, 2011-10-12 at 12:40 +0200, David Henningsson wrote:
Note: There is still no notification when status availability changes.
Signed-off-by: David Henningsson
---
The protocol skew in Ubuntu 11.10 was actually a mistake on my part. Since the
UI
changes that would depend on this information being available was backed out,
I probably should have backed the actual protocol change out as well.
Anyway, here is the patch that forms one of the base features for jack
detection,
and brings upstream out of protocol skew with Ubuntu 11.10.
(Reposted: Thanks courmisch for finding a typo.)
PROTOCOL|7 +++
configure.ac|2 +-
src/modules/module-tunnel.c | 91 +--
src/pulse/def.h | 15 ++
src/pulse/introspect.c | 16 +++
src/pulse/introspect.h |2 +
src/pulsecore/protocol-native.c |4 ++
src/pulsecore/sink.h|1 +
8 files changed, 85 insertions(+), 53 deletions(-)
diff --git a/PROTOCOL b/PROTOCOL
index 8c69190..b8b61e4 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -278,6 +278,13 @@ New field in PA_COMMAND_UNDERFLOW:
int64_t index
+## v24, implemented by>= 2.0
+
+New field in all commands that send/receive port introspection data
+(PA_COMMAND_GET_(SOURCE|SINK)_INFO, PA_COMMAND_GET_(SOURCE|SINK)_INFO_LIST]):
+
+uint32_t available
+
If you just changed the protocol, read this
## module-tunnel depends on the sink/source/sink-input/source-input protocol
## internals, so if you changed these, you might have broken module-tunnel.
diff --git a/configure.ac b/configure.ac
index 0bf40a8..d57dbc5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,7 +36,7 @@ AC_SUBST(PA_MINOR, pa_minor)
AC_SUBST(PA_MAJORMINOR, pa_major.pa_minor)
AC_SUBST(PA_API_VERSION, 12)
-AC_SUBST(PA_PROTOCOL_VERSION, 23)
+AC_SUBST(PA_PROTOCOL_VERSION, 24)
# The stable ABI for client applications, for the version info x:y:z
# always will hold y=z
diff --git a/src/modules/module-tunnel.c b/src/modules/module-tunnel.c
index faee995..0422c87 100644
--- a/src/modules/module-tunnel.c
+++ b/src/modules/module-tunnel.c
@@ -996,6 +996,41 @@ fail:
pa_module_unload_request(u->module, TRUE);
}
+static pa_bool_t read_ports(struct userdata *u, pa_tagstruct *t)
While in general I agree that a boolean is a fine success/failure return
type, I think in Pulseaudio the convention is to stick just to ints.
Hmm. A quick 'grep -r "return TRUE"' of PulseAudio source tree seems to
give enough results to falsify that assumption.
+{
+if (u->version>= 16) {
+uint32_t n_ports;
+const char *s;
+
+if (pa_tagstruct_getu32(t,&n_ports)) {
+pa_log("Parse failure");
I would prefer a bit more informative error message ("Parse failure
while reading the number of ports."). Oh, now I noticed that this is
just old code moving to a new place. Never mind...
+return FALSE;
+}
+
+for (uint32_t j = 0; j< n_ports; j++) {
+uint32_t priority;
+
+if (pa_tagstruct_gets(t,&s)< 0 || /* name */
+pa_tagstruct_gets(t,&s)< 0 || /* description */
+pa_tagstruct_getu32(t,&priority)< 0) {
+
+pa_log("Parse failure");
+return FALSE;
+}
+if (u->version>= 24&& pa_tagstruct_getu32(t,&priority)< 0) { /*
available */
+pa_log("Parse failure");
+return FALSE;
+}
+}
+
+if (pa_tagstruct_gets(t,&s)< 0) { /* active port */
+pa_log("Parse failure");
+return FALSE;
+}
+}
+return TRUE;
+}
+
#ifdef TUNNEL_SINK
/* Called from main context */
@@ -1066,32 +1101,8 @@ static void sink_info_cb(pa_pdispatch *pd, uint32_t
command, uint32_t tag, pa_t
}
}
-if (u->version>= 16) {
-uint32_t n_ports;
-const char *s;
-
-if (pa_tagstruct_getu32(t,&n_ports)) {
-pa_log("Parse failure");
-goto fail;
-}
-
-for (uint32_t j = 0; j< n_ports; j++) {
-uint32_t priority;
-
-if (pa_tagstruct_gets(t,&s)< 0 || /* name */
-pa_tagstruct_gets(t,&s)< 0 || /* description */
-pa_tagstruct_getu32(t,&priority)< 0) {
-
-pa_log("Parse failure");
-goto fail;
-}
-}
-
-if (pa_tagstruct_gets(t,&s)< 0) { /* active port */
-pa_log("Parse failure");
-goto fail;
-}
-}
+if (!read_ports(u, t))
+goto fail;
if (u->version>= 21) {
uint8_t n_formats;
@@ -1318,32 +1329,8 @@ static void source_info_cb(pa_pdispatch *pd, uint32_t
command, uint32_t tag, pa
}
}
-
Re: [pulseaudio-discuss] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.
Hi,
Looks quite good to me. Some review comments below.
On Wed, 2011-10-12 at 12:40 +0200, David Henningsson wrote:
> Note: There is still no notification when status availability changes.
>
> Signed-off-by: David Henningsson
> ---
>
> The protocol skew in Ubuntu 11.10 was actually a mistake on my part. Since
> the UI
> changes that would depend on this information being available was backed out,
> I probably should have backed the actual protocol change out as well.
>
> Anyway, here is the patch that forms one of the base features for jack
> detection,
> and brings upstream out of protocol skew with Ubuntu 11.10.
>
> (Reposted: Thanks courmisch for finding a typo.)
>
> PROTOCOL|7 +++
> configure.ac|2 +-
> src/modules/module-tunnel.c | 91
> +--
> src/pulse/def.h | 15 ++
> src/pulse/introspect.c | 16 +++
> src/pulse/introspect.h |2 +
> src/pulsecore/protocol-native.c |4 ++
> src/pulsecore/sink.h|1 +
> 8 files changed, 85 insertions(+), 53 deletions(-)
>
> diff --git a/PROTOCOL b/PROTOCOL
> index 8c69190..b8b61e4 100644
> --- a/PROTOCOL
> +++ b/PROTOCOL
> @@ -278,6 +278,13 @@ New field in PA_COMMAND_UNDERFLOW:
>
> int64_t index
>
> +## v24, implemented by >= 2.0
> +
> +New field in all commands that send/receive port introspection data
> +(PA_COMMAND_GET_(SOURCE|SINK)_INFO, PA_COMMAND_GET_(SOURCE|SINK)_INFO_LIST]):
> +
> +uint32_t available
> +
> If you just changed the protocol, read this
> ## module-tunnel depends on the sink/source/sink-input/source-input protocol
> ## internals, so if you changed these, you might have broken module-tunnel.
> diff --git a/configure.ac b/configure.ac
> index 0bf40a8..d57dbc5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -36,7 +36,7 @@ AC_SUBST(PA_MINOR, pa_minor)
> AC_SUBST(PA_MAJORMINOR, pa_major.pa_minor)
>
> AC_SUBST(PA_API_VERSION, 12)
> -AC_SUBST(PA_PROTOCOL_VERSION, 23)
> +AC_SUBST(PA_PROTOCOL_VERSION, 24)
>
> # The stable ABI for client applications, for the version info x:y:z
> # always will hold y=z
> diff --git a/src/modules/module-tunnel.c b/src/modules/module-tunnel.c
> index faee995..0422c87 100644
> --- a/src/modules/module-tunnel.c
> +++ b/src/modules/module-tunnel.c
> @@ -996,6 +996,41 @@ fail:
> pa_module_unload_request(u->module, TRUE);
> }
>
> +static pa_bool_t read_ports(struct userdata *u, pa_tagstruct *t)
While in general I agree that a boolean is a fine success/failure return
type, I think in Pulseaudio the convention is to stick just to ints.
> +{
> +if (u->version >= 16) {
> +uint32_t n_ports;
> +const char *s;
> +
> +if (pa_tagstruct_getu32(t, &n_ports)) {
> +pa_log("Parse failure");
I would prefer a bit more informative error message ("Parse failure
while reading the number of ports."). Oh, now I noticed that this is
just old code moving to a new place. Never mind...
> +return FALSE;
> +}
> +
> +for (uint32_t j = 0; j < n_ports; j++) {
> +uint32_t priority;
> +
> +if (pa_tagstruct_gets(t, &s) < 0 || /* name */
> +pa_tagstruct_gets(t, &s) < 0 || /* description */
> +pa_tagstruct_getu32(t, &priority) < 0) {
> +
> +pa_log("Parse failure");
> +return FALSE;
> +}
> +if (u->version >= 24 && pa_tagstruct_getu32(t, &priority) < 0) {
> /* available */
> +pa_log("Parse failure");
> +return FALSE;
> +}
> +}
> +
> +if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
> +pa_log("Parse failure");
> +return FALSE;
> +}
> +}
> +return TRUE;
> +}
> +
> #ifdef TUNNEL_SINK
>
> /* Called from main context */
> @@ -1066,32 +1101,8 @@ static void sink_info_cb(pa_pdispatch *pd, uint32_t
> command, uint32_t tag, pa_t
> }
> }
>
> -if (u->version >= 16) {
> -uint32_t n_ports;
> -const char *s;
> -
> -if (pa_tagstruct_getu32(t, &n_ports)) {
> -pa_log("Parse failure");
> -goto fail;
> -}
> -
> -for (uint32_t j = 0; j < n_ports; j++) {
> -uint32_t priority;
> -
> -if (pa_tagstruct_gets(t, &s) < 0 || /* name */
> -pa_tagstruct_gets(t, &s) < 0 || /* description */
> -pa_tagstruct_getu32(t, &priority) < 0) {
> -
> -pa_log("Parse failure");
> -goto fail;
> -}
> -}
> -
> -if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
> -pa_log("Parse failure");
> -goto fail;
> -}
> -}
> +if (!read_ports(u, t))
> +goto fail;
>
> if (u->version >= 21) {
> uint8_t n_formats;
> @@ -1318,32 +1329,8 @@ static void source_i
Re: [pulseaudio-discuss] Alternate sample rates
> Very Cool feature! Why not change sample_spec totally according to > sink's availability, but only sample rate? The default sample_spec > used at initialization, if alsa driver supports various formats/rates, > PA could change sink's sample_spec in order to fit sink-input's > request. Is there any risk or my misunderstanding ? These patches do not always use the rate of the client. This only happens when there's a exact match. In case of a difference between the client rate and the sink rates, SRC will be used. These set of patches are mostly intended to make SRC easier (integer ratios) or unnecessary. One of the main goals was for example that voice calls would be resampled to 48kHz instead of 44.1kHz, since a 3x or 6x resampling takes less resources. But to your point we've discussed with Arun of dynamically updating the number of channels supported for HDMI outputs. When the EDID/ELD is read, we could use the information to automatically make the output multichannel, and possibly set a higher sampling rate. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] core: New hook: PA_CORE_HOOK_CARD_PROFILE_ABOUT_TO_ACTIVATE.
The hook users probably want access to the card object as well,
so a pa_card pointer was added to pa_card_profile.
---
src/pulsecore/card.c | 17 +
src/pulsecore/card.h |6 ++
src/pulsecore/core.h |1 +
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/pulsecore/card.c b/src/pulsecore/card.c
index feaa444..b9e2988 100644
--- a/src/pulsecore/card.c
+++ b/src/pulsecore/card.c
@@ -43,6 +43,7 @@ pa_card_profile *pa_card_profile_new(const char *name, const
char *description,
pa_assert(name);
c = pa_xmalloc(PA_ALIGN(sizeof(pa_card_profile)) + extra);
+c->card = NULL;
c->name = pa_xstrdup(name);
c->description = pa_xstrdup(description);
@@ -55,6 +56,7 @@ pa_card_profile *pa_card_profile_new(const char *name, const
char *description,
void pa_card_profile_free(pa_card_profile *c) {
pa_assert(c);
+pa_assert(!c->card); /* Make sure nobody frees a profile while it's still
in use. */
pa_xfree(c->name);
pa_xfree(c->description);
@@ -106,6 +108,8 @@ void pa_card_new_data_done(pa_card_new_data *data) {
pa_card *pa_card_new(pa_core *core, pa_card_new_data *data) {
pa_card *c;
const char *name;
+void *state;
+pa_card_profile *p;
pa_core_assert_ref(core);
pa_assert(data);
@@ -140,6 +144,11 @@ pa_card *pa_card_new(pa_core *core, pa_card_new_data
*data) {
c->profiles = data->profiles;
data->profiles = NULL;
+if (c->profiles) {
+PA_HASHMAP_FOREACH(p, c->profiles, state)
+p->card = c;
+}
+
c->active_profile = NULL;
c->save_profile = FALSE;
@@ -148,9 +157,6 @@ pa_card *pa_card_new(pa_core *core, pa_card_new_data *data)
{
c->save_profile = data->save_profile;
if (!c->active_profile && c->profiles) {
-void *state;
-pa_card_profile *p;
-
PA_HASHMAP_FOREACH(p, c->profiles, state)
if (!c->active_profile || p->priority >
c->active_profile->priority)
c->active_profile = p;
@@ -198,8 +204,10 @@ void pa_card_free(pa_card *c) {
if (c->profiles) {
pa_card_profile *p;
-while ((p = pa_hashmap_steal_first(c->profiles)))
+while ((p = pa_hashmap_steal_first(c->profiles))) {
+p->card = NULL;
pa_card_profile_free(p);
+}
pa_hashmap_free(c->profiles, NULL, NULL);
}
@@ -231,6 +239,7 @@ int pa_card_set_profile(pa_card *c, const char *name,
pa_bool_t save) {
return 0;
}
+pa_hook_fire(&c->core->hooks[PA_CORE_HOOK_CARD_PROFILE_ABOUT_TO_ACTIVATE],
profile);
if ((r = c->set_profile(c, profile)) < 0)
return r;
diff --git a/src/pulsecore/card.h b/src/pulsecore/card.h
index 2d691b6..8dca0e4 100644
--- a/src/pulsecore/card.h
+++ b/src/pulsecore/card.h
@@ -30,6 +30,12 @@ typedef struct pa_card pa_card;
#include
typedef struct pa_card_profile {
+/* This pointer is set when this pa_card_profile instance is in the
+ * profiles hashmap of pa_card. At other times this is NULL. Managing
+ * this pointer is the responsibility of whoever manages the
+ * pa_card.profiles hashmap. */
+pa_card *card;
+
char *name;
char *description;
diff --git a/src/pulsecore/core.h b/src/pulsecore/core.h
index d0641cf..dbd0c6f 100644
--- a/src/pulsecore/core.h
+++ b/src/pulsecore/core.h
@@ -113,6 +113,7 @@ typedef enum pa_core_hook {
PA_CORE_HOOK_CARD_PUT,
PA_CORE_HOOK_CARD_UNLINK,
PA_CORE_HOOK_CARD_PROFILE_CHANGED,
+PA_CORE_HOOK_CARD_PROFILE_ABOUT_TO_ACTIVATE,
PA_CORE_HOOK_MAX
} pa_core_hook_t;
--
1.7.6.3
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Bluetooth Audio Handling IRC Meeting
Hi Everyone, [Sorry for cross posting but it might be interesting for someone on these mailing lists] I would like to invite to a IRC discussion on the HFP audio handling. Topic is to find a solution for the handling/routing of the audio streams (SCO link) in BlueZ, PulseAudio and oFono. - Currently, it is not possible for PulseAudio or BlueZ to know what the audio stream is carrying (*). This information is need for multi phone uses cases. Think about two connected phones at the same time and both are doing HFP. - If there is need for policy decisions, is desirable to have this done in one place only. With policy decision is meant deciding when to suspend and resume a SCO link. Of course we would have to agree first, if this should be done in placed into one component only. - For the two phone use cases I also like to discuss how to report the 'content' (*) of the audio links, so the above policies can be implemented. oFono doesn't export this information and I assume we really don't want to have a dependency on PulseAudio from oFono. (*) in band ringing, active call, held call, etc. irc server: freenode.net irc channel: #bop_audio date: 20.10.2011 (10/20/11 for the americans) time: 16:00 CEST (07:00 PDT, 09:00 CDT, 17:00 EEST) duration: < 1 hour (hopefully) If the date/time is really bad for you (sorry Marcel), please let me know. Johan told me he could also attend it if we start one hour later. cheers, daniel ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
On 10/18/2011 04:06 PM, Rémi Denis-Courmont wrote: Le mardi 18 octobre 2011 16:35:59 David Henningsson, vous avez écrit : Btw, as for recording microphone, that does seem adequate to me, e g if somebody records things like "Now look what happens when I press this button". Fair enough, but a PulseAudio client cannot cleanly ask PulseAudio to mix a microphone and a monitor, or can it? Hmm...not "cleanly", I think. I think that would require some loading of module-combine, -loopback or -null stuff, but other people here would know that stuff better than I. -- 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] Screen casting with PulseAudio
Le mardi 18 octobre 2011 16:35:59 David Henningsson, vous avez écrit : > Btw, as for recording microphone, that does seem adequate to me, e g if > somebody records things like "Now look what happens when I press this > button". Fair enough, but a PulseAudio client cannot cleanly ask PulseAudio to mix a microphone and a monitor, or can it? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
Dnia 2011-10-18, wto o godzinie 15:31 +0200, Rémi Denis-Courmont pisze: > > Not true. If you select the fallback recording stream before you start > > recording, that's what VLC will get as the source. Also, if you select a > > source for VLC, it will "stick" thanks to module-*-restore, so after > > setting it once, you'll get that until you change it again. Or other > > things happen, like external headsets connected and stuff. There was a > > lengthy post about routing (and its future) from Colin Guthrie, but I > > can't find it now... Interwebs, help, please? > > Restoring assumes that one application always want the same source/sink. > If the application has only one profile, that's just fine. > > Precisely my problem is, VLC captures different things. And there is no > application other than VLC itself to take care of them: > * camera (V4L2): > Audio should come from the microphone unless otherwise stated. > * screen (X11): > Audio should come from the monitor of the default-or-whatever sink > unless otherwise stated. > * analog TV (V4L2 with frequency tuning): > Audio _must_ come from the ALSA card matching the V4L2 device node. > * digital TV (DVB): > Audio is (de)muxed. > > While restoring makes sense for each of the first two profile, it does not > make much sense (IMHO) across them. And the audio input of the ATV profile > should definitely not be saved, then restored in the camera or screen > profile. So the only real case is ATV, since DVB doesn't go through PA. And that's a special case that needs to be taken care of differently. But the user won't have to select anything here. > It all depends on whether the application has/needs a dialog. If it anyway > needs a dialog to setup the capture, be it select the video source, define > the encoding parameters or the destination, then relying on a separate > dialog in another application just for audio input is backward. > > I would actually like to avoid selecting the audio input. But that's why > I'm trying to find a way to select the correct one, with regards to the > selected capture type. I really don't care if the logic has to be in > PulseAudio or in VLC. But it does not seem that PulseAudio has enough at > this point :( Yup, a selector for media roles (or even better - automagically selecting what makes most sense) would be my preference, too. > > So what's preventing you from listing all possible input sources in VLC? > > That's doable, but it is probably not as seamless as could be. It gets > worse if PulseAudio remembers the selection and restores it for some > unrelated purpose next time. > > FWIW for plain audio capture, user can choose the input or let PA decide > already. I don't think with that we can get anything better, the user might want to record from any source available and no role selection will help. > > Show me one modern media player that has output devices choice list. Or > > video conferencing, where it would make even more sense (hint: neither > > Skype nor Empathy allow you to select sinks/sources). Volume control in > > e.g. banshee is just a proxy to PA. > > So? Volume control and output device selection in VLC 1.2 is just a proxy > to PA too. It still is useful. Like if I'm watching a video fullscreen, I'd > much rather adjust the volume on the VLC fullscreen controller than go back > to windowed mode and open KMix. Especially if my keyboard lacks multimedia > keys. I agree that a music player needs a volume slider, but a device selector - no. > Similarly, if the user has multiple audio outputs, say stereo and > surround, (s)he might want to change them. I admit I don't use this feature > myself, but there is ample evidence that a number of our users do, be they > based on PulseAudio or not. Not a device selector again. You should be able to select between some of stereo / (analog) surround / digital / passthrough, but not the device you want to use. > > Another thing I could imagine is a media role (are those even > > implemented for sources?) of "desktop-recorder" or similar, that will > > choose the monitor of the active sink for you. That's as far as I'd go, > > TBH, to handling this case. > > Yeah that would be good. But I reckon it's not there (yet) which is why > I'm asking what's the correct path. It seems the only solution is to list > all inputs then :/ (or extend PulseAudio but my free time is not > extensible.) Depends on what you want to spend your time on. Cheers, -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
Dnia 2011-10-18, wto o godzinie 14:22 +0200, Rémi Denis-Courmont pisze: > So where in pavucontrol do I select the VIDEO source? Duh? As stated in my previous email - there isn't a video mixer. Yet. > > Even Skype does that now. > > The drop-downs in Skype's sound preferences only contain "Pulseaudio" > > here. > > Skype is a voice call and videoconferencing tool. Using the default > PulseAudio source makes perfect sense there. First time, it will get the > default microphone. Next time, it will get the source that it had the > previous time if available. All is good for Skype. Nope, it doesn't work like that. Every time it will get the source that is most suitable for a VoIP app. Be it the only microphone, a USB headset, BT headset or whatever makes most sense. Not until you manually set a different source will PA restore the selected source for Skype. Or, actually, for all VoIP apps, in that case. > If the user selects desktop recording, this does not work. So the consensus seems to be that the best solution would be a new 'screencasting' media role, as both me and David pointed out in other posts. That should, IMO, as David wrote, include default microphone, too. You could mute it, of course, but I don't think a separate 'screencasting+mic' role would make sense. Turn that into a feature request on PA trac, please, would you? Cheers, -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
On 10/18/2011 12:26 PM, Rémi Denis-Courmont wrote: Hello, One regularly requested feature addition for VLC media player is the ability to record desktop audio in sync with screen capture. This is theoretically feasible with a PulseAudio sink monitor source. But but, I am a it puzzled as how to record the correct source. In this case, the default source is obviously inadequate, as it would typically be the microphone. In particular, what to do if there are more than one sink, and thus more than one monitor?? Hmm. For your use case, it looks like we might need a new "media role" in PulseAudio for screencast recording, which would default to "the default sink's monitor", but that the user can change. Btw, as for recording microphone, that does seem adequate to me, e g if somebody records things like "Now look what happens when I press this button". -- 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] Screen casting with PulseAudio
On Tue, 18 Oct 2011 15:05:31 +0200, Michał Sawicz wrote: >> The "volume control" tool would have two problems: >> - It only works after the record stream is started, so that the source >> output exists. For recording purpose, you'd want to select the source >> before you start the recording. > Not true. If you select the fallback recording stream before you start > recording, that's what VLC will get as the source. Also, if you select a > source for VLC, it will "stick" thanks to module-*-restore, so after > setting it once, you'll get that until you change it again. Or other > things happen, like external headsets connected and stuff. There was a > lengthy post about routing (and its future) from Colin Guthrie, but I > can't find it now... Interwebs, help, please? Restoring assumes that one application always want the same source/sink. If the application has only one profile, that's just fine. Precisely my problem is, VLC captures different things. And there is no application other than VLC itself to take care of them: * camera (V4L2): Audio should come from the microphone unless otherwise stated. * screen (X11): Audio should come from the monitor of the default-or-whatever sink unless otherwise stated. * analog TV (V4L2 with frequency tuning): Audio _must_ come from the ALSA card matching the V4L2 device node. * digital TV (DVB): Audio is (de)muxed. While restoring makes sense for each of the first two profile, it does not make much sense (IMHO) across them. And the audio input of the ATV profile should definitely not be saved, then restored in the camera or screen profile. >> - It has poor usability. The user would have to configure the >> application, >> including all parameters except the audio source and amplification. For >> those, it would have to open a separate application. > Depends on the definition of usability. Having different dialogs in > every single application dealing with audio source selection might be > poor usability to some. It all depends on whether the application has/needs a dialog. If it anyway needs a dialog to setup the capture, be it select the video source, define the encoding parameters or the destination, then relying on a separate dialog in another application just for audio input is backward. I would actually like to avoid selecting the audio input. But that's why I'm trying to find a way to select the correct one, with regards to the selected capture type. I really don't care if the logic has to be in PulseAudio or in VLC. But it does not seem that PulseAudio has enough at this point :( >> So I think it's fair for recording/streaming applications to act as their >> own "volume control tool". Of course, they should play good citizens with >> the other volume control tool(s) in the system, and in particular not >> actively fight changes initiated by the PulseAudio daemon or another >> PulseAudio client. > So what's preventing you from listing all possible input sources in VLC? That's doable, but it is probably not as seamless as could be. It gets worse if PulseAudio remembers the selection and restores it for some unrelated purpose next time. FWIW for plain audio capture, user can choose the input or let PA decide already. >> And in fact, the same applies partly to output (playback/streaming). Any >> reasonable media player has a volume control, and possibly a balance and >> an >> output devices choice list. So long as it lets PulseAudio set the initial >> values and does not prevent other tools from moving or tuning the sink >> input, I must say I don't see a problem. > Show me one modern media player that has output devices choice list. Or > video conferencing, where it would make even more sense (hint: neither > Skype nor Empathy allow you to select sinks/sources). Volume control in > e.g. banshee is just a proxy to PA. So? Volume control and output device selection in VLC 1.2 is just a proxy to PA too. It still is useful. Like if I'm watching a video fullscreen, I'd much rather adjust the volume on the VLC fullscreen controller than go back to windowed mode and open KMix. Especially if my keyboard lacks multimedia keys. Similarly, if the user has multiple audio outputs, say stereo and surround, (s)he might want to change them. I admit I don't use this feature myself, but there is ample evidence that a number of our users do, be they based on PulseAudio or not. > That's just how it was designed, and on purpose. I can imagine a common > (just as printing is now - you generally > always should get a printing dialog you know well) dialog for advanced > applications to choose sinks and sources for a particular app / role on > demand. But I'm not sure that's necessary and I haven't seen anyone step > up and write it. > > Another thing I could imagine is a media role (are those even > implemented for sources?) of "desktop-recorder" or similar, that will > choose the monitor of the active sink for you. That's as far as I'd go, > TBH, to handling this c
Re: [pulseaudio-discuss] Screen casting with PulseAudio
Dnia 2011-10-18, wto o godzinie 14:19 +0200, Rémi Denis-Courmont pisze: --8<-- > Video applications need to provide a choice of video sources (webcams, > desktop capture...). For this, there is no video mixer applications. In > terms of usability, I would expect to choose the audio source at the same > time as the video source. As you said - there is no video mixer application. Yet. > The "volume control" tool would have two problems: > - It only works after the record stream is started, so that the source > output exists. For recording purpose, you'd want to select the source > before you start the recording. Not true. If you select the fallback recording stream before you start recording, that's what VLC will get as the source. Also, if you select a source for VLC, it will "stick" thanks to module-*-restore, so after setting it once, you'll get that until you change it again. Or other things happen, like external headsets connected and stuff. There was a lengthy post about routing (and its future) from Colin Guthrie, but I can't find it now... Interwebs, help, please? > - It has poor usability. The user would have to configure the application, > including all parameters except the audio source and amplification. For > those, it would have to open a separate application. Depends on the definition of usability. Having different dialogs in every single application dealing with audio source selection might be poor usability to some. > So I think it's fair for recording/streaming applications to act as their > own "volume control tool". Of course, they should play good citizens with > the other volume control tool(s) in the system, and in particular not > actively fight changes initiated by the PulseAudio daemon or another > PulseAudio client. So what's preventing you from listing all possible input sources in VLC? > And in fact, the same applies partly to output (playback/streaming). Any > reasonable media player has a volume control, and possibly a balance and an > output devices choice list. So long as it lets PulseAudio set the initial > values and does not prevent other tools from moving or tuning the sink > input, I must say I don't see a problem. Show me one modern media player that has output devices choice list. Or video conferencing, where it would make even more sense (hint: neither Skype nor Empathy allow you to select sinks/sources). Volume control in e.g. banshee is just a proxy to PA. That's just how it was designed, and on purpose. I can imagine a common (just as printing is now - you generally always should get a printing dialog you know well) dialog for advanced applications to choose sinks and sources for a particular app / role on demand. But I'm not sure that's necessary and I haven't seen anyone step up and write it. Another thing I could imagine is a media role (are those even implemented for sources?) of "desktop-recorder" or similar, that will choose the monitor of the active sink for you. That's as far as I'd go, TBH, to handling this case. Cheers, -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
On Tue, 18 Oct 2011 14:15:13 +0200, Michał Sawicz wrote: > Dnia 2011-10-18, wto o godzinie 14:03 +0200, Rémi Denis-Courmont pisze: >> If the user has selected "I want to record (or stream) my desktop", >> how does the application get hold of the desktop audio? In other words >> how should it select "a" sink monitor source? > "It" as in "the application" should not, at all. Oh really? > The user should select > that monitor in his volume-control of choice. So where in pavucontrol do I select the VIDEO source? Duh? > Even Skype does that now. > The drop-downs in Skype's sound preferences only contain "Pulseaudio" > here. Skype is a voice call and videoconferencing tool. Using the default PulseAudio source makes perfect sense there. First time, it will get the default microphone. Next time, it will get the source that it had the previous time if available. All is good for Skype. If the user selects desktop recording, this does not work. -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
On Tue, 18 Oct 2011 13:38:39 +0200, Michał Sawicz wrote: > Dnia 2011-10-18, wto o godzinie 13:33 +0200, Rémi Denis-Courmont pisze: >> Eh? The user doing the recording typically wants to hear the sound >> while recording. So I don't see what null sink has to do here. > As long as you only want to record your speakers, then just record the > monitor of the output sink. The null / loopbacks can help if you want to > record microphone, too. > >> > Obviously that's not relevant to VLC itself, it's through >> > pactl/pacmd (sorry) and pavucontrol that you need to select the >> > appropriate recording source. >> >> So that's not an answer to the problem. > Yes it is. VLC isn't the place to choose recording inputs. Volume > control tools are the place to do so. That's a different topic. But while this looks like a popular conception among PulseAudio developers, I have to partly disagree. Video applications need to provide a choice of video sources (webcams, desktop capture...). For this, there is no video mixer applications. In terms of usability, I would expect to choose the audio source at the same time as the video source. The "volume control" tool would have two problems: - It only works after the record stream is started, so that the source output exists. For recording purpose, you'd want to select the source before you start the recording. - It has poor usability. The user would have to configure the application, including all parameters except the audio source and amplification. For those, it would have to open a separate application. So I think it's fair for recording/streaming applications to act as their own "volume control tool". Of course, they should play good citizens with the other volume control tool(s) in the system, and in particular not actively fight changes initiated by the PulseAudio daemon or another PulseAudio client. And in fact, the same applies partly to output (playback/streaming). Any reasonable media player has a volume control, and possibly a balance and an output devices choice list. So long as it lets PulseAudio set the initial values and does not prevent other tools from moving or tuning the sink input, I must say I don't see a problem. -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
Dnia 2011-10-18, wto o godzinie 14:03 +0200, Rémi Denis-Courmont pisze: > If the user has selected "I want to record (or stream) my desktop", > how does the application get hold of the desktop audio? In other words > how should it select "a" sink monitor source? "It" as in "the application" should not, at all. The user should select that monitor in his volume-control of choice. Even Skype does that now. The drop-downs in Skype's sound preferences only contain "Pulseaudio" here. -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
On Tue, 18 Oct 2011 13:38:39 +0200, Michał Sawicz wrote: > Dnia 2011-10-18, wto o godzinie 13:33 +0200, Rémi Denis-Courmont pisze: >> Eh? The user doing the recording typically wants to hear the sound >> while recording. So I don't see what null sink has to do here. > As long as you only want to record your speakers, then just record the > monitor of the output sink. The null / loopbacks can help if you want to > record microphone, too. > >> > Obviously that's not relevant to VLC itself, it's through >> > pactl/pacmd (sorry) and pavucontrol that you need to select the >> > appropriate recording source. >> >> So that's not an answer to the problem. > Yes it is. VLC isn't the place to choose recording inputs. Volume > control tools are the place to do so. > Can you describe your complete usecase? 'Cause I fail to see the actual > issue at hand. If the user has selected "I want to record (or stream) my desktop", how does the application get hold of the desktop audio? In other words how should it select "a" sink monitor source? -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] New hook for card profile changes
Hi, I'm writing a new module that needs to run some code before the profiles of a certain alsa card are activated. For this I need a new hook in the core: PA_CORE_HOOK_CARD_PROFILE_ABOUT_TO_ACTIVATE or something like that. Will such hook be accepted in upstream even if the module is not merged in upstream? If yes, I'll post a patch for it soon. Ideas for a better name for the hook are most welcome. I believe that the new module will also be suitable for inclusion in upstream, but I'm not the one who will decide that. The module is specific to the WL1273 chip from Texas Instruments. The chip implements both bluetooth and fm radio functionality. Changing the audio routing between BT, FM rx and FM tx within the chip is a bit tricky. The in-chip audio routing is controlled with special HCI commands. Currently the kernel doesn't provide any nice interface for that - the commands need to be sent from userspace. It may be that the kernel will provide a sysfs interface for replacing the direct HCI commands, but that remains to be seen. Even nicer alternative would be if the audio routing could be controlled through the alsa mixer interface, but that seems unlikely to happen. Unless the alsa mixer solution materializes, our plan is that BlueZ will provide a special D-Bus interface for controlling the chip state, and Pulseaudio will call that interface whenever the WL1273 alsa card changes its profile. The card will have four profiles: "off", "bluetooth", "fmrx" and "fmrx", so those map nicely to the routing options in the chip. Those BlueZ calls will be made by this new module. So that's the background - at this point I'm mainly just asking about the new hook. (Of course, comments regarding other stuff are welcome too.) -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation
2011/10/18 Tanu Kaskinen : > On Tue, 2011-10-18 at 14:49 +0300, Wang Xingchao wrote: >> Tanu, i've not done much performance test, do you have some tools for >> svolume test? All suggestions are appreciated. > > No, I don't know any particular tools. I was asking just because I don't > think the patches can be merged before there is some proof that they are > actually helpful (I believe that it's not uncommon for optimization > efforts to not actually help as much as expected). > > -- > Tanu > > yeah, that's true, thanks. --xingchao ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation
On Tue, 2011-10-18 at 14:49 +0300, Wang Xingchao wrote: > Tanu, i've not done much performance test, do you have some tools for > svolume test? All suggestions are appreciated. No, I don't know any particular tools. I was asking just because I don't think the patches can be merged before there is some proof that they are actually helpful (I believe that it's not uncommon for optimization efforts to not actually help as much as expected). -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation
2011/10/18 Maarten Bosmans : >> 2011/10/18 Wang Xingchao : >>> if all channels have same volume setting, use fast way to >>> do volume change. this patch intended to work for two formats: >>> s16ne/s16re. > > I did some work to optimize svolume already, see my branch on github: > https://github.com/mkbosmans/pulseaudio/compare/master...orcify > > After a few pending patches that I have already sent to the list are > pulled, I plan to submit this branch in parts. (the branch needs to be > rebased after the pending patches are committed) > > For testing correctness of your volume implementation (and > performance, as Tanu suggested) you can use the svolume-test program > added in this commit: > https://github.com/mkbosmans/pulseaudio/commit/cf0c5c9ad47ba0434b0518ca79ca802d0e62153a > > The Orc svolume implementation currently only handles 1ch s16ne (the > orcify branch also adds 1ch float), so I added a similar test for > identical channel volumes for the Orc case: > https://github.com/mkbosmans/pulseaudio/commit/8659d08f22ccaba0c1ca18c0b29744318bf4fe08 > I like that way (only using one extra variable) a bit better than > yours (with both same_vol and fast_vol added), but that is not really > important. > > hi Maarten, Oh, glad to know you have done similar work, i will first refer to that and provide performance benchmark later. Tanu, i've not done much performance test, do you have some tools for svolume test? All suggestions are appreciated. --xingchao ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
Dnia 2011-10-18, wto o godzinie 13:33 +0200, Rémi Denis-Courmont pisze: > Eh? The user doing the recording typically wants to hear the sound > while recording. So I don't see what null sink has to do here. As long as you only want to record your speakers, then just record the monitor of the output sink. The null / loopbacks can help if you want to record microphone, too. > > Obviously that's not relevant to VLC itself, it's through > > pactl/pacmd (sorry) and pavucontrol that you need to select the > > appropriate recording source. > > So that's not an answer to the problem. Yes it is. VLC isn't the place to choose recording inputs. Volume control tools are the place to do so. Can you describe your complete usecase? 'Cause I fail to see the actual issue at hand. Regards, -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
On Tue, 18 Oct 2011 12:55:13 +0200, Michał Sawicz wrote: > Dnia 2011-10-18, wto o godzinie 12:26 +0200, Rémi Denis-Courmont pisze: >> One regularly requested feature addition for VLC media player is the >> ability to record desktop audio in sync with screen capture. >> This is theoretically feasible with a PulseAudio sink monitor source. >> But but, I am a it puzzled as how to record the correct source. In >> this case, the default source is obviously inadequate, as it would >> typically be the microphone. In particular, what to do if there are >> more than one sink, and thus more than one monitor?? > > See http://www.pulseaudio.org/wiki/Modules and read about > module-null-sink and module-loopback. You can obviously only record from > one source (for screencasting - probably a monitor), but you can also > loop back any number of sources to the sink whose monitor you're > recording. That can be a null sink, too, so that you don't get feedback > through your speakers. Eh? The user doing the recording typically wants to hear the sound while recording. So I don't see what null sink has to do here. > Obviously that's not relevant to VLC itself, it's through pactl/pacmd > (sorry) and pavucontrol that you need to select the appropriate > recording source. So that's not an answer to the problem. -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
Dnia 2011-10-18, wto o godzinie 12:26 +0200, Rémi Denis-Courmont pisze: > One regularly requested feature addition for VLC media player is the > ability to record desktop audio in sync with screen capture. > This is theoretically feasible with a PulseAudio sink monitor source. > But but, I am a it puzzled as how to record the correct source. In > this case, the default source is obviously inadequate, as it would > typically be the microphone. In particular, what to do if there are > more than one sink, and thus more than one monitor?? See http://www.pulseaudio.org/wiki/Modules and read about module-null-sink and module-loopback. You can obviously only record from one source (for screencasting - probably a monitor), but you can also loop back any number of sources to the sink whose monitor you're recording. That can be a null sink, too, so that you don't get feedback through your speakers. Obviously that's not relevant to VLC itself, it's through pactl/pacmd (sorry) and pavucontrol that you need to select the appropriate recording source. Cheers, -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Screen casting with PulseAudio
Hello, One regularly requested feature addition for VLC media player is the ability to record desktop audio in sync with screen capture. This is theoretically feasible with a PulseAudio sink monitor source. But but, I am a it puzzled as how to record the correct source. In this case, the default source is obviously inadequate, as it would typically be the microphone. In particular, what to do if there are more than one sink, and thus more than one monitor?? -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation
> 2011/10/18 Wang Xingchao : >> if all channels have same volume setting, use fast way to >> do volume change. this patch intended to work for two formats: >> s16ne/s16re. I did some work to optimize svolume already, see my branch on github: https://github.com/mkbosmans/pulseaudio/compare/master...orcify After a few pending patches that I have already sent to the list are pulled, I plan to submit this branch in parts. (the branch needs to be rebased after the pending patches are committed) For testing correctness of your volume implementation (and performance, as Tanu suggested) you can use the svolume-test program added in this commit: https://github.com/mkbosmans/pulseaudio/commit/cf0c5c9ad47ba0434b0518ca79ca802d0e62153a The Orc svolume implementation currently only handles 1ch s16ne (the orcify branch also adds 1ch float), so I added a similar test for identical channel volumes for the Orc case: https://github.com/mkbosmans/pulseaudio/commit/8659d08f22ccaba0c1ca18c0b29744318bf4fe08 I like that way (only using one extra variable) a bit better than yours (with both same_vol and fast_vol added), but that is not really important. 2011/10/18 Wang Xingchao : > Hi all, > > I didnot touch much formats optermization, only for most used > s16nr/re, please help review whether the idea is acceptable. If so, i > will take the responsbility for all formats. I'd say only float32ne is another candidate. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation
On Tue, 2011-10-18 at 12:24 +0300, Wang Xingchao wrote: > Hi all, > > I didnot touch much formats optermization, only for most used > s16nr/re, please help review whether the idea is acceptable. If so, i > will take the responsbility for all formats. Have you measured the performance with and without this patch? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation
Hi all,
I didnot touch much formats optermization, only for most used
s16nr/re, please help review whether the idea is acceptable. If so, i
will take the responsbility for all formats.
--xingchao
2011/10/18 Wang Xingchao :
> if all channels have same volume setting, use fast way to
> do volume change. this patch intended to work for two formats:
> s16ne/s16re.
>
> Signed-off-by: Wang Xingchao
> ---
> src/pulsecore/svolume_c.c | 70
> +
> 1 files changed, 70 insertions(+), 0 deletions(-)
>
> diff --git a/src/pulsecore/svolume_c.c b/src/pulsecore/svolume_c.c
> index 272e7a7..7919faa 100644
> --- a/src/pulsecore/svolume_c.c
> +++ b/src/pulsecore/svolume_c.c
> @@ -90,9 +90,43 @@ static void pa_volume_ulaw_c(uint8_t *samples, int32_t
> *volumes, unsigned channe
>
> static void pa_volume_s16ne_c(int16_t *samples, int32_t *volumes, unsigned
> channels, unsigned length) {
> unsigned channel;
> + int32_t same_vol = volumes[0];
> + unsigned fast_vol;
>
> length /= sizeof(int16_t);
>
> + for (channel = 0; channel < channels; channel++) {
> + if (volumes[channel] != same_vol)
> + break;
> + }
> +
> + fast_vol = channel < channels? 0 : 1;
> +
> + if (fast_vol) {
> + int32_t t, hi, lo;
> + int32_t ht, lt;
> +
> + hi = same_vol >> 16;
> + lo = same_vol & 0x;
> + while (length) {
> + t = *((int32_t *)samples);
> + ht = t >> 16;
> + lt = t & 0x;
> +
> + ht = ((ht * lo) >> 16) + (ht * hi);
> + ht = PA_CLAMP_UNLIKELY(ht, -0x8000, 0x7FFF);
> +
> + lt = ((lt * lo) >> 16) + (lt * hi);
> + lt = PA_CLAMP_UNLIKELY(lt, -0x8000, 0x7FFF);
> +
> + *((int32_t *)samples) = ht<<16|lt;
> +
> + samples += 2;
> + length -= 2;
> + }
> +
> + return;
> + }
> for (channel = 0; length; length--) {
> int32_t t, hi, lo;
>
> @@ -117,9 +151,45 @@ static void pa_volume_s16ne_c(int16_t *samples, int32_t
> *volumes, unsigned chann
>
> static void pa_volume_s16re_c(int16_t *samples, int32_t *volumes, unsigned
> channels, unsigned length) {
> unsigned channel;
> + int32_t same_vol = volumes[0];
> + unsigned fast_vol;
>
> length /= sizeof(int16_t);
>
> + for (channel = 0; channel < channels; channel++) {
> + if (volumes[channel] != same_vol)
> + break;
> + }
> +
> + fast_vol = channel < channels? 0 : 1;
> +
> + if (fast_vol) {
> + int32_t t, hi, lo;
> + int32_t ht, lt;
> +
> + hi = same_vol >> 16;
> + lo = same_vol & 0x;
> +
> + while (length) {
> + t = *((int32_t *)samples);
> + ht = (int32_t)PA_INT16_SWAP((int16_t)(t >> 16));
> + lt = (int32_t)PA_INT16_SWAP((int16_t)(t & 0x));
> +
> + ht = ((ht * lo) >> 16) + (ht * hi);
> + ht = PA_CLAMP_UNLIKELY(ht, -0x8000, 0x7FFF);
> +
> + lt = ((lt * lo) >> 16) + (lt * hi);
> + lt = PA_CLAMP_UNLIKELY(lt, -0x8000, 0x7FFF);
> +
> + *((int32_t *)samples) = PA_INT16_SWAP((int16_t)
> ht<<16)|PA_INT16_SWAP((int16_t) lt);
> +
> + samples += 2;
> + length -= 2;
> + }
> +
> + return;
> + }
> +
> for (channel = 0; length; length--) {
> int32_t t, hi, lo;
>
> --
> 1.7.1
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation
if all channels have same volume setting, use fast way to
do volume change. this patch intended to work for two formats:
s16ne/s16re.
Signed-off-by: Wang Xingchao
---
src/pulsecore/svolume_c.c | 70 +
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/src/pulsecore/svolume_c.c b/src/pulsecore/svolume_c.c
index 272e7a7..7919faa 100644
--- a/src/pulsecore/svolume_c.c
+++ b/src/pulsecore/svolume_c.c
@@ -90,9 +90,43 @@ static void pa_volume_ulaw_c(uint8_t *samples, int32_t
*volumes, unsigned channe
static void pa_volume_s16ne_c(int16_t *samples, int32_t *volumes, unsigned
channels, unsigned length) {
unsigned channel;
+int32_t same_vol = volumes[0];
+unsigned fast_vol;
length /= sizeof(int16_t);
+for (channel = 0; channel < channels; channel++) {
+ if (volumes[channel] != same_vol)
+ break;
+}
+
+fast_vol = channel < channels? 0 : 1;
+
+if (fast_vol) {
+ int32_t t, hi, lo;
+ int32_t ht, lt;
+
+ hi = same_vol >> 16;
+ lo = same_vol & 0x;
+ while (length) {
+ t = *((int32_t *)samples);
+ ht = t >> 16;
+ lt = t & 0x;
+
+ ht = ((ht * lo) >> 16) + (ht * hi);
+ ht = PA_CLAMP_UNLIKELY(ht, -0x8000, 0x7FFF);
+
+ lt = ((lt * lo) >> 16) + (lt * hi);
+ lt = PA_CLAMP_UNLIKELY(lt, -0x8000, 0x7FFF);
+
+ *((int32_t *)samples) = ht<<16|lt;
+
+ samples += 2;
+ length -= 2;
+ }
+
+ return;
+}
for (channel = 0; length; length--) {
int32_t t, hi, lo;
@@ -117,9 +151,45 @@ static void pa_volume_s16ne_c(int16_t *samples, int32_t
*volumes, unsigned chann
static void pa_volume_s16re_c(int16_t *samples, int32_t *volumes, unsigned
channels, unsigned length) {
unsigned channel;
+int32_t same_vol = volumes[0];
+unsigned fast_vol;
length /= sizeof(int16_t);
+for (channel = 0; channel < channels; channel++) {
+ if (volumes[channel] != same_vol)
+ break;
+}
+
+fast_vol = channel < channels? 0 : 1;
+
+if (fast_vol) {
+ int32_t t, hi, lo;
+ int32_t ht, lt;
+
+ hi = same_vol >> 16;
+ lo = same_vol & 0x;
+
+ while (length) {
+ t = *((int32_t *)samples);
+ ht = (int32_t)PA_INT16_SWAP((int16_t)(t >> 16));
+ lt = (int32_t)PA_INT16_SWAP((int16_t)(t & 0x));
+
+ ht = ((ht * lo) >> 16) + (ht * hi);
+ ht = PA_CLAMP_UNLIKELY(ht, -0x8000, 0x7FFF);
+
+ lt = ((lt * lo) >> 16) + (lt * hi);
+ lt = PA_CLAMP_UNLIKELY(lt, -0x8000, 0x7FFF);
+
+ *((int32_t *)samples) = PA_INT16_SWAP((int16_t)
ht<<16)|PA_INT16_SWAP((int16_t) lt);
+
+ samples += 2;
+ length -= 2;
+ }
+
+ return;
+}
+
for (channel = 0; length; length--) {
int32_t t, hi, lo;
--
1.7.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
2011/10/17 Brian Cameron : > I found this issue when I try to build PA clients. For example, when > PulseAudio tries to build pactl, I see these errors. I see similar > errors trying to build any PA client: > > Undefined first referenced > symbol in file > pa_object_unref > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > pa_sink_input_type_id > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > pa_object_type_id > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > pa_msgobject_type_id > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > pa_source_output_type_id > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > pa_object_ref > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > pa_sink_type_id > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > pa_source_type_id > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > pa_core_type_id > /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so > ld: fatal: symbol referencing errors. No output written to .libs/pacat > > I found that using the attached patch which causes PA clients to link > against libpulsecore fixes this problem. Now that I am looking at this > more closely, I suspect the problem is that PA clients are including > header files that define functions that are not included in the clients. I audited the utils and tests and the following programs where your patch adds libpulsecore only use functionality from libpulse and libpulsecommon: pacat, pactl, pasuspender, pacmd, pax11publish, mainloop-test, voltest libpulsecore should not be added for these, because they don't use functionality from that library. Your output log from above suggests that something in libpulsecommon uses functionality from pulsecore/object.[ch], so those files should probably be moved to from libpulsecore to libpulsecommon. Does that fix linking on Solaris? The rest of the utils only use public libpulse headers, so for these libpulsecommon should even be removed from the linker line. get-binary-name, pacat-simple, parec-simple, extended-test, channelmap-test, sync-playback, gtk-test, connect-stress Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] alsa-mixer: Implement a new path option: "mute-during-activation".
---
src/modules/alsa/alsa-mixer.c | 23 +++-
src/modules/alsa/alsa-mixer.h |3 +-
src/modules/alsa/alsa-sink.c |6 ++--
src/modules/alsa/alsa-source.c |6 ++--
.../alsa/mixer/paths/analog-output.conf.common |3 ++
5 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index 151eef5..34889ee 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -1235,7 +1235,7 @@ static int element_set_constant_volume(pa_alsa_element
*e, snd_mixer_t *m) {
return r;
}
-int pa_alsa_path_select(pa_alsa_path *p, snd_mixer_t *m) {
+int pa_alsa_path_select(pa_alsa_path *p, snd_mixer_t *m, pa_bool_t
device_is_muted) {
pa_alsa_element *e;
int r = 0;
@@ -1245,6 +1245,15 @@ int pa_alsa_path_select(pa_alsa_path *p, snd_mixer_t *m)
{
pa_log_debug("Activating path %s", p->name);
pa_alsa_path_dump(p);
+/* First turn on hw mute if available, to avoid noise
+ * when setting the mixer controls. */
+if (p->mute_during_activation) {
+PA_LLIST_FOREACH(e, p->elements) {
+if (e->switch_use == PA_ALSA_SWITCH_MUTE)
+element_set_switch(e, m, FALSE);
+}
+}
+
PA_LLIST_FOREACH(e, p->elements) {
switch (e->switch_use) {
@@ -1283,6 +1292,16 @@ int pa_alsa_path_select(pa_alsa_path *p, snd_mixer_t *m)
{
return -1;
}
+/* Finally restore hw mute to the device mute status. */
+if (p->mute_during_activation) {
+PA_LLIST_FOREACH(e, p->elements) {
+if (e->switch_use == PA_ALSA_SWITCH_MUTE) {
+if (element_set_switch(e, m, !device_is_muted) < 0)
+return -1;
+}
+}
+}
+
return 0;
}
@@ -2356,6 +2375,7 @@ pa_alsa_path* pa_alsa_path_new(const char *paths_dir,
const char *fname, pa_alsa
{ "priority",pa_config_parse_unsigned, NULL,
"General" },
{ "description", pa_config_parse_string,NULL,
"General" },
{ "name",pa_config_parse_string,NULL,
"General" },
+{ "mute-during-activation", pa_config_parse_bool, NULL,
"General" },
/* [Option ...] */
{ "priority",option_parse_priority, NULL, NULL
},
@@ -2387,6 +2407,7 @@ pa_alsa_path* pa_alsa_path_new(const char *paths_dir,
const char *fname, pa_alsa
items[0].data = &p->priority;
items[1].data = &p->description;
items[2].data = &p->name;
+items[3].data = &p->mute_during_activation;
if (!paths_dir)
paths_dir = get_default_paths_dir();
diff --git a/src/modules/alsa/alsa-mixer.h b/src/modules/alsa/alsa-mixer.h
index 92ddac5..5eb1d06 100644
--- a/src/modules/alsa/alsa-mixer.h
+++ b/src/modules/alsa/alsa-mixer.h
@@ -166,6 +166,7 @@ struct pa_alsa_path {
char *name;
char *description;
unsigned priority;
+pa_bool_t mute_during_activation;
pa_bool_t probed:1;
pa_bool_t supported:1;
@@ -216,7 +217,7 @@ int pa_alsa_path_get_volume(pa_alsa_path *p, snd_mixer_t
*m, const pa_channel_ma
int pa_alsa_path_get_mute(pa_alsa_path *path, snd_mixer_t *m, pa_bool_t
*muted);
int pa_alsa_path_set_volume(pa_alsa_path *path, snd_mixer_t *m, const
pa_channel_map *cm, pa_cvolume *v, pa_bool_t deferred_volume, pa_bool_t
write_to_hw);
int pa_alsa_path_set_mute(pa_alsa_path *path, snd_mixer_t *m, pa_bool_t muted);
-int pa_alsa_path_select(pa_alsa_path *p, snd_mixer_t *m);
+int pa_alsa_path_select(pa_alsa_path *p, snd_mixer_t *m, pa_bool_t
device_is_muted);
void pa_alsa_path_set_callback(pa_alsa_path *p, snd_mixer_t *m,
snd_mixer_elem_callback_t cb, void *userdata);
void pa_alsa_path_free(pa_alsa_path *p);
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index 7b31b1b..b14562a 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -1453,7 +1453,7 @@ static int sink_set_port_cb(pa_sink *s, pa_device_port
*p) {
data = PA_DEVICE_PORT_DATA(p);
pa_assert_se(u->mixer_path = data->path);
-pa_alsa_path_select(u->mixer_path, u->mixer_handle);
+pa_alsa_path_select(u->mixer_path, u->mixer_handle, s->muted);
mixer_volume_init(u);
@@ -1895,7 +1895,7 @@ static int setup_mixer(struct userdata *u, pa_bool_t
ignore_dB) {
data = PA_DEVICE_PORT_DATA(u->sink->active_port);
u->mixer_path = data->path;
-pa_alsa_path_select(data->path, u->mixer_handle);
+pa_alsa_path_select(data->path, u->mixer_handle, u->sink->muted);
if (data->setting)
pa_alsa_setting_select(data->setting, u->mixer_handle);
@@ -1908,7 +1908,7 @@ static int setup_mixer(struct userdata *u, pa_bool_t
ignore_dB) {
if (u->mixer_path) {
/* Hmm, we have only a single path, then let'
Re: [pulseaudio-discuss] [PATCH] alsa-card: Handle the "profile" modarg.
On Mon, 2011-10-03 at 18:11 +0300, Kaskinen Tanu wrote:
> ---
> src/modules/alsa/module-alsa-card.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/src/modules/alsa/module-alsa-card.c
> b/src/modules/alsa/module-alsa-card.c
> index 6d1a5e1..a8d9c59 100644
> --- a/src/modules/alsa/module-alsa-card.c
> +++ b/src/modules/alsa/module-alsa-card.c
> @@ -291,6 +291,7 @@ int pa__init(pa_module *m) {
> struct userdata *u;
> pa_reserve_wrapper *reserve = NULL;
> const char *description;
> +const char *profile = NULL;
> char *fn = NULL;
> pa_bool_t namereg_fail = FALSE;
>
> @@ -387,6 +388,9 @@ int pa__init(pa_module *m) {
> goto fail;
> }
>
> +if ((profile = pa_modargs_get_value(ma, "profile", NULL)))
> +pa_card_new_data_set_profile(&data, profile);
> +
> u->card = pa_card_new(m->core, &data);
> pa_card_new_data_done(&data);
Ping? Could this be merged?
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Alternate sample rates
2011/10/18 Arun Raghavan : > Hello, > I just pushed a bunch of patches by Pierre Louis-Bossart to introduce an > on-by-default alternate-sample-rate to configuration in addition to > default-sample-rate. This was discussed earlier this year on list[1]. > There's some more information on my blog[2]. Very Cool feature! Why not change sample_spec totally according to sink's availability, but only sample rate? The default sample_spec used at initialization, if alsa driver supports various formats/rates, PA could change sink's sample_spec in order to fit sink-input's request. Is there any risk or my misunderstanding ? --xingchao ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
