The Mystery Of The AC97 Sound...

[Floid]

Maybe Intel's PDF will help?

IANAAG (I Am Not An Audio Geek), but I gather most of the love for the SBLive stems from three things- Creative Labs' "superior" construction techniques, the ability of the EMU chips to (co)process audio data, and the powerful MIDI support in those same chipsets.

Many "normal" people dislike onboard AC97 audio systems because they find them 'of poor quality' - presumably due to interference in the analog stages, whether on-board or on-chip.  This depends a lot on your particular board and chip; when I was on my EPoX 8KTA3, I had to crank my external amp far beyond normal listening levels to hear any static or hum.  A more basic problem is that, even inside Windows, it's hard to trick the single 'speaker' jack provided on most boards into acting as a proper line-level output.  These aren't really AC97 problems; they're implementation issues.  Meanwhile, SBLives have at least half-decent analog stages, and carry on the tradition of separate 'speaker' and 'line out' jacks, or at least have a simple toggle in the driver.

From there, you get into features that AC97 simply doesn't provide- *if* you have the right software/drivers, the SBLives can offload a lot of processing (for MP3 decode, effects, etc) from the main CPU.  This comes in handy for three classes of application- what I'd consider "peon" apps (the audio players that come with the card, and allow you to select 'stadium' simulation or whatnot); audio libraries- presumably DirectX can take advantage of certain 'accellerations,' and support is claimed for whatever OpenAL is on Linux - for gaming, at least, some CPU offloading would occur, though 'quality' is probably subjective; and high-end professional tools, which no-doubt give real thought to accuracy, quality, etc.  Meanwhile, MP3 decoding to an AC97 chip uses only a fraction of CPU time on any modern system, so it's not like you're totally crippled by  not using a SBLive.  (For gamers, offloading the decoding for game music does translate to a mildly increased framerate.)

MIDI support isn't a part of AC97 at all, while the SBLive has numerous highly-advanced features... none of which you'll ever touch if you don't use MIDI.  For a pro, it's no-doubt great; for playing  back an annoying tune on a Geocities page, it's.. overkill.  (A software MIDI decoder comes with Windows, and Apple seems to have relied on them exclusively? during the '90s; I have no idea what they currently use for sound.  Similar software can be wedged into Linux/*BSD.)  I have to wonder how many (gamer/consumer) SBLive owners are using the Microsoft software decoder without realizing it, whilst bragging of their card's abilities.

The big problem (fixed with the Audigy?) is that all the snazzy features came at a price- all operations on the card were handled at a fixed sampling rate of 48KHz - meaning 'rounding errors' (more like framedropping/interpolation noise?) when going to/from (and worse, to/from/to/from/to ad nauseum) the popular 44.1KHz of CD audio.  One mitigating solution has been to leave the output at 48KHz... which works fine for other SBLive users, but requires conversion when going to CD... and could show up other samplerate-conversion/'rounding' issues in things like FreeBSD's "vchans" mixing code.

[Floid]

mdma wrote:
For anyone having problems with SBLive/Audigy on VIA chipset motherboards, do the following.

Installing a BIOS update can't hurt, either, especially if you have a board from a vendor (EPoX :-D) that specifically addressed the issue.

Googling around for "Via PCI burst transfers" and so forth ("burst transfer bug," "KT133A PCI burst," etc) should turn up more detail on the issue.

Looks like some detail on the latency patch - and a 686B bug! - here.

[Floid]

Martyn wrote:
http://www6.tomshardware.com/game/20030405/index.html

That's a good example of Tom being a crackhead.

Well, not really, but it's a pragmatic review for Windows gamers, and doesn't go into the issues that actually produce the results.

As a good example, the CS4624 pulls even with the Audigy- but they're in no way comparable chips.  It just happens that they both support EAX- and both hang off the same spot on the PCI bus (meaning, no intervening PCI<->PCI bridges to further cloud the issue).  Meanwhile, the 'crappy' Realtek and C-Media don't really support 3D sound* - no surprise there; CPU load can't help but go up, as DirectSound presumably takes over the processing... or even if DirectSound doesn't handle it (no idea; not a Windows sort), the *drivers* may not have been as polished, spending more CPU time unnecessarily, when the interrupt load/etc in accessing the hardware is probably *exactly the same* for plain stereo (when the driver gets around to actually sending the data out).

--

For the resident procyonid:  Welcome to the latency issues momma warned you about... and didn't Billy tell you to buy XP if you want to play games? ;-)

For Ole-Egil:  Please tell me this is only an issue for the PowerPC/AmigaOne kernel?  Or is Linux really that bad?  :-?  My last experience with it was trying to enable an old Soundscape ISA PnP, which didn't go well, but then, I was never any good with any of the Linux kernel/driver methodologies.

--

*Okay, not sure what the deal with the C-Media is, but I imagine he's confusing the '3D space enhancement' feature - basically a hardwired 'effect' with variable gain - with some claim to EAX support.  Which is, admittedly, easy to do.  (I made that mistake with my old Crystal Sound ISA card - AOpen model-numbered their cards *backwards* vs the chipsets used, or somesuch oddity.  I got an AW37 Pro when I wanted an AW35 Pro, or the other way around... too lazy to look it up.)

[Floid]

Blomberg wrote:

MIDI support isn't a part of AC97 at all

I will not dispute that, as I don't know much about AC'97 as a standard.
I use the MIDI in (joyport thingy) of a VIA 686b with AC'97 on a daily basis, and it does the job fine for me.

AFAIK, just about everything MIDI (except possibly 'odd ducks' like the SBLive) uses an MPU401-compatible interface.  AC97 is a standard interface for... AC97 audio (waveform data); the MPU401 was/is a MIDI UART, for transferring MIDI data (instrument selection, note triggers, etc).  I forgot that such support was built into the 686B, but yeah, there is something there.

My quarrel with this chip is the audio quality. When cranked up high, it creates noise. This is not a problem for 'normal' users, though, unless you do recording or are just picky with your audio  :-D

Yep.  I wouldn't have used my 8KTA3 for studio recording, but *not* overdriving the output (a feature mostly provided for people with, say, eMachines, and the associated $3 unamplified speakers), it was more than adequate for dumping music to a tape for play in the car.

I intend to get myself a 24bit, high quality sound card at some point (for my PC), but these most often come without any MIDI functionality at all, so the VIA chip will continue its duty in that particular area, it's quite adequate.

A UART is a UART is a UART (and unlike RS-232, MIDI hasn't gone through the speed bumps that make an Amiga CIA different from a 16550AFN. ;-)).  If you want to use the 686B as an instrument itself, it's probably limited to FM synthesis or software rendering (no idea, too lazy to look up the datasheet)... Something like an SBLive (whatever model includes the onboard RAM) has the power to replace actual MIDI instruments (if you have the software to program the wavetable(s) and whatever nifty DSP transforms can be run on them), but may not be perfect for pro digital-out/waveform use if you're stuck with the 48KHz issue.

Here's someone's tests/reviews.

[Floid]

Blomberg wrote:
I only use the controller part of the VIA MIDI, as I came to the conclusion some time ago, that all sound cards builtin MIDI sounds are crap by definition  :-D
I just use it to send events from my keyboard into the computer, for use with virtual instruments, soft samplers etc.

Well, as others have pointed out to me, the chipset(s) on the SBLives are quite literally the equivalents of standalone Emu synths.  Whether Emu's products are/were  any good, or the 10k1/10k2(?) are worthwhile successors/continuances of the lineage, are probably largely subjective calls.

And, of course (and just to illustrate the technical point), for that purpose, you don't need a "sound card" at all- just the MIDI UART, as was built into the Atari ST and available on various cheap Amiga adapters only a few weeks after launch.  It's just that, these days, there's no sense in wasting a whole chip on a 'glorified serial port,' when you can put in something a few times more powerful than Paula, and maybe a wavetable ROM, an IDE controller, and who knows what else without using up all the space on the minimum die size the chip-processing machinery can handle.

[Floid]

Waccoon wrote:

And they said it was VIA's fault

The problem is with the Win32 kernel, and how it uses interrupts, as far as I know.  Win32 doesn't allow any task to completely interrupt the system (supposedly), so sound latency problems arise.  As for Linux, I have no idea, but I'm sure the PC's horrible IRQ sharing hack has something to do with it.

Well, that's the problem in your *audio output.*

The other problem is that something about the Via chipset (KT133/133A + 686A/B) can't handle PCI bursts more than... X length, while Y length is the standard.  Further, it wouldn't recover properly from a failed attempt, leading to a latency on the PCI bus that made other transfers time out- not good for disk accesses, at least not with drivers that assumed the data in-flight was safe.

Audio will crackle on nearly *any* soundcard with Win2k; that's a dumb kernel bug.  However, disks could presumably corrupt on any *OS* run on the Via hardware, pre-patches-and-workarounds.

Needless to say, Via's later PCI implementations have, as far as I know, been much improved.

That's why I want to hear a Live! or Audigy card on an Amiga.  I'd be interesting to see how differently a PPC based machine handles sound latency issues.

Hear it under anything non-2k, preferrably on a non-KT133x board.  (I'm not sure which other Via chipsets were affected.)

Your audio should *never* be crackling, that's just lame.  The low-latency aspect of OS4 is more to help people who *really* need realtime response (studio/live/realtime effects work, stuff that needs to be synchronized to external triggers, etc) ... of course, it might help your Quake guy grunt a little more rapidly when you jump, too.

IMO, sound has always been the PC's major fault.  That explains why I spent most of my time sampling and creating music on my A1200.  Audition 4 for the Amiga is still one of the few sound editors out there that does realtime mixing (on the PC, the few sound editors that support previews simply mix clips a few seconds long.  Pssh).

You certainly outclass me there, but I'd be... not surprised, but amused... if the Windows software sucks that bad.  I use realtime mixing (well, MUXing) with FreeBSD's vchans daily- not to say the quality or latencies are anywhere near perfect- and DirectSound and all that has similar code built-in, too.  I assume you mean more in the sense of filtering/equalization/realtime effects, in which case I'd certainly agree... but I'd wonder how much of that is latencies showing through, vs. unnecessarily piggish effects code.