On Tue, 2012-12-04 at 14:54 +0100, Peter Meerwald wrote:
> From: Stefan Huber
>
> apply_diff_time() fails when dropping bytes from the playback stream
> and the sample spec of sink and source differ as source's sample spec is
> used. Fix this by using sink's sample spec.
>
> Signed-off-by: Stefa
On Fri, Dec 14, 2012 at 2:07 PM, Tanu Kaskinen wrote:
> On Fri, 2012-12-14 at 13:40 -0200, Flávio Ceolin wrote:
>> Hi Tanu,
>>
>> On Fri, Dec 14, 2012 at 5:44 AM, Tanu Kaskinen wrote:
>> > On Thu, 2012-12-13 at 17:00 -0200, Flavio Ceolin wrote:
>> >> This module works pretty similar to the module
On Fri, 2012-12-14 at 13:40 -0200, Flávio Ceolin wrote:
> Hi Tanu,
>
> On Fri, Dec 14, 2012 at 5:44 AM, Tanu Kaskinen wrote:
> > On Thu, 2012-12-13 at 17:00 -0200, Flavio Ceolin wrote:
> >> This module works pretty similar to the module-role-cork.
> >> It should be used as an alternative to that
Hi Tanu,
On Fri, Dec 14, 2012 at 5:44 AM, Tanu Kaskinen wrote:
> On Thu, 2012-12-13 at 17:00 -0200, Flavio Ceolin wrote:
>> This module works pretty similar to the module-role-cork.
>> It should be used as an alternative to that module. Basically
>> it decreases the volume of the streams specifie
Now you can actually see *which* sink/source that sends a specific
message to the log, which is quite useful if you have more than
one sound card.
Signed-off-by: David Henningsson
---
Nothing to delay a release for, so just put it in Tanu's or Arun's
"next" branches.
src/modules/alsa/alsa-sink
From: Mikel Astiz
Make the internal function bt_transport_acquire() consistent with the
API in bluetooth-util by replacing the old 'start' parameter with
exactly the opposite: 'optional'.
Therefore, all calls to the function need to negate the second
parameter.
Note also that the name is more a
From: Mikel Astiz
Do not call setup_stream() automatically inside bt_transport_acquire().
Instead, the caller is responsible to use both functions as necessary.
As a first trivial step, setup_stream() is now called manually after
all calls to bt_transport_acquire(u, TRUE), with the exception of
From: Mikel Astiz
All D-Bus infrastructure is now unused after bluetooth-util has covered
the pieces that were pending. Therefore, all D-Bus related code in
module-bluetooth-device can be safely removed.
---
src/modules/bluetooth/module-bluetooth-device.c | 103 +---
1 file c
From: Mikel Astiz
The transport state also reflects the state of the audio interface. The
state redundancy can thus be minimized by always using the first one,
and avoiding the use of profile-specific states with the exception of
finding out the initial state of a transport.
---
src/modules/blue
From: Mikel Astiz
The state of this interface is needed for one single reason: we need to
wait until all profiles have been connected (or more precisely, until
are connection attempts are finished). This can be made more explicit in
the code by just checking the CONNECTING state (and not loading
From: Mikel Astiz
The function body is now trivial and can thus be inlined.
---
src/modules/bluetooth/module-bluetooth-device.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/mod
From: Mikel Astiz
Transports can be acquired with different access rights, but in practice
"rw" was always used inside module-bluetooth-device. In addition, this
feature is removed in BlueZ 5.0 and therefore it is convenient to
abstract all this inside bluetooth-util.
---
src/modules/bluetooth/b
From: Mikel Astiz
Use transport state to calculate the corresponding port availability,
and while doing so use bluetooth-util to receive profile state updates
instead of directly parsing D-Bus PropertyChanged signals.
---
src/modules/bluetooth/bluetooth-util.c | 6 +-
src/modules/blue
From: Mikel Astiz
Split filter_cb() to separate the parsing of the D-Bus message from
the internal logic handling the new state.
---
src/modules/bluetooth/module-bluetooth-device.c | 85 -
1 file changed, 55 insertions(+), 30 deletions(-)
diff --git a/src/modules/bluetoo
From: Mikel Astiz
Move the function to the utility library where the enum is defined. At
same time avoid using the default clause in order to make sure the
compiler will complain if the enum type gets extended.
---
src/modules/bluetooth/bluetooth-util.c | 17 +
src/modul
From: Mikel Astiz
Use the new abstraction in bluetooth-util to both receive volume updates
and request them.
---
src/modules/bluetooth/module-bluetooth-device.c | 94 +++--
1 file changed, 58 insertions(+), 36 deletions(-)
diff --git a/src/modules/bluetooth/module-bluetooth-
From: Mikel Astiz
Similarly to the microphone gain, the speaker gain can be abstracted
inside the transport object, even though the actual D-Bus interface in
BlueZ differs.
---
src/modules/bluetooth/bluetooth-util.c | 25 +
src/modules/bluetooth/bluetooth-util.h | 3 +++
From: Mikel Astiz
The microphone gain represents the volume of the incoming audio stream
from the headset. This can be nicely abstracted inside the transport
object in bluetooth-util, so the modules don't have to take care about
the D-Bus details.
---
src/modules/bluetooth/bluetooth-util.c
From: Mikel Astiz
v1 includes the changes pointed out by Tanu, most significantly:
- Function naming fixes.
- Transport owner (bus name) considered for SetProperty().
- Traces improved.
- Use pa_dbus_append_basic_variant() to simplify code.
- pa_transport_is_acquired() refactored.
>From original
On Fri, 2012-12-14 at 10:58 +0100, Mikel Astiz wrote:
> On Fri, Dec 14, 2012 at 10:24 AM, Tanu Kaskinen wrote:
> > On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote:
> >> From: Mikel Astiz
> >>
> >> The state of this interface is needed for one single reason: we need to
> >> wait until all pro
On Fri, 2012-12-14 at 10:49 +0100, Mikel Astiz wrote:
> On Fri, Dec 14, 2012 at 10:15 AM, Tanu Kaskinen wrote:
> > The start parameter could be changed from "start" to "optional" to be
> > consistent with pa_bluetooth_transport_acquire(). On the other hand,
> > "start" describes better the behavio
Hi Tanu,
On Fri, Dec 14, 2012 at 10:24 AM, Tanu Kaskinen wrote:
> On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote:
>> From: Mikel Astiz
>>
>> The state of this interface is needed for one single reason: we need to
>> wait until all profiles have been connected (or more precisely, until
>> a
Hi Tanu,
On Fri, Dec 14, 2012 at 10:15 AM, Tanu Kaskinen wrote:
> On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote:
>> static bool bt_transport_is_acquired(struct userdata *u) {
>> -if (u->accesstype == NULL) {
>> +if (!u->transport_acquired) {
>> pa_assert(u->stream_fd < 0)
On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote:
> From: Mikel Astiz
>
> The state of this interface is needed for one single reason: we need to
> wait until all profiles have been connected (or more precisely, until
> are connection attempts are finished). This can be made more explicit in
On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote:
> static bool bt_transport_is_acquired(struct userdata *u) {
> -if (u->accesstype == NULL) {
> +if (!u->transport_acquired) {
> pa_assert(u->stream_fd < 0);
> return FALSE;
> } else {
Now that we have the transpo
On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote:
> /* Run from main thread */
> -static void handle_profile_state_change(struct userdata *u, enum profile
> profile, pa_bt_audio_state_t state) {
> +static void handle_transport_state_change(struct userdata *u, struct
> pa_bluetooth_transport
On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote:
> From: Mikel Astiz
>
> The microphone gain represents the volume of the incoming audio stream
> from the headset. This can be nicely abstracted inside the transport
> object in bluetooth-util, so the modules don't have to take care about
> th
27 matches
Mail list logo
