This patch serves two purposes:
1) Allows something other than the de-facto standard udev rules dir or
/lib/udev/rules.d to be used (the udev build system allows you to
customise this)
2) Allows a prefixed, non-root install (right now, the /lib/... path
is hard-coded into the
On Tue, 2009-12-22 at 12:47 -0500, Gene Heskett wrote:
[...]
Coding is kewl, I do it myself on smaller systems, but where are the man
pages that should allow us to make it Just Work(TM)?
[...]
I think the majority of us are interested. And contrary to rumors extant all
over the web, the
On Mon, 2010-01-11 at 13:33 +0100, Stéphane List wrote:
[...]
It works well if my PC is already playing a MP3. But if my PC is silent,
the 3 first ticks don't look very accurate.
Any hint ?
Sounds like this might be your problem:
On Thu, 2010-01-14 at 23:25 +0100, Lennart Poettering wrote:
[...]
4 Put a bigger focus on automatically managed stream
volumes. i.e. volume-follows-focus (Arun!),
Whoops - kind of got off-tracked on this particular project. Last place
I was stuck was how to get the window-state tracking
On Wed, 2010-02-10 at 11:16 -0500, Bill Cox wrote:
Ok, the new glitchless code sounds cool. Reducing the interrupts
seems close to pointless from a power savings view, unless we're in an
embedded environment where we slow down the CPU and lower it's power
on sub-second intervals. Otherwise,
Hello,
On Wed, 2010-02-10 at 20:28 +0530, Lakshmi N V wrote:
Hi,
I'm using the Pulse Audio v0.9.21 with Moblin 2.1 OS on an embedded
system.
I've observed that when a audio stream is in progress through Pulse
Audio and a system alert is generated through libcanberra-gtk-play,
the system
On Sat, 2010-09-11 at 17:49 +0200, Alexey Fisher wrote:
Hallo all,
i see in git you working on echo cancelation. Will it work for audio
feedback/Larsen effect too? I mean sort of feedback killer?
It will not. The echo cancellation module is meant for things like voip
calls. For example, if
Hey folks,
Here's a patchset to change PA_VOLUME_MAX to (2^31-1), which is about half its
current value. This really should not impact anything significantly, since the
maximum gain we can apply decreases from ~289 dB to ~271 dB. Why this change is
good is that we can significantly simplify the
This adds a PA_VOLUME_IS_VALID() macro for checking if a given
pa_volume_t is valid. This makes changes to the volume ranges simpler
(just change PA_VOLUME_MAX, for example, without needing to modify any
other code).
---
src/modules/dbus/iface-core.c |2 +-
This ensures that we always clamp the volume to PA_VOLUME_MAX. While
this currently has no effect, it will be required for making sure we
don't exceed PA_VOLUME_MAX when its value changes in the future.
---
src/modules/module-lirc.c|6 +++---
src/modules/module-match.c |2 +-
This causes an error to be generated if an invalid volume is provided to
commands that set sink/sink-input/source volume.
---
src/pulsecore/cli-command.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/pulsecore/cli-command.c
This makes sure that a valid volume is provided before setting on
sink/sink-input/source.
---
src/utils/pactl.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/utils/pactl.c b/src/utils/pactl.c
index cae96f2..98c4d45 100644
--- a/src/utils/pactl.c
+++
This decrease PA_VOLUME_MAX to be less than 2^31. We want to do this in
order to simplify signed arithmetic when applying software volume
scaling (since the volume can now always be safely treated as a signed
number).
---
src/pulse/volume.h |2 +-
1 files changed, 1 insertions(+), 1
On Sun, 2010-10-10 at 10:19 +0200, David Henningsson wrote:
On 2010-10-09 20:27, Arun Raghavan wrote:
Hey folks,
Here's a patchset to change PA_VOLUME_MAX to (2^31-1), which is about half
its
current value. This really should not impact anything significantly, since
the
maximum gain
On Sun, 2010-10-10 at 10:46 +0100, Colin Guthrie wrote:
[...]
I'd also like to expose a new constant in the headers called
PA_VOLUME_OVERDRIVE (or similarly named) that represents +11dB and
should be our generally recommended overdrive (aka software
amplification 100%) amount for volume
On Sun, 2010-10-10 at 13:03 +0100, Colin Guthrie wrote:
'Twas brillig, and Arun Raghavan at 10/10/10 11:30 did gyre and gimble:
On Sun, 2010-10-10 at 10:46 +0100, Colin Guthrie wrote:
[...]
I'd also like to expose a new constant in the headers called
PA_VOLUME_OVERDRIVE (or similarly
On Mon, 2010-10-18 at 16:43 -0500, pl bossart wrote:
Looks like the volume control logic has taken a big hit, when I move
the volume up and down with the slider on the Output Devices tab in
pavucontrol, I have _huge_ pops and clicks, the volume goes to zero in
the playback tab.
I don't get the
The commit that introduced this macro was incorrect in some places. This
patch fixes these. Thanks to Pierre-Louis Bossart for pointing this out.
---
src/modules/dbus/iface-sample.c |4 ++--
src/modules/dbus/iface-stream.c |2 +-
src/modules/module-stream-restore.c |2 +-
Hi folks,
I've been doing some work optimising the software volume scaling code,
and along with my previous changes to decrease the maximum volume to
2^31-1, there seems to be a pretty good performance increase (almost 2x
on my Core2 processor).
The actual optimisations have been written in
On Wed, 2010-10-27 at 15:14 -0500, pl bossart wrote:
I've been doing some work optimising the software volume scaling code,
and along with my previous changes to decrease the maximum volume to
2^31-1, there seems to be a pretty good performance increase (almost 2x
on my Core2 processor).
On Thu, 2010-10-28 at 01:47 +0100, Arun Raghavan wrote:
On Wed, 2010-10-27 at 15:14 -0500, pl bossart wrote:
I've been doing some work optimising the software volume scaling code,
and along with my previous changes to decrease the maximum volume to
2^31-1, there seems to be a pretty good
On Wed, 2010-10-27 at 15:10 +0100, Arun Raghavan wrote:
[...]
Comments/brickbats solicited :)
Hopefully I've addressed Pierre's concerns. Does other objections?
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https
On Thu, 2010-11-18 at 20:53 +0530, Arun Raghavan wrote:
On Wed, 2010-10-27 at 15:10 +0100, Arun Raghavan wrote:
[...]
Comments/brickbats solicited :)
Hopefully I've addressed Pierre's concerns. Does other objections?
D'oh! s/Does/Any/
-- Arun
On Sun, 2010-11-28 at 15:31 +, Colin Guthrie wrote:
[...]
So if we only had a single version number, the same problems would be
apparent with our current version conundrum. As a compromise for
simplifying things and for getting a sensible version tag pushed to
master, we decided to adopt a
This limits the maximum gain we perform in software to approximately 20
dB. There does not appear to be a good reason for greater gain, and
clipping to 20 dB can prevent accidentally setting an absurdly large
volume and potential damage to the ears.
---
src/pulse/volume.h |3 ++-
1 files
On Sun, 2010-12-05 at 19:47 +0530, Arun Raghavan wrote:
This limits the maximum gain we perform in software to approximately 20
dB. There does not appear to be a good reason for greater gain, and
clipping to 20 dB can prevent accidentally setting an absurdly large
volume and potential damage
On Thu, 2010-12-09 at 16:02 -0600, abraham duenas wrote:
Hello,
I have one question regarding resampler and working format. I have a
card which has 48kHz working sampling frequency and s16le format. When
I play any file at that frequency my understanding is that no
resampling should take
On Sat, 2010-12-18 at 00:03 -0500, Daniel Chen wrote:
Hi,
While triaging the Debian bugs for PulseAudio, I noticed this
trivially-fixed item. Here's a patch against stable-queue/master.
I think this is incorrect - the sentence basically said the src-*
resampling methods are provided by
On Mon, 2011-01-17 at 14:24 -0600, pl bossart wrote:
[...]
I can see cases where you have 1 compressed stream and 1 PCM, and you
mix the two in hardware, but I am having a really hard time finding a
use case where you would have multiple (more than 2) PCM streams at
different rates. Maybe
On Thu, 2011-01-20 at 15:03 +0200, Tanu Kaskinen wrote:
Hi,
When reviewing code, should I complain about excessive curly brackets in
code like this?
if (foo) {
bar = 0;
}
Pulseaudio source code follows quite consistently the unwritten rule
that you shouldn't use curly
Hey Colin,
On Sun, 2011-01-23 at 14:17 +, Colin Guthrie wrote:
Hi,
This is likely directed to Arun, but others may know too!
When I run a make distcheck and probably other builds too, I get this in
my checkout:
# Changed but not updated:
# (use git add file... to update what
On Tue, 2011-01-18 at 16:53 -0600, pl bossart wrote:
In my normal usage, there is a potential (solvable) problem with this
approach, though. I use Rhythmbox and most of my songs are at 44100 Hz,
but there are some at 48000 Hz. If I start playing one of the 48000 Hz
songs, all subsequent
On Mon, 2011-01-24 at 14:14 -0800, pl bossart wrote:
FWIW, the zero-length wait seems to work fine for me as well (also
HDAudio). A couple of things to consider if we do decide to go ahead
with this are are that:
Any ideas on how we can make this timeout sink-specific? Everything I
know
On Thu, 2011-02-03 at 08:34 +0200, Tanu Kaskinen wrote:
On Wed, 2011-02-02 at 13:29 +0530, Arun Raghavan wrote:
Currently Rhythmbox does fading using the GStreamer 'volume' element, so
this problem doesn't exist with Rhythmbox as it stands now. Some
background ...
To play audio
Hello,
On Tue, 2011-02-08 at 15:35 +0530, ssrk wrote:
Hi all,
I wish to know is there support for echo cancellation in PulseAudio?
when I was searching for it I found this link
http://nlnet.nl/project/pulseaudio/
Do we have echo cancellation support in PulseAudio already?
You can find
On Tue, 2011-02-08 at 16:31 +0530, ssrk wrote:
Hi Arun,
[...]
Thanks for that reply,
Let me try to download and compile it.
Have you tried loading that module and checking that feature? if so,
please send those commands also.
Once you've run the daemon, use pactl load-module
On Fri, 2010-11-19 at 18:11 -0200, João Paulo Rechi Vita wrote:
Hello Pierre,
On Wed, Nov 10, 2010 at 17:00, pl bossart bossart.nos...@gmail.com wrote:
Here's the corrected path with most comments from Tanu implemented. I
attached some additional gstreamer patches so that people can test
On Mon, 2011-02-07 at 12:52 -0600, Kurt Taylor wrote:
I am seeing the following when trying to build pulseaudio on an
ARM-based Beagleboard (OMAP3):
CC libpulsecore_1.0_la-svolume_arm.lo
../libtool: line 975: warning: setlocale: LC_MESSAGES: cannot change
locale (en_GB.utf8)
Hey folks,
I've put up a draft proposed API changes to get passthrough support to
the point where things Just Work™ for at least the common cases, based
on previous discussion on-/off-list:
http://pulseaudio.org/wiki/PassthroughSupport
Please review/comment. Once we have some consensus, I'll
On Tue, 2011-02-15 at 17:47 +0100, Xavier Bestel wrote:
Hi,
On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote:
Hey folks,
I've put up a draft proposed API changes to get passthrough support to
the point where things Just Work™ for at least the common cases, based
on previous
On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
Please review/comment. Once we have some consensus, I'll send in patches
to actually get this done.
Thanks Arun,
this is a good start. Couple of comments:
Thanks for the detailed review. Responses inline ...
- change raw to PCM, it's
On Tue, 2011-02-15 at 12:11 -0600, pl bossart wrote:
How about reusing gstreamer formats, so that adding a new format to PA
makes it appear automagically in apps using GST (no need to recompile
GST) ?
Tempting as it is ;), we want to keep PA framework-agnostic. Also, in
most cases, you
On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
Please review/comment. Once we have some consensus, I'll send in patches
to actually get this done.
[...]
- The receiver may support the same format at different sampling
frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for
On Tue, 2011-02-15 at 22:14 +0200, Tanu Kaskinen wrote:
On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote:
Hey folks,
I've put up a draft proposed API changes to get passthrough support to
the point where things Just Work™ for at least the common cases, based
on previous discussion
On Wed, 2011-02-16 at 10:10 +0200, Tanu Kaskinen wrote:
[...]
What if the stream would be created at the time when GStreamer queries
the sink format? The query apparently already contains information about
the preferred format, otherwise your proposal makes it impossible to do
routing
Hello,
On Wed, 2011-02-16 at 09:56 -0600, pl bossart wrote:
Fair enough. The only niggling API change would be adding a
PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for
each PCM format).
I think the PA_SAMPLE_* enumeration should be left alone. Let it be a
On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote:
- I am not sure I understand how/when the query would be used. Seems
to me like a notification with the formats exposed by the sink
currently selected would be more usable. And if a change in routing
happens (new accessory, audio policy,
On Thu, 2011-02-17 at 10:26 +0200, Tanu Kaskinen wrote:
On Wed, 2011-02-16 at 19:17 +0530, Arun Raghavan wrote:
Can you elaborate on what you had in mind regarding UIs?
As for UIs, it would probably be nice to have some sort of (hidden by
default) way to show supported format in a sink
Hi Tanu,
On Thu, 2011-02-17 at 09:45 +0200, Tanu Kaskinen wrote:
On Thu, 2011-02-17 at 02:54 +0530, Arun Raghavan wrote:
On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote:
- I am not sure I understand how/when the query would be used. Seems
to me like a notification with the formats
On Thu, 2011-02-17 at 09:13 +, Colin Guthrie wrote:
'Twas brillig, and Tanu Kaskinen at 17/02/11 07:45 did gyre and gimble:
Your proposal would probably work well enough in practice, but I still
would like more an approach where you create a stream and after it gets
routed you finalize
On Wed, 2011-02-16 at 12:33 +, Colin Guthrie wrote:
'Twas brillig, and Arun Raghavan at 16/02/11 04:42 did gyre and gimble:
On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
Please review/comment. Once we have some consensus, I'll send in patches
to actually get this done
Hello!
On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote:
Hey folks,
I've put up a draft proposed API changes to get passthrough support to
the point where things Just Work™ for at least the common cases, based
on previous discussion on-/off-list:
http://pulseaudio.org/wiki
On Fri, 2011-02-18 at 03:42 -0700, Kelly Anderson wrote:
[...]
The alsa driver has creates a /proc entry that lists the coding types
available for a particular device. It'd be nice if you would use that
for the list of supported coding types (at least for a default). I'm
not sure the list
On Fri, 2011-02-18 at 11:04 +, Colin Guthrie wrote:
'Twas brillig, and Arun Raghavan at 18/02/11 09:41 did gyre and gimble:
Hello!
On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote:
Hey folks,
I've put up a draft proposed API changes to get passthrough support to
the point
On Fri, 2011-02-18 at 23:00 +0200, Tanu Kaskinen wrote:
On Fri, 2011-02-18 at 11:15 -0600, Kurt Taylor wrote:
Thanks for organizing this Colin! I will do my best to attend, but that is
5am (UTC-6) for me.
It sounds like a few hours later would be better than the suggested
11:00 UTC. Arun
On Sat, 2011-02-19 at 13:28 +0200, Tanu Kaskinen wrote:
On Fri, 2011-02-18 at 15:11 +0530, Arun Raghavan wrote:
Hello!
On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote:
Hey folks,
I've put up a draft proposed API changes to get passthrough support to
the point where things
On Sun, 2011-02-20 at 19:20 +0100, Paul Menzel wrote:
Date: Sun, 20 Feb 2011 15:57:55 +0100
Building PulseAudio 051d8213 [1] using OpenEmbedded with distribution
`minimal-uclibc` for `MACHINE=om-gta01` having an ARMv4T architecture
(armv4t-oe-linux-uclibceabi) compilation fails with the
On Tue, 2011-02-22 at 09:48 +, Colin Guthrie wrote:
'Twas brillig, and Arun Raghavan at 21/02/11 20:31 did gyre and gimble:
On Sun, 2011-02-20 at 19:20 +0100, Paul Menzel wrote:
Date: Sun, 20 Feb 2011 15:57:55 +0100
Building PulseAudio 051d8213 [1] using OpenEmbedded with distribution
On Tue, 2011-02-22 at 10:03 -0600, pl bossart wrote:
Hi Arun,
I've updated this page with the changes discussed so far (and translated
them into the actual API changes that we need). Please take a look and
let me know if this looks acceptable.
Couple of comments:
- There is a miss
On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote:
Still, I am not clear about the negociation. the client would need to
use pa_stream_new_extended with multiple formats, and then get the
actual format with get_format_info. If my understanding is correct,
then maybe you would need a list
Hi Paul,
On Tue, 2011-02-22 at 12:33 +0100, Paul Menzel wrote:
Am Dienstag, den 22.02.2011, 09:48 + schrieb Colin Guthrie:
'Twas brillig, and Arun Raghavan at 21/02/11 20:31 did gyre and gimble:
On Sun, 2011-02-20 at 19:20 +0100, Paul Menzel wrote:
Date: Sun, 20 Feb 2011 15:57:55
On Fri, 2011-02-25 at 09:42 +, Colin Guthrie wrote:
'Twas brillig, and Arun Raghavan at 08/02/11 15:34 did gyre and gimble:
If there are no objections to this approach, we could expose the fading
API via a property (set it to trigger a fade) and a signal (for the
fade-done callback
On Sun, 2011-02-27 at 12:50 +0200, Tanu Kaskinen wrote:
---
src/.gitignore |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/.gitignore b/src/.gitignore
index c93974b..1380e26 100644
--- a/src/.gitignore
+++ b/src/.gitignore
@@ -66,3 +66,4 @@ voltest
On Tue, 2011-02-22 at 22:52 +0200, Tanu Kaskinen wrote:
[...]
The set of parameters can potentially grow forever - we don't know what
parameters may become relevant in the future. So, I think we should
start by documenting the parameters that we know are important today,
and define the
Hi Marcel,
On Sat, 2011-01-01 at 16:50 +0100, Marcel wrote:
I am porting pulseaudio to OS/2. During this I run into trouble with the
mainloop occasionally eating up all CPU resources. It turned out to be
an inconsistency in the internal state of the mainloop.
m-wakeup_requested was 0 while
On Sun, 2011-02-27 at 23:20 -0800, Christ Schlacta wrote:
[...]
mark settings as optional or required for negotiation. if one or the
other can't support an Optional parameter, then it gets replied to as
unsupported but continuing. a warning is logged. a mandatory option
will cause it to
I got bitten by this (stream aborts because client iterates on the
introspection data till all data is consumed), so hacked up a quick patch in
case Tanu hasn't had the time to get to this yet.
___
pulseaudio-discuss mailing list
This completes the client-side changes to the protocol extension
introduced by commit 99ddca89cdca9b0b92ab9870764f9211e6a82e31
---
src/pulse/introspect.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/pulse/introspect.c b/src/pulse/introspect.c
index
This completes the client-side changes to the protocol extension
introduced by commit 99ddca89cdca9b0b92ab9870764f9211e6a82e31
---
configure.ac |2 +-
src/pulse/introspect.c |8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
On Tue, 2011-03-01 at 21:38 +0200, Tanu Kaskinen wrote:
On Wed, 2011-03-02 at 00:43 +0530, Arun Raghavan wrote:
This completes the client-side changes to the protocol extension
Thanks for fixing this!
I forgot also incrementing PA_PROTOCOL_VERSION in my patch, so you
should fix that too
On Fri, 2011-03-04 at 20:47 -0700, Kelly Anderson wrote:
diff --git a/src/Makefile.am b/src/Makefile.am
index 24e2f82..bb501fb 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1131,7 +1131,9 @@ dist_alsapaths_DATA = \
On Sun, 2011-03-06 at 16:30 -0600, Pierre-Louis Bossart wrote:
This is the second version of my endeavors to remove or make SRC
simpler when possible. An idle non-network, local or passthrough
devices will be suspended immediately when there aren't any
inputs. When a new input is connected, we
On Tue, 2011-03-08 at 07:03 -0600, pl bossart wrote:
At sink-input trigger a reconfiguration if possible/supported. Sinks
expose a reconfigure_rate method (I'm sure we can find a better name) if
they can do a quick switch.
So far it's similar to the update_rate() method I added on the
Hi,
I haven't tested your patch, but some comments on the code below.
On Tue, 2011-03-08 at 17:15 +0100, Vincent Becker wrote:
This patch enables logging of text debug messages (pa_log feature) into a
file or a device driver.
Example : pulseaudio --log-target=file:./mylog.txt
Hello all,
Based on the RFC I posted earlier, I've implemented basic passthrough
support in some usable shape. It's up on the passthrough branch of each
of:
PulseAudio:
http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog;h=refs/heads/passthrough
gst-plugins-base:
On Wed, 2011-03-09 at 15:40 +0530, Arun Raghavan wrote:
Hello all,
Based on the RFC I posted earlier, I've implemented basic passthrough
support in some usable shape. It's up on the passthrough branch of each
of:
PulseAudio:
http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog
Hi Paul,
On Thu, 2011-03-10 at 13:02 +0100, Paul Menzel wrote:
Dear Arun,
your commit messages of commit 4cd90d9e [1] says the following.
… Since I haven't been able to test on other architectures, the
Orc code is only used when MMX/SSE* is present. This can be
On Sat, 2011-03-12 at 15:08 -0600, pl bossart wrote:
Hi Arun,
I looked at the passthrough branch. Looks pretty good. I wrote down some
notes:
gstaudioiec61937:
- need to check that frame is valid and synchronized on AC3 header
before pushing iec payload
I'm expecting valid data from the
On Sat, 2011-03-12 at 16:01 -0600, pl bossart wrote:
Looked at the BT modifications, doesn't look too bad.
I would try first with MP3 support only, so that you don't have
reconfiguration issues. If you support MP3 only from the beginning, it
should be easier to make progress.
Yep, I did that
On Mon, 2011-03-14 at 11:06 -0500, pl bossart wrote:
I've pushed updates to passthrough-bt branches on my trees for
pulseaudio (some core changes, rebased to current master),
gst-plugins-base (MPEG audio payloader), and gst-plugins-good (pulsesink
MPEG support). With all this, you should
On Mon, 2011-03-14 at 13:43 -0500, pl bossart wrote:
I forced support for pulse1.0 it by hand in config.h and found the
same problem with the headset. Trying to figure out the differences
with my initial patches. there must be a step missing.
ok, found a solution, see diff attached. For
On Mon, 2011-03-14 at 14:57 -0500, pl bossart wrote:
Other things I noticed: the volume is much higher in passthrough mode,
maybe we need to find a way to set the volume on the headset to match
the volume used for PCM. Also I heard some high-frequency modulations,
typically coding noise,
On Tue, 2011-03-15 at 01:36 +0530, Arun Raghavan wrote:
On Mon, 2011-03-14 at 14:57 -0500, pl bossart wrote:
Other things I noticed: the volume is much higher in passthrough mode,
maybe we need to find a way to set the volume on the headset to match
the volume used for PCM. Also I heard
On Tue, 2011-03-15 at 18:50 -0600, Kelly Anderson wrote:
On 03/09/11 03:10, Arun Raghavan wrote:
Hello all,
Based on the RFC I posted earlier, I've implemented basic passthrough
support in some usable shape. It's up on the passthrough branch of each
of:
PulseAudio:
http
On Tue, 2011-03-15 at 23:13 -0600, Kelly Anderson wrote:
On 03/15/11 22:04, Arun Raghavan wrote:
On Tue, 2011-03-15 at 18:50 -0600, Kelly Anderson wrote:
On 03/09/11 03:10, Arun Raghavan wrote:
Hello all,
Based on the RFC I posted earlier, I've implemented basic passthrough
support
On Tue, 2011-03-15 at 17:36 -0500, pl bossart wrote:
I pushed your change along with a fix for the assert you saw to my tree
as well.
I tested the latest batch of patches with AC3/SPDIF this time. Works
well in general, however I found some interesting points:
- in Rhythmbox, the
On Wed, 2011-03-16 at 11:19 +0530, Arun Raghavan wrote:
[...]
It will work, but not with paplay, only with the extended API when you
create a non-PCM stream. I will rationalise the check for passthrough
sink inputs in a bit, but for now, could you change the checks (there
I've pushed a more
Hi Paul,
On Wed, 2011-02-23 at 01:07 +0530, Arun Raghavan wrote:
[...]
The correct fix for this, imo, is in bluez (there is a new
sbc_primitives_armv6.h that can probably be used at least as a
template). We need to do an sbc-udpate on the PA side anyway, and can
pull this when we do.
Could
Since Maarten's declared war on warnings, thought I'd pitch in with a
couple of fixes too. :) The first one is a boo-boo from my Orc work, and
the second might be contentious to some (but is right imho).
Cheers,
Arun
___
pulseaudio-discuss mailing list
---
src/daemon/main.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/daemon/main.c b/src/daemon/main.c
index 533c4c3..f7aed51 100644
--- a/src/daemon/main.c
+++ b/src/daemon/main.c
@@ -95,6 +95,7 @@
#endif
#include pulsecore/cpu-arm.h
#include pulsecore/cpu-x86.h
While it seems to be common practice to just work around the cast to
integer and assume alignment is fine, let's play it safe and do it right
by memcpy'ing.
---
src/modules/bluetooth/ipc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/modules/bluetooth/ipc.c
On Sat, 2011-03-19 at 18:04 -0600, Kelly Anderson wrote:
On 03/16/11 10:48, Arun Raghavan wrote:
On Wed, 2011-03-16 at 11:19 +0530, Arun Raghavan wrote:
[...]
It will work, but not with paplay, only with the extended API when you
create a non-PCM stream. I will rationalise the check
On Sun, 2011-03-20 at 13:12 +, Colin Guthrie wrote:
'Twas brillig, and Maarten Bosmans at 19/03/11 15:26 did gyre and gimble:
Mostly warnings about unused stuff.
Furthermore, the first hunk is a fix for the change in 177948a6.
Finally, comment in AEC_dtd was translated and the code
On Sun, 2011-03-20 at 22:56 +0100, Maarten Bosmans wrote:
2011/3/20 Colin Guthrie gm...@colin.guthr.ie:
'Twas brillig, and Maarten Bosmans at 19/03/11 15:26 did gyre and gimble:
Mostly warnings about unused stuff.
Furthermore, the first hunk is a fix for the change in 177948a6.
Finally,
On Tue, 2011-03-22 at 16:06 +0100, Maarten Bosmans wrote:
Is there a better way than
#if defined(__linux__) !defined(__OPTIMIZE__)
to check for a debug build? By default the CFLAGS contain -g -O2, so
__OPTIMIZE__ will not be defined and running uninstalled does not
work.
Lennart might be
On Mon, 2011-03-21 at 00:06 +0100, Paul Menzel wrote:
Dear PulseAudio folks,
[...]
I guess it has something to do with
commit 4cd90d9e32ca9a23e3c0f7615974ea0c55ff3e49
Author: Arun Raghavan arun.ragha...@collabora.co.uk
Date: Mon Oct 25 17:59:08 2010 +0100
On Thu, 2011-03-24 at 11:46 +0100, Maarten Bosmans wrote:
[...]
I think only compiling that on developer builds and inlining return
FALSE for normal, e.g. distro builds makes sense. However __OPTIMIZE__
is not a good differentiator here.
The callers all seem to be initialisation routines only,
On Thu, 2011-03-24 at 13:07 +, Colin Guthrie wrote:
'Twas brillig, and Maarten Bosmans at 24/03/11 12:44 did gyre and gimble:
2011/3/24 Maarten Bosmans mkbosm...@gmail.com:
With this you can specify the volume with 6554, 10%, 0.001 or -60dB,
all resulting in the same volume change.
On Thu, 2011-03-24 at 23:20 +0100, Paul Menzel wrote:
Dear PulseAudio folks,
I get the following error with latest master (a9c8f904).
CC libbluetooth_sbc_la-sbc.lo
In file included from
modules/bluetooth/sbc/sbc_primitives_armv6.h:30:0,
On Fri, 2011-03-25 at 08:07 +0100, Paul Menzel wrote:
Am Freitag, den 25.03.2011, 11:10 +0530 schrieb Arun Raghavan:
On Thu, 2011-03-24 at 23:20 +0100, Paul Menzel wrote:
I get the following error with latest master (a9c8f904).
CC libbluetooth_sbc_la-sbc.lo
1 - 100 of 136 matches
Mail list logo
