LaserBoy
Software => Joint Development => Topic started by: James on November 18, 2009, 04:59:13 pm
-
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! ;D
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. :)
-
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 (http://hacylon.case.edu/laser/EzAudDac/EzAudDac_Sound_Card_Laser_DAC_API_notes.pdf)
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.
-
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.
-
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. :)
-
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.
-
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.
-
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.
-
what about OpenAL
http://connect.creativelabs.com/openal/default.aspx
-
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. :)
-
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.
-
Yeah..... there is all of that and I'd rather have all of the code in my sources anyway.
James. :)
-
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'.
-
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. :)
-
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.
-
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.
-
I think it's always best to generisize as much as possible.
I also do not believe that C-Media will always be the best choice of super cheap 7.1 sound devices.
James. :)
-
I just get frustrated because I see it a lot in open source projects, lots of people re-creating the wheel when their energies could be spent toward revolutionary improvements. I don't have the desire or time to do the direct interface on my own, but feel that we could accomplish it together and learn a lot in the process.
-
I just realized that by going to USB as you suggest for the cmedia card you would eliminate all of the windows config nightmare that I hate. But, you are still stuck with a single driver for a single chip so I don't think it would be worth it... unless you could buy a couple hundred of them and sell them as laser DACs with your driver. That isn't a bad idea actually.
-
exactly! AND it could be set up to support multiple units of the same kind at once!
No it's not a bad idea, and did you know that the cm6206 drivers also work with cm106? there are only so many ways to slice and dice 8 channel streaming data to USB. Their future chips I expect would only require minor changes for compatibility. Sure it would need software buffering like what I do now but that's no big deal, it's a given.
-
Well, you kind of have me interested in doing it just to see if it can be done now. I have no idea how to write to a USB port without using something like a FTDI driver or virtual com port, though. Also, when the device is detected by Windows it will want to install a driver. I guess you would have to make it install your fake one instead and communicate through it. I am not sure how that works but everyone is doing it so it can't be too hard to figure out.
-
Looks like a DDK must be downloaded. It includes the compiler and samples.
http://www.osronline.com/article.cfm?article=20
-
Yea, that part is pretty well documented. It's the part about writing to the USB port that puzzles me. I don't recall the data sheets for those devices saying anything about it but I haven't looked at one in a long time.
-
Well, looks like there is some sort of standard USB audio device spec for all audio USB devices. I found this pdf http://www.usb.org/developers/devclass_docs/audio10.pdf that talks about it. Over 100 pages of mumbo jumbo. I think I will go back to doing what i was doing now. LOL.
-
The good thing is that most of that doesn't apply, for this an audio streaming endpoint and HID endpoint are what is needed. It does look complex, there must be an audio driver example code out there that would help