• C

how can i find the registeradresses of loudspeakers

hi @ all,
i want to control my loudspeaker with the help of my own software i. e. software which i want write myself. The problem is that i don't know how to find the the registeradresses of my loudspeakers which means, that i can't therefore calculate the registeradresses of my loudspeakers. Is it at all possible to control or head for the loudspeakers with "c"?  
i thank you for every help i can get
cu next time
blafreakAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

_tackCommented:
Hi,
I really don't know how to do this, but I think you should provide some more details.
At lease the OS,

under linux you should be able to adjust it by using /dev/mixer

_tack
SalteCommented:
Ok, let's get the names straight first.

You access external hardware (speakers, hard disk, external clock, keyboard, mouse, etc etc etc) not through registers but through I/O addresses. The exact details how this is implemented vary from CPU to CPU but most CPU's does it in the way that they load an internal register which you cannot read/write with some bit pattern to identify which hardware you want to access and another internal register which you cannot read/write with some data if you want to send data to the hardware. It then signal that it want's to send data or retrieve data from that device. This will then set a signal line to its non-default state and so various hardware attached to your computer will look at the address to see if it was something for him or her - it's just like children on Xmas "have you got something for me?". The one card or hardware unit that recognize the address as to itself will then either provide the data you want to read or retrieve the data you sent it and do something with it. If the hardware wants to write data to the CPU it cannot do that unless the CPU asks for it so instead they will just set a bit pattern that identifies itself into some place and set a line to its non-default state in order to raise their hands and say "I need your attention Mr. CPU". The CPU will trigger on that line and stop whatever it's doing dead in its tracks and process a so-called interrupt routine which will detect read the bit pattern to see who wanted its attention. If it is some hardware it recognizes it will then indicate to the particular driver that there's some data for it. It could be that a hard disk has completed a read or write operation or that the user pressed the keyboard or whatever.

Ok, so for one thing, you don't have register addresses to identify the speakers, you have I/O addresses. Secondly, those I/O addresses doesn't really attach to the speakers. Speakers are usually dumb hardware and there just isn't much you can do with them. The speakers are also seldom attached to the computer directly, they are typically attached to a soundcard and you want the I/O addresses of the sound card incase you want anything.

Secondly, on most computer systems the software that are allowed to talk directly with hardware (soundcards, disk controllers etc) are drivers. Normal regular software just doesn't have permission to do that. So unless you run
MS-DOS or some other outdated OS you can generally forget about it unless you know how to write drivers. From your request and how you phrase it I doubt you are capable of writing a driver any time soon but if you really are interested you should 1. Tell us what OS you're on and 2. Depending on OS there are ways to learn how to write drivers for them. It is not trivial and it takes time to learn but it isn't impossible magic either.

And to answer your question, you can use "C", in fact near 100% of all drivers in work today is written in C. The rest are either written in C++ or assembler. The rest which is neither written in C, C++ nor assembler are so few and far between that they can be safely ignored ;)

In windows many drivers are actually written in C++. The DDK works for both C++ and C as far as I know. Traditionally most drivers are in C though just as in linux. In linux virtually all drivers are written in C and the
same goes for most other unixes as well.

However, a driver isn't a regular executable program so you typically have to do special things to make a driver and debugging them is a pain so it is a special trade to learn and is rather different from regular application programming. Don't even THINK about writing a GUI program which also does direct I/O address access. It can be done on some systems such as MS-DOS and a few others but it's a BAD THING TO DO, so don't do it.

Hope this explains.

Alf

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
imladrisCommented:
On the other hand, under windows, it is reasonably straightforward to get a soundfile to play on the speakers. If you use DirectX there are interface calls for loading the data into a buffer, and playing it.

It's still not trivial, but it is at the level of writing an application, instead of the very grotty and complicated business of writing drivers.
cookreCommented:
Take a look at the VB Multimedia MCI control to get a feel for what's going on, then, for C, use the MCI functions:

mciGetCreatorTask
mciGetDeviceID
mciGetErrorString
mciGetYieldProc
mciSendCommand
mciSendString
mciSetYieldProc
cookreCommented:
That, of course, presumes an MS Windows environment.  

One presumes MACs and the *nix world have their own similar APIs.

For DOS, you'ld have to enlist the aid of each sound card vendor for details on the interrupts and packet formats to use.  

Understand that sound card, video card, an CD/DVD vendors can engineer their products any way they want, and the drivers they deliver with their products provide the interface between their proprietary product and the standardized control methods defined by the OS maker.  In other words, your program talks to the generic multimedia API, which talks to the device driver, which talks to the device.
imladrisCommented:
I think the points should go to Salte.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C

From novice to tech pro — start learning today.