Re: [pulseaudio-discuss] [PATCH] protocol-native: fix bytes-to-usec conversion of "on-the-fly" data

[Arun Raghavan]

On Mon, 17 Jul 2017, at 10:17 PM, Tanu Kaskinen wrote:
> On Sat, 2017-07-15 at 11:20 +0530, Arun Raghavan wrote:
> > 
> > On Tue, 11 Jul 2017, at 11:46 PM, Tanu Kaskinen wrote:
> > > The on_the_fly_snapshot variable contains the amount of bytes that has
> > > been sent from the source IO thread to the main thread, but not yet
> > > pushed to the stream memblockq. The data is in the stream format, but
> > > the bytes-to-usec conversion used the source format, which caused random
> > > latency reporting errors.
> > > 
> > > BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=81075
> > > ---
> > >  src/pulsecore/protocol-native.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/src/pulsecore/protocol-native.c
> > > b/src/pulsecore/protocol-native.c
> > > index 266b676de..d5d032950 100644
> > > --- a/src/pulsecore/protocol-native.c
> > > +++ b/src/pulsecore/protocol-native.c
> > > @@ -2922,7 +2922,7 @@ static void command_get_record_latency(pa_pdispatch
> > > *pd, uint32_t command, uint3
> > >  pa_tagstruct_put_usec(reply, s->current_monitor_latency);
> > >  pa_tagstruct_put_usec(reply,
> > >s->current_source_latency +
> > > -  pa_bytes_to_usec(s->on_the_fly_snapshot,
> > > >source_output->source->sample_spec));
> > > +  pa_bytes_to_usec(s->on_the_fly_snapshot,
> > > >source_output->sample_spec));
> > >  pa_tagstruct_put_boolean(reply,
> > >   
> > > pa_source_get_state(s->source_output->source)
> > >   == PA_SOURCE_RUNNING &&
> > >   pa_source_output_get_state(s->source_output)
> > >   == PA_SOURCE_OUTPUT_RUNNING);
> > > -- 
> > 
> > Looks good. Let's get this into 11.0, maybe?
> 
> Ok, I'll push this to master. Would you like to have also
> 
> simple: Change latency estimation to account for already-read data
> in pa_simple_get_latency().
> 
> and
> 
> simple: fix negative latency handling
> 
> in 11.0? Those improve latency reporting for the simple API.

I thought about that, and if you're confident there's no chance of
regressing there, maybe a freeze exception is okay.

-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] Switching Between Bitstream and PCM

[Henk Visser]

Hello everyone!

1.) I playing videos with the VLC player and am using the "PulseAudio Sound
Server" as an audio output device from the VLC GUI.

2.) Using the "PulseAudio Sound Server" output device from within VLC, I am
able to play a file and I get bitstream (surround sound) coming out via
HDMI to my TV.

3.) While this is playing (bitstream) I want to which over to PCM. How do I
do this now? I don't see any settings for the Pulse Audio Server that stand
out to me. Shouldn't this be toggled by the player (VLC?) or PulseAudio?
The developers for VLC are mentioning PulseAudio to do this but I am stuck.

Thank you!
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] tunnel-{sink, source}-new: Fix assertion when used with module-loopback

[Georg Chini]

On 17.07.2017 19:32, Tanu Kaskinen wrote:

On Sun, 2017-07-16 at 11:42 +0200, Georg Chini wrote:

Currently pulseaudio crashes with an assertion in 
pa_rtpoll_item_new_asyncmsgq_read()
if a loopback is applied to a tunnel-new sink/source because 
tunnel-{sink,source}-new
do not set thread_info.rtpoll. Bug was reported on IRC.

This patch fixes the problem by initializing thread_info.rtpoll properly.

Did you test this patch? The tunnel devices don't run the rtpoll that
you create, so I would expect that the loopback won't work.

This is a known bug that I started working on in the past:
https://bugs.freedesktop.org/show_bug.cgi?id=73429

I made some patches, issues got pointed out in review, and then I never
finished v2 of the patches. I haven't given up on that, but it's been a
year since I last worked on it... In case you're interested in the
current state of the v2 patches, I pushed the code to
git://people.freedesktop.org/~tanuk/pulseaudio branch "rtpoll-mainloop-
v2".


I haven't tested it myself, but the bug reporter on IRC (tar-dingens)
tested them and said it worked. The patch looked like the easiest way to
make module-loopback happy.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v3 1/3] bluetooth: ofono: Use Acquire method if available

[Tanu Kaskinen]

On Sun, 2017-07-16 at 14:35 +0200, Georg Chini wrote:
> On 04.07.2017 15:38, Tanu Kaskinen wrote:
> > On Mon, 2017-07-03 at 21:01 +0300, Luiz Augusto von Dentz wrote:
> > > Hi Georg,
> > > 
> > > On Mon, Jul 3, 2017 at 8:32 PM, Georg Chini  wrote:
> > > > On 03.07.2017 17:51, Luiz Augusto von Dentz wrote:
> > > > > Hi Tanu,
> > > > > 
> > > > > On Mon, Jul 3, 2017 at 5:05 PM, Tanu Kaskinen  wrote:
> > > > > > On Mon, 2017-07-03 at 16:09 +0300, Luiz Augusto von Dentz wrote:
> > > > > > > Hi Tanu,
> > > > > > > 
> > > > > > > On Mon, Jun 19, 2017 at 4:29 PM, Tanu Kaskinen  
> > > > > > > wrote:
> > > > > > > > On Thu, 2017-05-25 at 11:36 +0300, Luiz Augusto von Dentz wrote:
> > > > > > > > > +if (!r) {
> > > > > > > > > +if (!pa_streq(err.name, DBUS_ERROR_UNKNOWN_METHOD)) {
> > > > > > > > > +pa_log_error("Failed to acquire %s: %s", 
> > > > > > > > > err.name,
> > > > > > > > > err.message);
> > > > > > > > > +return -1;
> > > > > > > > > +}
> > > > > > > > > +} else if ((dbus_message_get_args(r, NULL,
> > > > > > > > > + DBUS_TYPE_UNIX_FD, >fd,
> > > > > > > > > + DBUS_TYPE_BYTE, >codec,
> > > > > > > > 
> > > > > > > > I don't know how dbus_message_get_args() works, but it seems 
> > > > > > > > likely
> > > > > > > > that it can fail between setting card->fd and card->codec. We 
> > > > > > > > don't
> > > > > > > > want to set card->fd if the operation fails, so I think we 
> > > > > > > > should read
> > > > > > > > the values into local variables, and only update the card if the
> > > > > > > > operation is successful.
> > > > > > > 
> > > > > > > Will add separate variables just to be safe.
> > > > > > > 
> > > > > > > > The codec value should be checked (it has to be CVSD).
> > > > > > > > 
> > > > > > > > hf_audio_agent_new_connection() sets the transport state to 
> > > > > > > > PLAYING,
> > > > > > > > but that's not done here. This was pointed out by Georg as 
> > > > > > > > well. In the
> > > > > > > > previous discussion, he said that he'll send a patch related to 
> > > > > > > > this,
> > > > > > > > but that hasn't happened...
> > > > > > > 
> > > > > > > hf_audio_agent_new_connection is called for the main thread thus 
> > > > > > > why
> > > > > > > it can change the transport state, on the IO thread this would 
> > > > > > > cause a
> > > > > > > crash, in fact up to now all backends including A2DP do not set 
> > > > > > > the
> > > > > > > transport state from acquire callback directly for this very 
> > > > > > > reason
> > > > > > > which is why I decided to leave it be like this since perhaps we 
> > > > > > > want
> > > > > > > the caller to directly set the state which might make sense to 
> > > > > > > change
> > > > > > > in a separate patch.
> > > > > > 
> > > > > > Is a separate patch forthcoming? Without such patch it looks like
> > > > > > you're introducing a regression here.
> > > > > 
> > > > > Don't follow your logic, regression to what? _None_ of the the
> > > > > backends do set the transport state from the io thread, this is not
> > > > > changing anything either with Connect or Acquire the behavior is
> > > > > exactly the same in this regard. Im not saying we should not fix it,
> > > > > but considering the current behavior is to wait for NewConnection
> > > > > forever that is probably a much worse offender then having out of sync
> > > > > transport state.
> > > > > 
> > > > > A2DP also does a similar thing, though it return the fd in place it
> > > > > only changes the transport state when D-Bus indicate so:
> > > > > 
> > > > >   if (pa_streq(key, "State")) {
> > > > >   pa_bluetooth_transport_state_t state;
> > > > > 
> > > > >   if (transport_state_from_string(value, ) < 0) 
> > > > > {
> > > > >   pa_log_error("Invalid state received: %s", 
> > > > > value);
> > > > >   return;
> > > > >   }
> > > > > 
> > > > >   pa_bluetooth_transport_set_state(t, state);
> > > > > 
> > > > > Unfortunately the Connect + NewConnection is racy, which should be
> > > > > clear by now, this stayed for as long I remembered the ofono backend
> > > > > exists, so I fixing things because they are not very reliable,
> > > > > including ofono which got patched as well.
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > Hi, I don't understand the discussion. I think we don't want to set the
> > > > state
> > > > from the I/O thread. The transport state is set correctly from the main
> > > > thread in all cases except for the AG role when using the native
> > > > backend. The patch Tanu is referring to is here:
> > > > 
> > > > https://patchwork.freedesktop.org/patch/155661/
> > 
> > Oh, so you did send a patch for this already. Sorry, I don't know how I
> > missed it.
> > 
> > > Great, that should work regardless of the backend. 

Re: [pulseaudio-discuss] [PATCH] tunnel-{sink, source}-new: Fix assertion when used with module-loopback

[Tanu Kaskinen]

On Sun, 2017-07-16 at 11:42 +0200, Georg Chini wrote:
> Currently pulseaudio crashes with an assertion in 
> pa_rtpoll_item_new_asyncmsgq_read()
> if a loopback is applied to a tunnel-new sink/source because 
> tunnel-{sink,source}-new
> do not set thread_info.rtpoll. Bug was reported on IRC.
> 
> This patch fixes the problem by initializing thread_info.rtpoll properly.

Did you test this patch? The tunnel devices don't run the rtpoll that
you create, so I would expect that the loopback won't work.

This is a known bug that I started working on in the past:
https://bugs.freedesktop.org/show_bug.cgi?id=73429

I made some patches, issues got pointed out in review, and then I never
finished v2 of the patches. I haven't given up on that, but it's been a
year since I last worked on it... In case you're interested in the
current state of the v2 patches, I pushed the code to
git://people.freedesktop.org/~tanuk/pulseaudio branch "rtpoll-mainloop-
v2".

-- 
Tanu

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] [PATCH] equalizer-sink: update sink description when moving

[Tanu Kaskinen]

On Sat, 2017-07-15 at 11:28 +0530, Arun Raghavan wrote:
> 
> On Thu, 13 Jul 2017, at 12:59 AM, Tanu Kaskinen wrote:
> > If the description is not updated when moving, the old automatically
> > generated description will refer to the old master sink after the move,
> > which is not nice.
> > ---
> >  src/modules/module-equalizer-sink.c | 26 ++
> >  1 file changed, 22 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/modules/module-equalizer-sink.c
> > b/src/modules/module-equalizer-sink.c
> > index 280ca25fb..489062fc0 100644
> > --- a/src/modules/module-equalizer-sink.c
> > +++ b/src/modules/module-equalizer-sink.c
> > @@ -127,6 +127,8 @@ struct userdata {
> >  
> >  pa_database *database;
> >  char **base_profiles;
> > +
> > +bool automatic_description;
> >  };
> >  
> >  static const char* const valid_modargs[] = {
> > @@ -1080,6 +1082,17 @@ static void sink_input_moving_cb(pa_sink_input *i,
> > pa_sink *dest) {
> >  if (dest) {
> >  pa_sink_set_asyncmsgq(u->sink, dest->asyncmsgq);
> >  pa_sink_update_flags(u->sink,
> >  PA_SINK_LATENCY|PA_SINK_DYNAMIC_LATENCY, dest->flags);
> > +
> > +if (u->automatic_description) {
> > +const char *master_description;
> > +char *new_description;
> > +
> > +master_description = pa_proplist_gets(dest->proplist,
> > PA_PROP_DEVICE_DESCRIPTION);
> > +new_description = pa_sprintf_malloc(_("FFT based equalizer
> > on %s"),
> > +master_description ?
> > master_description : dest->name);
> > +pa_sink_set_description(u->sink, new_description);
> > +pa_xfree(new_description);
> > +}
> >  } else
> >  pa_sink_set_asyncmsgq(u->sink, NULL);
> >  }
> > @@ -1089,7 +1102,6 @@ int pa__init(pa_module*m) {
> >  pa_sample_spec ss;
> >  pa_channel_map map;
> >  pa_modargs *ma;
> > -const char *z;
> >  pa_sink *master;
> >  pa_sink_input_new_data sink_input_data;
> >  pa_sink_new_data sink_data;
> > @@ -1185,9 +1197,6 @@ int pa__init(pa_module*m) {
> >  pa_sink_new_data_set_sample_spec(_data, );
> >  pa_sink_new_data_set_channel_map(_data, );
> >  
> > -z = pa_proplist_gets(master->proplist, PA_PROP_DEVICE_DESCRIPTION);
> > -pa_proplist_setf(sink_data.proplist, PA_PROP_DEVICE_DESCRIPTION,
> > "FFT based equalizer on %s", z ? z : master->name);
> > -
> >  pa_proplist_sets(sink_data.proplist, PA_PROP_DEVICE_MASTER_DEVICE,
> >  master->name);
> >  pa_proplist_sets(sink_data.proplist, PA_PROP_DEVICE_CLASS,
> >  "filter");
> >  
> > @@ -1197,6 +1206,15 @@ int pa__init(pa_module*m) {
> >  goto fail;
> >  }
> >  
> > +if (!pa_proplist_contains(sink_data.proplist,
> > PA_PROP_DEVICE_DESCRIPTION)) {
> > +const char *master_description;
> > +
> > +master_description = pa_proplist_gets(master->proplist,
> > PA_PROP_DEVICE_DESCRIPTION);
> > +pa_proplist_setf(sink_data.proplist, PA_PROP_DEVICE_DESCRIPTION,
> > + _("FFT based equalizer on %s"),
> > master_description ? master_description : master->name);
> > +u->automatic_description = true;
> > +}
> > +
> 
> Looks fine, modulo a minor style comment that you can implement if you
> feel like -- it's nicer to factor the string construction to a single
> function rather than repeat between the two locations.
> 
> We likely need to do this across filters, so maybe we should be
> factoring out other such code (such as autoload handling) and have them
> reusable across modules.

I'll apply this as is, but I'll later look into simplifying the
description updating for all filter devices.

-- 
Tanu

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] [PATCH 0/3] Fix jack detection for Intel HDMI LPE

[Tanu Kaskinen]

On Sat, 2017-07-15 at 11:24 +0530, Arun Raghavan wrote:
> 
> On Mon, 12 Jun 2017, at 09:15 PM, Tanu Kaskinen wrote:
> > These patches hopefully fix jack detection (and ELD information
> > querying too) for Intel HDMI LPE. I don't have the hardware myself, so
> > further testing would be very welcome. Hans, Takashi and Pierre, you're
> > in Cc, because you indicated in this[1] thread that you have the
> > hardware.
> > 
> > Testing instructions:
> > 
> > First, before installing the modified PulseAudio version, check if you
> > still suffer from the problem that the kernel kills PulseAudio. I don't
> > know if these patches are sufficient to fix that problem, but it's worth
> > trying.
> > 
> > Next, apply the patches on top of the current PulseAudio master branch
> > and install the modified version. After installing, set
> > "realtime-scheduling = no" in daemon.conf to prevent the kernel from
> > killing PulseAudio.
> > 
> > Then, start pulseaudio and check if jack detection is working.
> > "pactl list cards" will show the cards, their profiles and the port
> > status. The HDMI card should only list HDMI profiles in the "Profiles:"
> > section (check that there are no analog profiles listed), and the port
> > status should change between "available" and "unavailable" in the
> > "Ports:" section as you plug the HDMI cable in and out.
> > 
> > If the jack detection seems to work, try setting
> > "realtime-scheduling = yes" in daemon.conf to see if the kernel still
> > kills PulseAudio.
> 
> I don't have the hardware to test this, so just a plain review
> follows...
> 
> The code looks fine, but I'm a bit concerned by adding such specific
> configuration parameters to the mapping files. This is just increasing
> complexity w.r.t. what we have to maintain more or less forever.
> 
> In my mind, it seems like it would be much nicer to have a way to signal
> the ELD device from the driver, rather than all this mucking around in
> configuration.
> 
> Takashi, Hans, Pierre: would it be possible to get such a mechanism?
> 
> I'm guessing that even if such a mechanism were to exist, we're going to
> have to wait for it to happen and be widely available, so let's go ahead
> and get Tanu's patches in, so that the hardware works ootb.

The driver already signals the ELD device. It's just that alsa-lib kind
of loses track of that information (or maybe it doesn't, maybe
snd_pcm_info_get_device() is more reliable than I think).

It would be nice to have a function in alsa-lib for returning the
underlying hw device number. snd_pcm_info_get_device() already does
that at least in some cases, but it's not documented how it behaves
when there are additional layers on top of the hw PCM. Takashi said
that it should work fine for the "hdmi:" devices, but can it always be
relied to either return the correct device number or an error? What
does the function do if there are multiple hw PCM devices behind a
plugin PCM? Hopefully it returns an error in that case. If it's
reliable enough, then we can query the hw device number for every
mapping, so we don't need special handling for HDMI.

Another option for avoiding the "query_hw_device" option would be to
query the device number automagically when a mapping's device string
starts with "hdmi:", but I don't really like that kind of magic.

-- 
Tanu

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] [PATCH] protocol-native: fix bytes-to-usec conversion of "on-the-fly" data

[Tanu Kaskinen]

On Sat, 2017-07-15 at 11:20 +0530, Arun Raghavan wrote:
> 
> On Tue, 11 Jul 2017, at 11:46 PM, Tanu Kaskinen wrote:
> > The on_the_fly_snapshot variable contains the amount of bytes that has
> > been sent from the source IO thread to the main thread, but not yet
> > pushed to the stream memblockq. The data is in the stream format, but
> > the bytes-to-usec conversion used the source format, which caused random
> > latency reporting errors.
> > 
> > BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=81075
> > ---
> >  src/pulsecore/protocol-native.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/pulsecore/protocol-native.c
> > b/src/pulsecore/protocol-native.c
> > index 266b676de..d5d032950 100644
> > --- a/src/pulsecore/protocol-native.c
> > +++ b/src/pulsecore/protocol-native.c
> > @@ -2922,7 +2922,7 @@ static void command_get_record_latency(pa_pdispatch
> > *pd, uint32_t command, uint3
> >  pa_tagstruct_put_usec(reply, s->current_monitor_latency);
> >  pa_tagstruct_put_usec(reply,
> >s->current_source_latency +
> > -  pa_bytes_to_usec(s->on_the_fly_snapshot,
> > >source_output->source->sample_spec));
> > +  pa_bytes_to_usec(s->on_the_fly_snapshot,
> > >source_output->sample_spec));
> >  pa_tagstruct_put_boolean(reply,
> >   pa_source_get_state(s->source_output->source)
> >   == PA_SOURCE_RUNNING &&
> >   pa_source_output_get_state(s->source_output)
> >   == PA_SOURCE_OUTPUT_RUNNING);
> > -- 
> 
> Looks good. Let's get this into 11.0, maybe?

Ok, I'll push this to master. Would you like to have also

simple: Change latency estimation to account for already-read data
in pa_simple_get_latency().

and

simple: fix negative latency handling

in 11.0? Those improve latency reporting for the simple API.

-- 
Tanu

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] [PATCH] fix dbus message leaks

[Tanu Kaskinen]

On Sat, 2017-07-15 at 11:08 +0530, Arun Raghavan wrote:
> 
> On Mon, 3 Jul 2017, at 08:05 PM, Tanu Kaskinen wrote:
> > I reviewed all places that call
> > dbus_connection_send_with_reply_and_block(), and found several places
> > where dbus messages aren't properly unreffed.
> > ---
> >  src/modules/bluetooth/backend-ofono.c |  6 ++
> >  src/modules/bluetooth/bluez4-util.c   | 12 ++--
> >  src/modules/bluetooth/bluez5-util.c   | 12 ++--
> >  src/modules/reserve.c |  6 ++
> >  4 files changed, 32 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/modules/bluetooth/backend-ofono.c
> > b/src/modules/bluetooth/backend-ofono.c
> > index 6e9a3664e..2c51497f3 100644
> > --- a/src/modules/bluetooth/backend-ofono.c
> > +++ b/src/modules/bluetooth/backend-ofono.c
> > @@ -168,9 +168,15 @@ static int
> > hf_audio_agent_transport_acquire(pa_bluetooth_transport *t, bool opti
> >  dbus_error_init();
> >  pa_assert_se(m = dbus_message_new_method_call(t->owner, t->path,
> >  "org.ofono.HandsfreeAudioCard", "Connect"));
> >  r =
> >  
> > dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(card->backend->connection),
> >  m, -1, );
> > +dbus_message_unref(m);
> > +m = NULL;
> > +
> >  if (!r)
> >  return -1;
> >  
> > +dbus_message_unref(r);
> > +r = NULL;
> > +
> >  if (card->connecting)
> >  return -EAGAIN;
> >  }
> > diff --git a/src/modules/bluetooth/bluez4-util.c
> > b/src/modules/bluetooth/bluez4-util.c
> > index 82654508f..ca606193d 100644
> > --- a/src/modules/bluetooth/bluez4-util.c
> > +++ b/src/modules/bluetooth/bluez4-util.c
> > @@ -1116,6 +1116,8 @@ int pa_bluez4_transport_acquire(pa_bluez4_transport
> > *t, bool optional, size_t *i
> >  pa_assert_se(m = dbus_message_new_method_call(t->owner, t->path,
> >  "org.bluez.MediaTransport", "Acquire"));
> >  pa_assert_se(dbus_message_append_args(m, DBUS_TYPE_STRING,
> >  , DBUS_TYPE_INVALID));
> >  r =
> >  
> > dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(t->device->discovery->connection),
> >  m, -1, );
> > +dbus_message_unref(m);
> > +m = NULL;
> >  
> >  if (!r) {
> >  dbus_error_free();
> > @@ -1143,7 +1145,7 @@ fail:
> >  
> >  void pa_bluez4_transport_release(pa_bluez4_transport *t) {
> >  const char *accesstype = "rw";
> > -DBusMessage *m;
> > +DBusMessage *m, *r;
> >  DBusError err;
> >  
> >  pa_assert(t);
> > @@ -1154,7 +1156,13 @@ void
> > pa_bluez4_transport_release(pa_bluez4_transport *t) {
> >  
> >  pa_assert_se(m = dbus_message_new_method_call(t->owner, t->path,
> >  "org.bluez.MediaTransport", "Release"));
> >  pa_assert_se(dbus_message_append_args(m, DBUS_TYPE_STRING,
> >  , DBUS_TYPE_INVALID));
> > -   
> > dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(t->device->discovery->connection),
> > m, -1, );
> > +r =
> > dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(t->device->discovery->connection),
> > m, -1, );
> > +dbus_message_unref(m);
> > +m = NULL;
> > +if (r) {
> > +dbus_message_unref(r);
> > +r = NULL;
> > +}
> >  
> >  if (dbus_error_is_set()) {
> >  pa_log("Failed to release transport %s: %s", t->path,
> >  err.message);
> > diff --git a/src/modules/bluetooth/bluez5-util.c
> > b/src/modules/bluetooth/bluez5-util.c
> > index 8956fb13a..c92832329 100644
> > --- a/src/modules/bluetooth/bluez5-util.c
> > +++ b/src/modules/bluetooth/bluez5-util.c
> > @@ -363,6 +363,8 @@ static int
> > bluez5_transport_acquire_cb(pa_bluetooth_transport *t, bool optional,
> >  dbus_error_init();
> >  
> >  r =
> >  
> > dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(t->device->discovery->connection),
> >  m, -1, );
> > +dbus_message_unref(m);
> > +m = NULL;
> >  if (!r) {
> >  if (optional && pa_streq(err.name,
> >  "org.bluez.Error.NotAvailable"))
> >  pa_log_info("Failed optional acquire of unavailable
> >  transport %s", t->path);
> > @@ -393,7 +395,7 @@ finish:
> >  }
> >  
> >  static void bluez5_transport_release_cb(pa_bluetooth_transport *t) {
> > -DBusMessage *m;
> > +DBusMessage *m, *r;
> >  DBusError err;
> >  
> >  pa_assert(t);
> > @@ -408,7 +410,13 @@ static void
> > bluez5_transport_release_cb(pa_bluetooth_transport *t) {
> >  }
> >  
> >  pa_assert_se(m = dbus_message_new_method_call(t->owner, t->path,
> >  BLUEZ_MEDIA_TRANSPORT_INTERFACE, "Release"));
> > -   
> > dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(t->device->discovery->connection),
> > m, -1, );
> > +r =
> > dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(t->device->discovery->connection),
> > m, -1, );
> > +dbus_message_unref(m);
> > +m = NULL;
> > +if 

[pulseaudio-discuss] input/output jack seems to be not handled by PulseAudio

[Alex ARNAUD]

Dear all,


I help a blind person to figure out a sound issue.

She has a "Intel Corporation C600/X79 series chipset High Definition 
Audio Controller (rev 05)" with several jack input/output plug.


On Windows everything works correctly, she can choose which jack plug 
she wants to use for output and which one to use for input.
Indeed, when a jack is plugged Windows open a dialog with a list to 
choose if it is a micro or an headphone.


On Debian 8, with Linux kernel 4.9 and PulseAudio 7 only one entry work 
for input and one work for output. If I change the jack cable of plug 
entry I noticed "unplugged" state on PavuControl.



What I can do to chose myself which one I want for output and which one 
for input ?


Best regards.
--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss