Hello.
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 mistakenly consider the samples to be properly
initial
On 2014-12-04 18:54, Alexander E. Patrakov wrote:
Hello.
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 mista
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 mistakenly consider the samples to be
On Thu, Dec 4, 2014 at 8:42 PM, 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
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 mista
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
> st
