Safari 11 / IOS 11 not supporting raw audio from microphone

[Kerry Davis]

Let me start by saying my code works on MacBook running Opera or Firefox or Chrome (but requires I disable a myriad of audio filters just to get raw audio from the mic).

Also works on Android in Opera or Firefox but not Chrome because the same constraints I used to disable the filters on my mac does not work in Android (for Chrome ONLY), resulting in my code only working on the lowest frequency band (below 10 KHz).

Nothing works in Safari, desktop or mobile and I could have sworn it at least partially worked just a month ago in Safari. Instead mic audio comes in only as a stream of 0's. And it is not just my code but also the demo code I got from https://webrtc.github.io/samples/src/content/getusermedia/volume/. The first run (on an iPhone) I seem to get audio data but it very quickly switches to a stream of zeros by merely hitting a breakpoint and resetting the web page with my JS code running in it.

Further, I have to use my own FFT on Safari simply because I need an analyzer node with minimum fftsize==32768. Which is fine for Chrome, Opera and Firefox but does not work in Safari 11.

1. Is there anyone that see the demo at https://webrtc.github.io/samples/src/content/getusermedia/volume/ working in Safari 11 (desktop or mobile)?

2. Any hint (for you apple web developers out there) as to if or when Safari 11 will actually support just the basic raw audio operation on both mobile and desktop Safari 11? (I can get by without the analyzer fftsize == 32768 for now)

3. Any hint (for you Android mobile Chrome web developers out there) as to if or when Chrome will actually support just the basic raw audio operation on mobile as it does now on desktop (Mac and seemingly PC based desktops)? 

In case it is not apparent, I am transceiving and demodulating short digital audio packet bursts at multiple bands.

In more detail, I just need a continuous stream of mic audio sampled at either 48KHz but preferably 41.1KHz that works on iPhone, Android and desktop. I have working Chrome Extension that can both send and receive and of course similar code to the extension runs in a website for both Mobile and Desktop (Except for the Chrome over android and Safari everywhere examples mentioned above).

Also, any clue as to who in Apple or Google that I can bug (in the kindest of ways possible) to actually get traction on this would also be helpful.

[PhistucK]

Any difference between browsers (whether across platforms or on the same platform) is usually a bug. The right thing to do, either way, would be to file an issue at crbug.com for the Chrome for Android case and at bugs.webkit.org for the Safari case.

You may also get further guidance and workarounds here, but the code should generally work everywhere (unless it is relying on a hack or nonstandard behavior, obviously). That is one of the goals of browsers nowadays.

☆PhistucK

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/0585c07c-7978-4702-8c06-9ff20257ac44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kerry Davis]

yep filed bugs everywhere i could months ago including the two you mentioned. Also posted on twitter. Not being able to get raw unfiltered audio from the mic is such a basic feature. It's not even really (or shouldn't be) a constraint parsing thing. I have been involved in a lot of standards processes and it is so obvious that without any constraints to a communications/signaling resource should result in a raw feed of that signal or resource. But with the one exception of desktop Chrome, this is not the case and to me that is a bit shocking. For Firefox, Opera mobile or desktop, you have to literally turn the filters OFF to get raw audio. And if you design the standard that way then you just massively increased your testing problem not to mention reliability across hardware platforms. If you don't have a solid base to any platform for even the basic features, the problems will ripple upward and outward.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.