hi,
I got not stable results, which means the optimization is not as good
as expected.
All results based on plain c volume function, not touch sse part.
All tests are for format s16ne.
Result1: channels 4, with same volume, with patch; samples 1021, loop 1000;
Result2: channels 4, with same
2011/10/18 Pierre-Louis Bossart pierre-louis.boss...@linux.intel.com:
Very Cool feature! Why not change sample_spec totally according to
sink's availability, but only sample rate? The default sample_spec
used at initialization, if alsa driver supports various formats/rates,
PA could change
2011/10/19 Robert Orzanna orsch...@googlemail.com:
Hello,
With the new version of pulse (1.0-4) I hoped that pulse will somehow take
care of my alsa settings which still is not the case.
All settings, for example set with alsamixer, are discarded after reboot.
Indeed, pulse takes over the
2011/10/19 Lu Guanqun guanqun...@intel.com:
Hi Maarten,
Thanks for your nice work, I'll take a look.
According to my test here, it seems soft volume processing doesn't cost
CPU usage too much, instead, it's the resampling that takes much CPU
usage. e.g. one sink input, resampler of
2011/10/19 Wang Xingchao wangxingchao2...@gmail.com:
hi,
I got not stable results, which means the optimization is not as good
as expected.
All results based on plain c volume function, not touch sse part.
It's good to test your optimizations. Be sure to also test with
various lengths of the
'Twas brillig, and David Henningsson at 18/10/11 20:56 did gyre and gimble:
While in general I agree that a boolean is a fine success/failure return
type, I think in Pulseaudio the convention is to stick just to ints.
Hmm. A quick 'grep -r return TRUE' of PulseAudio source tree seems to
give
'Twas brillig, and David Henningsson at 19/10/11 05:55 did gyre and gimble:
On 10/19/2011 12:11 AM, Pierre-Louis Bossart wrote:
Did you miss my previous explanation, or did you find it insufficient?
I'm repeating it below:
The protocol skew in Ubuntu 11.10 was actually a mistake on my part.
On Wed, 2011-10-19 at 13:00 +0300, Colin Guthrie wrote:
'Twas brillig, and David Henningsson at 18/10/11 20:56 did gyre and gimble:
While in general I agree that a boolean is a fine success/failure return
type, I think in Pulseaudio the convention is to stick just to ints.
Hmm. A quick
On Wed, 2011-10-19 at 13:11 +0300, Tanu Kaskinen wrote:
That gives a big list indeed. But did you check the context? I went
through quite a lot (but not nearly all) of the output from 'git grep -n
-e return TRUE -e return FALSE' and the overwhelming majority of the
I actually meant
git
Hi,
As a general comment, I'd rather avoid introducing a new naming
convension with the ABOUT_TO_ACTIVATE suffix.
We already have _POST, _START and _FINISH suffixes on some hooks, so I'd
suggest either a _PRE suffix to match _POST or perhaps just reusing
_START (tho' _START does seem to imply
'Twas brillig, and Daniel Wagner at 18/10/11 15:33 did gyre and gimble:
Hi Everyone,
[Sorry for cross posting but it might be interesting for someone on
these mailing lists]
I would like to invite to a IRC discussion on the HFP audio handling.
Topic is to find a solution for the
'Twas brillig, and Tanu Kaskinen at 18/10/11 13:03 did gyre and gimble:
Hi,
I'm writing a new module that needs to run some code before the profiles
of a certain alsa card are activated. For this I need a new hook in the
core: PA_CORE_HOOK_CARD_PROFILE_ABOUT_TO_ACTIVATE or something like
On Wed, 2011-10-19 at 13:20 +0300, Colin Guthrie wrote:
Hi,
As a general comment, I'd rather avoid introducing a new naming
convension with the ABOUT_TO_ACTIVATE suffix.
We already have _POST, _START and _FINISH suffixes on some hooks, so I'd
suggest either a _PRE suffix to match _POST or
On Wed, 2011-10-19 at 13:46 +0300, Tanu Kaskinen wrote:
One possibility would be CARD_PROFILE_ACTIVATING. I think that would
imply that it's fired prior to the actual activation. That's my vote
currently :)
I've changed my vote again. Now I vote for CARD_PROVILE_ACTIVATE_START.
I don't
On Wed, 2011-10-19 at 14:29 +0300, David Henningsson wrote:
Looks good and does not seem to interfere with anything in the jack
detection patches. Having a card pointer might even be helpful.
Just a thought: Can profiles be added after pa_card_new? In that case
they will never get a
2011/10/17 Brian Cameron brian.came...@oracle.com:
I found this issue when I try to build PA clients. For example, when
PulseAudio tries to build pactl, I see these errors. I see similar
errors trying to build any PA client:
Undefined first referenced
symbol
Maarten:
I updated the patch as attached to address your comments. This
has #ifdef __sun used more properly and a comment.
Also note that I added a comment to the bug to answer your question
that LOG_INFO and LOG_WARNING are defined in the system syslog.h
header, not in PulseAudio.
Brian
Maarten:
Thanks for the pointers, you helped me figure out how to get PulseAudio
building on Solaris without libpulsecommon needing to link against
libpulsecore.
The issue seems to be caused by the fact that libpulsecommon includes
pulsecore/pstream.c, which includes pulsecore/core-scache.h to
---
src/modules/alsa/alsa-mixer.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index 3f27fdc..f390119 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -2956,6 +2956,10 @@
The patch looks simple, but I'm not entirely sure the concept is
sound. Please review.
The problem I'm trying to solve is that analog-output-mono is (in my
view incorrectly) seen as a subset of analog-output-lfe-on-mono.
Relevant debug output:
D: [lt-pulseaudio] alsa-mixer.c: Path
2011/10/19 Brian Cameron brian.came...@oracle.com:
The issue seems to be caused by the fact that libpulsecommon includes
pulsecore/pstream.c, which includes pulsecore/core-scache.h to gain access
to the PA_SCACHE_ENTRY_SIZE_MAX #define.
Moving this #define so it is in pulsecore/memchunk.h (a
On 10/19/2011 08:47 PM, Maarten Bosmans wrote:
The patch looks simple, but I'm not entirely sure the concept is
sound. Please review.
The problem I'm trying to solve is that analog-output-mono is (in my
view incorrectly) seen as a subset of analog-output-lfe-on-mono.
Relevant debug output:
D:
OK, in my quest to get the output of one application to be used as the
input for another, I got module-null-sink all set
from list short sinks
9 vac module-null-sink.c s16le 2ch 44100Hz SUSPENDED
from list short sources
12 vac.monitor module-null-sink.c s16le
On Tue, 2011-10-18 at 14:48 +0800, Lu Guanqun wrote:
CC libpulsedsp_la-padsp.lo
utils/padsp.c:1524:5: warning: no previous prototype for '__open_2'
[-Wmissing-prototypes]
utils/padsp.c:2560:5: warning: no previous prototype for '__open64_2'
[-Wmissing-prototypes]
---
On Mon, 2011-10-03 at 18:11 +0300, Tanu Kaskinen wrote:
---
Pulled to my tree with a fix to the commit message since I'd like to
(somewhat) standardise the namespaces for commit messages.
Thanks,
Arun
___
pulseaudio-discuss mailing list
On Wed, 2011-10-19 at 14:10 +0200, Maarten Bosmans wrote:
As they are already included in libpulsecommon.
---
AFAICT, time-smoother.h is used in libpulse (pa_stream_get_time), but
shm.h is not, so shouldn't be in pulsecommon.
-- Arun
___
On Tue, 2011-10-18 at 17:09 -0400, Wang Xingchao wrote:
if all channels have same volume setting, use fast way to
do volume change. this patch intended to work for two formats:
s16ne/s16re.
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
As Tanu points out, some hard data here
On Tue, 2011-10-18 at 12:10 +0200, Maarten Bosmans wrote:
2011/10/18 Wang Xingchao xingchao.w...@intel.com:
if all channels have same volume setting, use fast way to
do volume change. this patch intended to work for two formats:
s16ne/s16re.
[...]
The Orc svolume implementation currently
28 matches
Mail list logo
