Audacity Forum

Gale,

I really appreciate all your help!

The Help gives:
3 milliseconds for the low recording latency.
13 milliseconds for the high.

That may explain why the 3 millisecond buffer size didn't work very long and probably the minimum buffer size should be greater than 13 to be safe.

I've recorded with a buffer of 10ms for 3 hours with no problems, but I also recorded using 300ms for 2 hours with no problems using music. Apparently recording speech puts very different demands on the system. At home the CPU load is pretty much the same with the large and small buffers. It runs about 33 - 38% according to the Activity Monitor.

I verified your diagnosis of the problem being dropouts by looking at identical places in the recordings done on the two machines. The bad one had definite spots that dropped out for about almost exactly 3 ms where the good one didn't.

Sure would be nice to know what actually was going on. Does making the buffer smaller keep the system awake so all works as it should or is it something else? Would making Audacity a higher priority make any difference? It doesn't seem like a hardware issue since it works fine with Mavericks.

Well, I'll keep trying parallel recordings for a while until I'm confident that the smaller buffer size keeps the problem at bay.

Thanks again.

Cliff

cmac185 wrote:Does making the buffer smaller keep the system awake so all works as it should or is it something else?

If the recording buffer is short then the system will have to attempt to come back to empty the buffer more frequently. More typically, a short buffer will cause recording dropouts because the machine cannot get back fast enough in-between its other duties.

Typically a long buffer is not harmful, but in recent Audacity versions on Mac, playback can click unless the buffer is set well below 100 ms.

I suspect if you recorded music with the wireless mic that you would have the same issue.

Gale

Well, I thought I had this problem pretty much figured out. Apparently not.

Did another parallel recording today and my machine with Yosemite had the same problem again.

Buffer was set to 50 and after a 35 minute good first recording and about 9 minutes into the second it went bad.

Looking at the wave form I don't see the dropouts that I've seen before, but there are the spikes I was seeing in the beginning.

I meant to bring home the mic and see if I could create a test case to I could experiment and see what affected what, but forgot. Seems as if that is what I need to do so I can figure this thing out faster than one shot a week.

Just for your viewing pleasure I've taken screen shots of the same period of time on the good recording and the bad. You will see the spikes I've mentioned. It seems as if even a good recording has an occasional pop, but normally it isn't even heard on playback unless it is in a quiet spot and then it isn't very loud. Whether those spikes have the same origin as the problem ones I don't know.

Cliff

cmac185 wrote:Did another parallel recording today and my machine with Yosemite had the same problem again.

Buffer was set to 50 and after a 35 minute good first recording and about 9 minutes into the second it went bad.

Have you tried rebooting between first recording and second recording? Sorry I don't recall if you answered that.

What is the machine doing between first recording and second recording - does it go to sleep?

cmac185 wrote:Looking at the wave form I don't see the dropouts that I've seen before, but there are the spikes I was seeing in the beginning.[...]

Just for your viewing pleasure I've taken screen shots of the same period of time on the good recording and the bad. You will see the spikes I've mentioned. It seems as if even a good recording has an occasional pop, but normally it isn't even heard on playback unless it is in a quiet spot and then it isn't very loud. Whether those spikes have the same origin as the problem ones I don't know.

Presumably you transposed the images, so that the "Good Recording" image is that of the bad recording?


Gale

Hi Gale,

I did not boot between recording. Thinking that I had finally a fix for the problem I tried to have everything as it had been before using Yosemite when it recorded without problems. Left other apps open, but not active, not booted for 2 days I believe. Between recordings the display sleeps, but the computer does not. Audacity is running the whole time. The first recording was saved and the window closed then a new window opened and it sat that way until it was time to start the second recording at which time the "Record" button was clicked and the recording track appeared. The recording level was active(monitoring) during the whole time. Audacity was not closed (Cmd+Q) between sessions.

The recordings are done in parallel to prove that the problem is within my machine and also to insure a good recording. I'm using Yosemite10.10.3 and Audacity 2.1.0 and getting the bad recording and the other machine is my wife's running Mavericks 10.9.5 & Audacity 2.0.5.

Opps, the labels are backwards on the attachments. The one with spikes is the bad one.

Upon expanding the spikes I found that the spikes are generally 5 - 6 samples long and often the first sample is at the max amplitude and the rest of the samples are gradually less in amplitude as the peak decays or the exact opposite where the first ones gradually build up to the max then the wave form drops off to zero amplitude in the space of one sample. There are exceptions to these two scenarios, but not too many.

Hopefully I can bring the mic system home this next week and setup a repeatable case so I can play with things and maybe track down at least a way of being sure of a good recording and maybe even a "fix" though I'm not too hopeful of that.

I've been wondering if last week when I got the good recording if changing the buffer size after the first recording reset something in the system so that recording was ok and really the buffer size itself wasn't the solution. Almost as if that reset the operation so it was acting as if it was the first recording and not the second. I know that is a stretch, but not beyond the realm of possibility.

Cliff

cmac185 wrote:I did not boot between recording. Thinking that I had finally a fix for the problem I tried to have everything as it had been before using Yosemite when it recorded without problems. Left other apps open, but not active, not booted for 2 days I believe. Between recordings the display sleeps, but the computer does not. Audacity is running the whole time. The first recording was saved and the window closed then a new window opened and it sat that way until it was time to start the second recording at which time the "Record" button was clicked and the recording track appeared. The recording level was active(monitoring) during the whole time. Audacity was not closed (Cmd+Q) between sessions.

Did you ever try disconnecting the wireless mic or power cycling/resetting it between recordings?

cmac185 wrote:I've been wondering if last week when I got the good recording if changing the buffer size after the first recording reset something in the system so that recording was ok and really the buffer size itself wasn't the solution. Almost as if that reset the operation so it was acting as if it was the first recording and not the second.

Changing the Audacity buffer should not reset anything in the system as far as I can see.


Gale

Did you ever try disconnecting the wireless mic or power cycling/resetting it between recordings?

Never recycled power on the mic. Since I was recording in parallel with the other computer and it didn't have an issue it seemed to me to eliminate the possibility of any external issues.

Changing the Audacity buffer should not reset anything in the system as far as I can see.

OK. Just a thought I would throw out the idea since the first recording was bad and the second was good which has never happened before. I was thinking more of the program starting a new/clean buffer since the size had changed rather than continuing to use an existing buffer if the size had not changed.

Cliff

cmac185 wrote:Opps, the labels are backwards on the attachments. The one with spikes is the bad one.

That's what I figured

Could you please specify the exact models Mac you are using?

There is specific problem with CPU switching with some of them. Can be resolved with a Terminal command to change or swith off hyperthreading, at least in some cases. But it might cause problems with others.

Pure guess: the working one has a Core 2 Duo and the pesky one has an i5 or i7?

Also, since Lion, OSX has some hidden background tasks. Jabbering to Facebook is one of them. Talking to the iCloud is another. Sometimes these need to be turned off. Unfortunately, Apple, in it's Infinte Wisdom, has decided to make that impossible from System Prefs.

I currently have small pile of audio interfaces that don't work with Lion or above. All of them perform well on 10.6.8.

If you are using a Firewire interface, some of those don't work with the Agere chipset in most 2007-2010 Macs. Again, there are some hardware tricks, but fairly specific to interface/mac.

Could you please specify the exact models Mac you are using?

Mine - the problem one: Mid 2009 MacBook Pro Core Duo 2.66 GHz, 8GB RAM MacBookPro5,3 MB985LL/A

Two others that record without problems:
Wife's - Mid 2010 MacBook Pro i7 2.66 GHz, 8 GB RAM MacBookPro6,2 MC373LL/A
Son's - Early 2008 MacBook Pro Core Duo 2.54 GHz, 4 GB RAM MacBookPro 4,1 MB133LL/A


FYI, Sound interface is purely analog, i.e. wireless mic to a receiver and line-out from the receiver to line-in on the laptop. For testing purposes, I have been recording on two machines in parallel by splitting the line-out to go to both computers.

Also, since Lion, OSX has some hidden background tasks. Jabbering to Facebook is one of them. Talking to the iCloud is another. Sometimes these need to be turned off. Unfortunately, Apple, in it's Infinte Wisdom, has decided to make that impossible from System Prefs.

At the time of recording there is no Internet access so nothing can be communicating outside the laptop itself. I have had FireFox and Messages open, but minimized, but not always and it doesn't seem to make any difference. Unless OSx is still trying to communicate without an Internet connection I don't see where these sort of programs could be an issue. Week before last I had closed down all apps except Audacity. Increased the recording buffer to 200 and the first recording was bad - It's always before been good on the first recording of the day. Changed the buffer size to 75 and the second recording was good whereas in the past it was always the second recording that was bad. Then last week started out with a buffer size of 50 and the first recording was good and the second recording bad. I'm running out of hair to scratch these days.

Cliff

cmac185 wrote:

Could you please specify the exact models Mac you are using?

Mine - the problem one: Mid 2009 MacBook Pro Core Duo 2.66 GHz, 8GB RAM MacBookPro5,3 MB985LL/A

Two others that record without problems:
Wife's - Mid 2010 MacBook Pro i7 2.66 GHz, 8 GB RAM MacBookPro6,2 MC373LL/A
Son's - Early 2008 MacBook Pro Core Duo 2.54 GHz, 4 GB RAM MacBookPro 4,1 MB133LL/A

Thanks. None of these are in the suspect range, so I'd guess it could be the OSX version?

FYI, Sound interface is purely analog...

OK that rules out interface problems.

At the time of recording there is no Internet access...

I don't see where these sort of programs could be an issue.

So did I. Until I noticed that some tasks (Time Machine, f.i.) still are active and caching stuff to harddisk.

And some of these tasks are really stubborn. There''s a sharing kernel extension that talks to icloud and it prepares such a cache. Even if you don't use icoud.

Week before last I had closed down all apps except Audacity. Increased the recording buffer to 200 and the first recording was bad - It's always before been good on the first recording of the day. Changed the buffer size to 75 and the second recording was good whereas in the past it was always the second recording that was bad. Then last week started out with a buffer size of 50 and the first recording was good and the second recording bad. I'm running out of hair to scratch these days.

Cliff

I know the feeling

Are you familiar with the Terminal?

None of those Macs are quadcore machines, which eliminates hyper threading problems. But YMMV these days.

I'm just testing an older 8/8 interface. It's perfectly working on Tiger, Snow (with a minor interface tick) and works with some Macs under Mavericks with serious dropouts every now and then. Doesn't work at all under Lion, ML or Yosemite...

To sum it up: PPC version OK. Intel version dead, murdered by Apple.

The interface came back from service with a note "short circuit".