... Contrary to the old comments, this class was no longer thread safe with
multi-core, because of the possibility of out-of-order reads and writes.
Use the minimal necessary memory ordering, not the default and maybe expensive
std::memory_order_seq_cst
At least one clicky recording has been seen where many small groups of
samples, a common power in two in size, seem to get displaced rightward.
I suspect out of order reads and writes might have caused that and this commit
might prevent it.
The shortcuts for these commands were changed in commit e01122e841fc25cd004ecea77b1665015700f937 to avoid conflicts with the access keys of menus.
They were changed to Ctrl+Alt+P/N. These aren't very convenient for typing, so this commit changes them to Alt+comma/period.
* commit 'a0bf2892fa20009a798f28387fc0e96bbe3260a0':
Revert "Possibly correct some cases of clicky playback or corrupt recording..."
Revert "Fix compilation on Windows."
Revert "Fixes for new ring buffers..."
Punch and roll from 0.0 deletes the whole track before punch and rolling.
That is unlikely to be what the user intended, since there is then no audio
cue, so disallow it.
Also reduced indentation.
... If recording one or two channels, use first unbroken subsequence within the
selected wave tracks for which the total of channels matches exactly; failing
that, use such a sequence among all wave tracks; failing that, record to
new tracks.
If recording more than two channels, and there is at least one selected wave
track, then use the topmost selected wave channels, up to the number of
recording channels, and if fewer channels are selected, just drop the extra
input channels.
If recording more than two, and no wave tracks are selected, ignore existing
wave tracks and record to new tracks.
In any case, the tracks chosen for append-record might not be consecutive
among all the tracks, because non-wave or non-selected tracks may come between.
These were the steps to reproduce:
Remember that the Realtek card in my new HP laptop *only* runs at 48000
1) Clear out the entire Audacity config/settings folder for virgin running
2) Launch Audacity audacity-2.3.0-alpha-20-a22be24ae3a224c90688504f8ff323c41f8c9c35
3) set recording for WASAPI/loopback (or WASAPI/mic)
4) press Record
5) Track records properly
6) rate shown in TCP is 44100
7) Project rate at bottom left shows 44100
8) Exit Audacity
9) Relaunch Audacity
10) Project rate at bottom left now shows 48000
11) Press Record
12) Track records OK - but at 48000 obviously
The problem: the default sample rate is read in like this:
gPrefs->Read(wxT("/SamplingRate/DefaultProjectSampleRate"), &mRate, AudioIO::GetOptimalSupportedSampleRate());
- the default is not fixed, it can vary with host/device.
Fix: Ensure that there is always an entry for the default sample rate in audacity.cfg
problem: The commit 1ccd2678b6985759915fe420c74a094361420dc2 swapped the actions of these two commands.
Fix: swap them back to their original actions:
Selection contract left: contracts the selection by moving its left hand end to the right.
Selection contract right: contracts the selection by moving its right hand end to the left.
This was caused by my commit: f9ee3cdc45ab3c5530505daa119ef01ccfdcc262
When void KeyConfigPrefs::PopulateOrExchange(ShuttleGui & S) is called for the purposes of GetInfo, the pointers to the radio buttons are null, so need to check for this before calls to SetAccessible.
menu item, tentative shortcut Shift+D ("do-over")
Add to recording preferences for pre-roll and crossfade
Define EXPERIMENTAL flag
Recording options allow crossfade data for start of recording
Stop playback of pre-rolled tracks at the right time
Allow for preRoll in start-stream options
