| From Martyn Shaw <martynshaw99@...>
| Sun, 30 Sep 2007 01:07:18 +0100
| Subject: [Audacity-devel] Crash on record-append
| > Well I'd be pretty naff if I did not have the best drivers I could given the | > number of hours I spend a week telling other people to do it :-).
| True. Just an idea. Didn't mean to offend ;-).
No offence taken :-)
| Actually I
| > never have reported recording speed problems that I can recall.
| There was something around here about recording always falling a
| fraction of a second short of what it should. Sorry, must have
| mis-remembered it. Won't waste time searching for a reference.
Yes that was me, but I wasn't thinking of it as a recording speed
problem because the last bit of the played back audio is missing in the
recording. It's an aim-to on the Checklist:
"Fix problem when recording stereo mix from a track in Audacity, about
100ms of the recording is truncated at the end (irrespective of latency
correction setting in Preferences)."
| My issue
| > was Audacity failing to report clipping. As I could not recall speed issues | > before on this machine, I was suspicious, especially as the problem was
| > *solely* when append-recording. Anyway, above tests were with USB
| > sound card (MS generic drivers as the "proper" ones just won't work
| > with my hardware). I have rebooted and tried again. No speed problem
| > now when append-recording with the USB card. Switched to inbuilt sound
| > (latest drivers) and no speed problem.
| Wierd, so a reboot fixed the speed problem? You don't have it any more?
No, and I have never seen the USB card do a classic record at wrong rate
before like that. Reboots often do fix things. As I am sure you know, when
you try to record you can sometimes find the recording cursor just stays
put without recording anything. I still get this problem sometimes after using
the computer for more than a day, even on a half decent XP 1.6 GHz system
with 1 GB or RAM. But reboot always fixes it. OTOH it may be that the
corrupted playback with append-recording issue you just fixed was behind it
somehow, given the MS drivers I have to use.
| > | The jump by the latency amount I noted yesterday "...Latency
| > | correction
| > | after append-recording should be of the 'Trim' or 'Clear' kind, in my
| > | opinion...". I'm thinking about that.
| > I'm not really clear Martyn where your lines of thought are heading. It
| > looked
| > by what you said that by "Trim" you mean truncate? We don't want
| > truncation do we? The checklist item currently suggests:
| > "Prevent latency correction occurring when append-recording, even if set in
| > Preferences, to prevent possibility of "real" audio being shifted behind
| > zero. Actual situation needs noting in the Manual, whether this aim-to is
| > done for 1.4.0 or not".
| Now there's a thing. That is not a very good solution to the problem, I
| think. I figure it like this:
| We have 2 tracks recorded/imported, like in your example of a 60s and a
| 30s track, both starting at zero. Synchronised together, in time.
| We select the shorter one.
| We have a +ve or -ve latence in prefs, possibly randomly typed in, or
| incorrectly concieved. Let's assume that it is correct and causes the
| recorded bit to move left by the correct amount (-162ms on my version,
| with tonight's HEAD version).
| We press shift-record (append-record) and record something, then press
| Do we want the shorter track, that was synchronised, to be shifted? No.
| Do we want the newly recorded bit to be in synch with what was listened
| to while recording it? Yes.
| Can we shift the new bit back (left)? No, it will overlap with the
| original bit (and that's not allowed in Audacity, and I think that's
| What can we do? Leave the original bit of that track where it is and
| truncate (Clear) the new bit so it's still in synch. That's my way of
| thinking, and what I'm working on doing.
Excellent explanation. I see you have committed a fix so that "latency
shift applied to newly recorded bit only". I'll have to wait till I see it as
I'm not sure what happens if the user sets a silly, excessive truncation.
| We could pop a warning but it would get annoying for people who knew
| what they were doing. We could have a 'don't show again'. We could do
| anything with enough develepers!
I may still cross swords with James on whether the warnings I have in mind
(like the one you suggest) are the same as what he is thinking about...
| Don't forget that, in terms of the codebase, a step towards a solution
| is better than waiting for a perfect solution!
Yes I've understood that in many cases (when programming) this may be so.
Outbound message virus free.
Tested on: 10/1/2007 2:05:45 AM