date:20121126

Re: [pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

2012-11-26 Thread Mikel Astiz

Hi Tanu,

On Fri, Nov 23, 2012 at 8:26 PM, Tanu Kaskinen ta...@iki.fi wrote:
 On Fri, 2012-11-23 at 13:41 +0100, Mikel Astiz wrote:
 From: Mikel Astiz mikel.as...@bmw-carit.de

 Merge the former hsp-output and a2dp-output ports into one single
 port, in order to fix the regression of having several independent
 entries in the UI.

 I'm not sure if this is anything serious, but with this change, I think
 (I haven't actually tested) module-bluetooth-policy works with headsets
 that support both profiles as follows, not very smartly:

  - It never does anything until both profiles enter the playing state.

That was not the intention. The patch should set the port to
PORT_AVAILABLE_YES if *any* of the two profiles is set, and thus the
port switch could be triggered.

 I'm not sure if this scenario is possible. Can headsets initiate the
 playing state for one profile while the other profile is already
 playing too?

It's very unlikely, I haven't seen that yet.


  - If both profiles enter the playing state, then semi-randomly one or
 the other will be activated.

As stated above, this will happen if any of the two profiles starts
playing *and* the active profile is off. But you're right, the
activated profile will be semi-random, i.e. the policy is not very
smart.

I can't think of any workaround to this problem once the ports get
merged, since module-bluetooth-policy is not able to distinguish the
state of each Bluetooth profile.

 To me it looks like this is not serious, so this is not a blocker issue
 for accepting the patch.


Cheers,
Mikel
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API

2012-11-26 Thread Ian Malone

On 24 November 2012 13:01, Tanu Kaskinen ta...@iki.fi wrote:
 On Wed, 2012-11-21 at 03:04 -0500, Ian Malone wrote:
 On 20 November 2012 14:01, Tanu Kaskinen ta...@iki.fi wrote:
  On Tue, 2012-11-20 at 20:43 +0200, Tanu Kaskinen wrote:
  On Tue, 2012-11-20 at 17:59 +, Ian Malone wrote:
   Thanks, I'll give it a go. I think handling the already_owner case in
   reserve.c as well might be worthwhile since there may be other ways to
   get to that state.
 
  I think it's a bug in the application if it calls rd_acquire for a
  device that it already owns. An assertion might be the way to go. If not
  an assertion, then at least an error.
 
  When writing that, I didn't realize that the current code already
  returns an error if dbus_bus_request_name() returns
  DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER. I think that's a fine way of
  handling it, so in my opinion nothing needs to be done here.
 

 Okay I agree there is probably a more serious bug somewhere. I'll just
 point out that the current response does not result in an error in
 verbose output and that encountering that response results in removing
 the reserve method and handlers, meaning if the service isn't broken
 before it happens then it certainly is afterwards.

 Yes, if that error happens, the device reservation won't work, but the
 problem is not that the error is handled badly, the problem is that the
 error happens.

 That's probably not very useful when debugging this bug, though. When
 debugging this, I'd like you to add this assertion to rd_acquire():

 assert(k != DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER);

 Then run pulseaudio in gdb and get a backtrace. Also, would it be
 possible for you try 2.99.2 (with the patch for reserve.c added)?


I'm attaching the backtrace for 2.1, without the reserve.c patch added
as otherwise it doesn't hit that condition.

2.99 with the reserve.c patch appears to work in that it drops the
DBus service correctly and the test playback from the KDE Audio Setup
works. 2.1 on the same setup does not release the device without the
reserve.c patch and with the reserve.c patch it drops the DBus service
but does not play the test sonud from audio setup.

-- 
imalone
http://ibmalone.blogspot.co.uk


pulse-2.1-nocbpatch-assert.bt
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

2012-11-26 Thread Henrik /KaarPoSoft

On 11/23/12 21:48, Tanu Kaskinen wrote:

On Fri, 2012-11-23 at 00:00 +0100, Henrik /KaarPoSoft wrote:

In any case, for whatever it is worth, here is what I am now seing with
2.99.2:

I can *not* reproduce the hang with:
open gnome-terminal (as only app on desktop), press backspace, close
terminal.

I *can* reproduce the hang with:
open firefox (as only app on desktop), play html5 video on youtube,
close firefox.

I *can* reliably produce the hang with:
open firefox (as first app on desktop), play html5 video on youtube.
open gnome-terminal (as second app on desktop), press backspace (ie.
*not* even closing terminal).
Now sound from youtube keeps playing, but the desktop is unresponsive.

I tried that last case myself, still can't reproduce.

It seems there are two different (probably unrelated) issues:

1) FIREFOX USING ALSA

Those two cases:

I *can* reproduce the hang with:
open firefox (as only app on desktop), play html5 video on youtube,
close firefox.

Seems to be caused by my own stupid misconfiguration.

Firefox seems to access alsa directly; not through pulseaudio.
I created a suitable /etc/asound.conf, and compiled the pulse alsa-plugin,
and now this issue seems to be fixed.

2) DESKTOP FREEZING ON CLOSING LAST WINDOW.

I wrote:

I can *not* reproduce the hang with:
open gnome-terminal (as only app on desktop), press backspace, close
terminal.

But it seems that i *can* reproduce it with 2.99.2.
It still happens, but just not every time.

So, back to square one.

When you press backspace, do you hear the pling sound, or does it
freeze silently?

I *do* hear the sound.

I took a fresh look at the backtrace that you pasted to
your original mail, and at least in that case the freeze seemed to
happen when giving the command to play the sample to pulseaudio. Either
pulseaudio didn't react to that command, or else pulseaudio did play
that sample, but never sent an acknowledgement back to the application.
Contrary to what Colin said, libcanberra is not waiting for the sound to
finish playing, it's waiting for an ack for the command to start the
sample playback. That command should always return quickly (it doesn't
wait for the sample to finish).

How to debug this? Maybe add extra log output to pulseaudio (and
libpulse) until you find the exact place where something goes wrong. Or
maybe this would be a good starting point: in the beginning of
src/pulsecore/pdispatch.c, theres #define DEBUG_OPCODES commented out.
Remove the commenting, that is, enable the debug option. Also, improve
the debug output a bit. The file contains this line in
pa_dispatch_run():

pa_log([%p] Received opcode %s, pd, p);

Change that to

pa_log([%p] Received opcode %s, tag % PRIu32, pd, p, tag);

The tag will allow you to match commands and replies. Replies have the
same tag as the original command.

Then build pulseaudio again. That debug option will make pulseaudio
print every command that is sent via the native protocol (both at the
server and the client end). When sample playback is requested, this
should be printed in the server log:

E: [pulseaudio] pdispatch.c: [0x1113390] Received opcode PLAY_SAMPLE, tag 2

Correspondingly, the client log should contain this:

[0x248caf0] Received opcode REPLY, tag 2

What would be interesting is that does pulseaudio receive the
PLAY_SAMPLE command, and if it does, does gnome-shell receive the REPLY
to that command.

Unfortunately, I don't know how to get log output from gnome-shell...
I made the above changes, and now get the Received opcode... from the
daemon in the log. Thanks.

But I cannot figure out how to get log output from gnome-shell either.

If I put this in my /etc/profile:
--
export PULSE_LOG=4
export PULSE_LOG_LEVEL=4
export PULSE_LOG_SYSLOG=1
--
clients in general show the expected traces in syslog.
So I can run firefox or pacat, and see the Received opcode... from
both client and daemon in syslog, and match them as you suggested.
However, with this /etc/profile, gnome-shell starts allright, but plays
no sound whatsoever, and logs nothing to syslog.

No clue why.

Anyway, here is a log from 2.99.2:
https://sourceforge.net/p/kaarpux/tickets/_discuss/thread/a1e6c549/cfd3/attachment/log_2_99_2.txt

I created a gnome-terminal, pressed backspace for a beep, then closed.
The first three times it worked OK, the last time it hung the desktop.

A bit later I was doing some desktop work, and closed all windows at the
end.

All there is in the log when closing the last window is:
Nov 25 17:54:40 kx8400-5 pulseaudio[2091]:
[pulseaudio][pulsecore/pdispatch.c:318 pa_pdispatch_run()] [0x8eb53e8]
Received

Re: [pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

2012-11-26 Thread Tanu Kaskinen

On Sun, 2012-11-25 at 18:35 +0100, Henrik /KaarPoSoft wrote:
 I made the above changes, and now get the Received opcode...  from the 
 daemon in the log. Thanks.
 
 But I cannot figure out how to get log output from gnome-shell either.
 
 If I put this in my /etc/profile:
 --
 export PULSE_LOG=4
 export PULSE_LOG_LEVEL=4
 export PULSE_LOG_SYSLOG=1
 --
 clients in general show the expected traces in syslog.
 So I can run firefox or pacat, and see the Received opcode... from 
 both client and daemon in syslog, and match them as you suggested.
 However, with this /etc/profile, gnome-shell starts allright, but plays 
 no sound whatsoever, and logs nothing to syslog.
 No clue why.

So gnome-shell doesn't want to log to syslog? I've attached a pulseaudio
patch that makes gnome-shell log to files under /tmp. Btw, I now noticed
that running gnome-shell --replace restarts gnome-shell and makes the
log from the new instance go to the current terminal.

 Anyway, here is a log from 2.99.2:
 https://sourceforge.net/p/kaarpux/tickets/_discuss/thread/a1e6c549/cfd3/attachment/log_2_99_2.txt

It looks like there are always two PLAY_SAMPLE requests. The first one
is bell-window-system, and the second is something that fails to play,
it probably doesn't exist in pulseaudio's sample cache (there are no
details logged for the failing sample - you may want to add some logging
to command_play_sample() in src/pulsecore/protocol-native.c). The hang
seems to happen when trying to play the second sample.

-- 
Tanu
From 67d2513751b59ae62168fe95f1ceaa372e1fb4f2 Mon Sep 17 00:00:00 2001
From: Tanu Kaskinen ta...@iki.fi
Date: Sun, 25 Nov 2012 21:41:39 +0200
Subject: [PATCH] Special logging configuration for gnome-shell

---
 src/pulsecore/log.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/src/pulsecore/log.c b/src/pulsecore/log.c
index 8eaef54..b7dcdf6 100644
--- a/src/pulsecore/log.c
+++ b/src/pulsecore/log.c
@@ -29,6 +29,7 @@
 #include unistd.h
 #include string.h
 #include errno.h
+#include fcntl.h
 
 #ifdef HAVE_EXECINFO_H
 #include execinfo.h
@@ -262,6 +263,30 @@ static void init_defaults(void) {
 if (getenv(ENV_LOG_NO_RATELIMIT))
 no_rate_limit = TRUE;
 
+if (pa_streq(getenv(_), /usr/bin/gnome-shell)) {
+unsigned n;
+int fd;
+
+for (n = 0; n  20; n++) {
+char *fn;
+
+fn = pa_sprintf_malloc(/tmp/gnome-shell-%u.txt, n);
+fd = pa_open_cloexec(fn, O_WRONLY | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
+pa_xfree(fn);
+
+if (fd = 0 || errno != EEXIST)
+break;
+}
+
+if (fd = 0) {
+pa_log_set_fd(fd);
+target_override = PA_LOG_FD;
+target_override_set = true;
+}
+
+maximum_level_override = PA_LOG_LEVEL_MAX-1;
+flags_override = PA_LOG_PRINT_TIME | PA_LOG_PRINT_FILE | PA_LOG_PRINT_META | PA_LOG_PRINT_LEVEL;
+}
 } PA_ONCE_END;
 }
 
-- 
1.7.10.4

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

Re: [pulseaudio-discuss] Bluetooth regression: a2dp not selectable

2012-11-26 Thread David Henningsson


On 11/23/2012 05:27 PM, Tanu Kaskinen wrote:

On Fri, 2012-11-23 at 16:40 +0100, David Henningsson wrote:

Under PulseAudio 2.1 I can select a2dp without problem.

Under PulseAudio 2.99.2, when I execute pactl set-card-profile 1 a2dp
I get Failure: Input/Output Error back (as the output from pactl), and
I see the following in PulseAudio's log:

module-bluetooth-device.c: Profile has no transport

...and the profile is not changed to a2dp. Anyone want to debug with me?


I can try to help, if it's not too late? You seem to have left IRC.


Thanks, I'll be around today.


I'm not able reproduce this with my headset.


Ok. I've done some minor debugging myself, but haven't got much. The 
pulseaudio debug log is here: http://pastebin.se/s3CIWSl0

At the same time I get these messages in syslog: http://pastebin.se/bilI1XGX

It looks like bluetoothd does find the A2DP Sink (and source?!), but 
then there is no callback to PulseAudio to register the transport, 
because this part is only shown for HSP, not for A2DP:


D: [lt-pulseaudio] bluetooth-util.c: dbus: 
interface=org.bluez.MediaEndpoint, path=/MediaEndpoint/HFPAG, 
member=SetConfiguration
D: [lt-pulseaudio] bluetooth-util.c: dbus: 
interface=org.bluez.MediaEndpoint, path=/MediaEndpoint/HFPAG, 
member=SetConfiguration
D: [lt-pulseaudio] bluetooth-util.c: Transport 
/org/bluez/634/hci0/dev_00_18_91_3A_B6_EC/fd3 profile 2 available




--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

2012-11-26 Thread Tanu Kaskinen

On Sun, 2012-11-25 at 22:25 +0200, Tanu Kaskinen wrote:
 So gnome-shell doesn't want to log to syslog? I've attached a pulseaudio
 patch that makes gnome-shell log to files under /tmp. Btw, I now noticed
 that running gnome-shell --replace restarts gnome-shell and makes the
 log from the new instance go to the current terminal.

When I started my computer today, I found out that the patch causes a
segfault during the gnome session startup, so X wouldn't come up. I've
attached a fixed patch. Another note is that the patch doesn't work for
the initial instance of gnome-shell. I'd guess that's because the _
environment variable isn't set during the session startup. The patch
should probably read the executable from /proc/self/cmdline rather than
the _ environment variable. I can do that change if necessary, but
given that gnome-shell --replace works for getting the log anyway,
maybe the whole patch is unnecessary.

-- 
Tanu
From 1decd84961a5dbc609cd688d881534011bbe11d3 Mon Sep 17 00:00:00 2001
From: Tanu Kaskinen ta...@iki.fi
Date: Sun, 25 Nov 2012 21:41:39 +0200
Subject: [PATCH] Special logging configuration for gnome-shell

---
 src/pulsecore/log.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/src/pulsecore/log.c b/src/pulsecore/log.c
index 8eaef54..8ed757b 100644
--- a/src/pulsecore/log.c
+++ b/src/pulsecore/log.c
@@ -29,6 +29,7 @@
 #include unistd.h
 #include string.h
 #include errno.h
+#include fcntl.h
 
 #ifdef HAVE_EXECINFO_H
 #include execinfo.h
@@ -262,6 +263,30 @@ static void init_defaults(void) {
 if (getenv(ENV_LOG_NO_RATELIMIT))
 no_rate_limit = TRUE;
 
+if ((e = getenv(_))  pa_streq(e, /usr/bin/gnome-shell)) {
+unsigned n;
+int fd;
+
+for (n = 0; n  20; n++) {
+char *fn;
+
+fn = pa_sprintf_malloc(/tmp/gnome-shell-%u.txt, n);
+fd = pa_open_cloexec(fn, O_WRONLY | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
+pa_xfree(fn);
+
+if (fd = 0 || errno != EEXIST)
+break;
+}
+
+if (fd = 0) {
+pa_log_set_fd(fd);
+target_override = PA_LOG_FD;
+target_override_set = true;
+}
+
+maximum_level_override = PA_LOG_LEVEL_MAX-1;
+flags_override = PA_LOG_PRINT_TIME | PA_LOG_PRINT_FILE | PA_LOG_PRINT_META | PA_LOG_PRINT_LEVEL;
+}
 } PA_ONCE_END;
 }
 
-- 
1.7.10.4

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

Re: [pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

2012-11-26 Thread Tanu Kaskinen

On Sun, 2012-11-25 at 12:28 +0100, Mikel Astiz wrote:
 Hi Tanu,
 
 On Fri, Nov 23, 2012 at 8:26 PM, Tanu Kaskinen ta...@iki.fi wrote:
  On Fri, 2012-11-23 at 13:41 +0100, Mikel Astiz wrote:
  From: Mikel Astiz mikel.as...@bmw-carit.de
 
  Merge the former hsp-output and a2dp-output ports into one single
  port, in order to fix the regression of having several independent
  entries in the UI.
 
  I'm not sure if this is anything serious, but with this change, I think
  (I haven't actually tested) module-bluetooth-policy works with headsets
  that support both profiles as follows, not very smartly:
 
   - It never does anything until both profiles enter the playing state.
 
 That was not the intention. The patch should set the port to
 PORT_AVAILABLE_YES if *any* of the two profiles is set, and thus the
 port switch could be triggered.

Ah, so it seems, my mistake.

  I'm not sure if this scenario is possible. Can headsets initiate the
  playing state for one profile while the other profile is already
  playing too?
 
 It's very unlikely, I haven't seen that yet.
 
 
   - If both profiles enter the playing state, then semi-randomly one or
  the other will be activated.
 
 As stated above, this will happen if any of the two profiles starts
 playing *and* the active profile is off. But you're right, the
 activated profile will be semi-random, i.e. the policy is not very
 smart.
 
 I can't think of any workaround to this problem once the ports get
 merged, since module-bluetooth-policy is not able to distinguish the
 state of each Bluetooth profile.

module-bluetooth-policy has all information it needs available from
bluetooth-util, doesn't it? It doesn't necessarily need to even care
about the port availability, it could just directly follow the profile
state (connected/playing).

Am I right that the profile switching logic isn't meant for headsets
anyway? The use case for which the code was written was enabling
hfgw/a2dp_source when those profiles entered the playing state without
pulseaudio initiating that state change, or do I remember wrong? Maybe
module-bluetooth-policy could just check that is the port that became
available hfgw or a2dp_source, that way there would be no risk of
messing up headset use cases.

-- 
Tanu

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

Re: [pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

2012-11-26 Thread Mikel Astiz

Hi Tanu,

On Mon, Nov 26, 2012 at 2:52 PM, Tanu Kaskinen ta...@iki.fi wrote:
 On Sun, 2012-11-25 at 12:28 +0100, Mikel Astiz wrote:
 Hi Tanu,

 On Fri, Nov 23, 2012 at 8:26 PM, Tanu Kaskinen ta...@iki.fi wrote:
  On Fri, 2012-11-23 at 13:41 +0100, Mikel Astiz wrote:
  From: Mikel Astiz mikel.as...@bmw-carit.de
 
  Merge the former hsp-output and a2dp-output ports into one single
  port, in order to fix the regression of having several independent
  entries in the UI.
 
  I'm not sure if this is anything serious, but with this change, I think
  (I haven't actually tested) module-bluetooth-policy works with headsets
  that support both profiles as follows, not very smartly:
 
   - It never does anything until both profiles enter the playing state.

 That was not the intention. The patch should set the port to
 PORT_AVAILABLE_YES if *any* of the two profiles is set, and thus the
 port switch could be triggered.

 Ah, so it seems, my mistake.

  I'm not sure if this scenario is possible. Can headsets initiate the
  playing state for one profile while the other profile is already
  playing too?

 It's very unlikely, I haven't seen that yet.

 
   - If both profiles enter the playing state, then semi-randomly one or
  the other will be activated.

 As stated above, this will happen if any of the two profiles starts
 playing *and* the active profile is off. But you're right, the
 activated profile will be semi-random, i.e. the policy is not very
 smart.

 I can't think of any workaround to this problem once the ports get
 merged, since module-bluetooth-policy is not able to distinguish the
 state of each Bluetooth profile.

 module-bluetooth-policy has all information it needs available from
 bluetooth-util, doesn't it? It doesn't necessarily need to even care
 about the port availability, it could just directly follow the profile
 state (connected/playing).

Actually this kind of information is missing in the bluetooth-util
library. Have a look at how module-bluetooth-device is directly
handling the property changes in filter_cb(). This can be improved of
course (patches coming soon) but I doubt it's worth addressing this
minor detail for 3.0.


 Am I right that the profile switching logic isn't meant for headsets
 anyway? The use case for which the code was written was enabling
 hfgw/a2dp_source when those profiles entered the playing state without
 pulseaudio initiating that state change, or do I remember wrong? Maybe
 module-bluetooth-policy could just check that is the port that became
 available hfgw or a2dp_source, that way there would be no risk of
 messing up headset use cases.

Yes, that could be a possible workaround. Afaik headsets would rarely
resume the audio for a specific profile, at least in desktop
use-cases.

As you say, we could disable the policy based on the profile to avoid
messing up with headsets, but doesn't this raise the question whether
module-bluetooth-policy should be loaded at all? I don't think the
average user will be doing both gateway and headset roles.

Cheers,
Mikel
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

2012-11-26 Thread Tanu Kaskinen

On Mon, 2012-11-26 at 15:06 +0100, Mikel Astiz wrote:
 Hi Tanu,
 
 On Mon, Nov 26, 2012 at 2:52 PM, Tanu Kaskinen ta...@iki.fi wrote:
  module-bluetooth-policy has all information it needs available from
  bluetooth-util, doesn't it? It doesn't necessarily need to even care
  about the port availability, it could just directly follow the profile
  state (connected/playing).
 
 Actually this kind of information is missing in the bluetooth-util
 library. Have a look at how module-bluetooth-device is directly
 handling the property changes in filter_cb(). This can be improved of
 course (patches coming soon) but I doubt it's worth addressing this
 minor detail for 3.0.

Fair enough.

  Am I right that the profile switching logic isn't meant for headsets
  anyway? The use case for which the code was written was enabling
  hfgw/a2dp_source when those profiles entered the playing state without
  pulseaudio initiating that state change, or do I remember wrong? Maybe
  module-bluetooth-policy could just check that is the port that became
  available hfgw or a2dp_source, that way there would be no risk of
  messing up headset use cases.
 
 Yes, that could be a possible workaround. Afaik headsets would rarely
 resume the audio for a specific profile, at least in desktop
 use-cases.
 
 As you say, we could disable the policy based on the profile to avoid
 messing up with headsets, but doesn't this raise the question whether
 module-bluetooth-policy should be loaded at all? I don't think the
 average user will be doing both gateway and headset roles.

I think playing music from a phone via bluetooth to a PC is common
enough use case to justify loading module-bluetooth-policy by default.

-- 
Tanu

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

Re: [pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

2012-11-26 Thread Henrik /KaarPoSoft


On 11/26/12 14:30, Tanu Kaskinen wrote:
 On Sun, 2012-11-25 at 22:25 +0200, Tanu Kaskinen wrote:
 So gnome-shell doesn't want to log to syslog? I've attached a pulseaudio
 patch that makes gnome-shell log to files under /tmp. Btw, I now noticed
 that running gnome-shell --replace restarts gnome-shell and makes the
 log from the new instance go to the current terminal.

 When I started my computer today, I found out that the patch causes a
 segfault during the gnome session startup, so X wouldn't come up. I've
 attached a fixed patch. Another note is that the patch doesn't work for
 the initial instance of gnome-shell. I'd guess that's because the _
 environment variable isn't set during the session startup. The patch
 should probably read the executable from /proc/self/cmdline rather than
 the _ environment variable. I can do that change if necessary, but
 given that gnome-shell --replace works for getting the log anyway,
 maybe the whole patch is unnecessary.


Tanu, again: Thanks for your help.

I tried the patch and various other changes to log.c, but getting no 
useful logging, and sometimes segfaults instead (as you also noted).


My mind kept coming back to this:

ldd /bin/gnome-shell | grep pulse
libpulse-mainloop-glib.so.0 = //lib/libpulse-mainloop-glib.so.0 
(0xb5771000)

libpulse.so.0 = //lib/libpulse.so.0 (0xb5723000)
libpulsecommon-2.1.so = //lib/pulseaudio/libpulsecommon-2.1.so 
(0xb56b7000)
libpulsecommon-2.99.so = //lib/pulseaudio/libpulsecommon-2.99.so 
(0xb4da6000)


So, I deleted every file installed by the original pulseaudio 2.1, 
recompiled+installed pulseaudio 2.99.2, and recompiled+installed 
gnome-shell.


Now I have:

ldd /bin/gnome-shell | grep pulse
libpulse-mainloop-glib.so.0 = //lib/libpulse-mainloop-glib.so.0 
(0xb56e3000)

libpulse.so.0 = //lib/libpulse.so.0 (0xb5695000)
libpulsecommon-2.99.so = //lib/pulseaudio/libpulsecommon-2.99.so 
(0xb562)


(A quick look at gnome-shell source did not reveal why it would link to 
an old version; I must have a closer look at this later).


And the good news:
Now the clients (incl gnome-shell) are showing the Received opcode in 
~/.xsession-errors (presumably because they log to stderr which is 
redirected to ~/.xsession-errors).


And the even better news:
I have tried to recreate the freeze without success.
So, maybe 2.99.2 solved the original problem after all.

However, I am still having some trouble...

Syslog show as lot (about 5/sec to 10/sec) entries like:
Nov 26 16:31:04 kx8400-5 pulseaudio[2078]: (1745.440|   0.057) 
[pulseaudio] pdispatch.c: [0x9ee32f0] Received opcode 
GET_PLAYBACK_LATENCY, tag 1088

And ~/.xsession-errors shows the corresponding
Received opcode REPLY

I am not sure if this is a problem or not, but previously I did not 
notice such pulseaudio bursts in syslog.


Further thunderbird crashes every now and then (maybe not related, but 
it never did that before),

and sometimes the terminal does not beep as expected.

For the latter case (terminal does not beep as expected) I have this in 
syslog:



Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.550|   0.000) 
[pulseaudio] pdispatch.c: [0x9f6f018] Received opcode AUTH, tag 0
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.550|   0.000) 
[pulseaudio] protocol-native.c: Protocol version: remote 27, local 27
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.550|   0.000) 
[pulseaudio] protocol-native.c: Got credentials: uid=2002 gid=2000 success=1
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.550|   0.000) 
[pulseaudio] protocol-native.c: SHM possible: yes
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.550|   0.000) 
[pulseaudio] protocol-native.c: Negotiated SHM: yes
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.551|   0.000) 
[pulseaudio] pdispatch.c: [0x9f6f018] Received opcode SET_CLIENT_NAME, 
tag 1
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.551|   0.000) 
[pulseaudio] module-augment-properties.c: Looking for .desktop file for 
gnome-shell
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.553|   0.001) 
[pulseaudio] pdispatch.c: [0x9f6f018] Received opcode 
CREATE_PLAYBACK_STREAM, tag 2
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.553|   0.000) 
[pulseaudio] module-intended-roles.c: Not setting device for stream ALSA 
Playback, because it lacks role.
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.553|   0.000) 
[pulseaudio] module-suspend-on-idle.c: Sink 
alsa_output.pci-_00_1e.2.analog-stereo becomes busy.
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.553|   0.000) 
[pulseaudio] sink-input.c: Failed to create sink input: too many inputs 
per sink.
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.554|   0.001) 
[pulseaudio] client.c: Freed 92 ALSA plug-in [gnome-shell]
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.556|   0.001) 
[pulseaudio] protocol-native.c: Connection died.
Nov 26 16:35:30 kx8400-5 pulseaudio[2078]: (2011.559|   0.003)

Re: [pulseaudio-discuss] Bluetooth regression: a2dp not selectable

2012-11-26 Thread Mikel Astiz

Hi David,

On Mon, Nov 26, 2012 at 10:15 AM, David Henningsson
david.hennings...@canonical.com wrote:
 On 11/23/2012 05:27 PM, Tanu Kaskinen wrote:

 On Fri, 2012-11-23 at 16:40 +0100, David Henningsson wrote:

 Under PulseAudio 2.1 I can select a2dp without problem.

 Under PulseAudio 2.99.2, when I execute pactl set-card-profile 1 a2dp
 I get Failure: Input/Output Error back (as the output from pactl), and
 I see the following in PulseAudio's log:

 module-bluetooth-device.c: Profile has no transport

 ...and the profile is not changed to a2dp. Anyone want to debug with me?


 I can try to help, if it's not too late? You seem to have left IRC.


 Thanks, I'll be around today.


 I'm not able reproduce this with my headset.


 Ok. I've done some minor debugging myself, but haven't got much. The
 pulseaudio debug log is here: http://pastebin.se/s3CIWSl0
 At the same time I get these messages in syslog: http://pastebin.se/bilI1XGX

 It looks like bluetoothd does find the A2DP Sink (and source?!), but then
 there is no callback to PulseAudio to register the transport, because this
 part is only shown for HSP, not for A2DP:

 D: [lt-pulseaudio] bluetooth-util.c: dbus:
 interface=org.bluez.MediaEndpoint, path=/MediaEndpoint/HFPAG,
 member=SetConfiguration
 D: [lt-pulseaudio] bluetooth-util.c: dbus:
 interface=org.bluez.MediaEndpoint, path=/MediaEndpoint/HFPAG,
 member=SetConfiguration
 D: [lt-pulseaudio] bluetooth-util.c: Transport
 /org/bluez/634/hci0/dev_00_18_91_3A_B6_EC/fd3 profile 2 available

Just to make sure... can you confirm that the device was paired before
PA was started? There is a potential issue immediately after pairing,
but this would be no regression and nobody has complaint so far.

Assuming the device was already paired, can you check if A2DP profile
is connected before and after this problem? You can see this in
BlueZ's AudioSink.GetProperties(), property State.

I can't see anything strange in the log, so my best guess is that A2DP
is actually disconnected? In this case the behavior would be the
expected one. This could typically happen if you shut PA down and then
restart it: HSP would still be connected but not A2DP. In this case
you can't use Audio.Connect() to connect the device, since it'll
complain with AlreadyConnected (since Audio.State == connected
represents that at least one of the profiles is connected). Therefore
AudioSink.Connect() would solve the issue.

It's a long shot but anyway...

Cheers,
Mikel
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH v1 0/3] bluetooth: Headset port availability

2012-11-26 Thread Mikel Astiz

From: Mikel Astiz mikel.as...@bmw-carit.de

This patchset extends the previous patch (resent unmodified here) with the 
policy change suggested by Tanu.

It seems no conclusion was reached about the names etc. but I believe this is 
the best alternative without the form factor and in any case the strings can 
easily be changed during/after pushing.

Mikel Astiz (3):
  bluetooth: Merge headset ports into one
  bluetooth: Disable profile auto-switch policy for headsets
  conf: Load bluetooth-policy module by default

 src/daemon/default.pa.in|  4 ++
 src/modules/bluetooth/module-bluetooth-device.c | 72 ++---
 src/modules/bluetooth/module-bluetooth-policy.c |  4 ++
 3 files changed, 60 insertions(+), 20 deletions(-)

-- 
1.7.11.7

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

[pulseaudio-discuss] [PATCH v1 1/3] bluetooth: Merge headset ports into one

2012-11-26 Thread Mikel Astiz

From: Mikel Astiz mikel.as...@bmw-carit.de

Merge the former hsp-output and a2dp-output ports into one single
port, in order to fix the regression of having several independent
entries in the UI.
---
 src/modules/bluetooth/module-bluetooth-device.c | 72 ++---
 1 file changed, 52 insertions(+), 20 deletions(-)

diff --git a/src/modules/bluetooth/module-bluetooth-device.c 
b/src/modules/bluetooth/module-bluetooth-device.c
index dd1bb86..506a479 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -1281,6 +1281,15 @@ static pa_port_available_t 
audio_state_to_availability(pa_bt_audio_state_t state
 return PA_PORT_AVAILABLE_UNKNOWN;
 }
 
+static pa_port_available_t 
audio_state_to_availability_merged(pa_bt_audio_state_t state1, 
pa_bt_audio_state_t state2) {
+if (state1  PA_BT_AUDIO_STATE_CONNECTED  state2  
PA_BT_AUDIO_STATE_CONNECTED)
+return PA_PORT_AVAILABLE_NO;
+else if (state1 = PA_BT_AUDIO_STATE_PLAYING || state2 = 
PA_BT_AUDIO_STATE_PLAYING)
+return PA_PORT_AVAILABLE_YES;
+else
+return PA_PORT_AVAILABLE_UNKNOWN;
+}
+
 /* Run from main thread */
 static DBusHandlerResult filter_cb(DBusConnection *bus, DBusMessage *m, void 
*userdata) {
 DBusError err;
@@ -1356,9 +1365,14 @@ static DBusHandlerResult filter_cb(DBusConnection *bus, 
DBusMessage *m, void *us
 
 if (state != PA_BT_AUDIO_STATE_INVALID  
pa_hashmap_get(u-card-profiles, hsp)) {
 pa_device_port *port;
-pa_port_available_t available = audio_state_to_availability(state);
+pa_port_available_t available;
 
-pa_assert_se(port = pa_hashmap_get(u-card-ports, hsp-output));
+if (pa_hashmap_get(u-card-profiles, a2dp) == NULL)
+available = audio_state_to_availability(state);
+else
+available = audio_state_to_availability_merged(state, 
u-device-audio_sink_state);
+
+pa_assert_se(port = pa_hashmap_get(u-card-ports, 
bluetooth-output));
 pa_device_port_set_available(port, available);
 
 pa_assert_se(port = pa_hashmap_get(u-card-ports, hsp-input));
@@ -1385,9 +1399,14 @@ static DBusHandlerResult filter_cb(DBusConnection *bus, 
DBusMessage *m, void *us
 
 if (state != PA_BT_AUDIO_STATE_INVALID  
pa_hashmap_get(u-card-profiles, a2dp)) {
 pa_device_port *port;
-pa_port_available_t available = audio_state_to_availability(state);
+pa_port_available_t available;
+
+if (pa_hashmap_get(u-card-profiles, hsp) == NULL)
+available = audio_state_to_availability(state);
+else
+available = audio_state_to_availability_merged(state, 
u-device-headset_state);
 
-pa_assert_se(port = pa_hashmap_get(u-card-ports, a2dp-output));
+pa_assert_se(port = pa_hashmap_get(u-card-ports, 
bluetooth-output));
 pa_device_port_set_available(port, available);
 
 acquire = (available == PA_PORT_AVAILABLE_YES  u-profile == 
PROFILE_A2DP);
@@ -1614,7 +1633,7 @@ static void connect_ports(struct userdata *u, void 
*sink_or_source_new_data, pa_
 
 switch (u-profile) {
 case PROFILE_A2DP:
-pa_assert_se(port = pa_hashmap_get(u-card-ports, a2dp-output));
+pa_assert_se(port = pa_hashmap_get(u-card-ports, 
bluetooth-output));
 pa_assert_se(pa_hashmap_put(data.sink_new_data-ports, port-name, 
port) = 0);
 pa_device_port_ref(port);
 break;
@@ -1627,7 +1646,7 @@ static void connect_ports(struct userdata *u, void 
*sink_or_source_new_data, pa_
 
 case PROFILE_HSP:
 if (direction == PA_DIRECTION_OUTPUT) {
-pa_assert_se(port = pa_hashmap_get(u-card-ports, 
hsp-output));
+pa_assert_se(port = pa_hashmap_get(u-card-ports, 
bluetooth-output));
 pa_assert_se(pa_hashmap_put(data.sink_new_data-ports, 
port-name, port) = 0);
 } else {
 pa_assert_se(port = pa_hashmap_get(u-card-ports, 
hsp-input));
@@ -2247,13 +2266,20 @@ static void create_ports_for_profile(struct userdata 
*u, pa_hashmap *ports, pa_c
 
 switch (*d) {
 case PROFILE_A2DP:
-pa_assert_se(port = pa_device_port_new(u-core, a2dp-output, 
_(Bluetooth High Quality (A2DP)), 0));
-pa_assert_se(pa_hashmap_put(ports, port-name, port) = 0);
-port-is_output = 1;
-port-is_input = 0;
-port-priority = profile-priority * 100;
-port-available = 
audio_state_to_availability(device-audio_sink_state);
-pa_hashmap_put(port-profiles, profile-name, profile);
+if ((port = pa_hashmap_get(ports, bluetooth-output)) != NULL) {
+port-priority = PA_MAX(port-priority, profile-priority * 
100);
+port-available =

[pulseaudio-discuss] [PATCH v1 2/3] bluetooth: Disable profile auto-switch policy for headsets

2012-11-26 Thread Mikel Astiz

From: Mikel Astiz mikel.as...@bmw-carit.de

Given that headsets have just one single port exposing whether the
audio is streaming (playing) or not, it's not possible that
module-bluetooth-policy would distinguish A2DP/HSP cases, and thus
the automatic selection of the card profile is not deterministic.

For this reason, disable the policy entirely for headsets and focus
only on HFGW and A2DP source profiles.
---
 src/modules/bluetooth/module-bluetooth-policy.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/modules/bluetooth/module-bluetooth-policy.c 
b/src/modules/bluetooth/module-bluetooth-policy.c
index 87a5716..f0bffe9 100644
--- a/src/modules/bluetooth/module-bluetooth-policy.c
+++ b/src/modules/bluetooth/module-bluetooth-policy.c
@@ -187,6 +187,10 @@ static pa_hook_result_t 
port_available_hook_callback(pa_core *c, pa_device_port
 if (!s || !pa_streq(s, bluetooth))
 return PA_HOOK_OK;
 
+/* Do not automatically switch profiles for headsets, just in case */
+if (pa_hashmap_get(port-profiles, hsp) || 
pa_hashmap_get(port-profiles, a2dp))
+return PA_HOOK_OK;
+
 is_active_profile = card-active_profile == pa_hashmap_get(port-profiles, 
card-active_profile-name);
 
 if (is_active_profile  port-available == PA_PORT_AVAILABLE_YES)
-- 
1.7.11.7

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

[pulseaudio-discuss] [PATCH v1 3/3] conf: Load bluetooth-policy module by default

2012-11-26 Thread Mikel Astiz

From: Mikel Astiz mikel.as...@bmw-carit.de

Headset use-cases shouldn't get affected by this module and the support
for A2DP source is interesting, therefore load the module by default.
---
 src/daemon/default.pa.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/daemon/default.pa.in b/src/daemon/default.pa.in
index e3f1f4f..13e548b 100755
--- a/src/daemon/default.pa.in
+++ b/src/daemon/default.pa.in
@@ -84,6 +84,10 @@ load-module module-jackdbus-detect
 
 ifelse(@HAVE_BLUEZ@, 1, [dnl
 ### Automatically load driver modules for Bluetooth hardware
+.ifexists module-bluetooth-policy@PA_SOEXT@
+load-module module-bluetooth-policy
+.endif
+
 .ifexists module-bluetooth-discover@PA_SOEXT@
 load-module module-bluetooth-discover
 .endif
-- 
1.7.11.7

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

Re: [pulseaudio-discuss] [PATCH v1 0/3] bluetooth: Headset port availability

2012-11-26 Thread Luiz Augusto von Dentz

Hi Mikel,

On Mon, Nov 26, 2012 at 7:32 PM, Mikel Astiz mikel.astiz@gmail.com wrote:
 From: Mikel Astiz mikel.as...@bmw-carit.de

 This patchset extends the previous patch (resent unmodified here) with the 
 policy change suggested by Tanu.

 It seems no conclusion was reached about the names etc. but I believe this is 
 the best alternative without the form factor and in any case the strings can 
 easily be changed during/after pushing.

 Mikel Astiz (3):
   bluetooth: Merge headset ports into one
   bluetooth: Disable profile auto-switch policy for headsets
   conf: Load bluetooth-policy module by default

  src/daemon/default.pa.in|  4 ++
  src/modules/bluetooth/module-bluetooth-device.c | 72 
 ++---
  src/modules/bluetooth/module-bluetooth-policy.c |  4 ++
  3 files changed, 60 insertions(+), 20 deletions(-)

 --
 1.7.11.7


I would like to see some good reasoning to do these changes, how we
gonna play out with port availability if we only have one that map for
both profiles? What about if one of the profiles disconnects /became
unavailable? Does that mean that all profiles has the same priority?


--
Luiz Augusto von Dentz
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/3] sink_input: new volume_factor system

2012-11-26 Thread Paul Menzel

Dear Flavio,


thank you for your patches. As you are asked to resend anyway, here are
some nitpicks.


Am Mittwoch, den 14.11.2012, 15:19 -0200 schrieb Flavio Ceolin:
 This patch makes possible to set more than one volume factor.  The

s,makes,makes it,

Also starting a commit message with »This patch« is redundant most of
the time.

 real value of the volume_factor will be the multiplication of these
 values.

Something like »Implement setting of more than one volume factor. …« or
so could also be used.

 ---
  src/pulsecore/sink-input.c | 172 
 ++---
  src/pulsecore/sink-input.h |  19 +++--
  2 files changed, 158 insertions(+), 33 deletions(-)

[…]


Thanks,

Paul


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] [PATCH 1/3] sink_input: new volume_factor system

2012-11-26 Thread Flávio Ceolin

Hi Paul,

On Mon, Nov 26, 2012 at 7:10 PM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Dear Flavio,


 thank you for your patches. As you are asked to resend anyway, here are
 some nitpicks.


 Am Mittwoch, den 14.11.2012, 15:19 -0200 schrieb Flavio Ceolin:
 This patch makes possible to set more than one volume factor.  The

 s,makes,makes it,

 Also starting a commit message with »This patch« is redundant most of
 the time.

 real value of the volume_factor will be the multiplication of these
 values.

 Something like »Implement setting of more than one volume factor. …« or
 so could also be used.

 ---
  src/pulsecore/sink-input.c | 172 
 ++---
  src/pulsecore/sink-input.h |  19 +++--
  2 files changed, 158 insertions(+), 33 deletions(-)

 […]


 Thanks,

 Paul

Thank you for reviewing the patch, i going to fix these mistakes.

Best Regards,
Flavio Ceolin
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v1 0/3] bluetooth: Headset port availability

2012-11-26 Thread Mikel Astiz

Hi Luiz,

On Mon, Nov 26, 2012 at 9:17 PM, Luiz Augusto von Dentz
luiz.de...@gmail.com wrote:
 Hi Mikel,

 On Mon, Nov 26, 2012 at 7:32 PM, Mikel Astiz mikel.astiz@gmail.com 
 wrote:
 From: Mikel Astiz mikel.as...@bmw-carit.de

 This patchset extends the previous patch (resent unmodified here) with the 
 policy change suggested by Tanu.

 It seems no conclusion was reached about the names etc. but I believe this 
 is the best alternative without the form factor and in any case the strings 
 can easily be changed during/after pushing.

 Mikel Astiz (3):
   bluetooth: Merge headset ports into one
   bluetooth: Disable profile auto-switch policy for headsets
   conf: Load bluetooth-policy module by default

  src/daemon/default.pa.in|  4 ++
  src/modules/bluetooth/module-bluetooth-device.c | 72 
 ++---
  src/modules/bluetooth/module-bluetooth-policy.c |  4 ++
  3 files changed, 60 insertions(+), 20 deletions(-)

 --
 1.7.11.7


 I would like to see some good reasoning to do these changes, how we

There was a long IRC discussion about this and the conclusion was that
introducing independent ports for A2DP and HSP/HFP headsets was a
regression (as first pointed out in [1]). There was no general
consensus but this seems the most strict interpretation of a port,
which represents a physical device no matter the underlying protocols.

 gonna play out with port availability if we only have one that map for

On how this affects Bluetooth, you are right that we now expose less
information in the port-availability. This was useful not only for
testingdebugging, but also to implement several policies in other
modules such as module-bluetooth-policy. The solution for the later
problem is to extend the API in bluetooth-util to expose the same
information.

 both profiles? What about if one of the profiles disconnects /became
 unavailable? Does that mean that all profiles has the same priority?

Regarding the profile priorities, I'm not sure what you mean. The
card-profile priorities remain untouched, but obviously the
profile-port mapping has changed and therefore port priorities will
get affected. Do you see any problem with this?

Cheers,
Mikel

[1] 
http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-November/015402.html
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API

Re: [pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

Re: [pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

Re: [pulseaudio-discuss] Bluetooth regression: a2dp not selectable

Re: [pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

Re: [pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

Re: [pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

Re: [pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

Re: [pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

Re: [pulseaudio-discuss] Bluetooth regression: a2dp not selectable

[pulseaudio-discuss] [PATCH v1 0/3] bluetooth: Headset port availability

[pulseaudio-discuss] [PATCH v1 1/3] bluetooth: Merge headset ports into one

[pulseaudio-discuss] [PATCH v1 2/3] bluetooth: Disable profile auto-switch policy for headsets

[pulseaudio-discuss] [PATCH v1 3/3] conf: Load bluetooth-policy module by default

Re: [pulseaudio-discuss] [PATCH v1 0/3] bluetooth: Headset port availability

Re: [pulseaudio-discuss] [PATCH 1/3] sink_input: new volume_factor system

Re: [pulseaudio-discuss] [PATCH 1/3] sink_input: new volume_factor system

Re: [pulseaudio-discuss] [PATCH v1 0/3] bluetooth: Headset port availability

19 matches

Site Navigation

Mail list logo

Footer information