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 :)
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.
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
> >
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
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
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
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
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()
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
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
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 |
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
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
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
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
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
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
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 ---
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
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
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
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
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
23 matches
Mail list logo
