new P2 added "Desynchronised playback mixing..."

[Gale (Audacity Team)]

P 2 Desynchronised playback mixing of short regions in different tracks.

This is a pain to reproduce reliably, but I've seen several reports on
Windows and Linux, and seen it myself on Windows XP, Vista and
Ubuntu, all with different sound devices. I'm pretty sure there is a
genuine problem, given I've completely failed to reproduce it in
1.2.6 on numerous occasions, but can do so in 1.3.9.

Steps to reproduce use cancellation by inversion, but the bug (probably)
does not depend on inversion:    

1 Tracks > Add New > Stereo Track
2 Generate > Noise > White noise 0.7, 22 seconds
3  Select 2 seconds from 11 seconds, Edit > Duplicate
4 Click in the Track Panel to select the duplicate, solo it and play
    - it sounds as expected
5 Invert the duplicate and play - it sounds similar, as expected
6  Unsolo the duplicate and play - you may get any of these:
     * louder white noise that now clips in the meter (inversion "looks"
         correct, so is apparently not being respected in playback,
         which "may" be a separate bug or not  
     * non-clipping noise for up to one second, then silence as delayed
        playback of track 2 starts
    * silence until near to end of selection, then noise in one channel
        only

Notes

* If the bug does not reproduce, duplicate another short section further
     along the track and repeat above steps.
* Time shifting the whole track before duplicating a region usually prevents
     the bug occurring.



Gale


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

There is a way to reproduce at least one instance of this generic bug title if the short clip is time-shifted away from zero and at a different sample rate:  
http://sourceforge.net/mailarchive/forum.php?thread_name=20090917203528.8486.79ADB3FC%40audacityteam.org&forum_name=audacity-users

This is a nasty one because the problem is not only in playback but still there if you render (Mix and Render or export). If I can reproduce the original report (the inversion scenario) I'll see if that problem also persists after rendering.  


Gale  

Gale (Audacity Team) wrote:

P 2 Desynchronised playback mixing of short regions in different tracks.

This is a pain to reproduce reliably, but I've seen several reports on
Windows and Linux, and seen it myself on Windows XP, Vista and
Ubuntu, all with different sound devices. I'm pretty sure there is a
genuine problem, given I've completely failed to reproduce it in
1.2.6 on numerous occasions, but can do so in 1.3.9.

Steps to reproduce use cancellation by inversion, but the bug (probably)
does not depend on inversion:    

1 Tracks > Add New > Stereo Track
2 Generate > Noise > White noise 0.7, 22 seconds
3  Select 2 seconds from 11 seconds, Edit > Duplicate
4 Click in the Track Panel to select the duplicate, solo it and play
    - it sounds as expected
5 Invert the duplicate and play - it sounds similar, as expected
6  Unsolo the duplicate and play - you may get any of these:
     * louder white noise that now clips in the meter (inversion "looks"
         correct, so is apparently not being respected in playback,
         which "may" be a separate bug or not  
     * non-clipping noise for up to one second, then silence as delayed
        playback of track 2 starts
    * silence until near to end of selection, then noise in one channel
        only

Notes

* If the bug does not reproduce, duplicate another short section further
     along the track and repeat above steps.
* Time shifting the whole track before duplicating a region usually prevents
     the bug occurring.



Gale

[Martyn Shaw-2]

I can confirm the bug with different sample rates when mixing and
rendering, but still haven't seen it with one sample rate.  These may
be separate bugs but let's assume it's one for now, it may be two.

Do we have a version number / date when it started to occur?  I'm
assuming that it wasn't in 1.2.6 and is in HEAD; any tighter idea?

TTFN
Martyn

Gale (Audacity Team) wrote:

> There is a way to reproduce at least one instance of this generic bug title
> if the short clip is time-shifted away from zero and at a different sample
> rate:  
> http://sourceforge.net/mailarchive/forum.php?thread_name=20090917203528.8486.79ADB3FC%40audacityteam.org&forum_name=audacity-users
>
> This is a nasty one because the problem is not only in playback but still
> there if you render (Mix and Render or export). If I can reproduce the
> original report (the inversion scenario) I'll see if that problem also
> persists after rendering.  
>
>
> Gale  
>
>
>
> Gale (Audacity Team) wrote:
>>
>> P 2 Desynchronised playback mixing of short regions in different tracks.
>>
>> This is a pain to reproduce reliably, but I've seen several reports on
>> Windows and Linux, and seen it myself on Windows XP, Vista and
>> Ubuntu, all with different sound devices. I'm pretty sure there is a
>> genuine problem, given I've completely failed to reproduce it in
>> 1.2.6 on numerous occasions, but can do so in 1.3.9.
>>
>> Steps to reproduce use cancellation by inversion, but the bug (probably)
>> does not depend on inversion:    
>>
>> 1 Tracks > Add New > Stereo Track
>> 2 Generate > Noise > White noise 0.7, 22 seconds
>> 3  Select 2 seconds from 11 seconds, Edit > Duplicate
>> 4 Click in the Track Panel to select the duplicate, solo it and play
>>     - it sounds as expected
>> 5 Invert the duplicate and play - it sounds similar, as expected
>> 6  Unsolo the duplicate and play - you may get any of these:
>>      * louder white noise that now clips in the meter (inversion "looks"
>>          correct, so is apparently not being respected in playback,
>>          which "may" be a separate bug or not  
>>      * non-clipping noise for up to one second, then silence as delayed
>>         playback of track 2 starts
>>     * silence until near to end of selection, then noise in one channel
>>         only
>>
>> Notes
>>
>> * If the bug does not reproduce, duplicate another short section further
>>      along the track and repeat above steps.
>> * Time shifting the whole track before duplicating a region usually
>> prevents
>>      the bug occurring.
>>
>>
>>
>> Gale
>>
>>
>>
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

1st August 2009 looks OK to me, must have been past that.  But I'm off
to bed.

TTFN
Martyn

Martyn Shaw wrote:

> I can confirm the bug with different sample rates when mixing and
> rendering, but still haven't seen it with one sample rate.  These may be
> separate bugs but let's assume it's one for now, it may be two.
>
> Do we have a version number / date when it started to occur?  I'm
> assuming that it wasn't in 1.2.6 and is in HEAD; any tighter idea?
>
> TTFN
> Martyn
>
> Gale (Audacity Team) wrote:
>> There is a way to reproduce at least one instance of this generic bug
>> title
>> if the short clip is time-shifted away from zero and at a different
>> sample
>> rate:  
>> http://sourceforge.net/mailarchive/forum.php?thread_name=20090917203528.8486.79ADB3FC%40audacityteam.org&forum_name=audacity-users 
>>
>>
>> This is a nasty one because the problem is not only in playback but still
>> there if you render (Mix and Render or export). If I can reproduce the
>> original report (the inversion scenario) I'll see if that problem also
>> persists after rendering.
>>
>> Gale
>>
>>
>> Gale (Audacity Team) wrote:
>>>
>>> P 2 Desynchronised playback mixing of short regions in different tracks.
>>>
>>> This is a pain to reproduce reliably, but I've seen several reports
>>> on Windows and Linux, and seen it myself on Windows XP, Vista and
>>> Ubuntu, all with different sound devices. I'm pretty sure there is a
>>> genuine problem, given I've completely failed to reproduce it in
>>> 1.2.6 on numerous occasions, but can do so in 1.3.9.
>>> Steps to reproduce use cancellation by inversion, but the bug (probably)
>>> does not depend on inversion:  
>>> 1 Tracks > Add New > Stereo Track
>>> 2 Generate > Noise > White noise 0.7, 22 seconds
>>> 3  Select 2 seconds from 11 seconds, Edit > Duplicate
>>> 4 Click in the Track Panel to select the duplicate, solo it and play
>>>     - it sounds as expected
>>> 5 Invert the duplicate and play - it sounds similar, as expected
>>> 6  Unsolo the duplicate and play - you may get any of these:
>>>      * louder white noise that now clips in the meter (inversion "looks"
>>>          correct, so is apparently not being respected in playback,
>>>          which "may" be a separate bug or not       * non-clipping
>>> noise for up to one second, then silence as delayed
>>>         playback of track 2 starts     * silence until near to end of
>>> selection, then noise in one channel
>>>         only
>>>
>>> Notes
>>> * If the bug does not reproduce, duplicate another short section further
>>>      along the track and repeat above steps.
>>> * Time shifting the whole track before duplicating a region usually
>>> prevents      the bug occurring.
>>>
>>>
>>> Gale
>>>
>>>
>>>
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Martyn Shaw <[hidden email]>
| Sat, 19 Sep 2009 01:30:29 +0100
| Subject: [Audacity-devel] new P2 added "Desynchronised playback mixing..."
> 1st August 2009 looks OK to me, must have been past that.  But I'm off
> to bed.
>
> TTFN
> Martyn

Thanks. You can take it that any issue listed by me was verified in a
Unicode Release build at the time I listed it.

We don't date stamp our comments though, so if someone looked at a
P3 or lower, the last verification date could be a long time ago. Not
sure if dating the comments is worth the space, but I guess we could
try it as an experiment?



Gale

 

> Martyn Shaw wrote:
> > I can confirm the bug with different sample rates when mixing and
> > rendering, but still haven't seen it with one sample rate.  These may be
> > separate bugs but let's assume it's one for now, it may be two.
> >
> > Do we have a version number / date when it started to occur?  I'm
> > assuming that it wasn't in 1.2.6 and is in HEAD; any tighter idea?
> >
> > TTFN
> > Martyn
> >
> > Gale (Audacity Team) wrote:
> >> There is a way to reproduce at least one instance of this generic bug
> >> title
> >> if the short clip is time-shifted away from zero and at a different
> >> sample
> >> rate:  
> >> http://sourceforge.net/mailarchive/forum.php?thread_name=20090917203528.8486.79ADB3FC%40audacityteam.org&forum_name=audacity-users 
> >>
> >>
> >> This is a nasty one because the problem is not only in playback but still
> >> there if you render (Mix and Render or export). If I can reproduce the
> >> original report (the inversion scenario) I'll see if that problem also
> >> persists after rendering.
> >>
> >> Gale
> >>
> >>
> >> Gale (Audacity Team) wrote:
> >>>
> >>> P 2 Desynchronised playback mixing of short regions in different tracks.
> >>>
> >>> This is a pain to reproduce reliably, but I've seen several reports
> >>> on Windows and Linux, and seen it myself on Windows XP, Vista and
> >>> Ubuntu, all with different sound devices. I'm pretty sure there is a
> >>> genuine problem, given I've completely failed to reproduce it in
> >>> 1.2.6 on numerous occasions, but can do so in 1.3.9.
> >>> Steps to reproduce use cancellation by inversion, but the bug (probably)
> >>> does not depend on inversion:  
> >>> 1 Tracks > Add New > Stereo Track
> >>> 2 Generate > Noise > White noise 0.7, 22 seconds
> >>> 3  Select 2 seconds from 11 seconds, Edit > Duplicate
> >>> 4 Click in the Track Panel to select the duplicate, solo it and play
> >>>     - it sounds as expected
> >>> 5 Invert the duplicate and play - it sounds similar, as expected
> >>> 6  Unsolo the duplicate and play - you may get any of these:
> >>>      * louder white noise that now clips in the meter (inversion "looks"
> >>>          correct, so is apparently not being respected in playback,
> >>>          which "may" be a separate bug or not       * non-clipping
> >>> noise for up to one second, then silence as delayed
> >>>         playback of track 2 starts     * silence until near to end of
> >>> selection, then noise in one channel
> >>>         only
> >>>
> >>> Notes
> >>> * If the bug does not reproduce, duplicate another short section further
> >>>      along the track and repeat above steps.
> >>> * Time shifting the whole track before duplicating a region usually
> >>> prevents      the bug occurring.
> >>>
> >>>
> >>> Gale
> >>>
> >>>
> >>>
> >>
> >
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Leland (Audacity Team)]

Martyn Shaw wrote:
> I can confirm the bug with different sample rates when mixing and
> rendering, but still haven't seen it with one sample rate.  These may
> be separate bugs but let's assume it's one for now, it may be two.
>
Looks to me like it started happening at 1.3.4.  But, 1.3.3 contains
another issue which was probably what was trying to be fixed.

In 1.3.3, try:

1)  Start a clean project
2)  Change project rate to 8000
3)  Generate 1 second of silence
4)  Change project rate to 96000
5)  Tracks -> Mix and Rander

The noise remains the correct length (well, visually anyway), but
there's some silence added to the end.

Doing the same thing in 1.3.4 cause the noise to be truncated.

Leland


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Leland (Audacity Team)]

Leland wrote:

> Martyn Shaw wrote:
>> I can confirm the bug with different sample rates when mixing and
>> rendering, but still haven't seen it with one sample rate.  These may
>> be separate bugs but let's assume it's one for now, it may be two.
>>
> Looks to me like it started happening at 1.3.4.  But, 1.3.3 contains
> another issue which was probably what was trying to be fixed.
>
> In 1.3.3, try:
>
> 1)  Start a clean project
> 2)  Change project rate to 8000
> 3)  Generate 1 second of silence
> 4)  Change project rate to 96000
> 5)  Tracks -> Mix and Rander
>
> The noise remains the correct length (well, visually anyway), but
> there's some silence added to the end.
>
> Doing the same thing in 1.3.4 cause the noise to be truncated.
>

Looks like this was probably my fault:

http://audacity.cvs.sourceforge.net/viewvc/audacity/audacity-src/src/Mix.cpp?view=log#rev1.62

Leland


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Leland (Audacity Team)]

Leland wrote:

> Leland wrote:
>> Martyn Shaw wrote:
>>> I can confirm the bug with different sample rates when mixing and
>>> rendering, but still haven't seen it with one sample rate.  These may
>>> be separate bugs but let's assume it's one for now, it may be two.
>>>
>> Looks to me like it started happening at 1.3.4.  But, 1.3.3 contains
>> another issue which was probably what was trying to be fixed.
>>
>> In 1.3.3, try:
>>
>> 1)  Start a clean project
>> 2)  Change project rate to 8000
>> 3)  Generate 1 second of silence
>> 4)  Change project rate to 96000
>> 5)  Tracks -> Mix and Rander
>>
>> The noise remains the correct length (well, visually anyway), but
>> there's some silence added to the end.
>>
>> Doing the same thing in 1.3.4 cause the noise to be truncated.
>>
> Looks like this was probably my fault:
>
> http://audacity.cvs.sourceforge.net/viewvc/audacity/audacity-src/src/Mix.cpp?view=log#rev1.62
>

Yep...that's the culprit.  Not sure how to fix the fix though.  Any ideas?

Leland

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

go 2, misaddressed the first time...

Leland wrote:
> Martyn Shaw wrote:
>> I can confirm the bug with different sample rates when mixing and
>> rendering, but still haven't seen it with one sample rate.  These may
>> be separate bugs but let's assume it's one for now, it may be two.
>>
> Looks to me like it started happening at 1.3.4.

That's odd.  I just installed older versions to find out when it
happened and concluded that the problem wasn't there in 1.3.5 but is
in 1.3.6 (this is on Windows).

I am testing with a chirp of amplitude 0->1, length 30s, 44100kHz
sampling and a second track with a short chirp from 5-6s (exactly),
4800kHz sampling.  Mix and render in 1.3.5 gives a waveform with the
extra bit at 5-6s, 1.3.6 gives the extra bit at 5.096-5.994s (just
39606 samples long).

TTFN
Martyn

But, 1.3.3 contains

> another issue which was probably what was trying to be fixed.
>
> In 1.3.3, try:
>
> 1)  Start a clean project
> 2)  Change project rate to 8000
> 3)  Generate 1 second of silence
> 4)  Change project rate to 96000
> 5)  Tracks -> Mix and Rander
>
> The noise remains the correct length (well, visually anyway), but
> there's some silence added to the end.
>
> Doing the same thing in 1.3.4 cause the noise to be truncated.
>
> Leland
>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Martyn Shaw wrote:

> go 2, misaddressed the first time...
>
> Leland wrote:
>> Martyn Shaw wrote:
>>> I can confirm the bug with different sample rates when mixing and
>>> rendering, but still haven't seen it with one sample rate.  These may
>>> be separate bugs but let's assume it's one for now, it may be two.
>>>
>> Looks to me like it started happening at 1.3.4.
>
> That's odd.  I just installed older versions to find out when it
> happened and concluded that the problem wasn't there in 1.3.5 but is in
> 1.3.6 (this is on Windows).
>
> I am testing with a chirp of amplitude 0->1, length 30s, 44100kHz
> sampling and a second track with a short chirp from 5-6s (exactly),
> 4800kHz sampling.  Mix and render in 1.3.5 gives a waveform with the
> extra bit at 5-6s,

well, 5-5.99406 actually, losing about 260 samples off the end.

Martyn

1.3.6 gives the extra bit at 5.096-5.994s (just 39606

> samples long).
>
> TTFN
> Martyn
>
> But, 1.3.3 contains
>> another issue which was probably what was trying to be fixed.
>>
>> In 1.3.3, try:
>>
>> 1)  Start a clean project
>> 2)  Change project rate to 8000
>> 3)  Generate 1 second of silence
>> 4)  Change project rate to 96000
>> 5)  Tracks -> Mix and Rander
>>
>> The noise remains the correct length (well, visually anyway), but
>> there's some silence added to the end.
>>
>> Doing the same thing in 1.3.4 cause the noise to be truncated.
>>
>> Leland
>>
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

The reproducible version of this bug I have found a reason for, and
hence a solution (or two).

Mix.cpp
373 track->GetEnvelopeValues(mEnvValues, getLen, (*pos) / trackRate,
                                      1.0 / trackRate);
but 3rd arg should be double and we are doing integer division!  Why
didn't a compiler find that and warn us, I wonder?  How many more
instances of this could there be floating about?

(double)(*pos) / (double)trackRate
works for me, but is it the neatest solution?

Have not committed this as Leland has another fix for Mix that he
needs to commit as well and I don't want to cause problems there.
Maybe you could incorporate this Leland?

Further thoughts a bit later...
The change was between releases 1.3.5 and 1.3.6, as I found before.
It is in revision 1.69 of Mix.cpp where
double trackRate = track->GetRate();
was changed to
int trackRate = (int)(track->GetRate());
which presumably gives us an integer result from
(*pos) / trackRate
rather than a double.

What is the best way forward here?

TTFN
Martyn

Martyn Shaw wrote:

>
>
> Martyn Shaw wrote:
>> go 2, misaddressed the first time...
>>
>> Leland wrote:
>>> Martyn Shaw wrote:
>>>> I can confirm the bug with different sample rates when mixing and
>>>> rendering, but still haven't seen it with one sample rate.  These
>>>> may be separate bugs but let's assume it's one for now, it may be two.
>>>>
>>> Looks to me like it started happening at 1.3.4.
>>
>> That's odd.  I just installed older versions to find out when it
>> happened and concluded that the problem wasn't there in 1.3.5 but is
>> in 1.3.6 (this is on Windows).
>>
>> I am testing with a chirp of amplitude 0->1, length 30s, 44100kHz
>> sampling and a second track with a short chirp from 5-6s (exactly),
>> 4800kHz sampling.  Mix and render in 1.3.5 gives a waveform with the
>> extra bit at 5-6s,
>
> well, 5-5.99406 actually, losing about 260 samples off the end.
>
> Martyn
>
> 1.3.6 gives the extra bit at 5.096-5.994s (just 39606
>> samples long).
>>
>> TTFN
>> Martyn
>>
>> But, 1.3.3 contains
>>> another issue which was probably what was trying to be fixed.
>>>
>>> In 1.3.3, try:
>>>
>>> 1)  Start a clean project
>>> 2)  Change project rate to 8000
>>> 3)  Generate 1 second of silence
>>> 4)  Change project rate to 96000
>>> 5)  Tracks -> Mix and Rander
>>>
>>> The noise remains the correct length (well, visually anyway), but
>>> there's some silence added to the end.
>>>
>>> Doing the same thing in 1.3.4 cause the noise to be truncated.
>>>
>>> Leland
>>>
>>>
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Leland (Audacity Team)]

Martyn Shaw wrote:
 > The reproducible version of this bug I have found a reason for, and
 > hence a solution (or two).
 >
 > Mix.cpp
 > 373 track->GetEnvelopeValues(mEnvValues, getLen, (*pos) / trackRate,
 >                                      1.0 / trackRate);
 > but 3rd arg should be double and we are doing integer division!

Good eyeball!!!  I would never have seen that.

 >  Why
 > didn't a compiler find that and warn us, I wonder?  How many more
 > instances of this could there be floating about?

I'll run a static analysis tonight to see what shows up.  I don't
remember if it points out these kinds of problems or not though.

 >
 > Have not committed this as Leland has another fix for Mix that he needs
 > to commit as well and I don't want to cause problems there. Maybe you
 > could incorporate this Leland?
 >
Yes, I'll incorporate it and I've also cleaned it up a bit by removing
some code duplication.

However, with the recent changes to Envelope, an assertion is triggered
when doing:

1)  Start a clean project
2)  Generate a 30sec tone at 44100
3)  Change it's rate to 8000 via the track menu
4)  Mix and Render

The assertion is unrelated to our Mixer changes.

Leland

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Leland (Audacity Team)]

Leland wrote:

>
> However, with the recent changes to Envelope, an assertion is triggered
> when doing:
>
> 1)  Start a clean project
> 2)  Generate a 30sec tone at 44100
> 3)  Change it's rate to 8000 via the track menu
> 4)  Mix and Render
>
> The assertion is unrelated to our Mixer changes.
>

Should the track menu simply set the rate of the track or should it
actually resample the track to the new rate???  This does get rid of the
assertion without having to do any additional magic in MixVariableRates().

Is there ever a reason where you'd want to change the sample rate of a
track without resampling???

Leland

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Leland wrote:
> Leland wrote:
>> However, with the recent changes to Envelope, an assertion is triggered
>> when doing:
>>
>> 1)  Start a clean project
>> 2)  Generate a 30sec tone at 44100
>> 3)  Change it's rate to 8000 via the track menu

Notice that it's length changes to 30s x 44100/8000 = 2m45.375s, but
the envelope's mTrackLen is still set to 30s.  That's what causes the
assert.

>> 4)  Mix and Render
>>
>> The assertion is unrelated to our Mixer changes.

True.  If you comment out the assert you'll find that it completes
(but leaves the track just a fraction short, I don't know why).  A
number of asserts were put in to Envelope relatively recently, but I
have not seen any real reason for them to be honest.  They fire for
non-problems I think.

> Should the track menu simply set the rate of the track or should it
> actually resample the track to the new rate???

Good question, and I don't know the answer.

If we set the rate in the way we do now, we should really rescale the
envelope points as well, so that they correspond to the same points on
the waveform, but I definitely think that's a 'feature request',
rather than a bug-fix.  It's been like that since before 1.2.6 I see.

This does get rid of the
> assertion without having to do any additional magic in MixVariableRates().
>
> Is there ever a reason where you'd want to change the sample rate of a
> track without resampling???

Speed up / slow down audio in a fast-and-dirty fashion?

TTFN
Martyn

> Leland
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Leland (Audacity Team)]

Martyn Shaw wrote:

>> Is there ever a reason where you'd want to change the sample rate of a
>> track without resampling???
>
> Speed up / slow down audio in a fast-and-dirty fashion?
>
Let as-is for now, but updated WaveClip to recalculate the envelope length.

And I committed the other changes to MixVariableRates() as well.

Leland

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Martyn Shaw <[hidden email]>
| Mon, 21 Sep 2009 22:41:20 +0100
| Subject: [Audacity-devel] new P2 added "Desynchronised playback mixing..."

> > Leland wrote:
>
>
> > Should the track menu simply set the rate of the track or should it
> > actually resample the track to the new rate???
>
> Good question, and I don't know the answer.
>
> If we set the rate in the way we do now, we should really rescale the
> envelope points as well, so that they correspond to the same points on
> the waveform, but I definitely think that's a 'feature request',
> rather than a bug-fix.  It's been like that since before 1.2.6 I see.

Seems kind of half bug/half request, and more of a request than a bug
because no one noticed it before? Anyway I added it to my ever
growing clipboard library of low priority "issues" (for want of a better
word).

Wouldn't another request be that the selection area moved to encompass
the new waveform length, as timeline changing effects do?


> > Is there ever a reason where you'd want to change the sample rate of a
> > track without resampling???
>
> Speed up / slow down audio in a fast-and-dirty fashion?

If we did resample, what rate do we resample to? If to the project
rate, that would look rather confusing on the Track Panel. If to the
rate they set, that seems to mean un-necessary resampling if they
intend to leave the project rate as it was?




Gale
 

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Richard Ash (audacity-help)]

On Mon, 2009-09-21 at 08:52 -0500, Leland wrote:
> Should the track menu simply set the rate of the track or should it
> actually resample the track to the new rate???  This does get rid of the
> assertion without having to do any additional magic in MixVariableRates().

> Is there ever a reason where you'd want to change the sample rate of a
> track without resampling???

I'd strongly feel that changing the track sample rate should do exactly
that - change the rate at which the samples in the project are shuffled
out the sound card. This is useful if you have files with the wrong rate
in their headers (for instance), or just because you want to modify the
sound by changing the sample rate. It's not something that many users
would want to use, but it's very useful at times.

Note that most of the time, you will still get resampling (to the
project rate), but the result is a track with a different pitch and the
same sample rate, where as resampling the track (which you can do from
the Tracks menu) gives the track with the same pitch but a different
sample rate.

Richard


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Hi Leland

Thanks for that.  My test case is now sample-perfect!  And no asserts
when changing sample rates!  Nice one.

Martyn

Leland wrote:

> Martyn Shaw wrote:
>
>>> Is there ever a reason where you'd want to change the sample rate of
>>> a track without resampling???
>>
>> Speed up / slow down audio in a fast-and-dirty fashion?
>>
> Let as-is for now, but updated WaveClip to recalculate the envelope length.
>
> And I committed the other changes to MixVariableRates() as well.
>
> Leland
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Hi Richard

Richard Ash wrote:

> On Mon, 2009-09-21 at 08:52 -0500, Leland wrote:
>> Should the track menu simply set the rate of the track or should it
>> actually resample the track to the new rate???  This does get rid of the
>> assertion without having to do any additional magic in MixVariableRates().
>
>> Is there ever a reason where you'd want to change the sample rate of a
>> track without resampling???
>
> I'd strongly feel that changing the track sample rate should do exactly
> that - change the rate at which the samples in the project are shuffled
> out the sound card. This is useful if you have files with the wrong rate
> in their headers (for instance), or just because you want to modify the
> sound by changing the sample rate. It's not something that many users
> would want to use, but it's very useful at times.

I note that it has been left like that.  The side-issue of the
envelope not keeping in synch is so minor (to most users, there'll
always be one) has been left as a 'feature request'.

> Note that most of the time, you will still get resampling (to the
> project rate),

Again just a note to avoid confusion, you are referring to the rate at
which samples get shoved out of the sound card, not any permanent
representations within Audacity.

Martyn

  but the result is a track with a different pitch and the

> same sample rate, where as resampling the track (which you can do from
> the Tracks menu) gives the track with the same pitch but a different
> sample rate.
>
> Richard
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Hi Gale

Gale Andrews wrote:

> | From Martyn Shaw <[hidden email]>
> | Mon, 21 Sep 2009 22:41:20 +0100
> | Subject: [Audacity-devel] new P2 added "Desynchronised playback mixing..."
>>> Leland wrote:
>>
>>> Should the track menu simply set the rate of the track or should it
>>> actually resample the track to the new rate???
>> Good question, and I don't know the answer.
>>
>> If we set the rate in the way we do now, we should really rescale the
>> envelope points as well, so that they correspond to the same points on
>> the waveform, but I definitely think that's a 'feature request',
>> rather than a bug-fix.  It's been like that since before 1.2.6 I see.
>
> Seems kind of half bug/half request, and more of a request than a bug
> because no one noticed it before? Anyway I added it to my ever
> growing clipboard library of low priority "issues" (for want of a better
> word).

Thanks!  "Feature Requests" is a good term (OK, not a 'word').

> Wouldn't another request be that the selection area moved to encompass
> the new waveform length, as timeline changing effects do?

Another good one!

>>> Is there ever a reason where you'd want to change the sample rate of a
>>> track without resampling???
>> Speed up / slow down audio in a fast-and-dirty fashion?
>
> If we did resample, what rate do we resample to?

The requested rate is the only one that makes sense.  But I think we
have it covered that we shouldn't do that.

TTFN
Martyn

If to the project

> rate, that would look rather confusing on the Track Panel. If to the
> rate they set, that seems to mean un-necessary resampling if they
> intend to leave the project rate as it was?
>
>
>
>
> Gale
>  
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel