0

I'm using WASAPI to capture and render audio for a VoIP application on Windows Phone 8. The app works fine when using the earpiece, but as soon as I switch to speakerphone, a distinct clicking noise appears on the far end. Looking into the timing of my system, I found that after I switched endpoints to speakerphone the mic hardware timer starts to act weird.

My audio loop starts with a WaitForMultipleObjectsEx which is woken up every 10ms by the mic capture event. After switching audio endpoints, I find this this event fires 101 times in 1 second, instead of 100. Every second, the last capture of 480 frames is split into 2 captures, whose timings add up to 10ms. This confuses me to no end, and is causing problems in my audio system. Does anyone know what is going on, or can someone point me in the right direction?

HarryHippo
  • 267
  • 1
  • 2
  • 9
  • Could be that you're experiencing clock jitter. In practice no hardware audio clock is going to run at precisely the sample rate you're asking it to. In any case it's a good idea not to rely on a perfect clock in your code as your bound to hit problems eventually. What is the actual problem that you're running into? – Sjoerd van Kreel Nov 18 '13 at 20:02
  • The actual problem is the clicking noise present in the far end when I switch the near end to speakerphone. Its unbearable. The thing is, the timing runs perfectly fine before switching audio endpoints (exactly 100 loops in 1 second), so I'm wondering where this change could come from. – HarryHippo Nov 18 '13 at 21:08
  • What exactly do you mean by near and far end? I know WASAPI pretty well but that's on desktop, I don't know the first thing about windows phone development. Any chance you can post some sample code? – Sjoerd van Kreel Nov 18 '13 at 21:15
  • Near end is the phone running the application, far end is the endpoint device on the other end of the call. I'll look into getting a code sample up soon. WASAPI for WP8 works similarly to that of the desktop, but the main difference is the amount of features available. – HarryHippo Nov 18 '13 at 22:15
  • Ok, so if I understand correctly you're always capturing on one device (near) and rendering on a second one (far), either to the earpiece or the speaker? Or are you capturing and rendering to and from the same device (near) in the first case? Also, are you using shared or exclusive mode? What happens when you increase latency, does it get any better? – Sjoerd van Kreel Nov 18 '13 at 23:07
  • My application has full duplex audio (its a VoIP app), but the only noticeable problem is perceived on the far end (the clicks) when the near end switches to speakerphone rendering. WASAPI is in shared mode, and the architecture of my application is akin to that of Chatterbox, MSFT's sample VoIP app -- expect my application truly does VoIP, not just loopback audio – HarryHippo Nov 18 '13 at 23:37
  • Thanks for the help, Sjoerd van Kreel, but I'm deciding to move on with a workaround for this problem. I'm embracing the extra capture, but discarding its data instead of using it. I may end up revisiting this, though. – HarryHippo Nov 19 '13 at 18:02
  • Ok, so it's full duplex on both sides. Are you using WaitForMultipleObjects to wait on both the capture and render event? In that case I think your best bet is to not use WaitForMultipleObjects but instead split your system up into 2 threads, one for render, one for capture, and use WaitForSingleObject instead. This way you avoid blocking input while waiting for output to be ready or vice versa. In any case you can never rely on these audio events being fired exactly every 10ms. One more thing that occurred to me, is it possible that you're somehow picking up static from the speaker phone? – Sjoerd van Kreel Nov 19 '13 at 18:05
  • Hey, you just beat me to it. Allright, good luck with it. – Sjoerd van Kreel Nov 19 '13 at 18:06

1 Answers1

0

MSFT is officially looking into a bug in WASAPI caused by multiple endpoint switches. It is confirmed on RT and being investigated for Wp8. Just an update.

HarryHippo
  • 267
  • 1
  • 2
  • 9