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)

Group

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

Page

1 | 2

Articles in period: 18

February 2012

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

Recent entries

make check failure: output len : 7889 (should be 7890 +/- 1) (17 Jun 2013)
SRC for Win7 x64 (2 Jun 2013)
one sample at a time (20 May 2013)
estimating total number of frames output (24 Feb 2013)
/bin/sh: /Volumes/Macintosh: No such file or directory (17 Feb 2013)
Making SRC_DATA const-correct (14 Jan 2013)
Recent version of libsamplerate.dll for Windows (9 Nov 2012)
Option to disable normalization in sndfile-resample (6 Oct 2012)
Building LibKeyFinder Source (5 Oct 2012)
/usr/bin/vlc was killed by signal 8 (SIGFPE) due to libsamplerate (21 Aug 2012)
Thread safety (20 Feb 2012)
Audio glitch with some audio content (9 Feb 2012)
libsamplerate and aliasing (23 Dec 2011)
SRC_MAX_RATIO (12 Nov 2011)
question about a possible bug in either libsamplerate or pulseaudio (7 Nov 2011)
Access violation with varispeed-play (1 Nov 2011)
Clicks and noises in output (26 Jul 2011)
Resampling Output Levels (7 Feb 2011)
Change in the tarball libsamplerate-0.1.7.tar.gz (15 Oct 2010)
Samplerate compile on 64 bit windows (21 Sep 2010)
Help with compiling the upsampler (15 Sep 2010)

Archives

13	June 2013
2	May 2013
13	February 2013
2	January 2013
1	November 2012
10	October 2012
9	August 2012
18	February 2012
2	December 2011
35	November 2011
4	July 2011
2	February 2011
4	October 2010
7	September 2010
2	May 2010
11	April 2010
2	March 2010
5	February 2010
12	January 2010
2	December 2009
3	November 2009
11	October 2009
2	September 2009
18	August 2009
4	July 2009

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template