Hit Spikes and Engine Sounds

[olds442]

Chalenge you are quite misinformed how little of processing time actually goes to audio playback. Secondly the anomalies you are describing is almost always a driver dependent issue.
Have a external DAC+AMP config that connects via USB and you will never have anomalies (Unless hardware failure of course), No drives, and it works on any USB device.

Here is a good link:

http://nwavguy.blogspot.com/2011/02/gain-and-headphone-ampsdacs.html
Poke around on his other articles and you will see why all the BS that goes around with "Advanced EQs" and "Special hardware thing that magically makes the result better than the source" is simply BS.


With that said I still use a sound card because they have a great price to quality ratio compared to external devices.

EDIT: And yes one could do everything a sound card does completely in software and on the CPU, Their is no magic.

[Chalenge]

Olds, that blog concerns straight up audio without a game playing in tandem. You need to go back and actually read what I wrote and take into consideration that I have actually tested audio in the game on many different systems to come to the conclusions that I have. Plus, I use an external "DAC" for audio input and that I am quite aware of the improvements by removing any type of load from the system altogether. However, your 'external DAC' does no 3D positional calculations whatsoever. None. It's all done on the CPU. Read up on latency, which is something you want to avoid.

We're not talking audio quality like your blogger friend. We're talking lack of latency instead.

I can make this real easy for you. Imagine you have a job sitting at a desk and taking a red ball from a dispenser and inserting it into a cup. You get the red ball from one dispenser, and the cup from another. You get really fast at doing the job and once you achieve 'flow' everything is smooth. Then the manager comes to you and suggests that shipping keeps dropping the balls out of the cups and that you now need to use a virtual third arm-hand combination to tape over the mouth of the cup to retain the ball. But, since only the best customers  care if the ball is in the cup or not the application of tape will be purely random. It will take some small amount of mental power to generate the third arm, but it will only slow you down by 9% to reshuffle everything. So, you start again only this time once you gain 'flow' a red light flashes and you have to reshuffle your thought processes in order to 'make room' for generating the arm and telling that third virtual arm what to do. Plus, you have to download the code to generate the arm, because it's not part of what you normally do (not in your DNA).

Now do you get it?

[olds442]

Chalenge you are forgetting how fast modern processors actually run. A couple million instructions execute in the micro second range. Secondly the CPU for the most part spends most of its time doing other things that are NOT game related such as keeping track of page tables, handling interrupts, managing PCIe lanes. So your CPU still has to move all the data to the sound card and give it instructions over the PCI/PCIe bus so while its not directly doing the calculations it still has to tell the sound card what to do and when to do it.

Almost all games (and I have lists) use the CPU instead of the sound card for 3d positioning. Even if the sound card has the option to because the CPU is faster (even while doing complex calculations and OS processes) than the slow DSP that is on your soundcard. This wasn't always the case (Back around 2005 sound cards could actually improve FPS a bit) but now it is.

Again let me say it: The CPU will always do the 3d positioning calculations faster than the sound card's DSP. It is a fact even while running stress tests for example because the OS will always give the sound some priority (Unless you set your process's priority to high or real time in task manager for example). This is done via a timer which triggers a hardware interrupt to APIC (Advanced Programmable Interrupt Controller) and the OS can set what priority said interrupt from the sound processor's timer is. For the most part its priority is higher than the keyboard. Once the switch happens (called a context switch in OS terminology) the sound calculations have ALL of the CPUs processing power for a certain amount of time. Its a very common misconception of how multitasking works in a OS and how the CPU handles it.

In short the higher the priority of the process (Sound in this case) the longer time slice it gets. However even on a very low priority sound calculation it will almost always calculate faster than the DSP on the sound card.



Also you don't use a DAC for audio input a DAC is a digital to analoge converter for input you would use a ADC.

[Skuzzy]

First off, a USB bus connected sound system suffers enormous interrupt overhead, as each byte traversing the USB bus requires an interrupt to be serviced. No way around that one.  Each time an IRQ happens, it invalidates the CPU cache as well.  It also causes all cores to suspend until the IRQ is serviced.

Next, FFT code running on a CPU is going to be orders of magnitude slower than a dedicated hardware FFT chip.  Those high end audio cards can parallel process up to 256 FFT instructions per cycle, versus the 4 a high end quad core CPU can and those hardware FFT chips can process those instructions with fewer cycles as well.

As far as the 3D positioning of sound, in a game, goes.  That is actually done on the graphics card, not the CPU.  When you use 3D positioning in a game, you set a vertex point as the source and a vector for the direction.  It is translated by the GPU, not the CPU and you use the translation for the 3D positioning.  Virtually no overhead at all.  What overhead there is, is the same for a high end audio card, versus a dumb motherboard chip.

Now, if you are talking about Dolby, that is a different beast.  Dolby support via their hardware chip, on a sound card, is much faster than the CPU can accomplish.  Licensed sound cards use the hardware from Dolby labs for this.  However, only a moron would use Dolby positioning in a game.

[Skuzzy]

One other thing.  A good quality sound card moves the data for the CPU.  The CPU just provides the address and the count, and sends it on its merry way.  On-board sound chips cannot accomplish that, nor can a USB based sound solution.

[olds442]

First off, a USB bus connected sound system suffers enormous interrupt overhead, as each byte traversing the USB bus requires an interrupt to be serviced. No way around that one.  Each time an IRQ happens, it invalidates the CPU cache as well.  It also causes all cores to suspend until the IRQ is serviced.

USB doesn't use the interrupt system at all, USB is a polled protocol (unlike PS/2 and AT) and this means that rely the CPU if it wanted never could check the USB buffer. The standard update rate for USB is 125hz and for each packet sent for USB 1.0 there can be a max of 8 bytes of data sent along. With USB 2.0 this was brought up to 1023 bytes and USB 3.0/3.1 this is 1024 bytes.
http://stackoverflow.com/questions/4813368/usb-polling-mechanism

Next, FFT code running on a CPU is going to be orders of magnitude slower than a dedicated hardware FFT chip.  Those high end audio cards can parallel process up to 256 FFT instructions per cycle, versus the 4 a high end quad core CPU can and those hardware FFT chips can process those instructions with fewer cycles as well.

As far as the 3D positioning of sound, in a game, goes.  That is actually done on the graphics card, not the CPU.  When you use 3D positioning in a game, you set a vertex point as the source and a vector for the direction.  It is translated by the GPU, not the CPU and you use the translation for the 3D positioning.  Virtually no overhead at all.  What overhead there is, is the same for a high end audio card, versus a dumb motherboard chip.

Yes those DSPs can process instructions in a wide issue format but have a painfully slow clockspeed in return which destroys latency compared to the CPU.

Secondly you say the 3D positioning is done on the graphics card (which makes sense) and if so why not leverage the extreme parallelism of the graphics card to execute those FFT instructions?

One other thing.  A good quality sound card moves the data for the CPU.  The CPU just provides the address and the count, and sends it on its merry way.  On-board sound chips cannot accomplish that, nor can a USB based sound solution.

And during this DMA the CPU can not access the RAM bus at all and because this operation is preformed atomicly, can't until the DMA has completed. So if the CPU is running a process and it gets a 3rd level cache miss it has to stall which is very bad.

However, only a moron would use Dolby positioning in a game.

New sig 

[Chalenge]

USB interrupts:  http://msdn.microsoft.com/en-us/library/windows/hardware/dn303348%28v=vs.85%29.aspx

As to 3D positioning, when I use my X-Fi card I get very precise indications where audio of vehicles on the ground are located (never have used Dolby). My "DAC" (audio interface that is actually a DAC/ADC and uses an ASIO stream) is much more loose on positions. So if you turn your head the same sound will appear to come from a much broader area when compared to the X-Fi. So, it would seem that the playback device has something to do with how audio is represented, whether the position is calculated on the GPU or not. Reading up on Miles it appears that Miles supports the X-Fi 3D capabilities of EAX. Given that why would anyone stick to USB, onboard, or generic audio cards?

[olds442]

USB interrupts:  http://msdn.microsoft.com/en-us/library/windows/hardware/dn303348%28v=vs.85%29.aspx

As to 3D positioning, when I use my X-Fi card I get very precise indications where audio of vehicles on the ground are located (never have used Dolby). My "DAC" (audio interface that is actually a DAC/ADC and uses an ASIO stream) is much more loose on positions. So if you turn your head the same sound will appear to come from a much broader area when compared to the X-Fi. So, it would seem that the playback device has something to do with how audio is represented, whether the position is calculated on the GPU or not. Reading up on Miles it appears that Miles supports the X-Fi 3D capabilities of EAX. Given that why would anyone stick to USB, onboard, or generic audio cards?

USB devices send interrupts as per their update rate NOT as asynchronous data transfer requests. For example if the cycle rate is 125hz then you get a USB interrupt 125 times per second. Unlike with PS/2 where you get an interrupt every time the device sends an interrupt request. Hardware interrupts are supported but act as a special value with in the USB buffer in the HOST controller (end point) and not as a special IRQ value. Basically the USB you send data synchronously at a predefined update rate.

Secondly yes if the software doesn't support 3D positioning with software then you won't get any 3D positioning. In aces high and in most games there is a "Stereo headphone" option in the sound settings which allows 3D spacial separation.

Here is something worth watching, turn off all your 3D positioning software and use any headphone you want but make sure its a pure stereo signal.

https://www.youtube.com/watch?v=IUDTlvagjJA

Here are some good threads of various forums explaining how the X-Fi "Magic" is just smoke n mirrors.

http://www.overclock.net/t/370851/sounds-cards-getting-pointless-or-atleast-for-me

http://youtu.be/d1rXcJuEsy0?t=16m18s (starting at 16:18 is the talk about the X-Fi and other software)

http://forums.anandtech.com/archive/index.php/t-2331046.html

http://www.techpowerup.com/forums/threads/eax-dead-what-is-openal-better-than-eax.61670/

[Skuzzy]

USB doesn't use the interrupt system at all, USB is a polled protocol (unlike PS/2 and AT) and this means that rely the CPU if it wanted never could check the USB buffer. The standard update rate for USB is 125hz and for each packet sent for USB 1.0 there can be a max of 8 bytes of data sent along. With USB 2.0 this was brought up to 1023 bytes and USB 3.0/3.1 this is 1024 bytes.
http://stackoverflow.com/questions/4813368/usb-polling-mechanism

You can poll or use Interrupts.  Most drivers use interrupts.  It is more efficient to do so.  The size of the packet is not determined by the specification.  It is determined by the hardware implementation.  I have written those drivers and I always used interrupts as polling is far too CPU intensive.  It would be stupid to do that.

Yes those DSPs can process instructions in a wide issue format but have a painfully slow clockspeed in return which destroys latency compared to the CPU.

Have you ever actually measured it with a scope?  I have and you are completely wrong here.  So far from the reality there is no way to have a conversation about it.

Secondly you say the 3D positioning is done on the graphics card (which makes sense) and if so why not leverage the extreme parallelism of the graphics card to execute those FFT instructions?

You missed the point.  The GPU processes the vertex data as part of its normal operation.  There is nothing extra being done.  Processing sound data on the video card would be rather silly.  Send the data to the video card, then read it back only to send it to the sound chip.  Makes no sense.

And during this DMA the CPU can not access the RAM bus at all and because this operation is preformed atomicly, can't until the DMA has completed. So if the CPU is running a process and it gets a 3rd level cache miss it has to stall which is very bad.

You do not understand how first party DMA works.  The device can only hold the bus for a short period of time.  During that time it can move data as fast as the bus or memory will allow, which is faster than the CPU can do a PIO transaction.  During this time no CPU can access memory.  However, the CPU's can act on any cached data they have available to them.

But then again, when one CPU core accesses memory none of the other cores can either.


This is getting into picking nits and not productive.  There is no way an onboard sound chip using the CPU for all the processing is going to be more efficient than a proper sound card with its own processor and hardware.  The minute you do it all on the motherboard, you lose all parallelism and become single threaded, from a hardware perspective.

Performance of sound card hardware, due to its own massively parallel architectures will always be faster than doing it on the motherboard using a shared CPU.  The sound card hardware can also do more per clock tick (up to 128 times more; this is not a wild guess nor an exaggeration) than a CPU as its functionality is very narrow in scope.

Whille all that is going on, within the sound card hardware, the CPU is 100% completely free to continue running its programs.  The more parallelism you can bring to the hardware, the more efficient it becomes.

[Chalenge]

Here are some good threads of various forums explaining how the X-Fi "Magic" is just smoke n mirrors.

Garbage in, garbage out. You cannot make quality decisions based on bad information. Olds, the problem is you are accepting bloggers as experts.

[olds442]

Garbage in, garbage out. You cannot make quality decisions based on bad information. Olds, the problem is you are accepting bloggers as experts.

I have yet to see any proof from you that your sound card is increasing your FPS by a noticeable amount and or in a double blind test that one could tell the difference. And no chalenge im not excepting bloggers as experts but if everyone is saying the same thing along with tests that I did myself that prove what I'm saying.

EDIT: Skuzzy because you think I am so wrong about this please show me what chips you're talking about which can execute 128 instructions per cycle and yet use almost no power and not need any sort of heatsink.

Second EDIT: The first blog I linked the user "NwAvGuy" Is infact an expert in the field of audio reproduction and his O2DAC and OAMP are one of the best in the industry so I'm certain he knows slightly more than you.

[Skuzzy]

An expert in audio reproduction is not a computer designer.  I have over 15 years in computer hardware design experience, and more than that in system software development experience.  I also hold a masters in electrical engineering.

NOTE:  I did not say 128 instructions.  I said said 128 times.  There is data and there is code.  A sound card operates on both, simultaneously with no interruptions from other sources.  Any high quality voice sound card can do it.  Heck, an ancient Creative AudioPCI 128 can do 128 parallel streams, simultaneously.  Slowly, but fast enough to keep the sound streaming.  All the while the CPU is free to do other things.

It is a simple matter of logic here.  It is more efficient to use a sound card, than to not use one.

[olds442]

An expert in audio reproduction is not a computer designer.  I have over 15 years in computer hardware design experience, and more than that in system software development experience.  I also hold a masters in electrical engineering.

NOTE:  I did not say 128 instructions.  I said said 128 times.  There is data and there is code.  A sound card operates on both, simultaneously with no interruptions from other sources.  Any high quality voice sound card can do it.  Heck, an ancient Creative AudioPCI 128 can do 128 parallel streams, simultaneously.  Slowly, but fast enough to keep the sound streaming.  All the while the CPU is free to do other things.

It is a simple matter of logic here.  It is more efficient to use a sound card, than to not use one.

This is what I'm getting at, yes it is more efficient but is it worth the cost of a sound card with these features than to upgrade something else for better FPS. In 2005? sure but today not really.
In short I'm not disputing if what you said is correct but if its worth it in this era of high speed processors. Also note most graphic cards and some APUs have a built in sound chip which almost eliminates these problems.

Also you said earlier its impractical to do sound processing on the GPU because it requires a lot of talking back in forth:

*Send instructions to GPU
*Get results back into memory
*Output to onboard DAC/AMP

But like I said most modern GPUs have built in sound chips which can directly output via HDMI and thus would be the same as a sound card at that point.

Also I'm going to dig around to find some benchmarks or make my own if I can't find any to see what the real difference is.

[Skuzzy]

If you are strictly talking about a gain in FPS, then the gains of a sound card may not be noticeable in the frame rate alone.  The gains are also in the number of simultaneous sounds the system can play, along with reduced CPU overhead which can be applied to other things (I/O, game code, other threads....).

The onboard audio devices of graphics cards sucks for games.  NVidia and AMD both, have yet to figure out how to deliver sound drivers which do not create other problems for the computer.  You also lose the true 3D sound positioning when you play audio through the HDMI port as the receiving decoder (the television, or receiver) expects decoding information to be sent with the interleaved audio stream.

[jimson]

If you are strictly talking about a gain in FPS, then the gains of a sound card may not be noticeable in the frame rate alone.  The gains are also in the number of simultaneous sounds the system can play, along with reduced CPU overhead which can be applied to other things (I/O, game code, other threads....).

The onboard audio devices of graphics cards sucks for games.  NVidia and AMD both, have yet to figure out how to deliver sound drivers which do not create other problems for the computer.  You also lose the true 3D sound positioning when you play audio through the HDMI port as the receiving decoder (the television, or receiver) expects decoding information to be sent with the interleaved audio stream.

So, just how inexpensive of a soundcard will provide a benefit over on board sound?