Re: For hardware engineer types re: sound controlers and/or codec chips ??

Thanks Les;

On Sun, 2009-09-06 at 17:02 -0700, Les wrote:
On Sat, 2009-09-05 at 13:36 -0400, William Case wrote:
Hi;



Is my assumption about temporary, perhaps 1-2 ticks, storage accurate?

Where is this data stored?

Does the sound card itself have some small capacity for memory?
-- SRAM or DRAM?


Hi, Bill,
Sound, like most everything else electronic is becoming more and more
integrated. The chip processes today are quite a bit different today
than they were even 20 months ago. Anything I might say is probably
different from the actual truth anyway.

But here is an attempt at a high level overview...

As I have said before, it is not essential I get the latest hardware
construction or software configuration. I am not building a computer
from scratch in my garage. But it is nice to know various nodes or
resting points of a system so that I can follow the the problems that
are being solved or the improvements being made.


Sound is digitized by an A/D. that is it comes in, is buffered to
isolate the source from the actions of the A/D, is selected or mixed
with other sources (either before the A/D or afterwards mathematically)
and then encoded. The encoding is dependent upon the standard(s)
chosen. In the past the data was simply passed to the cpu and the
encoding or decoding took place on the main processor. Today many of
the sound chips and advanced sound systems (USB or plug in board or
chipset) have encoder/decoder capable processors built in, and many of
them support programming to meet new standards, so that as MPEG2 becomes
MPG3 or 4, the software can be updated to manage that change. This
relieves the main processor of that task, so it can concentrate on other
things. At the same time, the video boards are also becoming more
powerful with array processing built in to do all kinds of 3d graphing,
and there are more powerful utilities being developed all the time
(facial recognition, tracking, movement detection, environment
measurements etc.) And again the on board processing relieves the main
processor of much of the processing burden. However the data is
handled, it is eventually sent to the main processor for storage or
transmission, and that part may be handled by DMA, although using DMA
for an Audio process is somewhat overkill, since DMA is in essence a
high speed process. It depends upon the demands put on the hardware
whether slow speed processes like audio are handled by DMA or polled
buffering, but in any event, the mixing of multiple channels, the
processing for Dolby, or other encoding like THX, or even simulated
projected sound as used by some forms of speakers with phasing
capabilities, means that the processing overhead is increasing, and the
demand for integrated processing increases with that. Also board real
estate is more expensive than IC real estate, so economies of scale
dictate that the chips become more and more powerful.

In an earlier post John Wendel suggested.
http://www.intel.com/design/chipsets/hdaudio.htm

It has most of what I want, it seems. I have perused the documents and
found stuff that seems to answer my posted questions but I have not yet
really dug into them. I will.

I am referring to:
Intel® I/O Controller Hub 7 (ICH7)/Intel® High Definition
Audio/AC’97/Programmer’s Reference Manual (PRM), or the Intel® I/O
Controller Hub 7 (ICH7) Family Data*** and one other.

In there is mention of several registers. I assume those registers are
in the hub and that is where the sound data is temporarily stored
whether it goes through DMA or not. If I am wrong just let me know. A
long explanation is not needed at this point until I actually dig into
the manuals and try to understand them myself.

The enemy of good sound is noise, and PC's with their switching power
supplies, digital I/O and something called ground bounce (where the
return path gets periodically overloaded with current, minimizing the
difference between the power rail and ground), all contribute noise. So
lots of systems now use USB or some other means to isolate the audio
system from the processing ground.

And then a new problem crops up. If the audio system does the
processing, how can it handle the processing noise it makes itself?
There are lots of methods, but one is to make the processing synchronous
with the sampling. This means that the noise occurs at the same time as
the ADC or DAC is switching to the next sample, so the noise is not
captured. Other techniques involved here all have to do with making the
noise "common mode" so that the audio system is balanced against ground,
and differential. When the ground noise goes into such an amplifier, it
is canceled by its own image of the wrong polarity. (this is a
simplified explanation).


I am always fascinated by the ingenious solutions engineers develop. It
just demonstrates that in spite of the innovation, how much of computing
is built on past endeavours.

So logically the Main processor will set up a process on the system
that will send and receive encoded digital streams and tell the audio
circuitry what is coming, how it is coded, how large the blocks are and
so forth for sound output, whose size and transfer method depend upon
the current expected standard and the chipset in use. The audio
circuitry will process the digital input to sound output for speakers
etc.


I never forget that computing, at its most basic level, is no more than
opening and closing a complex set of switches in order to get electrical
power to flow through one system of hardware or another.

The corresponding operation for audio in will setup the processor on the
audio board for the signals to process, the method to use and size of
the data blocks to transfer.

The audio input from the microphones or
other analog inputs are then sampled into digital data appropriately
encoded to pass back to the computer where a waiting process will
dispose of the data in the appropriate manner for the application.


Those two paragraphs are the crux of it. If I can get those essential
elements working (I mean working in my mind through logical analysis and
visualization), adding all the side-bars, caveats and exceptions just
becomes grunt work.

I hope that helps.

It does indeed.

Regards,
Les H

--
Regards Bill
Fedora 11, Gnome 2.26.3
Evo.2.26.3, Emacs 23.1.1

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Loading