pa_memblockq_drop is guaranteed to drop the chunk we just extracted from the
memblockq which internally unrefs the chunk.
---
I checked just after pa_memblockq_peek and before pa_memblockq_drop calls with
the following code:
pa_log(chunk memblock %p refs: %d ours: %d ro: %d silence: %d,
Several mallocs were made using fftwf_malloc and were erroneously freed by
pa_xfree. This patch corrects these calls of pa_xfree to fftwf_free.
---
src/modules/module-equalizer-sink.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
On 2014-12-05 00:42, Peter Meerwald wrote:
Hello David,
I am still trying to valgrind pulseaudio. The previous attempt yielded
nothing about the bug that I was trying to debug, but found a Bluetooth
issue. This time, I thought that maybe some memory pool or flist was
causing valgrind to
Hi,
Cool, thanks for testing and keep 'em coming :-)
did you test srbchannel on record streams?
I get one max-block-size worth of crap before capturing actual audio data;
can you reproduce?
Found it: this is due to block_id collision between the rwpool and the
standard mempool,
Every new memexport object now gets an ever increasing base index,
that prevents block ID collisions between different memexport
objects on the same pstream.
In particular, this prevents block ID collision between the srb memblock
(which has its own memexport object) and audio data blocks.
Make sure we don't hand out the wrong block, in case we have the
same block ID in different SHM segments.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/pulsecore/memblock.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/pulsecore/memblock.c
On 2014-12-05 12:51, Peter Meerwald wrote:
Make sure we don't hand out the wrong block, in case we have the
same block ID in different SHM segments.
this adds two checks: for block type and that the shm id matches
using %u in pa_log() would save the (int) casts;
Ok
maybe both, shm_id
On 2014-12-03 15:50, Michael DePaulo wrote:
Since some point after 5.0 was released, I have been unable to build
PulseAudio with ORC (The Oil Runtime Compiler).
I can work around this issue easily by disabling ORC (passing
--disable-orc to mingw32-configure), but I thought I'd report this
On Fri, 2014-12-05 at 00:37 +0500, Alexander E. Patrakov wrote:
(I have also looked at previous patches in the series, but have no
comments about them)
04.12.2014 23:44, Tanu Kaskinen wrote:
+void pa_tunnel_manager_remote_server_new(pa_tunnel_manager *manager,
Make sure we don't hand out the wrong block, in case we have the
same block ID in different SHM segments.
this adds two checks: for block type and that the shm id matches
using %u in pa_log() would save the (int) casts;
Ok
maybe both, shm_id and
memory.id could be logged?
This fixes an issue when requesting module unload for
module-bluetooth-discover. When unloading the module, it also unloads
module-bluez4-discover and/or module-bluez5-discover, and that
invalidated the state variable that was used for iterating through the
modules idxset.
The
On 2014-12-04 19:44, Tanu Kaskinen wrote:
When using PulseAudio in system mode, it may be interesting to know
which seats the devices are assigned to. This will be used in the
tunnel manager to filter out the devices that belong to other users.
I'd prefer if PA_PROP_UDEV_SEAT was called
This fixes an issue when requesting module unload for
module-bluetooth-discover. When unloading the module, it also unloads
module-bluez4-discover and/or module-bluez5-discover, and that
invalidated the state variable that was used for iterating through the
modules idxset.
The
It looks like this could cause a problem in case somebody (ab)uses the
API like:
pa_module_unload_request(m, true);
pa_module_unload(c, m, true);
...later on, the deferred event triggers, and modules_pending_unload now
has dangling pointers.
I'm not sure this is ever encountered in the
On Fri, 2014-12-05 at 15:00 +0100, David Henningsson wrote:
On 2014-12-04 19:44, Tanu Kaskinen wrote:
When using PulseAudio in system mode, it may be interesting to know
which seats the devices are assigned to. This will be used in the
tunnel manager to filter out the devices that belong
On Fri, 2014-12-05 at 16:22 +0200, Tanu Kaskinen wrote:
On Fri, 2014-12-05 at 15:00 +0100, David Henningsson wrote:
On 2014-12-04 19:44, Tanu Kaskinen wrote:
When using PulseAudio in system mode, it may be interesting to know
which seats the devices are assigned to. This will be used
On Fri, 2014-12-05 at 15:14 +0100, David Henningsson wrote:
It looks like this could cause a problem in case somebody (ab)uses the
API like:
pa_module_unload_request(m, true);
pa_module_unload(c, m, true);
...later on, the deferred event triggers, and modules_pending_unload now
has
Looks good to me.
On 2014-12-05 15:11, Tanu Kaskinen wrote:
This fixes an issue when requesting module unload for
module-bluetooth-discover. When unloading the module, it also unloads
module-bluez4-discover and/or module-bluez5-discover, and that
invalidated the state variable that was used for
Hi David,
That is indeed the problem. No matter what version of OpenSUSE I use
for the build (I just upgraded from 12.3 to 13.2), mingw32 liborc is
still at version 0.4.16:
https://build.opensuse.org/package/show/windows:mingw:win32/mingw32-orc
I will look into packaging the latest version of
On Fri, 2014-12-05 at 15:37 +0100, David Henningsson wrote:
Looks good to me.
Thanks, pushed.
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
On 2014-12-05 15:44, Michael DePaulo wrote:
Hi David,
That is indeed the problem. No matter what version of OpenSUSE I use
for the build (I just upgraded from 12.3 to 13.2), mingw32 liborc is
still at version 0.4.16:
https://build.opensuse.org/package/show/windows:mingw:win32/mingw32-orc
I
On 2014-12-05 15:31, Tanu Kaskinen wrote:
On Fri, 2014-12-05 at 16:22 +0200, Tanu Kaskinen wrote:
On Fri, 2014-12-05 at 15:00 +0100, David Henningsson wrote:
On 2014-12-04 19:44, Tanu Kaskinen wrote:
When using PulseAudio in system mode, it may be interesting to know
which seats the
It sounds like the cause is the current configuration I am using to build:
1. The native OpenSUSE 13.2 ORC compiler (package: orc ) at version 4.22,
2. The mingw32 headers (package: mingw32-liborc-devel ) at version 4.16
Although, it looks like the ORC compiler binary (orcc.exe) is actually
ACK to both patches.
05.12.2014 13:38, Jason Newton wrote:
pa_memblockq_drop is guaranteed to drop the chunk we just extracted from the
memblockq which internally unrefs the chunk.
---
I checked just after pa_memblockq_peek and before pa_memblockq_drop calls with
the following code:
24 matches
Mail list logo
