Hi João Paulo,
On Fri, Jul 12, 2013 at 8:06 PM, wrote:
> From: João Paulo Rechi Vita
>
> 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 supporting A2DP sink and source roles
Hi,
On Fri, Aug 31, 2012 at 12:51 PM, Mikel Astiz wrote:
> 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 fac
Hi Tanu,
On Mon, Jul 8, 2013 at 3:06 PM, Tanu Kaskinen
wrote:
> On Mon, 2013-07-01 at 10:27 +0200, Mikel Astiz wrote:
>> From: Mikel Astiz
>>
>> The source output and sink inputs should be corked if the corresponding
>> sink/source is suspended, as handled during
Hi Georg,
On Sun, Jun 30, 2013 at 2:48 PM, Georg Chini 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 wrote:
>>>
>>> On 30.06.2013 10:28, Mikel Astiz wro
From: Mikel Astiz
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 be different to the
Hi Georg,
On Sun, Jun 30, 2013 at 11:00 AM, Georg Chini wrote:
> On 30.06.2013 10:28, Mikel Astiz wrote:
>>
>> Hi Georg,
>>
>> On Sat, Jun 29, 2013 at 9:39 PM, Georg Chini wrote:
>>>
>>> On 28.06.2013 08:23, Mikel Astiz wrote:
>>>>
>&g
Hi Georg,
On Sat, Jun 29, 2013 at 9:39 PM, Georg Chini wrote:
> On 28.06.2013 08:23, Mikel Astiz wrote:
>>
>> Hi Georg,
>>
>> On Thu, Jun 27, 2013 at 1:31 PM, Georg Chini wrote:
>>>
>>> On 27.06.2013 08:22, Mikel Astiz wrote:
>>>>
>&g
From: Mikel Astiz
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 to be merged.
I'm submi
Hi Georg,
On Thu, Jun 27, 2013 at 1:31 PM, Georg Chini wrote:
> On 27.06.2013 08:22, Mikel Astiz wrote:
>>
>> Hi Georg,
>>
>> On Wed, Jun 26, 2013 at 8:45 PM, Georg Chini wrote:
>>>
>>> Hi Mikel,
>>>
>>>
>>> On 26.06.201
Hi Georg,
On Wed, Jun 26, 2013 at 8:45 PM, Georg Chini 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 wrote:
>>>
>>> Hi Mikel,
>>>
>>
Hi Georg,
On Wed, Jun 26, 2013 at 3:27 PM, Georg Chini 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.A
Hi Georg,
On Thu, Jun 20, 2013 at 5:02 PM, Georg Chini 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 filed a b
f you
reached the point where the profile connects, you're basically done with
oFono.
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
Hi Bram,
On Fri, Jun 14, 2013 at 10:20 AM, Bram de Jong 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 profiles bu
Hi Bram,
On Thu, Jun 13, 2013 at 3:59 PM, Bram de Jong wrote:
> On Thu, Jun 13, 2013 at 1:39 PM, Tanu Kaskinen
> 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. This should
>>> mainly be for making cal
Hi Alex,
On Sat, Jun 8, 2013 at 8:45 PM, Alexander Winnig
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 there's only listed what I alrea
Hi Alex,
On Wed, Jun 5, 2013 at 11:15 AM, Alexander Winnig
wrote:
> Thanks.
>
> Hi Alex,
>
> On Tue, Jun 4, 2013 at 9:45 PM, Alexander Winnig
> wrote:
>
> Thanks Mikel.
>
> Am 04.06.2013 14:02, schrieb Mikel Astiz:
>
>
> parecord -r --device=bluez_source.
Hi Alex,
On Tue, Jun 4, 2013 at 9:45 PM, Alexander Winnig
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 zer
Hi Alex,
On Tue, Jun 4, 2013 at 1:10 PM, Alexander Winnig
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 you're
>> recording fr
Hi,
On Wed, Mar 13, 2013 at 9:20 AM, Tanu Kaskinen wrote:
> On Tue, 2013-03-12 at 14:02 +0100, Mikel Astiz wrote:
>> On Tue, Mar 12, 2013 at 1:42 PM, Tanu Kaskinen wrote:
>> > If the MTU is initially set to 128, it sounds logical that it may be
>> > reconfigured to
Hi David,
On Wed, May 22, 2013 at 4:06 PM, David Henningsson
wrote:
> On 05/22/2013 03:35 PM, Mikel Astiz wrote:
>>
>> Hi David,
>>
>> On Wed, May 22, 2013 at 12:00 PM, David Henningsson
>> wrote:
>>>
>>> On 05/21/2013 05:18 PM, Mikel Astiz wr
Hi David,
On Wed, May 22, 2013 at 12:00 PM, David Henningsson
wrote:
> On 05/21/2013 05:18 PM, Mikel Astiz wrote:
>>
>> Hi David,
>>
>> On Tue, May 21, 2013 at 3:55 PM, David Henningsson
>> wrote:
>>>
>>> On 05/21/2013 02:58 PM, Mikel Astiz wr
Hi David,
On Tue, May 21, 2013 at 3:55 PM, David Henningsson
wrote:
> On 05/21/2013 02:58 PM, Mikel Astiz wrote:
>>
>> Hi David,
>>
>> On Tue, May 21, 2013 at 2:37 PM, David Henningsson
>> wrote:
>>>
>>> On 05/20/2013 11:48 AM,
Hi David,
On Tue, May 21, 2013 at 2:37 PM, David Henningsson
wrote:
> On 05/20/2013 11:48 AM, Mikel Astiz wrote:
>>
>> From: Mikel Astiz
>>
>> These patches address a regression existing in the master branch, which
>> specially affects the gnome UI. More info i
From: Mikel Astiz
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/bluetooth/module
From: Mikel Astiz
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-device.c
b/src/modules
From: Mikel Astiz
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
something like
From: Mikel Astiz
The endpoint is backend-specific and therefore it's logically more
appropriate to use the bluez_backend_private struct as the userdata
pointer in all endpoint callbacks.
---
src/modules/bluetooth/bluetooth-util.c | 39 ++
1 file change
From: Mikel Astiz
---
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/bluetooth-util.c
index 19072d0
From: Mikel Astiz
---
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/bluetooth-util.c
index d89c7a7
From: Mikel Astiz
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 files changed, 33
From: Mikel Astiz
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 a/src/modules/bluetooth
From: Mikel Astiz
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 +++--
src/modules/blue
From: Mikel Astiz
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 +++
2 files changed
From: Mikel Astiz
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 bluetooth
From: Mikel Astiz
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/bluetooth/bluetooth-util.h | 13
From: Mikel Astiz
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/bluetooth-util.h | 7 ++
2
From: Mikel Astiz
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-util.h | 12
From: Mikel Astiz
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 already discussed i
From: Vinicius Costa Gomes
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.
---
src/modules/bluetooth/bluetoo
From: Mikel Astiz
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/bluetooth/bluetooth-util.c
b
From: Mikel Astiz
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/bluetooth/bluetooth-util.c
b
From: Mikel Astiz
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 and that BlueZ will eventually
From: Mikel Astiz
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 a/src/modules/blue
From: Mikel Astiz
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 to pa_bluetooth_transport_releas
From: Mikel Astiz
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/bluetooth/blueto
From: Mikel Astiz
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-u
From: Mikel Astiz
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. For
performance reasons, the
From: Mikel Astiz
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 a/src/modules/bluetooth
From: Mikel Astiz
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 ++
1 file changed, 60
From: Mikel Astiz
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 for completeness despite
Hi Tanu,
On Fri, May 10, 2013 at 10:01 AM, Tanu Kaskinen 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
>> wrote:
>> > On Mon, 2013-04-29 at 18:28 +0200, Mikel
Hi Tanu,
On Fri, May 10, 2013 at 7:48 AM, Tanu Kaskinen wrote:
> On Mon, 2013-04-29 at 18:28 +0200, Mikel Astiz wrote:
>> From: Mikel Astiz
>>
>> Register the HSP/HFP endpoints in BlueZ 5 Media API for the sake of
>> completeness, despite the fact that there's cu
Hi Tanu,
On Thu, May 9, 2013 at 10:30 AM, Tanu Kaskinen wrote:
> On Mon, 2013-04-29 at 18:28 +0200, Mikel Astiz wrote:
>> From: Mikel Astiz
>>
>> Install matches for signal Properties.PropertiesChanged and process the
>> properties corresponding to the tracked devi
Hi João Paulo,
On Tue, May 7, 2013 at 12:01 AM, João Paulo Rechi Vita
wrote:
> On Mon, Apr 29, 2013 at 1:28 PM, Mikel Astiz
> wrote:
>> From: Mikel Astiz
>>
>> Install matches for signal Properties.PropertiesChanged and process the
>> properties corres
Hi João Paulo,
On Thu, May 2, 2013 at 10:05 PM, João Paulo Rechi Vita
wrote:
> On Thu, May 2, 2013 at 4:17 AM, Mikel Astiz wrote:
>> Hi João Paulo,
>>
>> On Tue, Apr 30, 2013 at 9:13 PM, João Paulo Rechi Vita
>> wrote:
>>> On Tue, Apr 30, 2013 at 7:20 A
Hi João Paulo,
On Tue, Apr 30, 2013 at 9:13 PM, João Paulo Rechi Vita
wrote:
> On Tue, Apr 30, 2013 at 7:20 AM, Luiz Augusto von Dentz
> wrote:
>> Hi Mikel,
>>
>> On Mon, Apr 29, 2013 at 7:27 PM, Mikel Astiz
>> wrote:
>>> From: Mikel Astiz
>>>
From: Mikel Astiz
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/bluetooth/bluetooth-util.c
b
From: Mikel Astiz
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/bluetooth/bluetooth-util.c
b
From: Vinicius Costa Gomes
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.
---
src/modules/bluetooth/bluetoo
From: Mikel Astiz
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 and that BlueZ will eventually
From: Mikel Astiz
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 a/src/modules/blue
From: Mikel Astiz
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 to pa_bluetooth_transport_releas
From: Mikel Astiz
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/bluetooth/blueto
From: Mikel Astiz
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-u
From: Mikel Astiz
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. For
performance reasons, the
From: Mikel Astiz
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/bluetooth-util.c
index 0a5f70e
From: Mikel Astiz
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-util.c
index 5fe3f0c..0a5f70e
From: Mikel Astiz
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/modules/bluetooth
From: Mikel Astiz
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/modules/bluetooth
From: Mikel Astiz
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 ++
1 file changed, 58
From: Mikel Astiz
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 changed, 119 insertions
From: Mikel Astiz
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 deletions(-)
diff --git a
From: Mikel Astiz
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
rote:
>>> > On Mon, 2013-04-29 at 16:20 +0200, Mikel Astiz wrote:
>>> >> On Mon, Apr 29, 2013 at 4:01 PM, Tanu Kaskinen
>>> >> wrote:
>>> >> > On Fri, 2013-04-26 at 12:30 -0300, jprv...@gmail.com wrote:
>>>
Hi Tanu,
On Mon, Apr 29, 2013 at 4:38 PM, Tanu Kaskinen wrote:
> On Mon, 2013-04-29 at 16:20 +0200, Mikel Astiz wrote:
>> On Mon, Apr 29, 2013 at 4:01 PM, Tanu Kaskinen
>> wrote:
>> > On Fri, 2013-04-26 at 12:30 -0300, jprv...@gmail.com wrote:
>> >> sr
Hi Tanu,
On Mon, Apr 29, 2013 at 4:01 PM, Tanu Kaskinen wrote:
> On Fri, 2013-04-26 at 12:30 -0300, jprv...@gmail.com wrote:
>> From: João Paulo Rechi Vita
>>
>> ---
>>
>> As already discussed with Tanuk and Mikel, this series should be applied to
>> the
>> master branch.
>
> I don't remember t
Hi João Paulo,
On Fri, Apr 26, 2013 at 5:30 PM, wrote:
> From: João Paulo Rechi Vita
>
> 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 on its existence.
> ---
> src/mod
Hi João Paulo,
On Thu, Apr 25, 2013 at 9:36 AM, Mikel Astiz wrote:
> Hi João,
>
> On Wed, Apr 24, 2013 at 7:51 PM, João Paulo Rechi Vita
> wrote:
>> On Wed, Apr 24, 2013 at 3:29 AM, Mikel Astiz
>> wrote:
>>> Hi João Paulo,
>>>
>>> On Tue,
Hi João,
On Wed, Apr 24, 2013 at 7:51 PM, João Paulo Rechi Vita
wrote:
> On Wed, Apr 24, 2013 at 3:29 AM, Mikel Astiz
> wrote:
>> Hi João Paulo,
>>
>> On Tue, Apr 23, 2013 at 10:48 PM, wrote:
>>> From: João Paulo Rechi Vita
>>>
>>>
Hi João Paulo,
On Tue, Apr 23, 2013 at 10:48 PM, wrote:
> From: João Paulo Rechi Vita
>
> 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' property may not be set, but the 'A
Hi João,
On Mon, Apr 22, 2013 at 3:30 PM, João Paulo Rechi Vita
wrote:
> On Mon, Apr 22, 2013 at 4:43 AM, Mikel Astiz
> wrote:
>> Hi João Paulo,
>>
>> On Mon, Apr 22, 2013 at 5:07 AM, wrote:
>>> From: João Paulo Rechi Vita
>>>
>>> When the
Hi João Paulo,
On Mon, Apr 22, 2013 at 5:07 AM, wrote:
> From: João Paulo Rechi Vita
>
> When the HFP sink/source is resumed and the transport is not acquired a
> new Audio Connection should be started by the HF. This is needed to
> support audio call transfer from the AG to the HF triggered by
From: Mikel Astiz
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/bluetooth/bluetooth-util.c
b
From: Mikel Astiz
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 and that BlueZ will eventually
From: Mikel Astiz
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/bluetooth/bluetooth-util.c
b
From: Vinicius Costa Gomes
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.
---
src/modules/bluetooth/bluetoo
From: Mikel Astiz
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 a/src/modules/blue
From: Mikel Astiz
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 to pa_bluetooth_transport_releas
From: Mikel Astiz
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/bluetooth/blueto
From: Mikel Astiz
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-u
From: Mikel Astiz
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. For
performance reasons, the
From: Mikel Astiz
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/bluetooth-util.c
index c9c60d1
From: Mikel Astiz
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-util.c
index 3560227..c9c60d1
From: Mikel Astiz
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/modules/bluetooth
From: Mikel Astiz
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/modules/bluetooth
From: Mikel Astiz
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 ++
1 file changed, 58
From: Mikel Astiz
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 changed, 119 insertions
From: Mikel Astiz
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 deletions(-)
diff --git a
From: Mikel Astiz
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 inside PulseAudio (next
1 - 100 of 590 matches
Mail list logo
