Phase jumps when recording

[DickN]

I'm having a problem on Vista with a Realtek sound card using Audacity 1.3.12 which I never had with 1.2. Occasionally the input has a lot of disturbances which sound a little like "Scratchy.mp3" (see "Scratchy sound on recordings" post) but I don't think it's the same phenomenon. That one looks like dropouts rather than phase discontinuities. I tried exporting my sample track as MP3, 128Kb/s, and it doesn't look like dropouts. I'm sending a wav file anyway to avoid other MP3 artifacts. Today the phase jump has a couple of times started happening in the middle of recording. I was recording a bongo track and it started sounding like double-hits on the bongo with an additional "scratchyness" quality. I've never seen it stop happening during recording once it has started. If Software Playthrough is enabled, I can hear it while recording. I finally caught it red-handed with a sinewave generator and have characterized it to facilitate debugging.

Setup:

Host: Windows DirectSound
Playback: Speakers (Realtek High Definition Audio)
Device: Microphone (Realtek High Definition Audio), 1 channel

Recording: Overdub ON
Software Playthrough ON

Latency:
Audio to buffer: 100 ms
Latency correction: -130 ms

Sample rate: 44,100 Hz
32 bit float

High-quality Sinc Interpolation
Dither: Shaped

High-quality Conversion:
Sample Rate Converter: High-quality Sinc Interpolation
Dither: Shaped

Update Display while Playing (I've found that turning this off doesn't help)
View Mode: Waveform

process priority: "above normal" (windows task manager)

Other tasks running:
Realtek HD Audio GUI (has to be on when I start Audacity or input device isn't detected);
Task Manager.

OS: Vista Home Premium SP2
Platform: AMD Phenom 9150e Quad-Core processor, 1.8 GHz with 4 GB RAM

What happens is this:

The phase jumps back 8 samples (i.e., the previous 8 samples are repeated. Note, it could be 8 samples +/- some multiple of 2 milliseconds, since the test signal is a 500 Hz sinewave. The bongo "double hit" separation was about 100 ms.). Then 10 ms (441 samples) later the phase jumps ahead to its previous state, causing input samples to be skipped. This behavior repeats at some random multiple of 120 ms from the previous occurrence.

The test method:

I recorded a 500 Hz sinewave from a sinewave generator plugged into the mic input. To find all of the disturbances, I duplicated the track and shifted it to place the initial coherent portion of the recording (before the first disturbance) under the portion with the disturbances and visually aligned the zero crossings. Then I inverted the copy. The playback thus is only noise except where there's a disturbance. To find all of the disturbances, I played it back at 0.1 x normal speed so 500 Hz became 50 Hz and I could stop the playback not too far past the disturbance upon hearing it. Each disturbance produces a short burst of 50 Hz in the playback.

Other observations:

I have found on other occasions (not using sinewave test signal) that in Record Pause with Software Playthrough enabled I still hear the disturbance.

When this first happened today I was playing back multiple tracks while recording, but while recording the sinewave test I tried muting all of them and it made no difference. Sorry, I didn't try turning Overdub OFF.

While uploading the sample, I looked at data acquired before I changed the process priority. The phase disturbance was in the other direction and lasted 22 ms instead of 10 ms. I don't know how consistent the quantitative results would be with multiple experiments, but qualitatively it's a phase jump that gets canceled later by another phase jump. I really doubt it's simply missed samples, because samples are repeated when the jump is in the reverse direction (OK, I'm using a periodic signal for test so this doesn't really prove it) and because the phase returns to exactly the previous state on the next jump. For this to be missed samples in both jumps, the number of samples missed would have to alternate between two specific counts, which seems very unlikely.

I hope this doesn't produce multiple copies of the attachment or the post. I've been trying all night to attach the wav file showing the phase discontinuities, but I keep getting bounced back to the Login page. The file is only 336K. I have dialup, but I don't think my login session is timing out.


- DickN

[steve]

Have you checked it the Windows Control Panel and checked that the sound card settings match the settings in Audacity?
(information about the sound card settings in the Control Panel: http://wiki.audacityteam.org/wiki/Mixer ... trol_Panel )

On Vista, can you give priority to "background services" ?
Audio runs as a background service, so it can improve performance noticeably to give it priority - I've only used this option on XP so I don't know if you can do it on Vista.

I've been trying all night to attach the wav file

The forum will only accept very short WAV files (just a few seconds of audio). Could you upload the sample to a file sharing site such as sendspace.com and post a link?
Please keep wav samples short - we only need to hear the problem, not listen to a concert, so just a few seconds should be enough

[kozikowski]

You can also try posting as a FLAC instead of WAV. FLAC is a lossless compression technique.

Koz

[DickN]

Here's a more revealing sample:

split & repeated mic thump.flac

Mic thump transient affected by a phase jump. A 20 ms slice of the transient appears, followed by the complete transient offset 120 ms from the slice.

(10.33 KiB) Downloaded 243 times

Looks to me like a circular buffer pointer race in which the write pointer passes the read pointer, then in 20ms the read pointer catches up, runs through the buffer and re-reads the same data but this time gets the complete transient. It's interesting (from the sinewave experiment) that the event always repeats at some multiple of 120 ms from the previous event. It would appear that this is also the buffer length if my hypothesis is correct.

This looks a lot more like Scratchy.mp3, I betcha it's the same syndrome. Maybe this thread should be p/o the "Scratchy sound on recordings" thread.

Have you checked it the Windows Control Panel and checked that the sound card settings match the settings in Audacity?
(information about the sound card settings in the Control Panel: http://wiki.audacityteam.org/wiki/Mixer ... trol_Panel )

On Vista, can you give priority to "background services" ?
Audio runs as a background service, so it can improve performance noticeably to give it priority - I've only used this option on XP so I don't know if you can do it on Vista.

I've been trying all night to attach the wav file

The forum will only accept very short WAV files (just a few seconds of audio). Could you upload the sample to a file sharing site such as sendspace.com and post a link?
Please keep wav samples short - we only need to hear the problem, not listen to a concert, so just a few seconds should be enough

This was recorded with "windows direct sound primary sound capture driver". In the sinewave experiment, I was using "Microphone (RealTek High Definition Audio)". It appears the probability of occurrence is slightly lower using the "Microphone" selection than "primary sound capture driver", but this time I was more interested in catching an event than in making the events less frequent.

I tried using "stereo mix" per the wiki, but that bus (if I can use the term here) also contains the sound output from Audacity so I get some spectacular reverb effect if Software Playthrough is ON. I surmise I'd also get the playback of other tracks if Overdub is ON. It is a neat addition to the source menu though, looks like I could record from any audio stream that goes through the mixer, which I guess includes everything.

I looked for a way to change the priority of Background service. There's an AudioSrv under Services, but it doesn't look like I can change the priority.

The .wav file was only 336K (~4 seconds), a third of the 1MB limit. I made a FLAC file, that was 145K and I still couldn't upload it (got bounced back to Login page). Should I look into putting it on sendspace.com?

- DickN

[steve]

Looks to me like a circular buffer pointer race ....

Out of curiosity, look in "Edit menu > Preferences > Recording". What settings do you have in the section titled "Latency"?

Have you checked it the Windows Control Panel and checked that the sound card settings match the settings in Audacity?
(information about the sound card settings in the Control Panel: http://wiki.audacityteam.org/wiki/Mixer ... trol_Panel )

The part that I meant was item 7:
"To prevent possible sample rate or recording channel discrepancies, right-click again and click Properties then the Advanced tab, and make sure the "Default format" matches both with the project rate bottom left of the Audacity screen, and with the number of "recording channels" in the Audio I/O tab of Audacity Preferences (Devices tab in current Audacity Beta); now click "OK"

[DickN]

Looks to me like a circular buffer pointer race ....

Out of curiosity, look in "Edit menu > Preferences > Recording". What settings do you have in the section titled "Latency"?

I have the initial settings: Latency = 100 ms, Latency Correction = -130 ms.

I tinkered with Latency setting and found it does affect the frequency of occurrence. I'll retry the sinewave test when I get a chance (next week) and see if setting it long enough eliminates the problem. Can't beat a continuous deterministic signal for detecting glitches. I did find that when the event does occur, the Latency setting has no effect on the time scale of the individual event. The facts that in the sinewave test the event happens only at multiples of 120 ms, which matches the buffer length if my "pointer race" assumption is correct, and that I never saw this happen in version 1.2, suggest to me that a bug has been introduced that should be investigated. It looks like the write pointer can pass the read pointer only at a certain point (the wrap?) in the buffer. Of course, if tweaking a user-settable parameter makes it a non-problem then it's rather unimportant.

Have you checked it the Windows Control Panel and checked that the sound card settings match the settings in Audacity?
(information about the sound card settings in the Control Panel: http://wiki.audacityteam.org/wiki/Mixer ... trol_Panel )

The part that I meant was item 7:
"To prevent possible sample rate or recording channel discrepancies, right-click again and click Properties then the Advanced tab, and make sure the "Default format" matches both with the project rate bottom left of the Audacity screen, and with the number of "recording channels" in the Audio I/O tab of Audacity Preferences (Devices tab in current Audacity Beta); now click "OK"

Sample Rates match, but I can't find any "1 channel" options for mic, line in or stereo mix. The mic input is a stereo TRS jack and I've used it that way (guitar pickup + mic), but typically with mic input I use 1 channel and set Balance in the RealTek GUI full Left to eliminate R channel noise. I definitely get a mix of both input channels when Edit->Preferences->Devices->Recording->Channels is set to 1.

I'm really not sure whether I've ever had this happen when recording in stereo or not, but will include it in my testing next week.

I also have Properties->Exclusive Mode->"Allow applications to take exclusive control of this device" and "Give exclusive mode applications priority" ticked for all Recording devices under Control Panel.

- DickN

[steve]

he facts that in the sinewave test the event happens only at multiples of 120 ms, which matches the buffer length

Which buffer length? Didn't you say the buffer is set to 100 ms?

suggest to me that a bug has been introduced that should be investigated.

Possibly not - with almost 2 million downloads of version 1.3.12, I've come across 2 cases that bare a fleeting resemblance to this, but nothing quite like it. If it were a bug we would be likely to get loads of people writing in about it. Definitely worth investigating though, and hopefully find some workaround/fix for the issue.

It would definitely be worth checking to see if there are any updated sound card drivers available from manufacturer (if it's a branded computer then you could try their website, and/or if it's an on-board sound card check the motherboard manufacturers web site).

[DickN]

he facts that in the sinewave test the event happens only at multiples of 120 ms, which matches the buffer length

Which buffer length? Didn't you say the buffer is set to 100 ms?

The Latency is set to 100 ms, but changing the Latency doesn't affect the time offset between the slice and the complete transient (referring to the mic thump recording I uploaded). More precisely, if you measure the time difference between say, a zero crossing in the slice (that extraneous piece of signal, truncated at both ends, near the beginning of the recording) and the same zero crossing in the complete mic thump which appears later, you will find it to be 120 ms. The length of the slice is 20 ms. These two time intervals don't change when I change the Latency setting.

I'm surmising that somewhere in the path between the sampling and writing data to the track there's a circular buffer whose length is 120 ms at 44100 sps, or about 5K samples. This doesn't mean the buffer always delays the signal by 120 ms - could be it serves as a FIFO to pass data between two asynchronous processes and normally contains only a small amount of data waiting to be read out. If the Read pointer were permitted to read this buffer continuously with no new data being written to it, the playback would resemble a tape loop 120 ms in length. New data are being written, however, and reading any data twice is possible only if the buffer momentarily overflows or underflows, i.e. the Read and Write pointers pass each other. If it overflows, some new data will be missed and some old data will be re-read once the Read pointer catches up. Most likely it's an overflow - my mental modeling just isn't coming up with a slice preceding the normal waveform and truncated at both ends in the underflow case.

The buffer length directly determines the time offset between the "slice", as I've been calling it, and the normal signal which resumes after it. The duration of the slice is the amount of data that gets read twice. It's interesting that this duration, 20 ms, is so consistent and that changing the Latency doesn't affect it. I suspect this is a really good clue - the buffer always overflows or underflows by the same amount. It's also interesting that with a continuous input signal (the sinewave test) these events are always separated by a multiple of 120 ms. Probably another clue. This one I think I understand, as explained in my previous post.

The buffer's location in the data path must be before the point where the Software Playthrough signal is sent out, since I can hear the disturbances while in Record Pause. There's another clue here: I don't notice an actual interruption of the continuous sinewave, and certainly no pitch variation, in the Software Playthrough, just impulses from the jumps in the waveform. This strongly suggests that the problem is not on the Read side of the buffer (unless there's another buffer after that one in the Software Playthrough path).

I must remember to check whether I hear it when Monitoring.

Anyone with a continuous coherent signal source (I'd recommend an electronic keyboard) can repeat my sinewave experiment - I would expect the same results with a long continuous tone from any source. It doesn't have to be a sine, but it does have to have constant frequency and amplitude (be free from vibrato or tremolo and not damp out) and be a strictly periodic signal (a note, not a chord) to do the experiment I described under "The test method" in my first post. A triangle would be perfect.

suggest to me that a bug has been introduced that should be investigated.

Possibly not - with almost 2 million downloads of version 1.3.12, I've come across 2 cases that bare a fleeting resemblance to this, but nothing quite like it. If it were a bug we would be likely to get loads of people writing in about it.

It doesn't happen on my laptop (OS = XT,SP2) either, and it happens inconsistently on the system I'm doing the testing on. I use it for a while with no problem and then it starts happening. The only reason I don't suspect the hardware is that it doesn't happen with version 1.2. Note to self: Try 1.2 again next week and make sure it still doesn't exhibit the problem.

- DickN

[DickN]

Update:

Today I tried the sine wave test on version 1.2.6. The event never occurred.

Back to 1.3.12, I now must retract my statement that it always occurs at a multiple of 120ms. Most of the time it does, but not always. The common denominator seems to be 30 ms, but they're never that close together - shortest time I've observed from beginning of one event to beginning of next is 120 ms. Also, the duration is not always 20 ms, but seems to always be a multiple of 10 ms.

Tried Right channel (previously I was always using Left), same thing.

Tried connecting sinewave generator to both channels and setting Preferences->Devices.Recording.Channels = 2, since my RealTek has no 1 ch. settings. Now, when event occurs, it is always in both channels. It does not seem to be any more or less frequent in Stereo than in Mono.

Switching Monitor on and off (Start Monitoring / Stop Monitoring), I occasionally hear the disturbance while monitoring (Record neither active nor paused). I didn't attempt to analyze the output to confirm it's the same disturbance. I could, by recording the output on the laptop, and will do this if advised that it's useful. It appears that I fairly often get a few glitches right after "Start Monitoring", but usually it stops happening in a couple of seconds. I do not get it in the output when Audacity's Monitoring is OFF and, in the RealTek GUI, Speakers in the Microphone tab is ON.

Right now, it's taking quite a few attempts to get a run of recording with the disturbance occurring. When it is happening, it happens a lot (average of more than 1 event / second). When it's happening more consistently I'll try 1.2.6 again and then try adjusting the Latency on 1.3.12.

There's another experiment I have to try when it's happening more consistently: My antivirus program is always running, and has a "gamer mode" for use when playing video games and not connected to the Internet. Apparently it interferes with some game programs. But why would Audacity 1.3.12 be more susceptible to this than 1.2.6?

[DickN]

Eureka! (and one remaining mystery)

Today recording was particularly badly behaved, which gave me a good chance to experiment. I found that frequency of occurrence didn't vary monotonically with Latency setting, in fact the worst performance was with Latency set around 10 ms. Even setting it to 0 worked better.

Tried setting my anti-spyware program to "gamer mode" - it made no difference.

Then [fanfare], I noticed a setting in Windows Task Manager: Affinity. This computer has a quad-core processor, and Affinity allows allocating a particular set of CPU's to a process. The CPU's are numbered 0 thru 3. I found that only when CPU 0 was selected exclusively did I have no glitches at all. I could record in stereo while playing back at least 8 stereo tracks with Latency=0, no problem. Any other CPU or combination gave me phase jumps regardless of Latency setting, although the frequency of occurrence varied in some odd fashion with the setting. This is with Priority = Normal. Previously (it's in one of these posts) I had tried setting Priority = "Above Normal", to no avail.

I did get one non-reverting phase jump with CPU 0 and Latency = 5 ms. By non-reverting I mean the phase didn't spontaneously jump back to normal after some small multiple of 10 ms as it has every time previously. This happened 19.7 sec into a sinewave test, and I hadn't noticed it while recording. The run continued only 0.53 seconds after it, but that's a long time. I've observed this non-reverting phase jump only once now among all of my tests today and previously.

Setting Preferences->Devices.Recording.Channels=1, which in my system causes both input channels to be summed into one, makes no difference re: phase jumps even though strictly speaking it looks like a mismatch of settings between Audacity and RealTek, which has no 1-Channel settings.

Finally, I repeated the Affinity tests with version 1.2.6. There were no phase jumps at all with any combination of CPU's.

So the bottom line is my problem seems to be solved. Now the mystery: Why is 1.3.12 fussy about multicore CPU allocation and 1.2.6 not fussy?