[mythtv] [mythtv-commits] Ticket #10396: Periodical, short audio artifacts in one the channels when upmixing to 5.1

Jean-Yves Avenard jyavenard at gmail.com
Thu Mar 8 08:18:46 UTC 2012


Hi

On 8 March 2012 17:33, Mark Spieth <mark at digivation.com.au> wrote:
> I did check that 16 secs could be 3072000/2/2/48000 (mpeg2 x 2ch x 48k)
> which is the primary buffer. Which indicates that its still a main
> buffer wrap issue.
> Not that I understand yet.

It is certainly a possibility. I had a great deal of trouble finding a
way to write in the audio ringbuffer that would be compatible with all
the sizes of the utility class being used: timestretch, upmixer,
downmixer, float conversion, int conversion, volume control, spdif
encoder

They all have a different buffer size and we have to write in such a
way in those buffers that data do not overflow..

One thing I do remember however, is that I've never managed to simply
increase the size of the upmixer internal buffer. Only the value set
now works. Why? I have no clue and I didn't spend much time looking
into it.

When I found out that with some media, the audio frames being sent
were huge (I have a sample of a german broadcast where the audio
packets are over 200kB (when it's normally around the 1-2k) That
caused a crash at multiple levels.

My first quick fix was to simply increase the size of the upmixer
buffer to the size of the audio ringbuffer * 3, ad it can't ever
receive more data.

Than didn't work at all.

So I still suspect something dodgy in the upmixer in the way it
handles when you fully fill its buffer. Because changing the size of
the upmixer buffer should have no consequences on how it works

> Could it be that the first more is overwritten in the buffer than is
> absorbed and that the 2nd read of the buffer is invalid or has crap?
> I also cant remember if the buffer was frame constrained or byte
> constrained in length?

the audio ringbuffer size is set in bytes. It can contains either
float (if audio processing is occurring) or the original audio data
format (8, 16 or 32 bits int)

> I need to take a close look at everything. weekend perhaps.

appreciated, a new set of eyes could definitely help. I'm so up to my
neck with this one that I may be overseeing an obvious problem

>
> apologies for my previous stupidity.

Sorry for being so touchy on the subject, I have reviewed that code a
1000 times because each time an issue arise, it's the obviously place
where it could be wrong.


More information about the mythtv-dev mailing list