Re: [pulseaudio-discuss] [PATCH] alsa-mixer: make the mono mapping a fallback only
On Thu, 2018-06-07 at 17:17 +0200, Georg Chini wrote: > On 01.06.2018 10:24, Tanu Kaskinen wrote: > > If a sound card doesn't have the "front" device defined for it, we have > > to use the "hw" device for stereo. Not so long ago, the analog-stereo > > mapping had "hw:%f" in its device-strings and everything worked great, > > except that it caused trouble with the Intel HDMI LPE driver that uses > > the first "hw" device for HDMI, and we were incorrectly detecting it as > > an analog device. That problem was fixed in commit ea3ebd09, which > > removed "hw:%f" from analog-stereo and added a new stereo fallback > > mapping for "hw". > > > > Now the problem is that if a sound card doesn't have the "front" device > > defined for it, and it supports both mono and stereo, only the mono > > mapping is used, because the stereo mapping is only a fallback. This > > patch makes the mono mapping a fallback too, so the mono mapping is used > > only if there's absolutely nothing else that works. > > > > This can cause trouble at least in theory. Maybe someone actually wants > > to use mono output on a card that supports both mono and stereo. But > > that seems quite unlikely. > > --- > > src/modules/alsa/alsa-mixer.c | 1 + > > .../alsa/mixer/profile-sets/default.conf | 18 ++ > > 2 files changed, 11 insertions(+), 8 deletions(-) > > > > Looks good to me. I don't mind having it in 12.0, but let Arun have > the last word. > > BTW, when are we going to release 12.0? I have not heard any > complaints yet. Next week seems possible. Hopefully Arun can comment on this patch. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [patches] constification 1/2
On Wed, 2018-06-06 at 17:57 +0100, jnq...@gmail.com wrote: > On Mon, 2018-06-04 at 13:28 +0300, Tanu Kaskinen wrote: > > On Mon, 2018-05-28 at 01:49 +0100, jnq...@gmail.com wrote: > > > Constification patch set ** 1 of 2 ** > > > > > > Collection of 16 patches constifying pointers in various parts of > > > the > > > API. > > > > > > This collection of patches has interdependencies, they must be > > > applied > > > in (roughly) the given order. > > > > > > These start off with constifying some core hashmap functions, which > > > then allows various proplist related functions to be changed. A > > > couple > > > of tagstruct functions are in there, and finally a couple of > > > context+proplist related functions. > > > > > > I have not been in a position to try and compile these changes. I > > > have > > > identified one possible problem - the hashmap.c BY_HASH macro - I'm > > > not > > > certain offhand if a const version will be required or if the > > > compiler > > > will be happy casting as is. Otherwise I'm fairly certain there are > > > no > > > (obvious) issues. > > > > Thanks! I pushed these to the "next" branch. The only issue was in > > the > > last patch - the function reused the constified variable when > > creating > > a new proplist, and the compiler didn't like when that temporary > > proplist was freed. I took the liberty of amending your patch with a > > fix. > > No problem, thanks :) > I noticed set 2/2 isn't there... Yes, I didn't get around to 2/2 yet. I thought I'd review it today, but I ended up doing other things instead... I'll be away until Monday, so you'll need to wait for a bit still (unless someone else reviews the patches). -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [patches] constification round #3
API constification set #3
Some API functions perform validation routines which may modify the
'error' attribute of a context object. For API functions where the
"primary" object is not a context object, and the object holds a non-
const context pointer, this internal mechanism could be successfully
hidden - such functions were constified in my previous two patch sets.
However, some functions, namely those related directly to context
objects, had to be passed over previously. These could not be
constified because the validation routines accessed the context object
directly to change the error attribute.
This patch set addresses this shortcoming.
Firstly the patch set moves the context's error attribute behind a
pointer. The validation routines are then changed to store the error
value via this pointer. That then allows a collection of further API
functions to be constified.
(actually pa_context_errno and the two rttime ones could have been done
previously on second inspection)
Although the indirection of the error attribute is obviously ever so
slightly worse off for efficiency, it is surely worth the price. After
all, the error setting of the validation checks is just an artifact of
an internal mechanism and should not be allowed to influence the public
API like it currently does.From b1659b17ef72f44ab299384026027eb4f8afde4f Mon Sep 17 00:00:00 2001
From: Lyndon Brown
Date: Thu, 7 Jun 2018 02:43:56 +0100
Subject: context: hide error attr behind pointer
Paves the way towards more of the API using const pointers.
(See email discussion).
diff --git a/src/pulse/context.c b/src/pulse/context.c
index adbeb153..d298ae3e 100644
--- a/src/pulse/context.c
+++ b/src/pulse/context.c
@@ -139,6 +139,9 @@ pa_context *pa_context_new_with_proplist(pa_mainloop_api *mainloop, const char *
c = pa_xnew0(pa_context, 1);
PA_REFCNT_INIT(c);
+c->error = pa_xnew0(pa_context_error, 1);
+assert(c->error);
+
c->proplist = p ? pa_proplist_copy(p) : pa_proplist_new();
if (name)
@@ -156,7 +159,7 @@ pa_context *pa_context_new_with_proplist(pa_mainloop_api *mainloop, const char *
PA_LLIST_HEAD_INIT(pa_stream, c->streams);
PA_LLIST_HEAD_INIT(pa_operation, c->operations);
-c->error = PA_OK;
+c->error->error = PA_OK;
c->state = PA_CONTEXT_UNCONNECTED;
reset_callbacks(c);
@@ -315,7 +318,7 @@ int pa_context_set_error(pa_context *c, int error) {
pa_assert(error < PA_ERR_MAX);
if (c)
-c->error = error;
+c->error->error = error;
return error;
}
@@ -1072,7 +1075,7 @@ int pa_context_errno(pa_context *c) {
pa_assert(PA_REFCNT_VALUE(c) >= 1);
-return c->error;
+return c->error->error;
}
void pa_context_set_state_callback(pa_context *c, pa_context_notify_cb_t cb, void *userdata) {
diff --git a/src/pulse/internal.h b/src/pulse/internal.h
index 01d2b6e4..04f35e9a 100644
--- a/src/pulse/internal.h
+++ b/src/pulse/internal.h
@@ -55,6 +55,10 @@
#define PA_PROTOCOL_FLAG_SHM 0x8000U
#define PA_PROTOCOL_FLAG_MEMFD 0x4000U
+typedef struct pa_context_error {
+int error;
+} pa_context_error;
+
struct pa_context {
PA_REFCNT_DECLARE;
@@ -80,7 +84,7 @@ struct pa_context {
uint32_t version;
uint32_t ctag;
uint32_t csyncid;
-int error;
+pa_context_error *error;
pa_context_state_t state;
pa_context_notify_cb_t state_callback;
From 590ee9dd0c9d513872ee0150c52f895a01dd04a8 Mon Sep 17 00:00:00 2001
From: Lyndon Brown
Date: Thu, 7 Jun 2018 02:50:54 +0100
Subject: add internal pa_context_error_set_error function
pa_context_set_error now redirects to this
Further paving the way towards more of the API using const pointers.
(See email discussion).
diff --git a/src/pulse/context.c b/src/pulse/context.c
index d298ae3e..45ff3fbb 100644
--- a/src/pulse/context.c
+++ b/src/pulse/context.c
@@ -313,16 +313,20 @@ void pa_context_set_state(pa_context *c, pa_context_state_t st) {
pa_context_unref(c);
}
-int pa_context_set_error(pa_context *c, int error) {
+int pa_context_error_set_error(pa_context_error *ce, int error) {
pa_assert(error >= 0);
pa_assert(error < PA_ERR_MAX);
-if (c)
-c->error->error = error;
+if (ce)
+ce->error = error;
return error;
}
+int pa_context_set_error(pa_context *c, int error) {
+return pa_context_error_set_error(c->error, error);
+}
+
void pa_context_fail(pa_context *c, int error) {
pa_assert(c);
pa_assert(PA_REFCNT_VALUE(c) >= 1);
diff --git a/src/pulse/internal.h b/src/pulse/internal.h
index 04f35e9a..725b7b46 100644
--- a/src/pulse/internal.h
+++ b/src/pulse/internal.h
@@ -281,6 +281,8 @@ pa_operation* pa_context_send_simple_command(pa_context *c, uint32_t command, vo
void pa_stream_set_state(pa_stream *s, pa_stream_state_t st);
+int pa_context_error_set_error(pa_context_error *ce, int error);
+
pa_tagstruct *pa_tagstruct_command(pa_context *c, uint32_t command, uint32_t *tag);
#define
[pulseaudio-discuss] [patch] const stream internal
quick patch to constify a couple of internal stream functionsFrom fdc7b0ebd82a98348d35ac1d76c937e021985a21 Mon Sep 17 00:00:00 2001
From: Lyndon Brown
Date: Thu, 7 Jun 2018 03:15:41 +0100
Subject: stream: constify internal functions
diff --git a/src/pulse/stream.c b/src/pulse/stream.c
index 73743cbb..f0c8034a 100644
--- a/src/pulse/stream.c
+++ b/src/pulse/stream.c
@@ -1731,7 +1731,7 @@ pa_operation * pa_stream_drain(pa_stream *s, pa_stream_success_cb_t cb, void *us
return o;
}
-static pa_usec_t calc_time(pa_stream *s, bool ignore_transport) {
+static pa_usec_t calc_time(const pa_stream *s, bool ignore_transport) {
pa_usec_t usec;
pa_assert(s);
@@ -2485,7 +2485,7 @@ int pa_stream_get_time(pa_stream *s, pa_usec_t *r_usec) {
return 0;
}
-static pa_usec_t time_counter_diff(pa_stream *s, pa_usec_t a, pa_usec_t b, int *negative) {
+static pa_usec_t time_counter_diff(const pa_stream *s, pa_usec_t a, pa_usec_t b, int *negative) {
pa_assert(s);
pa_assert(PA_REFCNT_VALUE(s) >= 1);
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Problem to receive RTP stream from ffmpeg
Hello, I struggle to perform my house audio setup. Let me explain: I have at home a raspberry pi with a USB microphone running under raspbian. Pulseaudio is not (and cannot) be installed on it. I stream the microphone with ffmpeg with the following command: arecord -D pcm.duplex -c2 -r 48000 -f S32_LE -t wav -V mono | avconv -i - -acodec libmp3lame -b 32k -f rtp rtp://225.5.5.5:1234/4 The streaming works correctly as I can listen to the audio from my laptop with the following command: ffplay rtp://225.5.5.5:1234 Now I have a home server where I have a tool that needs to use "rec" to work. Therefore I want to create a RTP source for the RTP stream and forward it to "rec" as default input. I checked with cli-visualizer script (configured for pulseaudio) and the following command works on the home server: ffplay rtp://225.5.5.5:1234 -nodisp Pulseaudio runs in system mode on the server, I tried to create a RTP source in /etc/pulse/system.pa by adding load-module module-null-sink sink_name=rtp load-module module-rtp-recv sink=rtp sap_address=225.5.5.5 set-default-source rtp.monitor There is no speakers on the server so I cannot verify if sound is played, however if I run cli-visualizer then there is no activity so my guess is that RTP stream is not captured by pulseaudio. Do you see what I miss? There is a lot of tutorials to stream RTP *from* pulseaudio, but there is a lot less help to send a RTP stream *to* pulseaudio that is not coming from another pulseaudio. Thanks! Antoine -- Antoine Vacher mail/jabber: antoine.vac...@tigre-bleu.net ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
