Topic: Windows API sound card functions

[James]

This post is a question mostly for drlava, but anyone else who has any comments is encouraged to reply as well.

Pretend I'm a complete noob when it comes to the Windows API...  (cause I am!) 

Could you please post a step-by-step HOWTO on connecting to, setting up and streaming to a multi channel sound device for all of us?

The reason I ask in writing in a thread is to make it public reference information.

I'm pretty sure meandean would like to see that too and would also have good questions.

After a bit, I will have had time to work this into the LaserBoy architecture and at some point I will be able to fully explain how the same functionality may be obtained in Linux.

I'm pretty sure with the help of Agent-C and maybe others, we can get together the Mac-OSX HOWTO; which I'm guessing will look very similar to Linux! 

Hopefully, if we go back and forth for a while, we can completely cover the ins and outs of all of these OS and create a nice platform independent chunk of C++ for all of us!

James. 

[drlava]

I don't know about windows API, you'd probably need to use DX for multi-channel in windows.

This is a much faster solution for you (in windows) that is already done:
EzAudDac API

If you want to go further, I'd suggest bypassing the windows API altogether and finding a direct interface to the sound card itself.  That sounds like an interesting project worth working on.

[Fanny Pack]

I pointed to you to the Window APIs for sound not too long ago.  You just need to research and use those.  I'll be happy to help if you have specific questions but I don't have time to write a tutorial.  I have said it before, but my original goal for Spaghetti was to use a sound card as a DAC and I almost had a streaming Win32 driver working for it but abandoned it when I got a great deal on a Moncha DAC.  Unfortunately, I can't find the source code for my driver.  It was essentially the same as what DrLava eventually came out with.  When I left off, I was having some buffering issues so there would be glitches in the output when streaming too fast.  It was 100% C using Win32 APIs and no DirectX.  DirectX isn't required at all.  It's only a wrapper around the Win32 function anyway. 

I can tell you that it isn't trivial but it isn't too hard, either.  The jist of it is that you need to set up your device and then build packets of WAV data and put them in buffers.  You have to keep feeding the buffers while they are streaming to the WavOut function.  You can send as many channels as you want but I think you have to send them in pairs or only 1.  (ie 1, 2, 4, 6, 8 etc).  Just leave the odd ones with no data if you dont need them I guess.

There are really only a handful of Win32 functions you have to use and I send you a link to that awhile back.  So, study the WavOut functions and if you have questions ask or google.  That's how I figured it out.  There are samples for streaming audio out there so there is code you can look at. 

Or, you can just use the EzAudDac API like DrLava suggests.  It will save you many many many hours of work.

[James]

That's cool.

I kinda' like "many many many hours of work" though. That's how I get satisfaction out of knowing exactly WTF I'm doing and talking about.

LaserBoy is a free, open source project with a GNU General Public License.

I don't think using drlava's driver is an appropriate fit for LaserBoy for that reason.

James. 

[Fanny Pack]

In that case go for it.  I'll be happy to help out.  If you are willing to use Visual C++ Express at least to get started and test the Win API I can help you since I can load your projects and share with you.  You can move the code over to whatever you are using later.  I just mention VC++ because I know it makes it easy to start the project. 

[drlava]

how 'bout what I said about skipping the windows sound API altogether?  That's what would make this really worthwhile. 

Maybe start here:

http://www.pcausa.com/Utilities/UsbSnoop/

the interface to the CM6206 ASIC should be a pretty straightforward data stream with control bits, perhaps in a header.  In this case, the learning would be less about windows API stuff and more about wdm stuff and it could benefit everyone, not just the people that want to avoid ezauddac.

[Fanny Pack]

I don't see how learning about a specific chip would do much good.  It would only work for that single device.  If you use the Win API you can talk to any sound device hooked up to a PC.

[BlinkenLights]

what about OpenAL
http://connect.creativelabs.com/openal/default.aspx

[James]

I plan on looking at OpenAL again. I looked at it a long time ago and it only did stereo. Now it says "Fixed 7.1". I'm not sure what that means.

Gotta' go eat!

James. 

[Fanny Pack]

Sounds like OpenAL is for 3D positioning of sound.  I imagine that the source material is actually two channel WAV and you specify the position of the source in respect to the listener and it converts it to multichannel sound based on that.  For example, if you said the sound was coming from the rear left it would mix it more to the right and rear channels.  Maybe you can just stream straight multichannel sound to it and let it send it out raw but it seems like a lot of bloat for that.

[James]

Yeah..... there is all of that and I'd rather have all of the code in my sources anyway.

James. 

[drlava]

I don't see how learning about a specific chip would do much good.  It would only work for that single device.  If you use the Win API you can talk to any sound device hooked up to a PC.

it's because cmedia will probably always have a simple multi-channel USB chip.  Future versions will likely be incremental updates as far as hardware interface goes.  By using the windows api you will always have the issues that you yourself complain about with dealing with sound card DACs.  What I'm supporting is an actual improvement in coding, not a re-creation of existing tech fueled by the desire to always say 'my code'.

[James]

fueled by the desire to always say 'my code'

E-Gadz Man!

I never said anything to the contrary of your idea.

If you want to do that, then have fun!

OK. So I like to say 'my code'. Is there a problem with that?

If I keep it all in one place then it's usable no matter what.

James. 

[Fanny Pack]

I'd agree with you but who is to say that cmedia will stay in business and continue to put out chips?  Or what if another player comes about?  It does no good for me if I want to stream from the realtek on my motherboard.  And, there is even no guarentee or any reason to believe, for that matter, that the cmedias transport media will be consisten from one chip to the next.  Afterall, you can't use the same cmedia driver with every cmedia chip.  So why would you expect to be able to use a driver you develop for one of their chips work for their next generation?  Any further, I expect that the data being sent to the cmedia devices is in packets so you will still have to buffer and send just as you do when you sent to the winapi.   What you would end up with is a cross platform driver for some USB soundcard that will probably be obsolete and unavailable to buy by the time you finish coding up all of the drivers for the various platforms. 

[Fanny Pack]

If you want to do some USB sniffing, buy one of those AlphaLites or whatever they are called for $150 and create a decent generic driver for it.  Then rebrand them and sell them for $200 and beat everyone.