Yes, I check every 5ms, and I use 2 buffers, 1st is the dma buffer and 2nd is a copy of the previous audio data so when I compare the 2, I know how much new audio was overwritten the style audio. I then wait til theres 10ms of free audio and start reading, every so ofter checking I am now too close or too far. With Vista it's buffer was 69ms long, but Win7 was 20ms ( 2x 10ms) that was very hard to get right until I learnt to increase the mutlimedia timer to support 5ms reading/ checking times.
I am aware that setting at the end of every poll the thread the media timer to 5ms will be a little more of a drain on battery life, but it had to be done to prevent the out of sync / overlapping new & old in a 10ms read cycle.
Also as a side note, I once asked where to get the audio format, and I was told it one of the properties being past. I found it is actually in IRP_Create request in stack->FileObject->FileName.Buffer. Using the format:
#pragma pack (1)
struct CreatePinRequest {
WCHAR szPath[39]; //{[KSNAME_PIN]}\
KSPIN_CONNECT pinConnect;
union {
KSDATAFORMAT ksData;
KSDATAFORMAT_DSOUND dsData;
KSDATAFORMAT_WAVEFORMATEX wfData;
} Format;
};
Thats correct for XP/Vista/Win7. (Of course it's technically possible
for it not to be a DSOUND/WAVEFORMATEX format, but thoses unique / rare
formats I can't handle in my app anyway.)
Cheers Obble. On 8/01/2010 1:05 PM, Tim Roberts wrote:
NCH Obble Smith wrote:May I ask why that can't be done? As I have done it in my audio filter that runs in XP/Vista/Win7. With Vista/Win7, it reads from that DMA buffer.So, you're chasing the buffer circular pointers? That's dangerous, isn't it? You don't net notifications when the pointers move. Are you polling?
****************** 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/