Hi Evan Now I wont be able to help you here, but will explain a little how sounds cards get requests for the format below (at least for AVStream type of drivers)... maybe phones and other low quality converters have different workings... Anyway first every pin on the driver can have a function called AaudioIntersectHandler which system uses to get a range of supported ranges (sample rate, bit size,..). Then there is another more runtime specific SetDataFormat which acts on pin directly and is used to check if pin can handle exactly requested connected format. If it does normally the pin is opened with requested format. Now at this position an already opened pin can again get a call to SetDataFormat, but with different format and it again decides if format can be handled and it makes necessary adjustments to support it. Or the pin can get a start request. So if you are getting an 8kHz limit I doubt it that this is a limitation of mixer... On the other hand you said that this only happens if 8kHz application is started first... put 16kHz application in StartUp icon with silent flag which would only start the 16khz audio and the stop it and exit. Hope this gave you some ideas... Peace Waldemar EL> Hi all, EL> EL> I am faced with a situation where my users must use two independent software applications throughout the day: the EL> first application (a phone) records audio at 8kHz and the second application (an automatic transcriber) records EL> audio at 16kHz. I am an engineer responsible for working on the transcriber application. EL> EL> My problem is that if my users launch the phone first, Windows initializes the sound system to a sampling rate of EL> 8kHz. When the users subsequently launch the transcriber, the transcriber requests 16kHz audio from the sound EL> system. The sound system provides a 16kHz audio stream, but it is really 8kHz audio resampled by KMixer to 16kHz. This results in an unacceptable loss of audio quality. EL> EL> I need to find a way to programmatically detect this situation. Upon detection I would warn the user and provide EL> problem resolution instructions. Something like "please launch transcriber first, phone second." EL> EL> My question is: can you think of a way to programmatically detect this situation? My first thought was to run FFT EL> analysis on the recorded audio and look for relatively low amplitude in the 4kHz+ range. However, this approach EL> isn't very deterministic, and the heuristics would be tricky to implement. EL> EL> What I'd really like is some way to query the Windows audio subsystem to try and determine definitively what's EL> going on. So I started learning about the Windows audio subsystems. I gave up pretty quickly on waveIn, waveOut EL> and DirectSound: they are too high level and don't know about what KMixer and KS are doing behind the scenes. I EL> looked into KMixer a bit, but it has no documented APIs. EL> EL> I then started looking into Kernel Streaming (KS), which has a huge API. I started modifying the DirectKS example EL> application to query filters and their pins for information. I tried many approaches to querying the exposed KS EL> filters and pins, with no luck. The KS APIs just seem like they aren't designed to help an external observer query EL> for detailed status information; they're more designed around a participant in the system. For example retrieving EL> certain pin properties requires a handle to the pin, and there is no way to get a list of instantiated pin handles. EL> The information that can be retrieved without pin handles seems unhelpful: the format intersection information EL> doesn't seem to change based on the pin's state. Some devices update their pin's GLOBALCINSTANCES property, but EL> others don't. KSPROPERTY_CONNECTION_DATAFORMAT seems like it can only be set, not retrieved. EL> EL> I'm not very hopeful about finding an elegant solution to detecting this situation. But, I've seen that there are EL> a lot of knowledgeable people here and I thought it might be worth a query. It seems like the problem might be EL> relevant to others as well, since the problem can exhibit with any two programs which want to record at different sampling rates. EL> EL> thanks! ****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/