Quantcast

Append Record: Bug 641 - Do we still have the bug?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Append Record: Bug 641 - Do we still have the bug?

James Crook
Audacity 2.2.0 has Record-Append as the default, rather than
record-new-track.
Bug 641 is a P3 bug about record-append, and we need to find out if this
bug is still present.

Bug 641 - Append record causes spurious playthrough and may crash.
http://bugzilla.audacityteam.org/show_bug.cgi?id=641


I've not seen/heard this bug, using Windows almost exclusively, and Gale
says it's moonphase.  The crash part apparently was caused by envelopes,
and apparently was debug builds only. We need to know if parts of bug
641 are still present in current builds, and if so how to make them
happen repeatably.

It is certainly possible the bug is fixed.  Vaughan did work on it.  
Paul has added exception safety and memory allocation safety to this
code since the bug was originally reported.  For Audacity 2.1.3 I added
this change from DarkAudacity (Sept 10 2016).

ControlToolBar.cpp/991

// Don't record more channels than configured recording pref.
if( (int)newRecordingTracks.size() >= recordingChannels ){
     break;
}

This stops us recording more channels than configured, and in particular
keeps us within the number of channels the sound card can handle.


I'm asking on quality, since with record append now as the default, a
problem in record append would affect all users.  I suspect we are OK on
Windows, since record-append is the default in DarkAudacity and that has
had a lot of use.  Possible things that might contribute to the bug
happening:

- Latency correction
- Adding on to different length tracks
- Envelopes on the already recorded tracks
- Stereo rather than mono recording


I also tried different sample rates on different tracks.  I found I can
record stereo to two tracks that have different sample rates, and one
track will progress faster than the other.  It's NOT resampling, and I
think this is an edge case (not something people will often do) that is OK.

Gale also wrote in the bug report:

"Also when Steve and I tested this at the time, we found many
weirdnesses and bugs with Append Record which I don't think ever got on
Bugzilla."

So can we collect a catalogue of weirdnesses too?



--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Append Record: Bug 641 - Do we still have the bug?

Robert Hänggi
On 16/05/2017, James Crook <[hidden email]> wrote:

> Audacity 2.2.0 has Record-Append as the default, rather than
> record-new-track.
> Bug 641 is a P3 bug about record-append, and we need to find out if this
> bug is still present.
>
> Bug 641 - Append record causes spurious playthrough and may crash.
> http://bugzilla.audacityteam.org/show_bug.cgi?id=641
>
>
> I've not seen/heard this bug, using Windows almost exclusively, and Gale
> says it's moonphase.  The crash part apparently was caused by envelopes,
> and apparently was debug builds only. We need to know if parts of bug
> 641 are still present in current builds, and if so how to make them
> happen repeatably.
>
> It is certainly possible the bug is fixed.  Vaughan did work on it.
> Paul has added exception safety and memory allocation safety to this
> code since the bug was originally reported.  For Audacity 2.1.3 I added
> this change from DarkAudacity (Sept 10 2016).
>
> ControlToolBar.cpp/991
>
> // Don't record more channels than configured recording pref.
> if( (int)newRecordingTracks.size() >= recordingChannels ){
>      break;
> }
>
> This stops us recording more channels than configured, and in particular
> keeps us within the number of channels the sound card can handle.
>
>
> I'm asking on quality, since with record append now as the default, a
> problem in record append would affect all users.  I suspect we are OK on
> Windows, since record-append is the default in DarkAudacity and that has
> had a lot of use.  Possible things that might contribute to the bug
> happening:
>
> - Latency correction
> - Adding on to different length tracks
> - Envelopes on the already recorded tracks
> - Stereo rather than mono recording
>
>
> I also tried different sample rates on different tracks.  I found I can
> record stereo to two tracks that have different sample rates, and one
> track will progress faster than the other.  It's NOT resampling, and I
> think this is an edge case (not something people will often do) that is OK.
>
I did not know that one can do that.
However, should this really be allowed?
One can't apply an effect afterwards since a error message will be displayed.
Any thoughts on that?

Robert

> Gale also wrote in the bug report:
>
> "Also when Steve and I tested this at the time, we found many
> weirdnesses and bugs with Append Record which I don't think ever got on
> Bugzilla."
>
> So can we collect a catalogue of weirdnesses too?
>
>
>
> --James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Append Record: Bug 641 - Do we still have the bug?

James Crook
On 5/16/2017 12:18 PM, Robert Hänggi wrote:

> On 16/05/2017, James Crook <[hidden email]> wrote:
>> Audacity 2.2.0 has Record-Append as the default, rather than
>> record-new-track.
>> Bug 641 is a P3 bug about record-append, and we need to find out if this
>> bug is still present.
>>
>> Bug 641 - Append record causes spurious playthrough and may crash.
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=641
>>
>>
>> I've not seen/heard this bug, using Windows almost exclusively, and Gale
>> says it's moonphase.  The crash part apparently was caused by envelopes,
>> and apparently was debug builds only. We need to know if parts of bug
>> 641 are still present in current builds, and if so how to make them
>> happen repeatably.
>>
>> It is certainly possible the bug is fixed.  Vaughan did work on it.
>> Paul has added exception safety and memory allocation safety to this
>> code since the bug was originally reported.  For Audacity 2.1.3 I added
>> this change from DarkAudacity (Sept 10 2016).
>>
>> ControlToolBar.cpp/991
>>
>> // Don't record more channels than configured recording pref.
>> if( (int)newRecordingTracks.size() >= recordingChannels ){
>>       break;
>> }
>>
>> This stops us recording more channels than configured, and in particular
>> keeps us within the number of channels the sound card can handle.
>>
>>
>> I'm asking on quality, since with record append now as the default, a
>> problem in record append would affect all users.  I suspect we are OK on
>> Windows, since record-append is the default in DarkAudacity and that has
>> had a lot of use.  Possible things that might contribute to the bug
>> happening:
>>
>> - Latency correction
>> - Adding on to different length tracks
>> - Envelopes on the already recorded tracks
>> - Stereo rather than mono recording
>>
>>
>> I also tried different sample rates on different tracks.  I found I can
>> record stereo to two tracks that have different sample rates, and one
>> track will progress faster than the other.  It's NOT resampling, and I
>> think this is an edge case (not something people will often do) that is OK.
>>
> I did not know that one can do that.
> However, should this really be allowed?
> One can't apply an effect afterwards since a error message will be displayed.
Some effects are fine.  I tried echo and fade out.

It's certainly odd behaviour, but if a user has gone to the trouble of
making two tracks at different sample rates, one might assume they are
doing this intentionally?
Maybe we should disallow recording to tracks that have different sample
rates.  I don't think resampling one track but not the other as we
record is a good idea here.

What about append-record Robert?  Have you seen the Bug 641 problems?  
If we have them they are much more pressing problems.

> Any thoughts on that?
>
> Robert


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Append Record: Bug 641 - Do we still have the bug?

Robert Hänggi
On 16/05/2017, James Crook <[hidden email]> wrote:

> On 5/16/2017 12:18 PM, Robert Hänggi wrote:
>> On 16/05/2017, James Crook <[hidden email]> wrote:
>>> Audacity 2.2.0 has Record-Append as the default, rather than
>>> record-new-track.
>>> Bug 641 is a P3 bug about record-append, and we need to find out if this
>>> bug is still present.
>>>
>>> Bug 641 - Append record causes spurious playthrough and may crash.
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=641
>>>
>>>
>>> I've not seen/heard this bug, using Windows almost exclusively, and Gale
>>> says it's moonphase.  The crash part apparently was caused by envelopes,
>>> and apparently was debug builds only. We need to know if parts of bug
>>> 641 are still present in current builds, and if so how to make them
>>> happen repeatably.
>>>
>>> It is certainly possible the bug is fixed.  Vaughan did work on it.
>>> Paul has added exception safety and memory allocation safety to this
>>> code since the bug was originally reported.  For Audacity 2.1.3 I added
>>> this change from DarkAudacity (Sept 10 2016).
>>>
>>> ControlToolBar.cpp/991
>>>
>>> // Don't record more channels than configured recording pref.
>>> if( (int)newRecordingTracks.size() >= recordingChannels ){
>>>       break;
>>> }
>>>
>>> This stops us recording more channels than configured, and in particular
>>> keeps us within the number of channels the sound card can handle.
>>>
>>>
>>> I'm asking on quality, since with record append now as the default, a
>>> problem in record append would affect all users.  I suspect we are OK on
>>> Windows, since record-append is the default in DarkAudacity and that has
>>> had a lot of use.  Possible things that might contribute to the bug
>>> happening:
>>>
>>> - Latency correction
>>> - Adding on to different length tracks
>>> - Envelopes on the already recorded tracks
>>> - Stereo rather than mono recording
>>>
>>>
>>> I also tried different sample rates on different tracks.  I found I can
>>> record stereo to two tracks that have different sample rates, and one
>>> track will progress faster than the other.  It's NOT resampling, and I
>>> think this is an edge case (not something people will often do) that is
>>> OK.
>>>
>> I did not know that one can do that.
>> However, should this really be allowed?
>> One can't apply an effect afterwards since a error message will be
>> displayed.
> Some effects are fine.  I tried echo and fade out.
>
> It's certainly odd behaviour, but if a user has gone to the trouble of
> making two tracks at different sample rates, one might assume they are
> doing this intentionally?

I thought so too. There may be applications where you have sound in
one track and a control signal for light effects in the other
(meditation machines for instance).
After all, Audacity is an audio editor and should as such respect
original sample rates and values.
Therefore, automatic resampling (as discussed in another thread) is
probably not the right way to go.
> Maybe we should disallow recording to tracks that have different sample
> rates.  I don't think resampling one track but not the other as we
> record is a good idea here.
>
The recording should still be allowed but the track could afterwards
automatically be split in order to show the different rates.
Equally, making stereo only after confirmation.

> What about append-record Robert?  Have you seen the Bug 641 problems?
> If we have them they are much more pressing problems.
>
Fortunately not. I had some problems in Windows 10 after upgrading.
However, it was due to different rates for mic and overdub audio.
I will look if your bug appears with other hosts (incl. Asio)although
I can't trigger it per envelope points.
Robert

>> Any thoughts on that?
>>
>> Robert
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Append Record: Bug 641 - Do we still have the bug?

Gale
Administrator
In reply to this post by James Crook
On 16 May 2017 at 13:04, James Crook <[hidden email]> wrote:

> On 5/16/2017 12:18 PM, Robert Hänggi wrote:
>> On 16/05/2017, James Crook <[hidden email]> wrote:
>>> Audacity 2.2.0 has Record-Append as the default, rather than
>>> record-new-track.
>>> Bug 641 is a P3 bug about record-append, and we need to find out if this
>>> bug is still present.
>>>
>>> Bug 641 - Append record causes spurious playthrough and may crash.
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=641
>>>
>>>
>>> I've not seen/heard this bug, using Windows almost exclusively, and Gale
>>> says it's moonphase.  The crash part apparently was caused by envelopes,
>>> and apparently was debug builds only. We need to know if parts of bug
>>> 641 are still present in current builds, and if so how to make them
>>> happen repeatably.
>>>
>>> It is certainly possible the bug is fixed.  Vaughan did work on it.
>>> Paul has added exception safety and memory allocation safety to this
>>> code since the bug was originally reported.  For Audacity 2.1.3 I added
>>> this change from DarkAudacity (Sept 10 2016).
>>>
>>> ControlToolBar.cpp/991
>>>
>>> // Don't record more channels than configured recording pref.
>>> if( (int)newRecordingTracks.size() >= recordingChannels ){
>>>       break;
>>> }
>>>
>>> This stops us recording more channels than configured, and in particular
>>> keeps us within the number of channels the sound card can handle.
>>>
>>>
>>> I'm asking on quality, since with record append now as the default, a
>>> problem in record append would affect all users.  I suspect we are OK on
>>> Windows, since record-append is the default in DarkAudacity and that has
>>> had a lot of use.  Possible things that might contribute to the bug
>>> happening:
>>>
>>> - Latency correction
>>> - Adding on to different length tracks
>>> - Envelopes on the already recorded tracks
>>> - Stereo rather than mono recording
>>>
>>>
>>> I also tried different sample rates on different tracks.  I found I can
>>> record stereo to two tracks that have different sample rates, and one
>>> track will progress faster than the other.  It's NOT resampling, and I
>>> think this is an edge case (not something people will often do) that is OK.

I think this is one thing that Steve and I noticed - I did eventually
add it to Bugzilla:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1563 .

There is an associated problem of recording time remaining being
"wrong".

I would have to dig to find the other things Steve/I discussed.


>> I did not know that one can do that.
>> However, should this really be allowed?
>> One can't apply an effect afterwards since a error message will be displayed.
> Some effects are fine.  I tried echo and fade out.
>
> It's certainly odd behaviour, but if a user has gone to the trouble of
> making two tracks at different sample rates, one might assume they are
> doing this intentionally?
> Maybe we should disallow recording to tracks that have different sample
> rates.  I don't think resampling one track but not the other as we
> record is a good idea here.

Offer to resample the track that doesn't match the project rate after
recording? I am not sure we should ask first - they could be
recording something live and unrepeatable.

If users import two files at different rates then append record
to both tracks, the issue will happen.


Gale



> What about append-record Robert?  Have you seen the Bug 641 problems?
> If we have them they are much more pressing problems.
>
>> Any thoughts on that?
>>
>> Robert
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...