Interesting critter when recording

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Interesting critter when recording

Leland (Audacity Team)
So, I've been trying to figure out what is causing this problem:



It only seems to happen in Debug Builds.
It only seems to happen with WASAPI and WDMKS.
It only seems to happen when recording in 16-bit.
It only seems to happen when recording at 44,100.
It happens with both of my audio devices.

So, as you can see, there's a LOT of things that have to be just right.  But, what I found makes me wonder how on earth this has never been noticed before.

It's nearly an 11 year old bug.

https://code.google.com/p/audacity/source/detail?r=1927&path=/sf-cvs/trunk/audacity-src/src/RingBuffer.cpp

This:

dest += block
* SAMPLE_SIZE(mFormat);

Should have been:

dest += block * SAMPLE_SIZE(format);

If this ever did exhibit itself in the wild, there would have been complaints about mysterious clicks, dropouts, noise, etc.  But, it may never have happened since I can't get it to occur with MME or DS.  It has to do with the gets and puts to the capture buffers being on an exact buffer end boundary.  (I "think" there might be an additional issue there, but still checking.)

I didn't want to commit anything until others have had a chance to look at RingBuffer::Get() to confirm (or reject) the change.

Leland


------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

MartynShaw
Any updates on this?

Martyn

On 23/09/2013 16:59, Leland wrote:

> So, I've been trying to figure out what is causing this problem:
>
>
>
> It only seems to happen in Debug Builds.
> It only seems to happen with WASAPI and WDMKS.
> It only seems to happen when recording in 16-bit.
> It only seems to happen when recording at 44,100.
> It happens with both of my audio devices.
>
> So, as you can see, there's a LOT of things that have to be just
> right.  But, what I found makes me wonder how on earth this has never
> been noticed before.
>
> It's nearly an 11 year old bug.
>
> https://code.google.com/p/audacity/source/detail?r=1927&path=/sf-cvs/trunk/audacity-src/src/RingBuffer.cpp
>
> This:
> *
> dest += block*** SAMPLE_SIZE(mFormat)**;*
>
> Should have been:
>
> *dest += block*** SAMPLE_SIZE(*f*ormat)**;*
>
> If this ever did exhibit itself in the wild, there would have been
> complaints about mysterious clicks, dropouts, noise, etc.  But, it may
> never have happened since I can't get it to occur with MME or DS.  It
> has to do with the gets and puts to the capture buffers being on an
> exact buffer end boundary.  (I "think" there might be an additional
> issue there, but still checking.)
>
> I didn't want to commit anything until others have had a chance to
> look at RingBuffer::Get() to confirm (or reject) the change.
>
> Leland
>
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

Leland (Audacity Team)
On 9/26/2013 8:12 PM, Martyn Shaw wrote:
> Any updates on this?
None really.  I'm pretty confident that the line is incorrect and I was
just waiting for someone else to take a peek and either confirm or deny.

Leland

>
> Martyn
>
> On 23/09/2013 16:59, Leland wrote:
>> So, I've been trying to figure out what is causing this problem:
>>
>>
>>
>> It only seems to happen in Debug Builds.
>> It only seems to happen with WASAPI and WDMKS.
>> It only seems to happen when recording in 16-bit.
>> It only seems to happen when recording at 44,100.
>> It happens with both of my audio devices.
>>
>> So, as you can see, there's a LOT of things that have to be just
>> right.  But, what I found makes me wonder how on earth this has never
>> been noticed before.
>>
>> It's nearly an 11 year old bug.
>>
>> https://code.google.com/p/audacity/source/detail?r=1927&path=/sf-cvs/trunk/audacity-src/src/RingBuffer.cpp
>>
>> This:
>> *
>> dest += block*** SAMPLE_SIZE(mFormat)**;*
>>
>> Should have been:
>>
>> *dest += block*** SAMPLE_SIZE(*f*ormat)**;*
>>
>> If this ever did exhibit itself in the wild, there would have been
>> complaints about mysterious clicks, dropouts, noise, etc.  But, it may
>> never have happened since I can't get it to occur with MME or DS.  It
>> has to do with the gets and puts to the capture buffers being on an
>> exact buffer end boundary.  (I "think" there might be an additional
>> issue there, but still checking.)
>>
>> I didn't want to commit anything until others have had a chance to
>> look at RingBuffer::Get() to confirm (or reject) the change.
>>
>> Leland
>>
>>
>>
>> ------------------------------------------------------------------------------
>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

Stevethefiddle
Can this bug produce NaN value samples?

We've had a few reports recently of weird audio corruption occurring
in projects on Mac OS X which are (at least in some cases) triggered
by NaN sample values. It's been difficult to track down this problem
due to it's intermittent nature, but another frustration has been that
there was no indication where these NaNs were coming from in the first
place. If this is a possible explanation of the NaNs then that could
help us to track down what is happening in (some) of these cases.

Steve

On 27 September 2013 02:57, Leland <[hidden email]> wrote:

> On 9/26/2013 8:12 PM, Martyn Shaw wrote:
>> Any updates on this?
> None really.  I'm pretty confident that the line is incorrect and I was
> just waiting for someone else to take a peek and either confirm or deny.
>
> Leland
>
>>
>> Martyn
>>
>> On 23/09/2013 16:59, Leland wrote:
>>> So, I've been trying to figure out what is causing this problem:
>>>
>>>
>>>
>>> It only seems to happen in Debug Builds.
>>> It only seems to happen with WASAPI and WDMKS.
>>> It only seems to happen when recording in 16-bit.
>>> It only seems to happen when recording at 44,100.
>>> It happens with both of my audio devices.
>>>
>>> So, as you can see, there's a LOT of things that have to be just
>>> right.  But, what I found makes me wonder how on earth this has never
>>> been noticed before.
>>>
>>> It's nearly an 11 year old bug.
>>>
>>> https://code.google.com/p/audacity/source/detail?r=1927&path=/sf-cvs/trunk/audacity-src/src/RingBuffer.cpp
>>>
>>> This:
>>> *
>>> dest += block*** SAMPLE_SIZE(mFormat)**;*
>>>
>>> Should have been:
>>>
>>> *dest += block*** SAMPLE_SIZE(*f*ormat)**;*
>>>
>>> If this ever did exhibit itself in the wild, there would have been
>>> complaints about mysterious clicks, dropouts, noise, etc.  But, it may
>>> never have happened since I can't get it to occur with MME or DS.  It
>>> has to do with the gets and puts to the capture buffers being on an
>>> exact buffer end boundary.  (I "think" there might be an additional
>>> issue there, but still checking.)
>>>
>>> I didn't want to commit anything until others have had a chance to
>>> look at RingBuffer::Get() to confirm (or reject) the change.
>>>
>>> Leland
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
>>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

Leland Lucius-2
On 9/27/2013 2:27 AM, Steve the Fiddle wrote:
> Can this bug produce NaN value samples?
>
> We've had a few reports recently of weird audio corruption occurring
> in projects on Mac OS X which are (at least in some cases) triggered
> by NaN sample values. It's been difficult to track down this problem
> due to it's intermittent nature, but another frustration has been that
> there was no indication where these NaNs were coming from in the first
> place. If this is a possible explanation of the NaNs then that could
> help us to track down what is happening in (some) of these cases.
It is certainly possible since invalid values are getting used if the
right conditions exist.  I know in my case, the values were int16, so I
would not have experienced NaNs, but if the buffer was supposed to
contain float data and reading outside the buffer happened I would
expect NaNs to occur eventually.

Not saying that this is the cause of those, but it surely could be.

Leland


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

Leland (Audacity Team)
In reply to this post by Stevethefiddle
On 9/27/2013 2:27 AM, Steve the Fiddle wrote:
> Can this bug produce NaN value samples?
>
> We've had a few reports recently of weird audio corruption occurring
> in projects on Mac OS X which are (at least in some cases) triggered
> by NaN sample values. It's been difficult to track down this problem
> due to it's intermittent nature, but another frustration has been that
> there was no indication where these NaNs were coming from in the first
> place. If this is a possible explanation of the NaNs then that could
> help us to track down what is happening in (some) of these cases.
It is certainly possible since invalid values are getting used if the
right conditions exist.  I know in my case, the values were int16, so I
would not have experienced NaNs, but if the buffer was supposed to
contain float data and reading outside the buffer happened I would
expect NaNs to occur eventually.

Not saying that this is the cause of those, but it surely could be.

Leland


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

Gale
Administrator
In reply to this post by Leland Lucius-2

| From Leland Lucius <[hidden email]>
| Fri, 27 Sep 2013 04:03:15 -0500
| Subject: [Audacity-devel] Interesting critter when recording

> On 9/27/2013 2:27 AM, Steve the Fiddle wrote:
> > Can this bug produce NaN value samples?
> >
> > We've had a few reports recently of weird audio corruption occurring
> > in projects on Mac OS X which are (at least in some cases) triggered
> > by NaN sample values. It's been difficult to track down this problem
> > due to it's intermittent nature, but another frustration has been that
> > there was no indication where these NaNs were coming from in the first
> > place. If this is a possible explanation of the NaNs then that could
> > help us to track down what is happening in (some) of these cases.
> It is certainly possible since invalid values are getting used if the
> right conditions exist.  I know in my case, the values were int16, so I
> would not have experienced NaNs, but if the buffer was supposed to
> contain float data and reading outside the buffer happened I would
> expect NaNs to occur eventually.
>
> Not saying that this is the cause of those, but it surely could be.
>
> Leland

Another aspect is that some of these Mac cases don't involve
content recorded by Audacity itself, so possibly other applications
have a similar problem.

Then there is another intermittent issue with "Audacity playback
stutter" which is only reported on Mac OS X and even apparently
affects files ripped from CD's.

Could there be some equivalent error somewhere that affects
playback?



Gale


>> On 23/09/2013 16:59, Leland wrote:
>>> So, I've been trying to figure out what is causing this problem:
>>>
>>>
>>>
>>> It only seems to happen in Debug Builds.
>>> It only seems to happen with WASAPI and WDMKS.
>>> It only seems to happen when recording in 16-bit.
>>> It only seems to happen when recording at 44,100.
>>> It happens with both of my audio devices.
>>>
>>> So, as you can see, there's a LOT of things that have to be just
>>> right.  But, what I found makes me wonder how on earth this has never
>>> been noticed before.
>>>
>>> It's nearly an 11 year old bug.
>>>
>>> https://code.google.com/p/audacity/source/detail?r=1927&path=/sf-cvs/trunk/audacity-src/src/RingBuffer.cpp
>>>
>>> This:
>>> *
>>> dest += block*** SAMPLE_SIZE(mFormat)**;*
>>>
>>> Should have been:
>>>
>>> *dest += block*** SAMPLE_SIZE(*f*ormat)**;*
>>>
>>> If this ever did exhibit itself in the wild, there would have been
>>> complaints about mysterious clicks, dropouts, noise, etc.  But, it may
>>> never have happened since I can't get it to occur with MME or DS.  It
>>> has to do with the gets and puts to the capture buffers being on an
>>> exact buffer end boundary.  (I "think" there might be an additional
>>> issue there, but still checking.)
>>>
>>> I didn't want to commit anything until others have had a chance to
>>> look at RingBuffer::Get() to confirm (or reject) the change.



Gale


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

Leland (Audacity Team)
On 9/27/2013 1:36 PM, Gale Andrews wrote:

> | From Leland Lucius <[hidden email]>
> | Fri, 27 Sep 2013 04:03:15 -0500
> | Subject: [Audacity-devel] Interesting critter when recording
>> On 9/27/2013 2:27 AM, Steve the Fiddle wrote:
>>> Can this bug produce NaN value samples?
>>>
>>> We've had a few reports recently of weird audio corruption occurring
>>> in projects on Mac OS X which are (at least in some cases) triggered
>>> by NaN sample values. It's been difficult to track down this problem
>>> due to it's intermittent nature, but another frustration has been that
>>> there was no indication where these NaNs were coming from in the first
>>> place. If this is a possible explanation of the NaNs then that could
>>> help us to track down what is happening in (some) of these cases.
>> It is certainly possible since invalid values are getting used if the
>> right conditions exist.  I know in my case, the values were int16, so I
>> would not have experienced NaNs, but if the buffer was supposed to
>> contain float data and reading outside the buffer happened I would
>> expect NaNs to occur eventually.
>>
>> Not saying that this is the cause of those, but it surely could be.
>>
>> Leland
> Another aspect is that some of these Mac cases don't involve
> content recorded by Audacity itself, so possibly other applications
> have a similar problem.
>
> Then there is another intermittent issue with "Audacity playback
> stutter" which is only reported on Mac OS X and even apparently
> affects files ripped from CD's.
>
> Could there be some equivalent error somewhere that affects
> playback?
RingBuffers are used for both playback and capture, so yes, I suppose it
could be the cause of some of the strange happening.

Leland


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

MartynShaw
In reply to this post by Leland (Audacity Team)
Hiya Leland

I don't know this part of the code very well at all.
I have tried a small number of cases and can't see one where 'format'
is different to 'mFormat', and I don't see the bug (which I guess is
saying the same).

I take it you are using 'append record' to record in 16-bit?  Or maybe
another method that I have not tried?

Do you have any 'steps to reproduce'?

Alternatively, a reasoned argument to change it?

FWIW, I can't actually record with WASAPI, I just get a cursor
flashing randomly at the start point.

TTFN
Martyn

On 27/09/2013 02:57, Leland wrote:

> On 9/26/2013 8:12 PM, Martyn Shaw wrote:
>> Any updates on this?
> None really.  I'm pretty confident that the line is incorrect and I was
> just waiting for someone else to take a peek and either confirm or deny.
>
> Leland
>
>>
>> Martyn
>>
>> On 23/09/2013 16:59, Leland wrote:
>>> So, I've been trying to figure out what is causing this problem:
>>>
>>>
>>>
>>> It only seems to happen in Debug Builds.
>>> It only seems to happen with WASAPI and WDMKS.
>>> It only seems to happen when recording in 16-bit.
>>> It only seems to happen when recording at 44,100.
>>> It happens with both of my audio devices.
>>>
>>> So, as you can see, there's a LOT of things that have to be just
>>> right.  But, what I found makes me wonder how on earth this has never
>>> been noticed before.
>>>
>>> It's nearly an 11 year old bug.
>>>
>>> https://code.google.com/p/audacity/source/detail?r=1927&path=/sf-cvs/trunk/audacity-src/src/RingBuffer.cpp
>>>
>>> This:
>>> *
>>> dest += block*** SAMPLE_SIZE(mFormat)**;*
>>>
>>> Should have been:
>>>
>>> *dest += block*** SAMPLE_SIZE(*f*ormat)**;*
>>>
>>> If this ever did exhibit itself in the wild, there would have been
>>> complaints about mysterious clicks, dropouts, noise, etc.  But, it may
>>> never have happened since I can't get it to occur with MME or DS.  It
>>> has to do with the gets and puts to the capture buffers being on an
>>> exact buffer end boundary.  (I "think" there might be an additional
>>> issue there, but still checking.)
>>>
>>> I didn't want to commit anything until others have had a chance to
>>> look at RingBuffer::Get() to confirm (or reject) the change.
>>>
>>> Leland
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
>>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

Leland (Audacity Team)
On 9/29/2013 6:54 PM, Martyn Shaw wrote:
Hiya Leland

I don't know this part of the code very well at all.
I have tried a small number of cases and can't see one where 'format' 
is different to 'mFormat', and I don't see the bug (which I guess is 
saying the same).

I take it you are using 'append record' to record in 16-bit?  Or maybe 
another method that I have not tried?

Just plain record.

Do you have any 'steps to reproduce'?
In preferences, I set quality up like this:



And use the WASAPI (or WDMKS) hostapi to record some audio.  This produces:



In this case, the source format was "float" and the dest format was "16-bit".

Alternatively, a reasoned argument to change it?
How about: "It's wrong the way it is."  :-)

But, let's see if I can explain it.  Here's the code in question (from RingBuffer::Get):

   while(samplesToCopy) {
      block = samplesToCopy;
      if (block > mBufferSize - mStart)
         block = mBufferSize - mStart;

      CopySamples(mBuffer + mStart * SAMPLE_SIZE(mFormat), mFormat,
                  dest, format,
                  block);

      dest += block * SAMPLE_SIZE(mFormat);
      mStart = (mStart + block) % mBufferSize;
      samplesToCopy -= block;
      copied += block;
   }

CopySamples()  copies the samples from the input buffer to the output buffer.  Along the way, any sample format differences are handled as well.  In this case, "mBuffer" is the source and it has "mFormat" type samples.  And "dest" is the destination with "format" type samples.

But, when updating the "dest" pointer to the next location the source format "mFormat" is used to calculate the new "dest" address.  So, for examples, if the source format is "float" (four bytes) and the dest format is "int16" (two bytes), then the 2nd time through the loop, the "dest" pointer will be pointing to a location that is twice the distance of where it is supposed to be.

Now, as you've seen, the planet's have to be properly aligned to have it cause any issues.  For any problem to happen, the loop must be executed more than once.  In most cases it never does.  I was never able to get it to happen with MME or DS, only WASAPI and WDMKS.  That's not to say it never does happen, I just couldn't produce the exact situation.
 
FWIW, I can't actually record with WASAPI, I just get a cursor 
flashing randomly at the start point.
For WASAPI to record, you need to feed it.  Do one of the loopbacks and play some music in the background to the same device.  Or you can use WDMKS...it does the same thing.

Leland



------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

MartynShaw
Hi there Leland

I support the change, but please see below for more questions.

So I followed your steps exactly, as far as I can tell.

On 30/09/2013 01:57, Leland wrote:

> On 9/29/2013 6:54 PM, Martyn Shaw wrote:
>> Hiya Leland
>>
>> I don't know this part of the code very well at all.
>> I have tried a small number of cases and can't see one where 'format'
>> is different to 'mFormat', and I don't see the bug (which I guess is
>> saying the same).
>>
>> I take it you are using 'append record' to record in 16-bit?  Or maybe
>> another method that I have not tried?
>
> Just plain record.
>
>> Do you have any 'steps to reproduce'?
> In preferences, I set quality up like this:
>
>
>
> And use the WASAPI (or WDMKS) hostapi to record some audio.  This
> produces:
>
>
>
> In this case, the source format was "float" and the dest format was
> "16-bit".

Why is the source format "float" for you?  I am seeing
RingBuffer::RingBuffer
being called by
AudioIO::StartStream
and setting
mFormat = format;
but you clearly aren't.  Is there some other thing that I am not
doing, or that you are?

>> Alternatively, a reasoned argument to change it?
> How about: "It's wrong the way it is."  :-)

'tis a short argument! :-)

> But, let's see if I can explain it.  Here's the code in question (from
> RingBuffer::Get):
>
>     while(samplesToCopy) {
>        block = samplesToCopy;
>        if (block > mBufferSize - mStart)
>           block = mBufferSize - mStart;
>
>        CopySamples(mBuffer + mStart * SAMPLE_SIZE(mFormat), mFormat,
>                    dest, format,
>                    block);
>
>        dest += block * SAMPLE_SIZE(mFormat);
>        mStart = (mStart + block) % mBufferSize;
>        samplesToCopy -= block;
>        copied += block;
>     }
>
> CopySamples()  copies the samples from the input buffer to the output
> buffer.  Along the way, any sample format differences are handled as
> well.  In this case, "mBuffer" is the source and it has "mFormat" type
> samples.  And "dest" is the destination with "format" type samples.
>
> But, when updating the "dest" pointer to the next location the source
> format "mFormat" is used to calculate the new "dest" address.  So, for
> examples, if the source format is "float" (four bytes) and the dest
> format is "int16" (two bytes), then the 2nd time through the loop, the
> "dest" pointer will be pointing to a location that is twice the
> distance of where it is supposed to be.

That is clear, and on that basis I am in favour of changing it.  I
have not seen the problem that it causes however, for the reason I
outlined above.  But yes, "It's wrong the way it is.".

There must be a code path that leads to format != mFormat and it would
be interesting to see a recipe for that, that works for me.

> Now, as you've seen, the planet's have to be properly aligned to have
> it cause any issues.  For any problem to happen, the loop must be
> executed more than once.  In most cases it never does.

I didn't see it either, on any host.  Are samplesToCopy and
mBufferSize related to latency settings? (I could look that up I
suppose, thought it better to ask.)

   I was never
> able to get it to happen with MME or DS, only WASAPI and WDMKS.
> That's not to say it never does happen, I just couldn't produce the
> exact situation.
>
>> FWIW, I can't actually record with WASAPI, I just get a cursor
>> flashing randomly at the start point.
> For WASAPI to record, you need to feed it.  Do one of the loopbacks
> and play some music in the background to the same device.

Oh, that's a bit odd!  I see what you mean though.

TTFN
Martyn

   Or you can
> use WDMKS...it does the same thing.
>
> Leland
>
>

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Interesting critter when recording

Gale
Administrator
In reply to this post by Leland (Audacity Team)
Leland wrote:
> It's nearly an 11 year old bug.
>
> https://code.google.com/p/audacity/source/detail?r=1927&path=/sf-cvs/trunk/audacity-src/src/RingBuffer.cpp
>
> This:
> dest += block * SAMPLE_SIZE(mFormat);
>
> Should have been:
>
> dest += block * SAMPLE_SIZE(Format);

Just documenting in case someone comes looking that this was fixed in http://code.google.com/p/audacity/source/detail?r=12767 .


Gale