Reclaiming SATA for audio

I apologize up front for such a long post, but it covers a fairly deep topic which requires a lot of explanation. I did my best to make a long story short wherever I could, and placed links for deeper reading elsewhere. Still, it's definitely not the shortest post in the world, not by a long shot!

I have had some good success recently solving a thorny problem with clicks and pops while using SATA drives for audio. You'll find the gory details of my saga posted here, but I'm posting the "short" story here because:

• I am a fellow SONAR 3 Pro user
  
• Other posts in this forum greatly helped to identify the true nature of the problem, and thus, a workable solution
  
• Perhaps this post could help others in a similar predicament to dust off their SATA drives and reinstate them to useful audio service (which would be gratifying for me to know).
  

My configuration is as follows:
ASUS A7N8X Deluxe, Athlon XP 2500+, 1GB RAM Dual-Channel
Enabled onboard peripherals: nVidia LAN, nVidia audio (for system sounds), Firewire, USB (all)
ATI RADEON 9000 Dual-Head
Seagate 80G PATA System Drive
2X Seagate 80G SATA RAID 0 Audio drives
Terratec EWS88D, connected via ADAT to...
...Fostex VM200 Digital Mixer

After some fussing, I have successfully managed to take this system from a glitchy nightmare (even with a measly two tracks) to being able to simultaneously monitor 36 tracks, evenly split through all eight outputs on the soundcard, all while recording on all eight soundcard inputs to eight more tracks, and all without a single glitch!!

Here is the recipe that worked for me (and maybe could work for you):
1) Start where you finished off before. Resolve all IRQ conflicts, and be sure to place your audio card in a non-IRQ-shared PCI slot. Look in the PCI table of your motherboard manual for the highest-priority slot that does not share with another device or another slot. (For the A7N8X Deluxe, the PCI table is on page 17. You should use PCI Slot 4, preferably with no other slots filled.) Don't worry about taking your computer off of ACPI. Judging by other posts, it doesn't make any real difference. I have ACPI enabled and it works fine for me.
2) Install and learn to use SiSoft SANDRA. This utility reveals secrets about your machine that you never knew existed. Lots of other great performance-testing stuff, too. The PCI info tool will be very useful for verifying the values of the PCI latency timers (more on that later) for every device that hangs on the PCI bus, either logical or physical. (BTW, some of the logical ones will surprise you, too, like the AGP controller for instance.)
3) Install and learn to use a good PCI utility. I do recommend one near the end of this post. If you're interested enough, then read on...

The SATA glitching problem has been discussed at length elsewhere in the Cakewalk forums and in others as well. In short, it manifests as annoying glitches (pops and clicks, but not to be confused with dropouts or stutters) either in playback, recording, or both. The glitches cannot be resolved by any of the standard means, i.e. isolating IRQ's, swapping slots, adjusting audio buffer latencies, yelling at tech support etc.

The problems are typical for systems configured with:

• an early-design motherboard (i.e. with the nForce2 chipset) featuring onboard SATA, and
  
• a PCI card for audio I/O, and
  
• a SATA (or SATA RAID) drive for audio.
  

The problem has been explained as follows. These earlier SATA motherboards implemented their SATA interface using a controller chip separate from the processor's chipset (on mine, it's the Silicon Image SiI3112). Such SATA controllers are hardwired onto the PCI slot bus, and as such, they must share bandwidth with any and every other PCI card plugged into a PCI slot on the motherboard. Later motherboards integrate the SATA controller into the Southbridge of the processor chipset, and so do not appear to show this problem. Technically, the entire PCI slot bus must communicate with the CPU through the PCI-PCI bridge controller, which in turn bridges the internal high-bandwidth PCI bus to the external one with physical slots running (typically, now) at 66MHz. This causes a bottleneck for high-demand PCI devices like the SATA drive, which then tend to choke the PCI bus from other devices, particularly the sound card, thus leading to the glitches. The problem is fundamental to PCI bus communication and as such, it goes deeper than your typical IRQ and buffer settings.

Like other posts to this forum, I found out too late that my configuration fit this profile perfectly. My system exhibited the same steady stream of random pops, clicks, and other garbage while monitoring recorded audio from the SATA RAID drive set. At first I just threw my hands up in disgust, but not long afterward I started digging for a solution.

Frankly, such a design limitation really stuck in my craw as a professional researcher. Besides, I knew that the numbers just didn't square up: PCI 66MHz = 66 Msamples/sec at 32 bits/sample = about 1500 tracks at 44.1kHz/32bits (accounting for 24bit samples "unpacked" into 32 bits). Of course, the disk drives themselves would top out way before that (SATA, RAID, or otherwise). Rather, this astronomical number is the theoretical maximum for the external PCI bus itself (bridge controller included) with 100% bus usage by one device, going one way only. So, in terms of raw bandwidth the 66Mhz PCI slot bus is far from a bottleneck, in principle at least. Way far. Adding the audio card only adds a relative few "effective" tracks, even if its I/O capacity is maxed out (in my case, 8I/8O for ADAT).

So, just exactly where is the beef? How do we account for the discrepancy? In general, the major source of overhead for buses lies in how the various devices sharing the bus cooperate with one another. Think of a bunch of kids taking a drink from a water fountain. Plenty of water for everyone, but the kid at the front of the line with the mouthful of water needs to get out of the way for the next kid in line, or the whole thing grinds to a halt. The SATA controller is like the big kid in front who just won't get out of the way.

So, how to solve this dilemma? I actually stumbled upon a solution that worked for me (and hopefully, for you too). I have yet to hear about anyone else repeating success with this particular problem, besides myself and some gamers. I'm sure I'm not the only SATA audio head that can be helped by this.

The secret for me was revealed by none other than Silicon Image's tech support (that is, after they spoke with their software engineers). It revolves around what are called PCI latency timers. Scouring the web turned up a lot of interesting info on this intriguing, important, and neglected topic. (One of the better examples can be found here. You'll find some fascinating material if you read past all of the gaming talk.)

In short, these low-level timers are part of the PCI specification, and regulate how long any PCI device is allowed to lock the PCI bus before yielding control to the next device requesting bus access (e.g. through the IRQ mechanism). The values for these timers range from zero to a max of 255. Zero means the device is extremely cooperative, and 255 means, basically, that it is a PCI hog. The value of this timer relative to those of all other PCI system devices therefore has a huge impact over how the bus will be shared by all other active devices. Now some points:

• Some BIOS's provide settings for these values, and some don't. If they do, it may be for only a limited number of onboard controllers, usually the AGP controller.
  
• There is no industry standard for the default values of these timers. Most motherboards, to be as universal as possible, just pick a number out of thin air.
  
• (This point trumps the other two) BIOS settings are allowed to be, and for the most part are, overwritten by device drivers, to whatever value the hardware manufacturer thinks is good for them. Since performance is maximized with high values, you can guess that these values will be set as high as they think they can get away with. For example, AGP cards usually show up just under 255.
  

Being able to access these timers opens up an entirely new level of control over the flow of time-critical data through the system. So the logical, pivotal question is: How do we get at these timer settings?

A lot of freeware utilities are available on the web, here and here for Win9X/Me and here for Win2K/XP. But instead, I recommend a shareware utility called PowerStrip since it is much more user-friendly and provides access to various "locked" timers. Also, it does a good job integrating with Windows seamlessly; for instance, it can be configured to run automatically at startup. As Martha Stewart would say, that's "a good thing", because otherwise the timers will be set back at their good old values by the device drivers as they load.

I also recommend that you read up on how to use the PCI utility. Good info here, and PowerStrip has a user forum. Generally, the philosophy is to set the latencies high enough to get the needed performance, and no higher. To give you an idea, the default bootup timer settings on my system were as follows (as conveniently reported by PowerStrip):

RADEON 9000 Output 1: 248
RADEON 9000 Output 2: 32
Terratec EWS88D: 32
SiI 3112 SATA: 32

The 248 on the graphics 1 was too high, and the 32 on output 2 was too low. (Yes, it can be too low. Setting the graphics to zero in my case resulted in repeatable dropouts in SONAR, just because the graphics couldn't keep up.) Also, the Terratec and SATA had the same values. Tweaking for optimal performance with two tracks resulted in these settings:

RADEON 9000 Output 1: 88
RADEON 9000 Output 2: 88
Terratec EWS88D: 32
SiI 3112 SATA: 16

Those settings carried through to the 44-track glitch-free scenario described at the top of this post. Well, if you've been patient and/or interested enough to read this far, then I know that you're patient enough to try some of these fixes! If you do manage to reclaim your SATA/RAID drive for audio, then post and let me (and I suppose, the rest of the world) know that it worked. If not, well, I guess that would be useful information, too. But surely, I couldn't be the only person that this works for (besides gamers, that is)?

losguy,

That's some interesting info and got me experimenting with PowerStrip and PCI Latency settings. Because I tend to use of lot of softsynths and samplers, I'm finding that I need a higher latency setting for my sound card (Echo Layla24) compared to the settings you arrived at. But I am able to fine tune better performance by adjusting the PCI latencies with this utility, so thanks tons for sharing all this info.

Also using the Asus A7N8X deluxe board with the SATA (though no RAID) as an audio drive. But expecting to move to a newer board where the SATA is no longer on the PCI bus. :)

jeff

Great info losguy - I will investigate when I get a chance. I use a firewire hardrive, not SATA but you never know what you may find :)

Eric

Geez,

I need to not eat for a few days so I have enough room to digest all that! Strong work.

todd

I have had some good success recently solving a thorny problem with clicks and pops while using SATA drives for audio.

I admire your perseverance and thank you for your post. I have an Abit NF7-S (nVidia 2) which was giving me exactly the same problems. Downgrading latency on the Sil3112 SATA card to 16 cured the pops and crackles. It wasn't causing a problem before as I still have 2 big IDE drives in that machine, but you've now allowed me to use my 160Gb SATA drive for audio instead of storage. Very cool.

Thanks very much.

(For the A7N8X Deluxe, the PCI table is on page 17. You should use PCI Slot 4, preferably with no other slots filled.)

Great work losguy!

I have the A7NX8-DL 1.06 and also a P4C800-E. I'm afraid I'm stuck back at what PCI slot to use. I have the manual pages in front of me entitled; "IRQ assignments for this motherboard" and I still can't figure out how to read the tables so I can follow how you figured out that Slot 4 is best to use. I would appreciate some advice on how to interpret the tables.

Thanks.

ORIGINAL: Scott Reams
Remember that most motherboards, including your A7N8X, have a 33MHz/32bit PCI bus. 66MHz and faster PCI is typically found on higher-end workstation and server boards. The -theoretical- bandwidth of 33MHz/32bit PCI is 133MB/sec. In reality, it typically won't do much better than 100MB/sec.

This equates to about 750 audio streams at 44.1KHz/24bit. These would include those being read from a disk on a PCI controller... those being sent to an audio card on the PCI bus, and those being sent to and from a card like the UAD1.

Obviously this is still far more than anyone needs.

Thanks for the reality check, Scott. I stand corrected. (Actually, I rewired my PCI bus to run DDR. And my soundcard, too. No, really, I did! ) Seriously, even so, it's clear that the external PCI bus can in principle easily support plenty of audio. No problem, it's good to clarify...

Question... Out of curiosity, why did you determine that the Terratec and the SAT controller having the same values was a bad thing?

Nothing earth-shattering, really. It just crackled when the audio controller was less than or equal to the SATA controller. Sorry if I was a little nebulous there (and elsewhere, for that matter). I tried to steer clear of making too many sweeping statements because of the variety of system configurations out there, and the strong dependence that results will have on specific hardware and drivers, let alone combinations of those. You know, mix to taste, YMMV...

Also, it seems that the high values for your video card should not be a problem... since the AGP bus has no other devices on it (the PCI bus is independent of it). There is nothing else to share the bus with. The only thing one might want to do is distribute the timing between the two outputs better... but I think I know why they chose to balance it the way they did. Radeons and GeForces are primarily 3D accellerators... and most games utilize output 1 only. Output 2 typically only handles 2D graphics, and shouldn't need as large a timeslice.

You make good points. It's hard to argue with you, at least in theory. The only thing that I can offer is that it worked better for me by lowering and balancing the two AGP outputs. Heck, I'll take the total absence of crackles, even if it does upset a few apple carts!

But I'd still love to entertain thoughts on an explanation. One possibility could be that despite the AGP controller/bridge being independent of the external PCI bus controller/bridge, they eventually must all communicate with the same CPU. So, is internal PCI bus 0 not a common channel? If it is, then it would seem to me like a slam-dunk. High speed or not, if anything hogged a common channel for whatever reason, that would seem to be enough. Anyway, you're right, it's still a bit of a mystery...

This post was amazing. Many thanks. You laid this out the way only someone who is seriously immersed in the topic could. I've spoken to many tech support people on this subject who could not approach the level of detail you demonstrated here. Your post is sincerely appreciated.

I have an ASUS A7N8X-E Deluxe motherboard with two Seagate SATA drives. I suffered from the same problem with the M-Audio Delta 66 card I was using. After multiple hours of pulling my hair out, I bought a Western Digital ATA-100 HD to use as my audio drive and that fixed the problem. The crackling was driving me nuts.

I am going to check out that PCI latency utility and see how it works. Thank you again, losguy. Job well done.

Tom

Yup good post. Always good to do your homework. Only way I would go with SATA is PCI based.

Best,

ORIGINAL: Jay Stephen
...
I have the A7NX8-DL 1.06 and also a P4C800-E. I'm afraid I'm stuck back at what PCI slot to use. I have the manual pages in front of me entitled; "IRQ assignments for this motherboard" and I still can't figure out how to read the tables so I can follow how you figured out that Slot 4 is best to use. I would appreciate some advice on how to interpret the tables.
...

PCI IRQ Tables... I'll go ahead and provide some detail here since this made some difference in my system. Also, it could help in general, to dispel some of the mystery surrounding which PCI slot is best to use for what on your motherboard. I'll mostly talk about my particular motherboard (an ASUS A7N8X Deluxe), but I expect that the process for other motherboards will be similar. If you want the ultimate rundown on this topic, go here. Unfortunately, I can't upload the image for the IRQ table on this motherboard, but for reference purposes you can find it here, in your choice of language. You will find the PCI IRQ Table at the top of p.17 of the English version.

Across the top of the PCI IRQ Table are headings for INTA, INTB, INTC, and INTD. These correspond to low-level IRQ lines that are hardwired between the PCI controller and the PCI slots. Recall that the PCI controller, sometimes called the PCI-to-PCI bridge, funnels PCI communication between the PCI slots and the CPU. These low-level IRQ's map up through the PCI controller, via the ACPI/IRQ Steering arrangement, into the higher-level IRQ's that we all know and love, e.g. the ones that you see in the device manager. They're called INTA-D so as not to be confused with the higher-level ones. (Like Dr. McCoy said once, "It's like child's play." Don't you agree? )

Anyway, along the left of the table are listed the PCI slots, along with anything else that's hardwired to the PCI controller. In my case, that includes the SATA controller. Inside the table you'll find entries saying "shared" and "used". A "shared" entry means that the corresponding INT is shared with at least one other device. Sharing a low-level IRQ is worse than sharing a high-level IRQ, because it's hardwired and so it can't be altered, no matter what Bill Gates throws at it. Looking down the INTA column, you'll see that INTA is shared between PCI Slots 1 and 5. In similar fashion, you'll also see that INTC is shared between Slot 3 and the SATA controller. Now, a "used" entry in the table is actually a good thing, because it means that particular INT is wired to only one slot and/or device. So, you'll find that INTB is used by Slot 4 and nothing else, and that INTD is used by Slot 2 and nothing else.

So, with this arrangement, Slot 3 is the absolute worst slot you could use for a soundcard, because you're forcing IRQ sharing between the soundcard and the SATA controller. Slot 1 or 5 should be OK, but don't use them both, that is, except for cards that you don't mind sharing an IRQ. Also, keep in mind that Slot 1 is next to the AGP card and could pick up noise. That leaves Slots 2 and 4 which ensure a single IRQ.

Now I did a little guessing. Based on prior experience with hardware priority assignments, I have a hunch that the INTA through INTD are in order of decreasing priority. Based on that assumption, Slot 4 would have higher priority than the SATA controller, and Slot 2 would have lower priority. So, Slot 4 it is.

(I haven't verified this priority-assignment theory, and it may be all wet, but again, it worked out great that way for me. I also got report of someone else with this motherboard, with glitch-free SATA using PCI Slot 5, which at least does not debunk this theory.)

In general, then, the recipe is simple: Just look down the INTX columns of the PCI IRQ Table and find the highest-priority, non-shared slot that you can live with. Hope that helps!!

Hi Thomas Campitelli - Thanks for the compliments. I notice that you also have and A7N8X-E DX MOBO. You may want to have a look at the last few posts, to maybe circumvent some potential pitfalls with PCI slot selection, particularly with your MOBO.

General note... while you're experimenting, it may be best to depopulate all PCI slots except the soundcard that you're trying to make work. Once you're (hopefully) glitch-free with SATA, you could try carefully adding other cards back (if you must). This procedure could help isolate contention problems between cards as well.

losguy--Thanks for the very clear interupt/slot priority explanation. I got it!(finally)

So much to know about my hardware and all I ever really wanted to do was lay down some tracks!

Now, is there someplace I can go to make sure I have all my S3 settings(buffers, read/write cache, etc.) and my bios settings (shadow, cache, etc.) optimized?

I have the A7NX8-DL but my prime system is an ASUS P4C800-E.

Many thanks again!

I'm currently in the process of building a vst pc,

What's a "vst pc"?

and was going to get a Motherboard with SATA to make it more convenient. After reading this now, someone said up there that the new Motherboards with onboard SATA don't have these problems now. My question which are these "good" Motherboards...examples would be greatly appreciated. Thanks.

Intel's latest P4 chipsets and Via's K8T800 for Athlon64 have integrated SATA that does not consume PCI bandwidth.

-S

Ah... gotcha...

I am not aware of any AthlonXP chipsets that provide integrated SATA.

-S

Hi vtd,

Since you asked "How...", the best answer that I can give you is this short recipe (good at least for today):

1) Find a motherboard that you like with SATA support, and make sure that it is either an Intel P4 or an AMD Athlon64 MOBO.
2) Look past the overview page, and go however deep you need to go to find the "real" specs page.
3) Make sure that the SATA is implemented as part of the CPU chipset, and not with a separate controller chip. If you must, use the A7N8X as a counter-example.

Of course, even if you did choose the wrong one, this thread could help you turn a wrong one into a right one!

Also, if you go back to the top of this thread, you'll find that the problems show up primarily with a PCI card in combination with SATA. I'd love to hear from anyone/everyone out there on whether or not they are having problems with SATA while using USB or Firewire for audio I/O. I would suspect that the number is much lower, or the problems (if there even are any) are due to other things particular to those buses. Anyone?