Slashdot Mirror

It does. The part in the Pixel is(I think) a Qualcomm; but they are annoying as hell to get datasheets for; so these examples are Realtek:

Here are their I2S codecs(what you'd likely find in a cellphone or similar device); and here are the Intel HDA ones; as you'd see in a PC. Unless you are doing something particularly fancy(in which case the an offboard DSP might actually be worth the trouble); the main purpose appears to be allowing you to decouple the ADCs and DACs(which aren't necessarily well suited to being fabbed on the process that makes the most sense for a SoC or PC chipset; and which can vary widely in number and quality depending on the desired features of the product, which would lead to nasty SKU proliferation) from the SoC or chipset; with just a simple, versatile, digital data link between the two chips, allowing the SoC or chipset to support a wide variety of audio configurations with just one design; and allowing the device vendor to get their choice of features and performance(anywhere from a single mic, single audio out, lousy ADC and DAC quality; up to zillions-of-peripherals-and-golden-eared-audiophile-DACs) just by attaching a different codec chip.

The most spartan designs might not need a 'codec' at all(you can get MEMs mics that speak I2S directly, with the analog support circutry integrated into the package; and you can also get audio amps/speaker/headphone drivers that speak I2S directly and have a DAC onboard, rather than accepting a low voltage analog audio input); but if you've got a mic array, a speaker, headphone/mic jack, line out, etc. a codec can bundle up all the support for the various analog interfaces and allow you to attach them all to the SoC/chipset with a single digital bus.

In this case, the fact that it's a codec soldering issue is presumably why all three mics die at once. That would be seriously unlikely if the mics themselves failed; but the codec handles all the mics, so a failure there knocks out the mics in roughly the same way that just yanking out a soundcard would.

It does. The part in the Pixel is(I think) a Qualcomm; but they are annoying as hell to get datasheets for; so these examples are Realtek:

Here are their I2S codecs(what you'd likely find in a cellphone or similar device); and here are the Intel HDA ones; as you'd see in a PC. Unless you are doing something particularly fancy(in which case the an offboard DSP might actually be worth the trouble); the main purpose appears to be allowing you to decouple the ADCs and DACs(which aren't necessarily well suited to being fabbed on the process that makes the most sense for a SoC or PC chipset; and which can vary widely in number and quality depending on the desired features of the product, which would lead to nasty SKU proliferation) from the SoC or chipset; with just a simple, versatile, digital data link between the two chips, allowing the SoC or chipset to support a wide variety of audio configurations with just one design; and allowing the device vendor to get their choice of features and performance(anywhere from a single mic, single audio out, lousy ADC and DAC quality; up to zillions-of-peripherals-and-golden-eared-audiophile-DACs) just by attaching a different codec chip.

The most spartan designs might not need a 'codec' at all(you can get MEMs mics that speak I2S directly, with the analog support circutry integrated into the package; and you can also get audio amps/speaker/headphone drivers that speak I2S directly and have a DAC onboard, rather than accepting a low voltage analog audio input); but if you've got a mic array, a speaker, headphone/mic jack, line out, etc. a codec can bundle up all the support for the various analog interfaces and allow you to attach them all to the SoC/chipset with a single digital bus.

In this case, the fact that it's a codec soldering issue is presumably why all three mics die at once. That would be seriously unlikely if the mics themselves failed; but the codec handles all the mics, so a failure there knocks out the mics in roughly the same way that just yanking out a soundcard would.

And since most onboard solutions are realtek, you get what you pay for. Complete shit.

Complete shit?! May you elaborate? Realtek produces quite damn advanced stuff.

...was Realtek. I mean come on, their logo ( http://www.realtek.com.tw/ ) is a freaking crab anyway. How long before we see cheap network or sound cards based on _actual_ crab technology!?

I have also had good results with the TP-LINK TL-WR1043ND Ultimate Wireless N Gigabit Router running OpenWrt and use them as network firewall/gateways, OpenVPN server/clients and small VLAN-capable switches.

The hardware specs are great for the price ($55-$65): 5 gigabit ports, 802.11n and the real winner is that OpenWrt has good support for the RTL8366RB switch chipset, including tagged VLANs. Getting a switch that has VLAN support for this price is not otherwise available, that I've found. The stock TP-LINK firmware does not expose the VLAN features but they are there and available if OpenWrt is used.

- Chipset is the Atheros AR9132 rev. 2 WISOC, which contains: Atheros 3×2 (3rx, 2 tx) MIMO wireless + MIPS 24Kc V7.4 CPU running at 400Mhz) – 266.24 BogoMIPS
- RAM: 32 MB
- FLASH NVRAM: 8 MB
- 801.11n/g/b 2.4 GHz
- 4+1 gigabit Ethernet ports (RTL8366RB chipset with 802.1Q VLAN support – see http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PNid=18&PFid=15&Level=5&Conn=4&ProdID=197)
- 1 USB 2.0 (can put a small USB stick in and use it as swap space to run programs that otherwise wouldn't work given 32 MB of RAM, such as dansguardian)

The one main problem I've found is that some wireless clients have problems connecting using 802.11 -- see the bug "Backfire ar71xx error: ath: Failed to stop TX DMA!" at https://dev.openwrt.org/ticket/9693 for examples. This has improved with -rc5 and -rc6.

-Tim Miller Dyck

I can't answer 2 and 4, but as for 1 and 3... my computer is a few years old and has an integrated Realtek ALC888S sound processor. It seems to do environmental effects OK in Source (HL2) based games.

Note: I'm saying this purely from my experience playing Team Fortress 2, as it's the Source game I've played the most... I've noticed that Source has different effects based on the floor and room types. A good example of this would be the echoing in the sewer tunnels below 2fort.

Then again, I don't know if this is specific to the Orange Box 2009 version of the engine or if it affects all Source games (almost all of Valve's games were updated to at least Orange Box 2007 with their Mac releases).

http://www.realtek.com.tw/
That site would explain a lot of things to you, especially their way of handling things. Stupid Creative and other vendors made them (!) the emperor of sound with their policies. If you find about their marketshare, it will likely surpass Intel vs. AMD.
Companies like Apple, who thinks it is wise to pack up old versions of drivers so "maccie" won't have a decent experience on Windows also adds to the problem.
If Microsoft did their job fine, told Realtek "just don't ship drivers, we will handle it with windows updates as fast as you would post to website", there wouldn't be a need for third party realtek driver site to begin with. It became a common thing to go to realtek site and get/update to latest drivers.
Realtek is an advanced hardware design (IC) house, this is what happens if you force them to do software things. One day, they lose the certificate.

Audio drivers available for download from the Realtek website are general drivers for our audio ICs, and may not offer the customizations made by your system/motherboard manufacturer.

... and all I had to do to solve it was go to Realtek's site and download the latest version of their driver. Problem solved (knock on wood).

So.. If the fix is that simple, is this issue really an issue or is this issue blown out of proportion?

I have an Asus A7N8X-E Deluxe and had all kinds of audio problems with the stock Vista nForce 2 audio driver till I grabbed the Vista driver from Realtek's site.

While not ideal (no Dolby Digital encoding), it did solve all my stuttering problems that the stock Vista driver had.

Also, if you need them, Silicon Image has Vista drivers for the Sil3112 SATA chip. I know most boards from that era that used the nForce 2 chipset also used the Sil3112.

According to the article, there are three companies that have actually worked with the free software community on drivers. Here is the list:

Ralink Technology

Atmel Corporation

Realtek Linux drivers here

Vote with your money, folks. If you would like to see companies cooperate with the free software community, reward the companies that do so by buying their products.

If you know of a particular piece of WiFi hardware that works particularly well in Linux or BSD, please follow up here so we all know what to buy. (See also this list.)

According to the article, there are three companies that have actually worked with the free software community on drivers. Here is the list:

Ralink Technology

Atmel Corporation

Realtek Linux drivers here

Vote with your money, folks. If you would like to see companies cooperate with the free software community, reward the companies that do so by buying their products.

If you know of a particular piece of WiFi hardware that works particularly well in Linux or BSD, please follow up here so we all know what to buy. (See also this list.)

steveha

couldn't get the embedded sound working on a motherboard that is only a year old

I thought that's what the built-in RealTek ALC850 chip was supposed to do?

Speaking of which, DO NOT install the nForce drivers under Linux! They are WAY out of date and will just screw stuff up. Just get the latest version of non-Kernel ALSA and you should be fine. The ethernet is already supported.

The GeForce drivers should work without a hitch, though.

99.9% of the time an 8139 is the best ethernet chip for the job. If you can spend some money, go with 1000Mb.

Maybe those of use stuck with a Realtek 8180 card? The model number is close enough to 8181 that there is some chance that the 8181 AP driver would work with the 8180 PCMCIA card, with only minor modifications.

Yes, I know that there already is a binary driver for the 8180, but it is very flaky, and rather picky about the kernels and distributions it agrees to work with... (as binary drivers usually are, alas!)

The only thing I know about the nForce2's sound part is the connection to the RealTek ALC650 audio CODEC/a?. If it's not the best chip out there for throwing MCP-T output to the analog connectors, then that's too bad.

I think the best thing to do is use the nForce2's SPDIF output and work from there. What receivers are good with a non-home-theatre PC setup?

You should be able to tell if it's a RealTek-based card by looking at the drivers that came with it... if there are Linux drivers, look for something obvious like rtl8139.o . :-) Otherwise, search Google. Lots of manufacturers (SMC, Linksys, etc.) get the RTL-8139 chips with their brand name and a different part number and dump 'em on the board. I have an El-Cheapo 8139 card in my beige G3 MT here that works fine w/ the drivers, and an SMC 8139-based card in another G3 desktop that works fine in X too.

Step 1. Buy a D-Link 530TX+. I know, it's not on the HCL, but...
Step 2. Go here to get the drivers for the chipset.
Step 3. Have as much fun as Solaris will allow.

Or, if you really need something on the HCL, Netgear still has their FA310TX available from their store, for a rather large shipping charge though :-(