Onboard vs. PCI sound and LAN

[Adcadet]

Hey all -
so as many of you know I recently rebuilt my main machine. I decided to use my old(ish) SB Live sound card and disabled the onboard AC97 audio thinking that this would relieve my CPU of much of the sound duties and give better sound. On the other hand I went with the onboard LAN (which happens to be GigaE) since I figured there was absolutely no reason to put in a PCI card. Is there any advantage of using a PCI LAN card (like my old Netgear FA311)? I assume the onboard LAN connects straight into my PCI bus just the same as the PCI card does. And I assume the LAN chipset is about the same as my PCI one, in contrast to AC97 audio which only has basic sound functionality and requires the CPU to do much of the computation. Please correct me if I'm wrong, and comments welcome as usual.

Off to study micro and immu!

Adcadet

 

[sechs]

Sounds right.

I recall reading some review of various ethernet NICs with the determination that performance was more dependent upon the driver implementation than the use of any particular chipset. So, as long as you get reasonable drivers, there's no reason to not go with the onboard.

 

[LunarMist]

I assume the onboard LAN connects straight into my PCI bus just the same as the PCI card does.

Adcadet

Not all chipsets have this limitation. If yours has CSA, then use the integrated LAN to reduce traffic on the PCI bus.

 

[Bozo]

I recently upgraded to a new box. I'm using both the onboard NIC and sound. Haven't had any problems.
With a much faster CPU, more and faster RAM, and faster bus speeds, the sound computation is nothing more than a pimple on the CPU's a$$.

But, I don't listen to music much on the PC. I use a dedicated stereo for that.

I believe the on-board NIC is also faster, but that just might be 'perception' rather than fact given the upgrade. PIII 800 to a P4 3.2.

Bozo :mrgrn:

 

[Mercutio]

Bad thing about AC97 audio: Part of the spec is an internal resample to 48kHz, even for samples which are already 48kHz, then a downsample to 44.1kHz for standard analog output.
I know AC97 is good enough for a lot of people, but working in the same school of thought as "don't recompress MPEG2 files", I don't think I'd want AC97 mangling anything I actually chose to listen to.

 

[blakerwry]

I thought that any modern sound card also was compatible w/ AC97. Are you sure you're not thinking of one vendor's specific implementation of AC97?

 

[Adcadet]

I thought that any modern sound card also was compatible w/ AC97. Are you sure you're not thinking of one vendor's specific implementation of AC97?

Huh?

 

[blakerwry]

http://www.intel.com/labs/media/audio/


from the turtel beach santa cruz specs:

Crystal DAC, 2-4-6 speaker surround, 2 AC97 2.1 codecs, VersaJack, all standard ports incl. game port, CD-ROM connector, etc.

from SB live:

48kHz recording from AC97 sample rate converted to 8 common rates to host memory

 

[Mercutio]

AC97 is nothing more than an I/O specification for a sound chip (e.g. RealTek, Via Envoy, Crystal Audio...). You can use any chip you want, as long as, for example, pin #30 - 46 on that chip output a 16-bit 48kHz PCM stream.

The upsample to downsample deal is a lot like trying to add quality while editing a JPEG: it doesn't work that way, and I don't know why AC97 wants things that way.

 

[CityK]

Does anyone know why AC97 does this 48KHz resampling? Why on earth would the specification not handle 44.1?

 

[blakerwry]

why would you want to output at 44.1 when you can do it at 48kHz?

This is only for the digital to analog conversion, so it only effectys what is actually getting sent to the speakers.

 

[Pradeep]

The point is that in the 44->48->44 conversion, you are losing quality/introducing artifacts. If AC97 just left the bloody 44 alone, there wouldn't be any loss.

 

[blakerwry]

then it would make sense not to use AC97 if dealing only with 44.1 audio and needing to output it to speakers or another device.

if processing the audio internally this is a non-issue.

if dealing with 48kHz this is a non issue

are you sure that the sound is actually downsampled to 44.1 after the 48KHz conversion?

 

[CityK]

why would you want to output at 44.1 when you can do it at 48kHz?

- As Pradeep points out, you want to avoid the situation of having 2 sampling rate conversions in series.
- If the the device downstream doesn't have a built in sampling rate converter, and is expecting a 44.1 sampling rate, the outcome is?
- other reasons??? mmmm, 44.1 was standard for a while. Why create the incompatibility?

are you sure that the sound is actually downsampled to 44.1 after the 48KHz conversion?

yes

 

[Mercutio]

A better question than "why would you want to listen to 44.1kHz upsampled to 48kHz when you can listen to unadulterated 44.1?"

A lot of devices that handle digital audio expect a 44.1 digital stream. e.g. Stereo component CD burners, minidisc recorders.

AC97 is not cool if you really care about Audio.

 

[blakerwry]

aren't we talking about DACs here?

if so that makes alot of these statements moot

 

[Platform]

CSA, Communications Streaming (or Communications Screaming) Architecture, allows vastly better Ethernet performance than a GbE card plugged into a PCI slot, because with CSA you have the Ethernet controller tied directly to a dedicated bi-directional 2Gb/s channel to primary memory in the system memory controller. It doesn't get any better than that.

 

[blakerwry]

... PCI-X currently offers 4x the bandwidth of CSA.

Or take VIA or SiS's connection between the northbrige and southbridge. A Gigabit ethernet controller integrated into the southbridge would have much more bandwidth than the puny intel offerings.

 

[blakerwry]

why is that here anyway?

 

[i]

...and where can I get a network card that utilizes it?

 

[Mercutio]

aren't we talking about DACs here?

if so that makes alot of these statements moot

The upsampling is a digital-to-digital conversion that happens before a DAC gets ahold of anything to convert.

Your data arrives pre-mangled, so to speak, even if it's being shot out a SPDIF to an external DAC afterward.

 

[blakerwry]

AC97 is a standard for a DAC, if your sound card mangles digital to digital then I'd say that's a problem with the impementation of your sound card and no fault of the AC97 standard.

 

[CityK]

Speaking about crappy onboard sound, this Realtek codec looks miles above the typical AC97....

 

[Mercutio]

AC97 is a standard for a DAC, if your sound card mangles digital to digital then I'd say that's a problem with the impementation of your sound card and no fault of the AC97 standard.

... and therein lies the problem. AC97 receives 44.1 input from, say, an audio CD. This is digital if it's coming through audio extraction or a SPDIF cable. It immediately converts that digital stream to 48kHz. This is the mangling. Once the conversion to 48kHz has been completed, the sound passes out in whatever format it's needed in - analog (there's your DAC) or via SPDIF (still digital). AC97 isn't a DAC, it's an interface specification.

 

[GIANT]

... PCI-X currently offers 4x the bandwidth of CSA.

It doesn't matter how fast half-duplex PCI-X is because CSA gives you direct access to memory through a dedicated 2 Gb/s full-duplex channel. 1 Gb Ethernet isn't ever going to gain any additional throughput communicating through a pipe with more than 2 Gb/s. In this case, you are cutting out a few hops within the host computer for networking communications.

Or take VIA or SiS's connection between the northbrige and southbridge. A Gigabit ethernet controller integrated into the southbridge would have much more bandwidth than the puny intel offerings.

Well then, just what are Intel's puny offerings?

...and where can I get a network card that utilizes it?

There aren't any CSA NICs. CSA is a feature built into the i875 memory controller. You have a GbE medium interface (just a comm transceiver + buffer) on the mobo which is hard-wired into the CSA port.

If there were a lot of network mediums to deal with besides copper Ethernet, you would see a riser card slot capable of interfacing to various fibre and copper network mediums instead of a GbE connector soldered to the mobo.

 

[blakerwry]

Or take VIA or SiS's connection between the northbrige and southbridge. A Gigabit ethernet controller integrated into the southbridge would have much more bandwidth than the puny intel offerings.

Well then, just what are Intel's puny offerings?

intel currently uses the intel hub arcitecture that runs at a blazing 266MB/sec between the NB and SB.

That's for two 150MB/sec S-ATA channels, two 100MB ATA channels, 6? USB 2.0 controllers, and one PCI bus.. and the other devices of the superIO chip (LPT, serial, PS/2, etc).


2*150+2*100+6*60+1*133 > 266

intel needs CSA.. the others don't. Both VIA and SiS offfer 1Gbyte/sec links between the NB and SB. When gig-e gets integrated into the SB on these chipsets then I see absolutely no advantage to the intel's CSA. When PCI express comes to the desktop I will see no advantage to intel's CSA.

Right now intel is enjoying CSA because no one else is integrating Gig-e into the SB. If you need gig-e right now on the desktop, the intel 865/875 are your chipsets.. Not because of any miraculsous technological improvement, but simply a more practical design when it comes to networking.

CSA seems to be a temprorary way to implement gig-e effectively and cheaply in todays desktop boards.

 

[Jan Kivar]

I'd like to add that some i865 boards, which have a Gbit chip onboard, don't use CSA. So the chip is actually connected to SB/PCI. Which increases the bottleneck Blake pointed out.

I think that CSA is only compatible with Intel Gbit chips.

Cheers,

Jan

 

[Onomatopoeic]

I'd like to add that some i865 boards, which have a Gbit chip onboard, don't use CSA...

Well, obviously, since they aren't i875 chipsets. The i865 ("Springdale") chipset doesn't have CSA.

...I think that CSA is only compatible with Intel Gbit chips.

CSA is only implemented in an Intel chipset -- the i875. That (CSA) was one of items in the big headline splash a while back when "Canterwood" was introduced.

 

[Onomatopoeic]

intel currently uses the intel hub arcitecture that runs at a blazing 266MB/sec between the NB and SB.

Who? What? Traffic between North Bridge and South Bridge? I'm talking about CSA.

As I was saying earlier, CSA has a dedicated 2Gb/s direct path to memory via the memory controller. In the Intel Architecture, the memory controller has always been located in the North Bridge. You simply can't do better than having your network transceivers so close to primary memory. The implementation of CSA has far lower latency and better throughput than any Via or SiS solution.

intel needs CSA.. the others don't.

If anything, Via and SiS only wished they had CSA! Maybe they will sooner or later.

 

[Jan Kivar]

I'd like to add that some i865 boards, which have a Gbit chip onboard, don't use CSA...

Well, obviously, since they aren't i875 chipsets. The i865 ("Springdale") chipset doesn't have CSA.

Um... looks like my train of thought de-railed on that post. I meant i875 chipsets...

...I think that CSA is only compatible with Intel Gbit chips.

CSA is only implemented in an Intel chipset -- the i875. That (CSA) was one of items in the big headline splash a while back when "Canterwood" was introduced.

I meant that i875 supports only Intel Gbit chips, not from 3Com or Broadcom etc., or at least that's what I believe.

Cheers,

Jan

 

[Onomatopoeic]

OK. I went diggin' around Intel and found a picture.

This is why CSA spanks every other existing system network implementation in the Intel Architecture world: No bottlenecks! 2 Gb/s full-duplex direct memory access! No hops / no latency problems!

 

[time]

I think you meant 2GBytes, not 2Gbits?

Unfortunately, I don't agree with your conclusions. I think you misunderstood Blake's well-reasoned argument that this is a 'band-aid' solution from Intel (not to say it won't work extremely well, just that it's quite unnecessary for the other chip manufacturers).

You are almost certainly correct about the lower latency; however, surely that's a moot point when the Gigabit Ethernet latency might be as much as two orders of magnitude greater?

In any case, I don't see how lower latency will necessarily lead to higher throughput - especially with normal packet sizes. And I have no idea what you mean by "hops" in this context. :-?

I am now hiding in a SuperMicro-proof bunker.

 

[blakerwry]

CSA seems to be a temprorary way to implement gig-e effectively and cheaply in todays desktop boards.

my point stands.


CSA is another bus that comes off the NB, just like the AGP bus is a dedicated bus for graphics, and there is a dedicated memory bus, and there is a dedicated bus between the NB and SB.

Typically, all Input/output devices(IDE, SCSI, LAN, Printer, serial, etc) go in the southbridge or the PCI bus.

Since all the I/O devices are in the SB, it makes sense to give them a high bandwdith low latency connection to the NB (and from there to memory or CPU).

SiS, Nvidia, and VIA all have these high bandwidth, low latency buses between the NB and SB (SiS having taken the lead a while back, but the others catching up). Intel has a reletively slow link that runs at 266MB/sec.

Since Intel has this slow link, rather than designing a new bus, they designed their new NB (the 865 and 875) to have an additional bus hanging off of it. From what I've read CSA operates at the same speed as The intel hub arcitecture already used to link the NB and SB... it's probably very similar.


The use of multiple independant buses can reduce latency, but it's not as easy as comparing A to A+A. You are comparing SiS's MultiTol or VIA's V-Link to CSA+IHA. Comparing low level aspects, VIA and SiS win on bandwidth and latency compared to CSA+IHA.


Gig-e will be integrated into the SB soon enough, and PCI express will be integrated into the SB later this year.

At that time VIA and SiS will already be ahead of the game. Intel is going to need a new SB(which I'm sure is alreay in the works), and a new bus (which wont be as mature as SiS's technology which has already been out for several generatesion or VIAs who will have been out fo atleast another generation by that time)

As such, yes, Time got it right. CSA is a "band aid". It works for now. If you need gig-e now, then get CSA.

 

[GIANT]

I think you meant 2GBytes, not 2Gbits?

No, I definitely meant 2 Giga bits (per second); that's 1 Gb/S upstream and 1 Gb/s downstream. A single GbE connection isn't going to gain anything by being plumbed into a fatter pipe than it could ever possibly use (2 GB/s). Even a 2 Gb/s (full duplex, of course) is more than enough, statistically speaking.

Unfortunately, I don't agree with your conclusions. I think you misunderstood Blake's well-reasoned argument that this is a 'band-aid' solution from Intel (not to say it won't work extremely well, just that it's quite unnecessary for the other chip manufacturers).

Jeez, have I ran into some sort of luddite subculture here? :-? I guess next, we'll hear how Hyper-threading is not an advancement, but a band-aid because Intel's processor are too slow. Ditto for InfiniBand, SATA, SAS.

You are almost certainly correct about the lower latency; however, surely that's a moot point when the Gigabit Ethernet latency might be as much as two orders of magnitude greater?

As far as what happens over the network wire, it can, of course vary greatly. But I'm mainly coming from the angle that if you've invested in good hardware (like a dedicated port non-blocking Cisco GbE switch hardware) and have good cabling infrastructure, you're likely going to want to get the most out of what you have. Workstations with CSA are flat out going to give you more return on your investment -- provided that throughut is important to you. If throughput is not important to you, then you might as well go with low-bidder stuff. More interestingly that just GbE, CSA could be ramped up to support IP SAN in the near future.

...And I have no idea what you mean by "hops" in this context.

Lingua franca for "stages." And, by the way, this is within the silicon of the chipset. Signal propagation will be demonstratively factor in the overall performance capability every time your data gets on the bucket brigade to its destination. Reduce the number of "hops" (stages) along the way and you will increase performance.

 

[blakerwry]

Jeez, have I ran into some sort of luddite subculture here? I guess next, we'll hear how Hyper-threading is not an advancement, but a band-aid because Intel's processor are too slow. Ditto for InfiniBand, SATA, SAS.

CSA works fine, but it's a temporary solution. In 6 months I doubt intel will still be using CSA. It's just more of the same stuff... not any technical advancement. From what I can tell it was only meant to be around for a generation or so as a temporary measure before we either 1) get gig-e into the SB or 2) get PCI-E.

S-ATA was meant to completely replace P-ATA, SAS meant to replace SCSI. PCI-E to replace PCI/AGP. USB2 to replace USB1.

There's an important difference here.