crash after ten seconds of recording through SPDIF-in

[richardash1981]

I don't have an answer, but I can make some more observations. One is that zooming out doesn't just change how often the re-draw happens, but it also changes how detailed that re-draw is. The more you are zoomed in, the more points are drawn on a given 10-second block of audio. To speed up loading your project, audacity caches a small number of points for every stored audio block in the project file (and in memory during recording). So if the display is zoomed out, then these cached points will be enough to draw the waveform, without touching the actual audio data on the disk. If you are zoomed in, then audacity needs more points, and has to get them by looking at the actual audio files on disk.

Where I'm coming to is that the difference between 20 seconds and 10 seconds may be the difference between drawing using cached data, and drawing based on disk data, and that may be the culprit.

To test this, you can uncheck the "Autoscroll whilst playing" option on the Interface tab of the preferences. This will stop audacity scrolling automatically when the cursor reaches the right hand side of the screen. If I'm right, then at 10 sec zoom, you should be able to keep recording whilst the cursor goes off the edge of the screen, but if you try and use the scroll bar to catch up you will get a crash.

I'm also worried by the fact that you get an unhandled exception error. Release versions of audacity shouldn't be built with exception support, because that should only go into debug builds. So I'm wondering if the crash is somewhere else entirely. The point of that dialogue is that if you have a debugger installed then clicking "Abort" would start it and let you examine where the failure had occurred.

[marbo]

To test this, you can uncheck the "Autoscroll whilst playing" option on the Interface tab of the preferences. This will stop audacity scrolling automatically when the cursor reaches the right hand side of the screen. If I'm right, then at 10 sec zoom, you should be able to keep recording whilst the cursor goes off the edge of the screen, but if you try and use the scroll bar to catch up you will get a crash.

Exactly. When disabling "update display while playing" in interface preferences audacity doesn't crash anymore, unless when trying to catch up.

The point of that dialogue is that if you have a debugger installed then clicking "Abort" would start it and let you examine where the failure had occurred.

A de... what? No, seriously, I do not have experiences with debuggers and think that I haven't installed one, unless there are debuggers that get installed with other software. Anyway, if this is of any help and there is a chance that an absolute beginner can handle it, I would install one. But you will have to tell me: 1.which debugger, 2.what to do!

[alatham]

As per debuggers, I think Richard was trying to tell you not to worry about it and that you never should have seen that type of error message in the first place.

If you don't know what a debugger is and how to use one, we certainly won't be able to explain everything on this forum.

[richardash1981]

No, don't worry about the debugger, certainly at the moment. If you don't mind a couple more tests:
* If you leave autoscroll turned on at 10 seconds zoom, but minimise audacity, does it do it?
* If you do something that does a load of disk accesses, like copying a pile of files, whilst you record, does that crash audacity?

There is either a bug in audacity which your system produces but none of the developers does, or there is something else in your system that is struggling, and causing audacity to crash.

[marbo]

* If you leave autoscroll turned on at 10 seconds zoom, but minimise audacity, does it do it?

It doesn't crash as long as minimized (recorded for about 2min), but directly after coming up, it crashes again.

* If you do something that does a load of disk accesses, like copying a pile of files, whilst you record, does that crash audacity?

To get a lot of disk accesses, I started defragmentation, unpacked a 280MB 7zip-file and copied a whole CD to hard disk simultaneously and consider that Firefox, Thunderbird and foobar were running. I didn't close down no task. The light of my hard disk was always-on.
This I've done twice for about 7min without audacity crashing.
First time with autoscroll on, but before recording I zoomed out once.
Second time I turned autoscroll off and pushed stop after 7min, without trying to catch up.

[richardash1981]

Hmm, that does confirm it as an audacity bug. There is a possibility a recent fix to the development version may have fixed it (it was another scrolling bug that crashed audacity), so I'll try and get hold of a test version for you to try out.

[marbo]

Now that I know how to work around this, I tried to record whole songs and found s.th. else! When recording through SPDIF-in or line-in after six seconds and then every 5,4 seconds there is a gap in audio. It is reproducable and CPU-usage or harddisk access does not rise at this points. In most tries these gaps are visible and get slightly larger after 16,8 sec. See picture! Sometimes they are not visible but they are always audible (like a skipping CD). This does not happen with 1.2.6!

Gaps.jpg

[alatham]

Marbo, in the edit -> preferences -> audio i/o menu there is a "Latency" -> "audio to buffer" field. What is this set to?

What happens if you set it to something quite high (like 500 ms)?

[marbo]

"audio to buffer" field. What is this set to?

100ms
And setting it to 500ms doesn't change anything. I went up to 10.000ms and tried 1.000, 2.000 and 5.000ms without preventing the gaps. The only thing that changed was the gap length. The gaps alternate from big to small to big ... gaps.
How does 1.2.6 deal with latency?

[alatham]

That changed the gap length? Well, that was unexpected...

I was really taking a stab in the dark with that one, I don't know what to say other than to suggest that you try Windows Sound Recorder and see if the problem shows up there too.

As for 1.2.6, it makes a guess as to what the Latency correction should be, it doesn't allow you to set it manually. Have you tried using 1.2.6? Does that work? I've found it to record just a bit more smoothly than 1.3.4 (which I get the occasional dropped sample with).

You can install both 1.2.6 and 1.3.4 together at the same time.