Mysterious Gaps

I'm working on a couple of album projects, recorded the LPs to my computer and am editing them to make CD-Rs (albums never made available on CD).

My new iMac is so powerful that, unlike all my previous boxes, it seemed to do fine doing two things at once, like viewing e-mail while recording the music.

Oops.  I just noticed, in the last album I did this, tiny little gaps (about ten samples wide) where the audio defaults to zero amplitude before resuming.  Apparently, the CPU was busy doing something else while this audio was coming in and rather than caching it just skipped over it.  I have HUNDREDS of these teeny-tiny gaps in the song I'm working on.

Lesson learned!

Here's a question for the technicians among you.

The gaps seem to come in sets of six closely-spaced gaps. One big one (ten samples) followed by five smaller ones of about 3 samples each.

Whyzzat? Write, verify, uh, tag & confirm?

You didn't buy the music from iTunes, so you're being punished by Steve's ghost.      

Are the gaps in a file that you created, or only on a CD?

In the file. Steve is dead, BTW.

NoCoPilot wrote:

Steve is dead, BTW.

Well, DUH. Otherwise his ghost couldn't fuck with your files.

Is there a consistent interval between the groups of gaps?

You've got an i5 processor, don't you? Or maybe an i7? Either is more than capable of processing your recordings while doing many other things.

Did you check your source files to see if the gaps are there? Might be helpful to know if the gaps were created during the original ripping of the LPs.

Yeah that's what I'm assuming. I was doing other things while I was ripping the LPs.

So you see the data errors in the files that came straight from the LPs?

How are you connected to the turntable's output?
If it's a USB connection, that may be causing the problem.

You've ripped LPs before with no problem, haven't you?

Are you using the same audio editing program that you used before?

The only difference is doing something else at the same time.

CPU cycles in use, I'm guessing.

I can't believe that your iMac doesn't have the power to do many things at once. That's the last place I would look for the problem. On my old computer I would rip DVDs while doing other things, even video editing. Your new machine has a lot more power than my old one.

Is it just the one song that has gaps? If so, it might be the LP.

Or it might be your stylus or cartridge. It might be your USB port. It might be the software (that's the first place I would look).

Can you swap out your ADC?

It's not the LP or my turntable.  The nature of the gaps is pretty stark -- there's signal going along, then Oliver Sudden the bits are zero amplitude, then Oliver Sudden there's signal again.  These gaps are about ten samples wide, or 1/4400th of a second, so you have to listen carefully to even hear them.

But when I'm making CDs that's what I do, listen carefully.

I could probably use an external analog-to-digital converter, but since this problem has only popped up once -- when I was trying to do two things simultaneously -- I'm inclined to simply not do two things simultaneously again.

In all my previous computer boxes -- Mac or Windows -- you could not run anything else while you were capturing audio because it is very CPU intensive.  I thought maybe this box was different... but apparently not.

You may be absolutely correct, NoCo, but if I was debugging the problem I would not quickly conclude that CPU usage was the problem.

The way you describe the problem it sounds as though the signal is properly shaped but has some incorrect data - the "gaps." For that data to be there - whether correct or not - the program has to be running. By that, I mean that the multitasking has not caused the audio program to fail by skipping some data. If that was the case, then there would not be gaps: there would be missing data, not incorrect data, and the waveform would be compressed in the gap areas. Of course, that would not be visible to the human eye. The question is: why is there incorrect data?

Are you using the analog audio input port on the iMac? Does the computer have a built-in DAC? Surely it is not doing the conversion in software.

If you're curious, pop up the Activity Monitor and watch as you rip a song from the LP. I think you will find that the CPU is not stressed at all.

I hope you don't think I'm just trying to be a pain in the ass. I'm just curious. I spent so many years debugging software, and sometimes hardware, problems that I cannot sit idly by while a computer won't do what we want it to do.

On closer inspection, these are not gaps.

They are INSERTIONS of tiny silences into the existing waveforms.  When I zoom in and remove the zeroed-out bits, the waveforms on either side line up exactly.  There's nothing missing.

Now I really am confused.

I don't know if you can accurately tell whether the gaps are bad data or extra data. At a sample rate of 44,000, there would be an incredibly small difference in the samples on either side of the three-sample gap. Go into a part of the signal that has no errors but similar wave form and remove three samples. See if the wave form looks distorted to you.

The way you describe it, it really sounds like a small glitch in the ADC. If the program is not running consistently because of multitasking, you would have much more severe errors, and there would be no pattern in the errors.

I thought about how I would design a program for capturing the output of an ADC, and it involves very little CPU time. I think the Apple OS is too well designed to cause this problem because of using the browser or email program while grabbing an audio file. Remember, the ADC and the DMA chips are carrying the heavy load, not the CPU.

If you use the browser while grabbing audio, you are only adding one or a few more processes. If you look at the activity monitor, you will see maybe twenty or thirty processes that are sharing the time with the audio program. One or a few more won't be the straw that broke the Apple's back.

_Howard wrote:

I don't know if you can accurately tell whether the gaps are bad data or extra data. At a sample rate of 44,000, there would be an incredibly small difference in the samples on either side of the three-sample gap. Go into a part of the signal that has no errors but similar wave form and remove three samples. See if the wave form looks distorted to you.

I wish I could show you a picture.  It's worth 1,000 words.

Ah, here's a pretty good example online:


This shows several wavecycles missing.  I've had some like this, but mostly they're much smaller gaps with only part of a single wave missing.  If you take the beginning of the gap, and the end of the gap, and delete everything in between, the two halves line up exactly.

Here's what it looks like if a SINGLE BIT is missing:


Somewhat harder to spot.  You can tell it's a gap however because nothing else on either side is as rapidly changing amplitude.  And because of that, an anomaly of a single bit like this will be audible as a tick.

Maybe the explanation that goes with this graphic makes sense to you?

Quote :

What was strange about these samples was that they always seemed to happen at the beginning of my 256-sample block. I could understand if they were at the end, as that would mean that my block end pointer was off by one sample. But for the error to happen in the beginning would mean that my start address was off, and I was pretty sure that was not the case.

To make sure my understanding of the problem was correct, I hacked my audio_callback to always copy the second sample of the block to the first sample, and that did indeed get rid of most of the crackling. There was still the occasional crackling, which was yet another mystery.

After running the sample copying in the debugger many many times and never seeing anything wrong, I was about ready to give up studying this problem. Then, almost by accident, I suddenly caught the problem! Here is the actual log from my debugger window of the situation. If you want to spot the problem yourself, you need these bits of information:

   The memory address 0xa627b8 is in the the input buffer (created by the game into the DOS memory of the game itself) at the position where I need to start reading to fill the next 256-sample output block.
   The stepi commands run my SBEmulation code.
   The line 1608 is where I load the 8-bit sample value from the input memory buffer.
   The line 1620 is where I write the resulting 16-bit sample into the output buffer.
   I never write to the input buffer in this code.

(gdb) x/8bx 0xa627b8
0xa627b8:       0x84    0x7f    0x90    0x8d    0x7c    0x8d    0x97    0x87
(gdb) stepi
1608    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
1609    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
1611    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
1613    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
.sb_13_irq_cont () at /home/patrick/zerox86/source/ports_SB.S:1616
1616    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
1617    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
1618    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
0x005d4b6c      1618    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
1620    in /home/patrick/zerox86/source/ports_SB.S
(gdb)
sb_13_play_auto () at /home/patrick/zerox86/source/ports_SB.S:1608
1608    in /home/patrick/zerox86/source/ports_SB.S
(gdb) x/8bx 0xa627b8
0xa627b8:       0x96    0x7f    0x90    0x8d    0x7c    0x8d    0x97    0x87
(gdb)

If you looked at the log closely, you may have spotted that the input sample value at address 0xa627b8 was 0x84 when I started stepping through my code, but was 0x96 when I had copied it to my output buffer!

Since I was sure that my code never changes the input buffer contents, at first I just looked at this log with my mouth open, I couldn't understand what was going on! Until it suddenly hit me: Since zerox86 is multithreaded and I was stepping through the audio thread code, it must have been one of the other threads (most likely the CPU emulation thread where the game was running) that changed that memory!

Okay, now the problem began to make sense. If I report the position up to where I have read the samples from the input buffer to the game wrong, the game may well write new data to the ring buffer before I have managed to read the old data. The game uses the DMA position register to keep track of where the SoundBlaster card is reading the sample data. I adjusted my DMA position register to not point to the next sample I am going to read, but instead to the last sample I actually did read. That finally got rid of the crackling! This same problem may have caused crackling in other games as well, and also the fix for the first issue (audio gaps after sending an IRQ) may improve audio in several other games as well.

Source

Can you do a print screen and then crop out the problem portion and then post it?

The pic you posted is illustrative, but it's also at half your sample rate and has a hell of a lot more than three samples missing.

It's possible that the problem is in the program displaying the wave and that the file is okay. Just a possibility.

The second pic doesn't show bits missing - it shows bytes missing.

The guy's explanation shows an error in coding.

_Howard wrote:

It's possible that the problem is in the program displaying the wave and that the file is okay. Just a possibility.

The glitches are audible.

_Howard wrote:

The second pic doesn't show bits missing - it shows bytes missing.

Isn't a byte eight bits?

Yes, but the sample size for CD audio is two bytes (16 bits).

What's odd, to me anyway, is how these gaps cluster. It will go many thousands of bytes (up to a minute of audio) with no glitches then there will be one fairly big one (maybe 20 bytes), followed by a discontinuity spike about ten bytes later, followed by a series of smaller gaps (3-5 bytes) every 20 bytes. The "bouncing" can be a single occurrence or about ten in a row.

No pattern. That I have discerned anyway.

_Howard wrote:

The guy's explanation shows an error in coding.

Okay.  I probably need to run some tests, since this is the first time I've encountered it, and see if something's permanently broken or whether I just got a bad read on Mick Fleetwood's solo album. I KNOW I've never seen this error before (I've done hundreds of LP transfers).

NoCoPilot wrote:

What's odd, to me anyway, is how these gaps cluster.  

I just fixed one that was a single gap -- no brother gaps.

NoCoPilot wrote:

Okay.  I probably need to run some tests...

Is this the first time you've ripped LPs on the new computer?

If I may, try ripping the song that had a lot of gaps in it with nothing else running. If that turns out error free, play a DVD and maybe edit a photo - something to keep the CPU busy,while you rip the same song again. If that one is screwed up, then you'll know you were right all along: the CPU can't handle it.