Hi João Paulo,
On Fri, Jul 12, 2013 at 8:06 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
This series reverts the previous support for BlueZ 5, renames the bluetooth
portion of the old modules name for bluez4, creates a new set of modules for
BlueZ 5
Hi,
On Fri, Aug 31, 2012 at 12:51 PM, Mikel Astiz mikel.astiz@gmail.com wrote:
From: Mikel Astiz mikel.as...@bmw-carit.de
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
Hi Tanu,
On Mon, Jul 8, 2013 at 3:06 PM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
On Mon, 2013-07-01 at 10:27 +0200, Mikel Astiz wrote:
From: Mikel Astiz mikel.as...@bmw-carit.de
The source output and sink inputs should be corked if the corresponding
sink/source is suspended
From: Mikel Astiz mikel.as...@bmw-carit.de
The source output and sink inputs should be corked if the corresponding
sink/source is suspended, as handled during module initialization. This
also needs to be handled during stream move, because the suspend state
of the destination sink/source might
Hi Georg,
On Sun, Jun 30, 2013 at 2:48 PM, Georg Chini ge...@chini.tk wrote:
Hi again,
On 30.06.2013 12:57, Mikel Astiz wrote:
Hi Georg,
On Sun, Jun 30, 2013 at 11:00 AM, Georg Chini ge...@chini.tk wrote:
On 30.06.2013 10:28, Mikel Astiz wrote:
Hi Georg,
On Sat, Jun 29, 2013 at 9:39
Hi Georg,
On Sat, Jun 29, 2013 at 9:39 PM, Georg Chini ge...@chini.tk wrote:
On 28.06.2013 08:23, Mikel Astiz wrote:
Hi Georg,
On Thu, Jun 27, 2013 at 1:31 PM, Georg Chini ge...@chini.tk wrote:
On 27.06.2013 08:22, Mikel Astiz wrote:
Hi Georg,
On Wed, Jun 26, 2013 at 8:45 PM, Georg
Hi Georg,
On Sun, Jun 30, 2013 at 11:00 AM, Georg Chini ge...@chini.tk wrote:
On 30.06.2013 10:28, Mikel Astiz wrote:
Hi Georg,
On Sat, Jun 29, 2013 at 9:39 PM, Georg Chini ge...@chini.tk wrote:
On 28.06.2013 08:23, Mikel Astiz wrote:
Hi Georg,
On Thu, Jun 27, 2013 at 1:31 PM, Georg
Hi Georg,
On Thu, Jun 27, 2013 at 1:31 PM, Georg Chini ge...@chini.tk wrote:
On 27.06.2013 08:22, Mikel Astiz wrote:
Hi Georg,
On Wed, Jun 26, 2013 at 8:45 PM, Georg Chini ge...@chini.tk wrote:
Hi Mikel,
On 26.06.2013 16:54, Mikel Astiz wrote:
Hi Georg,
On Wed, Jun 26, 2013 at 3:27
From: Mikel Astiz mikel.as...@bmw-carit.de
The previous implementation to send 2 packets first and then try to
account the received packets vs sent packets seems to generate some
issues in several devices. The alternative is to always do it
time-based.
---
This is WIP and thus not intended
Hi Georg,
On Wed, Jun 26, 2013 at 8:45 PM, Georg Chini ge...@chini.tk wrote:
Hi Mikel,
On 26.06.2013 16:54, Mikel Astiz wrote:
Hi Georg,
On Wed, Jun 26, 2013 at 3:27 PM, Georg Chini ge...@chini.tk wrote:
Hi Mikel,
On 24.06.2013 11:22, Mikel Astiz wrote:
This seems a successful
Hi Georg,
On Wed, Jun 26, 2013 at 3:27 PM, Georg Chini ge...@chini.tk wrote:
Hi Mikel,
On 24.06.2013 11:22, Mikel Astiz wrote:
This seems a successful connection of HSP/HFP. The module is however not
loaded because the overall connection procedure (org.bluez.Audio) is still
ongoing
Hi Georg,
On Thu, Jun 20, 2013 at 5:02 PM, Georg Chini ge...@chini.tk wrote:
Hello,
after upgrading to Pulseaudio 4.0 my bluetooth devices (headset, 2 mobiles)
are no longer discovered. I am running Debian unstable on an amd64 CPU,
the new Debian package was released a few days ago.
I also
Hi Bram,
On Fri, Jun 14, 2013 at 10:20 AM, Bram de Jong bram.dej...@gmail.com wrote:
Hi Mikel,
As Tanu mentioned, this can be done calling
HandsfreeGateway.Connect(). You can do this in command line or using a
tool such as d-feet. People tend to think that Audio.Connect()
connects all audio
.
I would strongly encourage to upgrade to a more recent version of PA. Some
of the fixes after 2.1 were specifically addressing this Bluetooth role.
Cheers,
Mikel
- bram
On Fri, Jun 14, 2013 at 12:03 PM, Mikel Astiz mikel.astiz@gmail.com
wrote:
Hi Bram,
On Fri, Jun 14, 2013 at 10:20
Hi Bram,
On Thu, Jun 13, 2013 at 3:59 PM, Bram de Jong bram.dej...@gmail.com wrote:
On Thu, Jun 13, 2013 at 1:39 PM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
What I want to do is use the Raspberry as a speaker only using the
low-latency HSP (which you cann HFGW) bluetooth profile.
Hi Alex,
On Sat, Jun 8, 2013 at 8:45 PM, Alexander Winnig
vernehmlass...@googlemail.com wrote:
So I managed to install pulseaudio 4.0 including sbc, speex, bluez and d-bus
and I encounter the same problem. I installed D-feet to monitor dbus. This
didn't really help move things forward as
Hi Alex,
On Wed, Jun 5, 2013 at 11:15 AM, Alexander Winnig
vernehmlass...@googlemail.com wrote:
Thanks.
Hi Alex,
On Tue, Jun 4, 2013 at 9:45 PM, Alexander Winnig
vernehmlass...@googlemail.com wrote:
Thanks Mikel.
Am 04.06.2013 14:02, schrieb Mikel Astiz:
parecord -r --device
Hi Alex,
On Tue, Jun 4, 2013 at 9:45 PM, Alexander Winnig
vernehmlass...@googlemail.com wrote:
Thanks Mikel.
Am 04.06.2013 14:02, schrieb Mikel Astiz:
parecord -r --device=bluez_source.00_1A_7D_11_C0_66 mm.wav
in my case. Creates a crackling sound in the earpiece and a mm.wav of zero
Hi,
On Wed, Mar 13, 2013 at 9:20 AM, Tanu Kaskinen ta...@iki.fi wrote:
On Tue, 2013-03-12 at 14:02 +0100, Mikel Astiz wrote:
On Tue, Mar 12, 2013 at 1:42 PM, Tanu Kaskinen ta...@iki.fi wrote:
If the MTU is initially set to 128, it sounds logical that it may be
reconfigured to 128 too
Hi Alex,
On Tue, Jun 4, 2013 at 1:10 PM, Alexander Winnig
vernehmlass...@googlemail.com wrote:
I re-copied a new wheezy-image on my sd-card. Now pactl list sources
short shows the bluez-device. But still, an empty file is the output.
How exactly did you record the file? Did you ensure that
Hi David,
On Wed, May 22, 2013 at 12:00 PM, David Henningsson
david.hennings...@canonical.com wrote:
On 05/21/2013 05:18 PM, Mikel Astiz wrote:
Hi David,
On Tue, May 21, 2013 at 3:55 PM, David Henningsson
david.hennings...@canonical.com wrote:
On 05/21/2013 02:58 PM, Mikel Astiz wrote
Hi David,
On Tue, May 21, 2013 at 2:37 PM, David Henningsson
david.hennings...@canonical.com wrote:
On 05/20/2013 11:48 AM, Mikel Astiz wrote:
From: Mikel Astiz mikel.as...@bmw-carit.de
These patches address a regression existing in the master branch, which
specially affects the gnome UI
Hi David,
On Tue, May 21, 2013 at 3:55 PM, David Henningsson
david.hennings...@canonical.com wrote:
On 05/21/2013 02:58 PM, Mikel Astiz wrote:
Hi David,
On Tue, May 21, 2013 at 2:37 PM, David Henningsson
david.hennings...@canonical.com wrote:
On 05/20/2013 11:48 AM, Mikel Astiz wrote
From: Mikel Astiz mikel.as...@bmw-carit.de
These patches address a regression existing in the master branch, which
specially affects the gnome UI. More info in
https://bugs.freedesktop.org/show_bug.cgi?id=64713.
The proposed solution is fairly simple but triggers the question whether
From: Mikel Astiz mikel.as...@bmw-carit.de
Both operations are currently independent and their order can therefore
be swapped.
---
src/modules/bluetooth/module-bluetooth-device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/modules/bluetooth/module-bluetooth
From: Mikel Astiz mikel.as...@bmw-carit.de
Commit 17b3cb954b179392e80b0a46d8f2ba4693aec386 merged Bluetooth ports
into two ports (one for input, one for output) but the association
between ports and profiles was lost.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=64713
---
src/modules
From: Mikel Astiz mikel.as...@bmw-carit.de
There's some ongoing work by João Paulo to add oFono support to PulseAudio.
This requires the adoption of some backend infrastructure in order to keep the
codebase and dependencies clean, which is exactly what this patchset is
proposing.
For reasons
From: Mikel Astiz mikel.as...@bmw-carit.de
Components other than BlueZ can also implement Bluetooth profiles and
some infrastructure is required to keep the codebase cleanly split.
---
src/modules/bluetooth/bluetooth-util.c | 32
src/modules/bluetooth/bluetooth
From: Mikel Astiz mikel.as...@bmw-carit.de
Make a clear split to define an API implementing transport operations,
and how these backends should report the events to the Bluetooth core.
---
src/modules/bluetooth/bluetooth-util.c | 143 +++--
src/modules/bluetooth
From: Mikel Astiz mikel.as...@bmw-carit.de
Backends are responsible for the notification of new transports, which
is backend-dependant. The core still holds ownership of the transport
objects.
---
src/modules/bluetooth/bluetooth-util.c | 45 --
src/modules
From: Mikel Astiz mikel.as...@bmw-carit.de
BlueZ 5 supports external profiles, meaning that certain Bluetooth
profiles (e.g. HFP/HSP) are completely handled outside BlueZ.
However, some other profiles (i.e. A2DP) are still implemented inside
BlueZ, so let's keep a BlueZ-specific backend inside
From: Mikel Astiz mikel.as...@bmw-carit.de
Replace the transport path with the device path and the profile id,
which should be more relevant and also backend-agnostic.
---
src/modules/bluetooth/bluetooth-util.c | 9 +
src/modules/bluetooth/module-bluetooth-device.c | 11
From: Mikel Astiz mikel.as...@bmw-carit.de
bluetooth-util internally implements a backend for BlueZ Media API
but it's nevertheless convenient to have the backend-specific data split
into separated data structures.
---
src/modules/bluetooth/bluetooth-util.c | 108
From: Mikel Astiz mikel.as...@bmw-carit.de
This callback notifies the backend that the core needs to destroy the
transport.
---
src/modules/bluetooth/bluetooth-util.c | 12 ++--
src/modules/bluetooth/bluetooth-util.h | 3 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git
From: Mikel Astiz mikel.as...@bmw-carit.de
Transport acquisition and release are backend-dependant so add the
necessary callbacks to struct pa_bluetooth_backend.
---
src/modules/bluetooth/bluetooth-util.c | 28
src/modules/bluetooth/bluetooth-util.h | 5 +
2
From: Mikel Astiz mikel.as...@bmw-carit.de
---
src/modules/bluetooth/bluetooth-util.c | 20 +---
src/modules/bluetooth/bluetooth-util.h | 2 ++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c
b/src/modules/bluetooth
From: Mikel Astiz mikel.as...@bmw-carit.de
---
src/modules/bluetooth/bluetooth-util.c | 20 +---
src/modules/bluetooth/bluetooth-util.h | 2 ++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c
b/src/modules/bluetooth
Hi Tanu,
On Fri, May 10, 2013 at 10:01 AM, Tanu Kaskinen tanu.kaski...@intel.com wrote:
On Fri, 2013-05-10 at 09:06 +0200, Mikel Astiz wrote:
Hi Tanu,
On Fri, May 10, 2013 at 7:48 AM, Tanu Kaskinen tanu.kaski...@intel.com
wrote:
On Mon, 2013-04-29 at 18:28 +0200, Mikel Astiz wrote:
From
From: Mikel Astiz mikel.as...@bmw-carit.de
Sending v5 with the following changes:
- Leaked D-Bus matches removed as pointed out by João Paulo.
- Several warning messages added as suggested by Tanu.
- Minor code refactoring in pa_bluetooth_transport_release().
Again, the last 5 patches are sent
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signals ObjectManager.InterfacesAdded and
ObjectManager.InterfacesRemoved, and process the devices that are
registered and unregistered dynamically.
---
src/modules/bluetooth/bluetooth-util.c | 60
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signal Properties.PropertiesChanged and process the
properties corresponding to the tracked devices.
---
src/modules/bluetooth/bluetooth-util.c | 33 +
1 file changed, 33 insertions(+)
diff --git
From: Mikel Astiz mikel.as...@bmw-carit.de
Add the code to parse the properties of the media transport object when
a PropertiesChanged signal is received.
Note that the transport might have an owner other than BlueZ, and thus
the property changes would be emitted from arbitrary senders
From: Mikel Astiz mikel.as...@bmw-carit.de
BlueZ 5 exposes a 'State' property in the media transport interface.
With regard to PA, this replaces the profile-specific interfaces, since
they were being used to know if the audio was streaming or not.
---
src/modules/bluetooth/bluetooth-util.c | 42
From: Mikel Astiz mikel.as...@bmw-carit.de
The new D-Bus API doesn't support access rights, which weren't used by
PulseAudio anyway, but it does solve a race condition: now optional
acquires can be implemented by bluetooth-util atomically using the D-Bus
TryAcquire() method.
---
src/modules
From: Mikel Astiz mikel.as...@bmw-carit.de
With BlueZ 5, if the remote device suspends the audio, the transport
state will change to idle and the endpoint is not required to release
the transport, since this could introduce race conditions. Therefore,
ignore the call
From: Mikel Astiz mikel.as...@bmw-carit.de
Register the HSP/HFP endpoints in BlueZ 5 Media API for the sake of
completeness, despite the fact that there's currently no known user of
such an endpoint.
---
src/modules/bluetooth/bluetooth-util.c | 5 -
1 file changed, 5 deletions(-)
diff --git
From: Mikel Astiz mikel.as...@bmw-carit.de
Now that the transport can be configured from some other process (i.e.
oFono), there is no guarantee that the UUID from BlueZ will already have
been received.
This requires PulseAudio to assume that the UUID is actually supported
by the device
From: Mikel Astiz mikel.as...@bmw-carit.de
If BlueZ 5 is in use, the standard org.freedesktop.DBus.Properties needs
to be used instead of the old SetProperty() method.
---
src/modules/bluetooth/bluetooth-util.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/modules
From: Mikel Astiz mikel.as...@bmw-carit.de
In BlueZ 5, the microphone and speaker gains are exposed as properties
of the MediaTransport1 interface.
---
src/modules/bluetooth/bluetooth-util.c | 41 ++
1 file changed, 41 insertions(+)
diff --git a/src/modules
From: Vinicius Costa Gomes vinicius.go...@openbossa.org
According to the HFP 1.6 spec, the default codec (CVSD) has ID 0x01.
This change has no effect in older versions of BlueZ since the codec ID
was ignored for HFP, due to the fact that HFP versions prior to 1.6 do
not have such a field.
---
Hi Tanu,
On Thu, May 9, 2013 at 10:30 AM, Tanu Kaskinen tanu.kaski...@intel.com wrote:
On Mon, 2013-04-29 at 18:28 +0200, Mikel Astiz wrote:
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signal Properties.PropertiesChanged and process the
properties corresponding
Hi João Paulo,
On Tue, May 7, 2013 at 12:01 AM, João Paulo Rechi Vita
jprv...@gmail.com wrote:
On Mon, Apr 29, 2013 at 1:28 PM, Mikel Astiz mikel.astiz@gmail.com
wrote:
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signal Properties.PropertiesChanged and process
Hi João Paulo,
On Thu, May 2, 2013 at 10:05 PM, João Paulo Rechi Vita
jprv...@gmail.com wrote:
On Thu, May 2, 2013 at 4:17 AM, Mikel Astiz mikel.astiz@gmail.com wrote:
Hi João Paulo,
On Tue, Apr 30, 2013 at 9:13 PM, João Paulo Rechi Vita
jprv...@gmail.com wrote:
On Tue, Apr 30, 2013
Hi João Paulo,
On Tue, Apr 30, 2013 at 9:13 PM, João Paulo Rechi Vita
jprv...@gmail.com wrote:
On Tue, Apr 30, 2013 at 7:20 AM, Luiz Augusto von Dentz
luiz.de...@gmail.com wrote:
Hi Mikel,
On Mon, Apr 29, 2013 at 7:27 PM, Mikel Astiz mikel.astiz@gmail.com
wrote:
From: Mikel Astiz
Hi Tanu,
On Mon, Apr 29, 2013 at 4:01 PM, Tanu Kaskinen tanu.kaski...@intel.com wrote:
On Fri, 2013-04-26 at 12:30 -0300, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
---
As already discussed with Tanuk and Mikel, this series should be applied to
the
master
Hi Tanu,
On Mon, Apr 29, 2013 at 4:38 PM, Tanu Kaskinen tanu.kaski...@intel.com wrote:
On Mon, 2013-04-29 at 16:20 +0200, Mikel Astiz wrote:
On Mon, Apr 29, 2013 at 4:01 PM, Tanu Kaskinen tanu.kaski...@intel.com
wrote:
On Fri, 2013-04-26 at 12:30 -0300, jprv...@gmail.com wrote:
src
tanu.kaski...@intel.com
wrote:
On Mon, 2013-04-29 at 16:20 +0200, Mikel Astiz wrote:
On Mon, Apr 29, 2013 at 4:01 PM, Tanu Kaskinen tanu.kaski...@intel.com
wrote:
On Fri, 2013-04-26 at 12:30 -0300, jprv...@gmail.com wrote:
src/modules/bluetooth/module-bluetooth-device.c | 1 +
1
From: Mikel Astiz mikel.as...@bmw-carit.de
Resending v3 with a small change in patch 3/16, where the Name property of
org.bluez.Device1 is now considered as optional.
This version is intended for the next branch since it depends on
module-bluetooth-device not making use of device-name, which
From: Mikel Astiz mikel.as...@bmw-carit.de
Check the existence of ObjectManager to detect the version of the
running daemon. If the interface exists, it should be BlueZ 5.
---
src/modules/bluetooth/bluetooth-util.c | 52 --
1 file changed, 50 insertions(+), 2
From: Mikel Astiz mikel.as...@bmw-carit.de
Parse the result of ObjectManager.GetManagedObjects(), which includes
all objects registered, their interfaces and the corresponding
properties per interface.
---
src/modules/bluetooth/bluetooth-util.c | 125 +++--
1 file
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signals ObjectManager.InterfacesAdded and
ObjectManager.InterfacesRemoved, and process the devices that are
registered and unregistered dynamically.
---
src/modules/bluetooth/bluetooth-util.c | 58
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signal Properties.PropertiesChanged and process the
properties corresponding to the tracked devices.
---
src/modules/bluetooth/bluetooth-util.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/src
From: Mikel Astiz mikel.as...@bmw-carit.de
Use the new interface name if BlueZ 5 has been detected.
---
src/modules/bluetooth/bluetooth-util.c | 51 --
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c
b/src
From: Mikel Astiz mikel.as...@bmw-carit.de
Use the new interface name if BlueZ 5 has been detected.
---
src/modules/bluetooth/bluetooth-util.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c
b/src/modules/bluetooth/bluetooth
From: Mikel Astiz mikel.as...@bmw-carit.de
Use the new interface name if BlueZ 5 has been detected.
---
src/modules/bluetooth/bluetooth-util.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c
b/src/modules/bluetooth
From: Mikel Astiz mikel.as...@bmw-carit.de
Add the code to parse the properties of the media transport object when
a PropertiesChanged signal is received.
Note that the transport might have an owner other than BlueZ, and thus
the property changes would be emitted from arbitrary senders
From: Mikel Astiz mikel.as...@bmw-carit.de
The new D-Bus API doesn't support access rights, which weren't used by
PulseAudio anyway, but it does solve a race condition: now optional
acquires can be implemented by bluetooth-util atomically using the D-Bus
TryAcquire() method.
---
src/modules
From: Mikel Astiz mikel.as...@bmw-carit.de
With BlueZ 5, if the remote device suspends the audio, the transport
state will change to idle and the endpoint is not required to release
the transport, since this could introduce race conditions. Therefore,
ignore the call
From: Mikel Astiz mikel.as...@bmw-carit.de
Register the HSP/HFP endpoints in BlueZ 5 Media API for the sake of
completeness, despite the fact that there's currently no known user of
such an endpoint.
---
src/modules/bluetooth/bluetooth-util.c | 5 -
1 file changed, 5 deletions(-)
diff --git
From: Mikel Astiz mikel.as...@bmw-carit.de
Now that the transport can be configured from some other process (i.e.
oFono), there is no guarantee that the UUID from BlueZ will already have
been received.
This requires PulseAudio to assume that the UUID is actually supported
by the device
From: Vinicius Costa Gomes vinicius.go...@openbossa.org
According to the HFP 1.6 spec, the default codec (CVSD) has ID 0x01.
This change has no effect in older versions of BlueZ since the codec ID
was ignored for HFP, due to the fact that HFP versions prior to 1.6 do
not have such a field.
---
From: Mikel Astiz mikel.as...@bmw-carit.de
If BlueZ 5 is in use, the standard org.freedesktop.DBus.Properties needs
to be used instead of the old SetProperty() method.
---
src/modules/bluetooth/bluetooth-util.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/modules
From: Mikel Astiz mikel.as...@bmw-carit.de
In BlueZ 5, the microphone and speaker gains are exposed as properties
of the MediaTransport1 interface.
---
src/modules/bluetooth/bluetooth-util.c | 41 ++
1 file changed, 41 insertions(+)
diff --git a/src/modules
Hi João Paulo,
On Fri, Apr 26, 2013 at 5:30 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
The org.bluez.Device1.Name property is optional and may not be present
(that happens with the PTS 4.7.0), so it's better not to expose it to
clients so they don't rely
Hi João,
On Wed, Apr 24, 2013 at 7:51 PM, João Paulo Rechi Vita
jprv...@openbossa.org wrote:
On Wed, Apr 24, 2013 at 3:29 AM, Mikel Astiz mikel.astiz@gmail.com
wrote:
Hi João Paulo,
On Tue, Apr 23, 2013 at 10:48 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv
Hi João Paulo,
On Thu, Apr 25, 2013 at 9:36 AM, Mikel Astiz mikel.astiz@gmail.com wrote:
Hi João,
On Wed, Apr 24, 2013 at 7:51 PM, João Paulo Rechi Vita
jprv...@openbossa.org wrote:
On Wed, Apr 24, 2013 at 3:29 AM, Mikel Astiz mikel.astiz@gmail.com
wrote:
Hi João Paulo,
On Tue
Hi João Paulo,
On Tue, Apr 23, 2013 at 10:48 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
According to the BlueZ API documentation the 'Alias' property should be
preffered over the 'Name' property. Also, if the device doesn't have a
remote name the 'Name'
Hi João,
On Mon, Apr 22, 2013 at 3:30 PM, João Paulo Rechi Vita
jprv...@openbossa.org wrote:
On Mon, Apr 22, 2013 at 4:43 AM, Mikel Astiz mikel.astiz@gmail.com
wrote:
Hi João Paulo,
On Mon, Apr 22, 2013 at 5:07 AM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv
From: Mikel Astiz mikel.as...@bmw-carit.de
The patchset has been hanging around for a while and several efforts exist that
depend on this series, so it seems we should merge this despite the existing
discussions about how different backends (BlueZ 4, BlueZ 5, oFono, etc.) should
be supported
From: Mikel Astiz mikel.as...@bmw-carit.de
Parse the result of ObjectManager.GetManagedObjects(), which includes
all objects registered, their interfaces and the corresponding
properties per interface.
---
src/modules/bluetooth/bluetooth-util.c | 125 +++--
1 file
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signals ObjectManager.InterfacesAdded and
ObjectManager.InterfacesRemoved, and process the devices that are
registered and unregistered dynamically.
---
src/modules/bluetooth/bluetooth-util.c | 58
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signal Properties.PropertiesChanged and process the
properties corresponding to the tracked devices.
---
src/modules/bluetooth/bluetooth-util.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/src
From: Mikel Astiz mikel.as...@bmw-carit.de
Use the new interface name if BlueZ 5 has been detected.
---
src/modules/bluetooth/bluetooth-util.c | 51 --
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c
b/src
From: Mikel Astiz mikel.as...@bmw-carit.de
Use the new interface name if BlueZ 5 has been detected.
---
src/modules/bluetooth/bluetooth-util.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c
b/src/modules/bluetooth/bluetooth
From: Mikel Astiz mikel.as...@bmw-carit.de
Use the new interface name if BlueZ 5 has been detected.
---
src/modules/bluetooth/bluetooth-util.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c
b/src/modules/bluetooth
From: Mikel Astiz mikel.as...@bmw-carit.de
BlueZ 5 exposes a 'State' property in the media transport interface.
With regard to PA, this replaces the profile-specific interfaces, since
they were being used to know if the audio was streaming or not.
---
src/modules/bluetooth/bluetooth-util.c | 42
From: Mikel Astiz mikel.as...@bmw-carit.de
Register the HSP/HFP endpoints in BlueZ 5 Media API for the sake of
completeness, despite the fact that there's currently no known user of
such an endpoint.
---
src/modules/bluetooth/bluetooth-util.c | 5 -
1 file changed, 5 deletions(-)
diff --git
From: Vinicius Costa Gomes vinicius.go...@openbossa.org
According to the HFP 1.6 spec, the default codec (CVSD) has ID 0x01.
This change has no effect in older versions of BlueZ since the codec ID
was ignored for HFP, due to the fact that HFP versions prior to 1.6 do
not have such a field.
---
From: Mikel Astiz mikel.as...@bmw-carit.de
Now that the transport can be configured from some other process (i.e.
oFono), there is no guarantee that the UUID from BlueZ will already have
been received.
This requires PulseAudio to assume that the UUID is actually supported
by the device
From: Mikel Astiz mikel.as...@bmw-carit.de
In BlueZ 5, the microphone and speaker gains are exposed as properties
of the MediaTransport1 interface.
---
src/modules/bluetooth/bluetooth-util.c | 41 ++
1 file changed, 41 insertions(+)
diff --git a/src/modules
Hi João,
On Wed, Apr 17, 2013 at 7:02 PM, João Paulo Rechi Vita
jprv...@gmail.com wrote:
On Tue, Apr 16, 2013 at 10:40 AM, Mikel Astiz mikel.astiz@gmail.com
wrote:
From: Mikel Astiz mikel.as...@bmw-carit.de
In BlueZ 5, the microphone and speaker gains are exposed as properties
Hi João Paulo,
On Wed, Apr 17, 2013 at 7:00 PM, João Paulo Rechi Vita
jprv...@gmail.com wrote:
On Tue, Apr 16, 2013 at 10:40 AM, Mikel Astiz mikel.astiz@gmail.com
wrote:
From: Mikel Astiz mikel.as...@bmw-carit.de
Now that the transport can be configured from some other process (i.e
Hi João Paulo,
On Mon, Apr 15, 2013 at 11:53 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
---
src/modules/bluetooth/bluetooth-util.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/modules/bluetooth/bluetooth-util.c
Hi João Paulo,
On Mon, Apr 15, 2013 at 11:53 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
When the transport backend is oFono the stream file descriptor is passed
through the NewConnection() method call. Additionally, set the kernel
default SCO MTU value
Hi João Paulo,
On Wed, Apr 17, 2013 at 9:20 PM, João Paulo Rechi Vita
jprv...@openbossa.org wrote:
On Mon, Apr 15, 2013 at 6:53 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
CVSD and mSBC stream have different sample rates, and the CODEC of the
Audio
Hi João Paulo,
On Thu, Apr 18, 2013 at 4:04 PM, João Paulo Rechi Vita
jprv...@openbossa.org wrote:
On Thu, Apr 18, 2013 at 10:43 AM, Mikel Astiz mikel.astiz@gmail.com
wrote:
Hi João Paulo,
On Mon, Apr 15, 2013 at 11:53 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv
From: Mikel Astiz mikel.as...@bmw-carit.de
I resubmit this patchset as-is after updating it according to the latest
upstream changes.
The patchset has been hanging around for a while and several efforts exist that
depend on this series, so it seems we should merge this despite the existing
From: Mikel Astiz mikel.as...@bmw-carit.de
Parse the result of ObjectManager.GetManagedObjects(), which includes
all objects registered, their interfaces and the corresponding
properties per interface.
---
src/modules/bluetooth/bluetooth-util.c | 120 +++--
1 file
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signals ObjectManager.InterfacesAdded and
ObjectManager.InterfacesRemoved, and process the devices that are
registered and unregistered dynamically.
---
src/modules/bluetooth/bluetooth-util.c | 58
From: Mikel Astiz mikel.as...@bmw-carit.de
Install matches for signal Properties.PropertiesChanged and process the
properties corresponding to the tracked devices.
---
src/modules/bluetooth/bluetooth-util.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/src
1 - 100 of 507 matches
Mail list logo
