On Wed, 2014-11-05 at 22:29 -0600, Hajime Fujita wrote:
> Hi Tanu,
>
> Thank you for your comment and sorry for the late reply.
>
> Tanu Kaskinen wrote:
> > On Tue, 2014-10-21 at 00:49 -0500, Hajime Fujita wrote:
> >> Hello,
> >>
> >> I'm currently working on IPv6 support for the raop module [1].
Hi Tanu,
Thank you for your comment and sorry for the late reply.
Tanu Kaskinen wrote:
On Tue, 2014-10-21 at 00:49 -0500, Hajime Fujita wrote:
Hello,
I'm currently working on IPv6 support for the raop module [1].
During the work I found a potential issue in
pa_socket_client_new_string() (in
Ack
On 2014-11-05 00:26, Peter Meerwald wrote:
From: Peter Meerwald
Signed-off-by: Peter Meerwald
---
src/pulsecore/resampler.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c
index 5e9dc39..8b30c24 100644
--- a/src/pulsecore/
>>>
>>> These two control names are currently being added to the HDA driver,
>>> so let's support them in PulseAudio as well.
>>>
>>> Signed-off-by: David Henningsson
>>> ---
>>>
>>> v2: Addressed comments by Tanu
>>>
>>> src/modules/alsa/mixer/paths/analog-output-headphones-2.conf | 8
05.11.2014 04:25, Peter Meerwald wrote:
this patch series aims to save memory allocations and some system calls
related to PA's client/server protocol implementation
Patches 49, 46, 41, 39, 35, 32, 24, 13, 12 are obviously correct. And I
don't feel like looking at non-obvious patches after tod
On Tue, Nov 4, 2014 at 3:39 PM, Colin Guthrie wrote:
> Felipe Sateler wrote on 03/11/14 20:28:
>> On Mon, Nov 3, 2014 at 1:30 PM, Colin Guthrie wrote:
>>> Felipe Sateler wrote on 03/11/14 12:55:
Hi,
I'm replying to this message but I the general question is a bit
broader than
On Wed, 5 Nov 2014, Alexander E. Patrakov wrote:
> 05.11.2014 04:26, Peter Meerwald wrote:
> > -/* work-around assert in pa_source_set_latency_within_thead,
> > - keep track of min_latency and reuse it when
> > - this routine is called from IO context */
> > +/*
05.11.2014 04:26, Peter Meerwald wrote:
-/* work-around assert in pa_source_set_latency_within_thead,
- keep track of min_latency and reuse it when
- this routine is called from IO context */
+/* Work-around assert in pa_source_set_latency_within_thead,
Typo
Hi,
> > probably not in a measureable way;
>
> Hmm, but yet you listed this one as one of your "critical patches"...?
ah, critical in the sense that it might break something, needs review...
for most patches it is hard to say what the impact is (besides argueing
that at malloc(), read(), etc.
On 2014-11-05 12:01, Peter Meerwald wrote:
when the wakeup pipe became ready, and poll() returned
just one descriptor, we can stop scanning io_events
Eh, does this really make things faster?
probably not in a measureable way;
Hmm, but yet you listed this one as one of your "critical pat
On Wed, 2014-11-05 at 12:06 +0100, David Henningsson wrote:
>
> On 2014-11-04 11:53, Tanu Kaskinen wrote:
> > On Mon, 2014-11-03 at 07:20 +0100, David Henningsson wrote:
> >> diff --git a/src/modules/alsa/mixer/paths/analog-output-headphones-2.conf
> >> b/src/modules/alsa/mixer/paths/analog-outpu
On 2014-11-04 11:53, Tanu Kaskinen wrote:
On Mon, 2014-11-03 at 07:20 +0100, David Henningsson wrote:
These two control names are currently being added to the HDA driver,
so let's support them in PulseAudio as well.
Signed-off-by: David Henningsson
---
v2: Addressed comments by Tanu
src/
> > when the wakeup pipe became ready, and poll() returned
> > just one descriptor, we can stop scanning io_events
>
> Eh, does this really make things faster?
probably not in a measureable way;
I think the patch makes the codes more logical:
* if we know that no io_event triggered, there is n
On 2014-11-05 00:26, Peter Meerwald wrote:
From: Peter Meerwald
when the wakeup pipe became ready, and poll() returned
just one descriptor, we can stop scanning io_events
Eh, does this really make things faster?
Right now it seems to add another syscall - with the patch, we call
clear_wak
Hi,
> > > preliminary benchmarking on Intel i5-2400S, 64-bit, Linux 3.13:
> > >
> > > running 'paplay --latency-msec=10 stereo_48KHz.wav', output on internal
> > > soundcard (Intel HDA), measuring the maximum CPU% in top for the
> > > pulseaudio
> > > and paplay
> > >
> > > code flags
> > ... in order to increase the chance that SHMRELEASE will be combined
> > with some other message; SHMRELEASE gets into the send queue, but
> > the mainloop is not notified about it
>
> ...the idea being that shmrelease is not crucial to get any time soon,
> it's just about reclaiming memory
On 2014-11-05 00:26, Peter Meerwald wrote:
From: Peter Meerwald
... in order to increase the chance that SHMRELEASE will be combined
with some other message; SHMRELEASE gets into the send queue, but
the mainloop is not notified about it
...the idea being that shmrelease is not crucial to ge
On 05.11.2014 11:57, Arun Raghavan wrote:
On 5 November 2014 15:04, Ville Sundell wrote:
Greetings everyone!
I am having some problems with corking: pulseaudio policy enforcer will cork
all the streams which belongs to a corked group. However, despite the fact
corking itself happens correctly
Hi,
> > preliminary benchmarking on Intel i5-2400S, 64-bit, Linux 3.13:
> >
> > running 'paplay --latency-msec=10 stereo_48KHz.wav', output on internal
> > soundcard (Intel HDA), measuring the maximum CPU% in top for the pulseaudio
> > and paplay
> >
> > code flags PA pa
On 5 November 2014 15:04, Ville Sundell wrote:
> Greetings everyone!
> I am having some problems with corking: pulseaudio policy enforcer will cork
> all the streams which belongs to a corked group. However, despite the fact
> corking itself happens correctly (via pa_sink_input_cork() at
> pulseau
On 2014-11-05 00:25, Peter Meerwald wrote:
preliminary benchmarking on Intel i5-2400S, 64-bit, Linux 3.13:
running 'paplay --latency-msec=10 stereo_48KHz.wav', output on internal
soundcard (Intel HDA), measuring the maximum CPU% in top for the pulseaudio
and paplay
code flags
Greetings everyone!
I am having some problems with corking: pulseaudio policy enforcer will
cork all the streams which belongs to a corked group. However, despite
the fact corking itself happens correctly (via pa_sink_input_cork() at
pulseaudio-policy-enforcement:src/policy-group.c) the stream
22 matches
Mail list logo
