Having multiple APIs isn't too much of a problem. Having poorly designed multiple APIs is a pain, but can usually be overcome. Having poorly designed multiple APIs that each return different values is a deal killer. This is the case for requesting supported sample rates from an audio device. Many times, the device simply replies that it can handle all "normal" sampling rates (8000, 11025, 16000, 22050, 44100, 48000, 96000). However, when you open the device using some of the faster or more obscure modes (basically, not 44100 or 48000), you can get some strange results.
How much of this is the device drivers fault and how much is due to the poor API design is up for discussion. But the only reliable way that I know of (and PortAudio has found the same) to figure out whether an audio device supports a particular sample rate in windows is to open a stream and try it out. If it fails, it is not supported. This is not a good solution, but it is the only one that I am aware of that gives consistently correct results. Eric Wachsmann FlexRadio Systems > -----Original Message----- > From: Jim Lux [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 05, 2006 1:41 PM > To: Eric Wachsmann > Cc: flexradio@flex-radio.biz > Subject: Re: [Flexradio] Anyone know how to debug into the Native code > from PowerSDR > > At 08:06 AM 9/5/2006, Eric Wachsmann wrote: > >In PortAudio's defense, they do this because the combination of Windows > and > >the hardware drivers yield unreliable information when using the > traditional > >means of finding what sample rates a device supports. > > > And, in fact, this is a sticky point for Windows multimedia in > general, which makes it mind-bendingly-complex to navigate through > all the stuff. They try to provide interfaces at all levels of > abstraction, while accomodating developers that want a lot of control > over the audio (and video) rendering of their streams. This means > that Windows provides all sorts of filtering and rate conversion > stuff that "can be" transparent, or, which defined in a myriad of > data structures and API calls. > > For instance, in DirectShow 9.0 You have the AM_MEDIA_TYPE structure > which contains the AUDIO_STREAM_CONFIG_CAPS structure which is > retrieved by the IAMStreamConfig::GetStreamCaps method. > > There's also a variety of things available (the whole Presentation > Clock mechanism) to synchronize multiple streams (to 100 ns > resolution, if not accuracy) > > But, all this stuff requires a substantial time investment to really > figure out what's going on. And, of course, it's all changing as we speak. > > > There's a big transition in how various media get handled in Windows > from the old style "call device driver and feed queue of buffers" > sort of model (with all the workarounds, DirectX, etc. to get > streaming media to work at all, in the context of the usual "one big > event loop" windows application programming model) to a more > consistent multiple synchronizable streams of media that get routed > from here to there with various processing blocks that's needed to do > such simple things as play a DVD (where you've got to have the video > and audio align) and allow users to do things like have graphic > equalizers, video processors, and Codecs (not to mention digital > rights management). > > The latter stuff is important for lots of applications that MS wants > to be able to suppor. A nice commercial example is video > conferencing with multiple microphones used to determine how to > automatically point the camera at the speaker. Not only do you do > adaptive processing to steer the acoustic beam to suppress > interference, but you also process multiple overlapping video images > to do a "virtual zoom" to the current speaker. So it's not all > directed at video games and movies... > > > > > _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
