On 2014-11-05 00:26, Peter Meerwald wrote:
From: Peter Meerwald p.meerw...@bct-electronic.com
don't encapsulate a tagstruct in a packet anymore, allow to
pass the tagstruct directly to the pstream
this removes the ugly macro pa_pstream_send_tagstruct()
in pstream-util.h and calls the new
Hello David,
add 128 bytes of storage in each tagstruct that will initially
be used; if this storage is exceeded the type changes to _DYNAMIC
v2: (thanks Alexander Patrakov)
* replace constant 100 with GROW_TAG_SIZE (the increment in with a dynamic
tagstruct grows when extend()ed)
Hallo,
implement inlineable functions PA_CVOLUME_VALID(),
PA_CVOLUME_CHANNELS_EQUALS_TO(), PA_CVOLUME_IS_MUTED(),
PA_CVOLUME_IS_NORM() that assume data is valid
Why are these uppercase? AFAIK, we don't usually uppercase inline
functions.
I've modelled after e.g. PA_ALIGN_PTR() in
On 10 November 2014 15:15, Peter Meerwald pme...@pmeerw.net wrote:
Hallo,
implement inlineable functions PA_CVOLUME_VALID(),
PA_CVOLUME_CHANNELS_EQUALS_TO(), PA_CVOLUME_IS_MUTED(),
PA_CVOLUME_IS_NORM() that assume data is valid
Why are these uppercase? AFAIK, we don't usually uppercase
... as Peter aptly put it. :-)
I'd like to freeze master for 6.0 in a couple of days (tentatively
morning of Nov 13th). If you have any patches pending that you'd like
included for the next release, please scream and shout now.
Ideally, I'd like to avoid adding anything non-obvious/trivial at
On Mon, 10 Nov 2014 15:32:15 +0530, Arun Raghavan a...@accosted.net
wrote:
I'd like to freeze master for 6.0 in a couple of days (tentatively
morning of Nov 13th). If you have any patches pending that you'd like
included for the next release, please scream and shout now.
RAOP2!! That would be
On 10 Nov 2014 15:47, Colin Leroy co...@colino.net wrote:
On Mon, 10 Nov 2014 15:32:15 +0530, Arun Raghavan a...@accosted.net
wrote:
I'd like to freeze master for 6.0 in a couple of days (tentatively
morning of Nov 13th). If you have any patches pending that you'd like
included for the
[adding pulseaudio-discuss to CC]
On 2014-11-10 13:34, Michael Schwendt wrote:
Hello David!
I've noticed a recently applied patch from you for Pulse Audio,
http://comments.gmane.org/gmane.comp.audio.pulseaudio.general/21635
which adds a warning that _somehow_ affects a user of Audacious:
Hello again!
I've traced the invocation of pa_sink_suspend(), and the erroneous
uncorking seems to lead to module-suspend-on-idle.so. Going to dig more
into that.
However, it seems that PA_SINK_SUSPENDED and PA_SINK_INPUT_CORKED are
accidentally sharing the same enum placement, could it be
This implements some autodetect if both headset backends are compiled in:
First we try to contact the oFono service, if that's not working,
then we start the native backend instead.
Likewise if the oFono service is going offline/online, we load/unload
the native backend accordingly.
Changes since v1:
* Added check for bluez headers for native backend (thanks to pmeerw)
* Added module argument that can choose between native, ofono and auto
behaviour
I'm glad if this set makes into 6.0rc1
David Henningsson (5):
bluez 5: Build both headset backends, if available
bluez
Enable both ofono and native backends to be built into the same
libbluez5-util. Never build the null backend.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
configure.ac | 33 -
src/Makefile.am
This patch adds a module argument headset=ofono|native|auto to
module-bluetooth-discover and module-bluez5-discover.
To make Arun's happy, the default is 'native' if compiled in, otherwise
'ofono'. 'Auto' will try to autoswitch depending on whether ofono is
running or not.
Signed-off-by: David
There is no need to have a null backend anymore.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/modules/bluetooth/backend-null.c | 37
1 file changed, 37 deletions(-)
delete mode 100644 src/modules/bluetooth/backend-null.c
diff
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/modules/bluetooth/backend-native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/modules/bluetooth/backend-native.c
b/src/modules/bluetooth/backend-native.c
index 66dacf9..86af422 100644
---
Hi Colin,
While I was adding systemd .service and .socket files for the system
mode in Tizen, I noticed something in configure.ac that I didn't pay
attention to before...
On Mon, 2014-11-03 at 09:42 +, Colin Guthrie wrote:
---
configure.ac | 11 +++
Tanu Kaskinen wrote on 10/11/14 15:49:
Hi Colin,
While I was adding systemd .service and .socket files for the system
mode in Tizen, I noticed something in configure.ac that I didn't pay
attention to before...
On Mon, 2014-11-03 at 09:42 +, Colin Guthrie wrote:
---
configure.ac
On Mon, 2014-11-10 at 16:13 +, Colin Guthrie wrote:
Tanu Kaskinen wrote on 10/11/14 15:49:
Hi Colin,
While I was adding systemd .service and .socket files for the system
mode in Tizen, I noticed something in configure.ac that I didn't pay
attention to before...
On Mon,
Tanu Kaskinen tanu.kaski...@linux.intel.com [2014-11-10 18:29:16 +0200]:
Are you sure installing to /usr/local/lib/systemd/user doesn't work? To
me path-lookup.c looks like it includes /usr/local/lib/systemd/user in
the unit search paths.
Fwiw, just as an empirical datapoint here: I run
Tanu Kaskinen wrote on 10/11/14 16:29:
On Mon, 2014-11-10 at 16:13 +, Colin Guthrie wrote:
Tanu Kaskinen wrote on 10/11/14 15:49:
Hi Colin,
While I was adding systemd .service and .socket files for the system
mode in Tizen, I noticed something in configure.ac that I didn't pay
attention
Glenn Golden wrote on 10/11/14 16:39:
Tanu Kaskinen tanu.kaski...@linux.intel.com [2014-11-10 18:29:16 +0200]:
Are you sure installing to /usr/local/lib/systemd/user doesn't work? To
me path-lookup.c looks like it includes /usr/local/lib/systemd/user in
the unit search paths.
Fwiw, just
Colin Guthrie gm...@colin.guthr.ie [2014-11-10 16:58:29 +]:
Glenn Golden wrote on 10/11/14 16:39:
Tanu Kaskinen tanu.kaski...@linux.intel.com [2014-11-10 18:29:16 +0200]:
Are you sure installing to /usr/local/lib/systemd/user doesn't work? To
me path-lookup.c looks like it includes
Felipe Sateler wrote on 05/11/14 16:19:
If you wanted to go really far, you could also hack PA source to check
for systemd as an init (just checking sd_booted() I guess) and make the
default based on that - while it's not the same as using the user
daemon, it's 99% accurate IMO. It would
On 10 November 2014 19:59, Ville Sundell ville.sund...@nomovok.com wrote:
Hello again!
I've traced the invocation of pa_sink_suspend(), and the erroneous uncorking
seems to lead to module-suspend-on-idle.so. Going to dig more into that.
Right, so that uncorking is likely the culprit.
On 2014-11-10 19:42, Michael Schwendt wrote:
On Mon, 10 Nov 2014 13:47:47 +0100, David Henningsson wrote:
In your call to pa_stream_write, you try to send 687 bytes, but with a
frame size of 8 (could be e g 32-bit float, stereo), 687 bytes is 85.875
frames, i e not an integer number of
On Nov 06 17:59 -0500, SGT. Garcia wrote:
On Nov 06 23:14 +0100, Martin Blanchard wrote:
Hello.
On Thu, 2014-10-30 at 15:43 -0400, SGT. Garcia wrote:
hello,
i've got an airport express and i would like to use it as an output sound
device on this linux box. i read somewhere that
On Mon, 2014-11-10 at 16:34 +0100, David Henningsson wrote:
This implements some autodetect if both headset backends are compiled in:
First we try to contact the oFono service, if that's not working,
then we start the native backend instead.
Likewise if the oFono service is going
On Mon, 2014-11-10 at 16:34 +0100, David Henningsson wrote:
This patch adds a module argument headset=ofono|native|auto to
module-bluetooth-discover and module-bluez5-discover.
To make Arun's happy, the default is 'native' if compiled in, otherwise
'ofono'. 'Auto' will try to autoswitch
On Mon, 2014-11-10 at 16:34 +0100, David Henningsson wrote:
Changes since v1:
* Added check for bluez headers for native backend (thanks to pmeerw)
* Added module argument that can choose between native, ofono and auto
behaviour
tbh, I don't see that the auto behaviour is very useful,
29 matches
Mail list logo
