[wdmaudiodev] Re: Race to set record sampling rate on KMixer / KS pin / soundcard

  • From: Waldemar Haszlakiewicz <waldemar.haszlakiewicz@xxxxxxxx>
  • To: Evan Lerch <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 4 Mar 2010 10:02:33 +0100

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 
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

Hope this gave you some ideas...


EL> Hi all,
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> 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> 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> 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> 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> 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> 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> 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


Other related posts: