[pulseaudio-discuss] ARM NEON patches, status

2012-08-27 Thread Peter Meerwald
Hello, I have submitted v3 of my ARM NEON patches July 24 (http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-July/014226.html) but not received any feedback I understand this takes some time to review and test; this is just a reminder to make sure the patches do not go unnoticed :)

[pulseaudio-discuss] open pavucontrol of another user

2012-08-27 Thread Martin Hamant
Hi there ! I am working on a custom ubuntu distribution (based on lucid) that runs: - mpd - as mpd user - spawning it's own pulseaudio session. (it is the default configuration). - At least one regular graphical user that uses gnome and pavucontrol ; who uses it's own pulseaudio session too.

Re: [pulseaudio-discuss] Documentation for how rewinding works

2012-08-27 Thread Tanu Kaskinen
On Mon, 2012-08-27 at 09:41 +0800, Raymond Yau wrote: > > > > > > > > it seem that the alsa sink is more complicated than your figure. > > > > The fact that there's a region in the beginning of the sink buffer > that > > shouldn't be rewound is an implementation detail of alsa sink, and > does > >

Re: [pulseaudio-discuss] running in high priority

2012-08-27 Thread Sladjan Ri
I forgot to mention that I was using Debian Wheezy and their standard 64bit kernel. Without high-prio it has worked very good. Regards On Aug 16, 2012 4:55 AM, "Sladjan Ri" wrote: > Hi, > > is it beneficial to run in high priority at all? I tested and found > stuttering with the src-high-quality

[pulseaudio-discuss] [PATCH v1 00/18] Revisiting Bluetooth modules

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz This patchset revisits the mapping between Bluetooth (BT) and PulseAudio (PA) states, as well as how the PA infrastructure and APIs fit the BT use-cases, including desktop and IVI use-cases. The topic has already been discussed several times in the mailing-list and IRC. This

[pulseaudio-discuss] [PATCH v1 01/18] bluetooth: Remove return value of bt_transport_config()

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz The function bt_transport_config() never fails so the code can be simplified by just removing the return value. --- src/modules/bluetooth/module-bluetooth-device.c | 16 +++- 1 files changed, 7 insertions(+), 9 deletions(-) diff --git a/src/modules/bluetooth/modu

[pulseaudio-discuss] [PATCH v1 02/18] bluetooth: Refactor code to helper function

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Make code more readable by introducing the helper function bt_transport_is_acquired(). This also adds assertions to check whether the internal state is consistent. --- src/modules/bluetooth/module-bluetooth-device.c | 14 -- 1 files changed, 12 insertions(+), 2 de

[pulseaudio-discuss] [PATCH v1 03/18] bluetooth: Always config transport after acquire

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz The configuration of the transport should be performed every time the transport has been acquired, since the parameters depend on what the Media API provides. This makes the code more robust, since the existing multiple calls to bt_transport_acquire() do not rely on setup_bt()

[pulseaudio-discuss] [PATCH v1 04/18] bluetooth: Refactor parsing of signal PropertyChanged

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Wrap the code parsing the PropertyChanged signal into a helper function that will return the new state of the interface. --- src/modules/bluetooth/module-bluetooth-device.c | 80 +- 1 files changed, 47 insertions(+), 33 deletions(-) diff --git a/src/modul

[pulseaudio-discuss] [PATCH v1 05/18] bluetooth: Fix wrongly set "phone" role for HFGW

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz The HFGW source should be consistent with the sink by not setting the "phone" intended role. Even though setting this role seems to make sense strictly speaking, the rest of the codebase doesn't handle this well. Therefore, the audio coming from a Bluetooth phone can be routed

[pulseaudio-discuss] [PATCH v1 06/18] sink, source: Support creating suspended sinks and sources

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz The initial state of a sink or source might not necessarily be IDLE, because sometimes it might be suspended from the very beginning. --- src/pulsecore/sink.c |7 +-- src/pulsecore/sink.h |2 ++ src/pulsecore/source.c |7 +-- src/pulsecore/source.h |

[pulseaudio-discuss] [PATCH v1 07/18] bluetooth: Set profile even if transport not acquired

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz If the acquisition of the transport fails, the profile should still be set. In this case the audio is not actually streaming, so the sink and source will be created but left suspended. If the transport needs to be acquired later, for example because the user wants to route the

[pulseaudio-discuss] [PATCH v1 08/18] bluetooth: Provide dummy set_port callbacks

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz There should be one port per sink/source so a dummy set_port callback will be enough. Adding this callback avoid the "operation not implemented" error message and additionally makes the module work nicely with module-switch-on-port-available. --- src/modules/bluetooth/module-b

[pulseaudio-discuss] [PATCH v1 09/18] bluetooth: Support port availability flag

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Use the port availability flag to expose whether a certain profile is connected and whether it's doing actual audio streaming. The proposed mapping is the following: - Profile disconnected: port is unavailable. - Profile is connected (but not streaming/playing): availability uk

[pulseaudio-discuss] [PATCH v1 10/18] bluetooth: Do not acquire transport during profile change

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Until today, setting the card to some profile resulted in a transport acquisition, leading to audio stream setup. This is generally not very interesting and even undesireable for HFGW use-cases, where the Gateway role (the remote end) would typically request the SCO link. Never

[pulseaudio-discuss] [PATCH v1 11/18] bluetooth: Acquire transport when becomes available

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Try to acquire the transport as soon as the audio stream is started, along with the availability flag update. --- src/modules/bluetooth/module-bluetooth-device.c | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/src/modules/bluetooth/mod

[pulseaudio-discuss] [PATCH v1 12/18] bluetooth: Release transport when not available

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Handle the Playing->Connected transition gracefully by releasing the transport and setting the sink and sources as suspended. We also need to take care of the HUP case in the IO thread, since we don't known which of both events (HUP or D-Bus state transition) will be triggered

[pulseaudio-discuss] [PATCH v1 13/18] bluetooth: Do not switch to HFGW automatically

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Card profile hfgw should be no different from the rest, and thus no internal policy inside module-bluetooth-device should decide to switch to its profile automatically. This should be handled by policy modules. --- src/modules/bluetooth/module-bluetooth-device.c | 16 ---

[pulseaudio-discuss] [PATCH v1 14/18] bluetooth: Do not set profile in bluetooth-discover

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Avoid any profile-related policy inside module-bluetooth-discover. We just load module-bluetooth-device and assume the policies to handle these profiles will be implemented somewhere else. --- src/modules/bluetooth/module-bluetooth-discover.c | 14 -- 1 files chan

[pulseaudio-discuss] [PATCH v1 15/18] bluetooth: Avoid suspend-on-idle for HFGW

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz The hfgw card profile (headset role of the HFP Bluetooth profile) has some particularities that make it unsuitable for idle-timeout-based suspension. The motivation starts with the fact that the remote end (the phone) will report to the user whether the audio is being routed to

[pulseaudio-discuss] [PATCH v1 16/18] bluetooth: Handle suspend in module-bluetooth-policy

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Load module-loopback only while the sink or source is not suspended. If it enters suspend state after the module was loaded, this module should be unloaded. This patch is required in order to avoid module-bluetooth-policy always resuming an idle device, therefore undesirably re

[pulseaudio-discuss] [PATCH v1 17/18] bluetooth: Add port availability transition policies

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz Handle availability changes in Bluetooth ports inside module-bluetooth-policy. The implemented behavior is similar to how module-switch-on-port-available behaves, but the conditions are more relaxed and thus more profile changes are triggered. --- src/modules/bluetooth/module-b

[pulseaudio-discuss] [PATCH v1 18/18] bluetooth-experimental: Fix race condition using accesstype "?"

2012-08-27 Thread Mikel Astiz
From: Mikel Astiz BlueZ now supports a flag in the accesstype in order to avoid the race condition between the state-test (state should be "Playing") and the call to Acquire(). This fixes the previously existing race condition during profile change. --- src/modules/bluetooth/module-bluetooth-dev