Secret Rabbit Code (aka libsamplerate) is a Sample Rate Converter for audio. One example of where such a thing would be useful is converting audio from the CD sample rate of 44.1kHz to the 48kHz sample rate used by DAT players.

Jean-Yves Avenard | 9 Feb 2012 15:36

Picon

Audio glitch with some audio content

Hello

I am a developer of the mythtv projects (www.mythtv.org) ; and I'm
responsible for the audio side of things.

MythTV uses your libsamplerate to resample the audio to a sampling
rate supported by the audio card hardware rather than letting the OS
audio do its own resampling: this is to guarantee a higher level of
audio quality.

I've noticed that with 8kHz 8 bits audio (and yes, those still exist
today!) , resampled to either 32kHz or 48kHz a glitch could be heard
every once in a while like a loud "click".

This phenomenon can be heard twice in the following sample:
http://miffteevee.co.uk/filebin/audio_glitch.mov

MythTV can be used to use 3 type of SRC converters:
        SRC_SINC_BEST_QUALITY           = 0,
        SRC_SINC_MEDIUM_QUALITY         = 1,
        SRC_SINC_FASTEST                        = 2,

When using SRC_SINC_FASTEST, the glitch can't be heard

With MEDIUM and BEST is can be heard, more often with MEDIUM...

To be perfectly honest, I'm not 100% sure the problem isn't in mythtv
and how it's working on block of data before feeding SRC, but provided
I get a glitch free audio when disabling SRC or using
SRC_SINC_FASTEST, it seems to me that the culprit is in libsamplerate

(Continue reading)

Erik de Castro Lopo | 9 Feb 2012 20:14

Re: Audio glitch with some audio content

Jean-Yves Avenard wrote:

> Would you mind checking it out on your side and see if you are seeing a problem?

I am 100% positive that this glitch does not occur when doing
conversions with float inputs and float output. I suspect you're
seeing this:

    http://www.mega-nerd.com/SRC/faq.html#Q001

and that if you wrote yourself a function much like these

     http://www.mega-nerd.com/SRC/api_misc.html#Aux

but to handle 8 bit samples you problems would be lessened.

Erik
--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Jean-Yves Avenard | 10 Feb 2012 01:40

Picon

Re: Audio glitch with some audio content

Hi

Thanks for your answer..

On 10 February 2012 06:14, Erik de Castro Lopo <erikd@...> wrote:
> I am 100% positive that this glitch does not occur when doing
> conversions with float inputs and float output. I suspect you're
> seeing this:
>
>    http://www.mega-nerd.com/SRC/faq.html#Q001

I should have mentioned that the 8 bits data is converted to float
obviously before being fed to SRC

The C code is as followed (we do use a converter using SSE which does
clipping automatically:
{
    int i = 0;
    float f = 1.0f / ((1<<7) - 1);

    for (; i < len; i++)
        *out++ = (*in++ - 0x80) * f;
    return len << 2;
}

>
> and that if you wrote yourself a function much like these
>
>     http://www.mega-nerd.com/SRC/api_misc.html#Aux
>

(Continue reading)

Erik de Castro Lopo | 10 Feb 2012 02:57

Re: Audio glitch with some audio content

Jean-Yves Avenard wrote:

> It's just surprising that this effect can only be heard with a
> particular resampler quality.

Ok, I didn't look at the original .mov file. Would it be possible
to extract the audio from that file and post a link to it.

Erik
--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Jean-Yves Avenard | 11 Feb 2012 09:35

Picon

Re: Audio glitch with some audio content

Hi there

On 10 February 2012 06:14, Erik de Castro Lopo <erikd@...> wrote:
> I am 100% positive that this glitch does not occur when doing
> conversions with float inputs and float output. I suspect you're
> seeing this:
>
>    http://www.mega-nerd.com/SRC/faq.html#Q001

Ok, I have checked our code once again, making sure that any clipping
properly occurs when doing the conversion from float back to int

In the clip I provided earlier, the glitch occurs 13s into playback...
I added some logs whenever the value is > 1.0 and < -1.0, it prints
out the value received.

As the minimum sampling rate support by my audio card is 32kHz, this
clip is resampled from 8kHz to 32kHz in order to be played

Here are the values I'm seeing:
2012-02-11 18:33:07.665488 I  AOUtil: Clipcheck overflow: 2.85226e+29
2012-02-11 18:33:07.665503 I  AOUtil: Clipcheck overflow: 2.85226e+29
2012-02-11 18:33:07.665507 I  AOUtil: Clipcheck overflow: 3.21367e+32
2012-02-11 18:33:07.665510 I  AOUtil: Clipcheck overflow: 3.21367e+32
2012-02-11 18:33:07.665514 I  AOUtil: Clipcheck overflow: 1.25487e+33
2012-02-11 18:33:07.665517 I  AOUtil: Clipcheck overflow: 1.25487e+33
2012-02-11 18:33:07.665521 I  AOUtil: Clipcheck overflow: 8.32266e+37
2012-02-11 18:33:07.665525 I  AOUtil: Clipcheck overflow: 8.32266e+37
2012-02-11 18:33:07.665528 I  AOUtil: Clipcheck overflow: 1.16768e+27
2012-02-11 18:33:07.665531 I  AOUtil: Clipcheck overflow: 1.16768e+27

(Continue reading)

Erik de Castro Lopo | 11 Feb 2012 09:56

Re: Audio glitch with some audio content

Jean-Yves Avenard wrote:

> Ok, I have checked our code once again, making sure that any clipping
> properly occurs when doing the conversion from float back to int
> 
> In the clip I provided earlier, the glitch occurs 13s into playback...
> I added some logs whenever the value is > 1.0 and < -1.0, it prints
> out the value received.
> 
> As the minimum sampling rate support by my audio card is 32kHz, this
> clip is resampled from 8kHz to 32kHz in order to be played
> 
> Here are the values I'm seeing:
> 2012-02-11 18:33:07.665488 I  AOUtil: Clipcheck overflow: 2.85226e+29

<snip>

> 2012-02-11 18:33:07.666374 I  AOUtil: Clipcheck overflow: 1.88322e+19
> 
> 
> Those are values *significantly* over 1.0f, max is 8.38964e+37

Those are not due to libsamplerate. You have a bug in your code.

> Now, interestingly, this doesn't happen all the time... I could play
> the clip 5 times, and only get the glitch twice...

I suspect that these weird values are due to uniinitialized data.

> I've extracted the audio for you (you can do so easliy yourself with

(Continue reading)

Jean-Yves Avenard | 13 Feb 2012 02:27

Picon

Re: Audio glitch with some audio content

Hi

Thanks for the quick answer...

On 11 February 2012 19:56, Erik de Castro Lopo <erikd@...> wrote:
> Those are not due to libsamplerate. You have a bug in your code.

I did indeed.

I created a mockup code processing the data the same way myth did, and
sure enough, the output was identical.

Turned out, it was how the data was being rewritten into the audio
circular buffer, the pointer to the buffer was miscalculated (only
when upmixing mono to stereo) and was pointing to garbage ...

I noticed something that caught my attention however..

From the documentation:
The input_frames_used and output_frames_gen fields are set by the
converter to inform the caller of the number of frames consumed from
the data_in array and the number of frames generated in the data_out
array respectively. These values are for the current call to
src_process only.

is there a possibility, after a call to src_process that
input_frames_used be different to input_frames? and if so, does SRC
buffers unused frame from a previous call to src_process to be used
for another call later (end_of_input is set to 0 in my case)

(Continue reading)

Erik de Castro Lopo | 13 Feb 2012 03:56

Re: Audio glitch with some audio content

Jean-Yves Avenard wrote:

> On 11 February 2012 19:56, Erik de Castro Lopo wrote:
> > Those are not due to libsamplerate. You have a bug in your code.
> 
> I did indeed.



> I noticed something that caught my attention however..
> 
> From the documentation:
> > The input_frames_used and output_frames_gen fields are set by the
> > converter to inform the caller of the number of frames consumed from
> > the data_in array and the number of frames generated in the data_out
> > array respectively. These values are for the current call to
> > src_process only.
> 
> is there a possibility, after a call to src_process that
> input_frames_used be different to input_frames?

Yes.

> and if so, does SRC
> buffers unused frame from a previous call to src_process to be used
> for another call later (end_of_input is set to 0 in my case)

Absolutely yes. In fact it must do so with all the SRC_SINC_* converters
because those are basically linear phase FIR filters which calculate
current output based on past *and* future input. Obviously it can't see

(Continue reading)

Jean-Yves Avenard | 13 Feb 2012 07:47

Picon

Re: Audio glitch with some audio content

Hi

On 13 February 2012 13:56, Erik de Castro Lopo <erikd@...> wrote:

>> is there a possibility, after a call to src_process that
>> input_frames_used be different to input_frames?
>
> Yes.

Is that also the case for MEDIUM and BEST?

>
>> and if so, does SRC
>> buffers unused frame from a previous call to src_process to be used
>> for another call later (end_of_input is set to 0 in my case)
>
> Absolutely yes. In fact it must do so with all the SRC_SINC_* converters
> because those are basically linear phase FIR filters which calculate
> current output based on past *and* future input. Obviously it can't see
> the future input so it only generates output for the amount of future
> samples it has in hand.

hum...

I wonder if I can assume that, knowing I only use FAST, MEDIUM and
BEST, I can safely assume that the input before and processed will be
the same. This would greatly simplify the code...

Erik de Castro Lopo | 13 Feb 2012 07:53

Re: Audio glitch with some audio content

Jean-Yves Avenard wrote:

> Hi
> 
> On 13 February 2012 13:56, Erik de Castro Lopo <erikd@...> wrote:
> 
> >> is there a possibility, after a call to src_process that
> >> input_frames_used be different to input_frames?
> >
> > Yes.
> 
> Is that also the case for MEDIUM and BEST?

Yes, all SRC_SINC_* converters. In fact all the converters depend on
that.

> hum...
> 
> I wonder if I can assume that, knowing I only use FAST, MEDIUM and
> BEST, I can safely assume that the input before and processed will be
> the same. This would greatly simplify the code...

Err, what is the question?

Erik
--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

(Continue reading)

Jean-Yves Avenard | 13 Feb 2012 08:17

Picon

Re: Audio glitch with some audio content

Hi

On 13 February 2012 17:53, Erik de Castro Lopo <erikd@...> wrote:
>> Is that also the case for MEDIUM and BEST?
>
> Yes, all SRC_SINC_* converters. In fact all the converters depend on
> that.

ok
>> I wonder if I can assume that, knowing I only use FAST, MEDIUM and
>> BEST, I can safely assume that the input before and processed will be
>> the same. This would greatly simplify the code...
>
> Err, what is the question?

No question other that if I could just assume it would be the same
both in and out...
I have so far always ignored the number of processed frame returned by
SRC, and I've seen no ill effect. And the code has been used for a
while by quite a significant amount of people, and no-one has reported
issue either.

While audio wouldn't suffer any glitch (as SRC just buffered it, so
nothing is ever lost), how much data is buffered has an impact when
calculating the latency and as such would result in bad A/V sync..

So I need to cater for the amount buffered and include this when
determining the audio latency
JY

(Continue reading)

Erik de Castro Lopo | 13 Feb 2012 08:27

Re: Audio glitch with some audio content

Jean-Yves Avenard wrote:

> No question other that if I could just assume it would be the same
> both in and out...

You cannot assume that.

> I have so far always ignored the number of processed frame returned by
> SRC, and I've seen no ill effect.

You haven't looked hard enough. The input_frames_used and output_frames_gen
fields should be used apprpriately.

> And the code has been used for a
> while by quite a significant amount of people, and no-one has reported
> issue either.

With 8 bit audio, thats not too supsrising.

Erik
--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Jean-Yves Avenard | 13 Feb 2012 08:34

Picon

Re: Audio glitch with some audio content

Hi

On 13 February 2012 18:27, Erik de Castro Lopo <erikd@...> wrote:
> With 8 bit audio, thats not too supsrising.
>

This isn't limited to 8 bits audio... but to any audio being played
requiring resampling..

Jean-Yves Avenard | 13 Feb 2012 11:53

Picon

Re: Audio glitch with some audio content

Hi

On 13 February 2012 18:27, Erik de Castro Lopo <erikd@...> wrote:
>> No question other that if I could just assume it would be the same
>> both in and out...
>
> You cannot assume that.

For what it's worth..
I've tried pretty much every combination possible of sampling rate,
and input_frames_used was always equal to input_frames in all cases
after src_process...

JY

Erik de Castro Lopo | 13 Feb 2012 22:01

Re: Audio glitch with some audio content

Jean-Yves Avenard wrote:

> Hi
> 
> On 13 February 2012 18:27, Erik de Castro Lopo <erikd@...> wrote:
> >> No question other that if I could just assume it would be the same
> >> both in and out...
> >
> > You cannot assume that.
> 
> For what it's worth..
> I've tried pretty much every combination possible of sampling rate,
> and input_frames_used was always equal to input_frames in all cases
> after src_process...

The thing about the SRC process is that for all ratios other than 1.0,
the number of output frames and the number of input frames are going
to be different.

If you:

  a) Upsample, ie ratio > 1.0 (choose say 2.0).
  b) Use small output buffers.
  c) Use input buffers much larger than the output buffers

you will see input_frames_used < input_frames.

Erik
--

-- 
----------------------------------------------------------------------

(Continue reading)

Jean-Yves Avenard | 14 Feb 2012 02:54

Picon

Re: Audio glitch with some audio content

Hi again

On 14 February 2012 08:01, Erik de Castro Lopo <erikd@...> wrote:
> If you:
>
>  a) Upsample, ie ratio > 1.0 (choose say 2.0).
>  b) Use small output buffers.
>  c) Use input buffers much larger than the output buffers

I've tried the following conversion
8kHz -> 32, 44.1, 48, 96kHz
32kHz -> 44.1, 48, 96
48 -> 44.1, 96

input_frames_used always equaled to input_frames after src_process.

output buffer size is calculated so the whole input buffer can be upsampled

So I'm not sure why I'm not seeing what you describe....

I'll give this a rest for now...
Thanks again for your help

Return

Return to gmane.comp.audio.src.general.

Advertisement

Project Web Page

Secret Rabbit Code (aka libsamplerate) is a Sample Rate Converter for audio. One example of where such a thing would be useful is converting audio from the CD sample rate of 44.1kHz to the 48kHz sample rate used by DAT players.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane