Audio is not working on iOS / Safari (with no mp3 support)

[mlchevallier]

Hi,
I'm trying to make the audio work on my iPad / iPhone (with Safari), but it doesn't. The audio button renders the "loading" image after clicking it, but it stays in this state and no audio is played. The HTTP request is well processed (I checked in the Apache's log), and no error is triggered in the outputAudioFile() method either. I also tested using the "captcha.html" file provided with the package, and it doesn't work too (whereas everything works well on my computer, using Chrome, Firefox or MSIE). I've tested the demo on the phpcaptcha.org site, and I have no issue with my iPad. The only difference between your site and my server seems to be that Lame is not enabled on my side, so only wave audio is supported. Is that the point? Are iOS devices only supporting MP3 audio files?
Could you please check out that the audio works for you on iOS if the MP3 / Lame support is not available?
Thanks a lot for your help.
ML.

[dapphp]

This page would seem to indicate Safari on iOS supports uncompressed WAV.

Safari on iOS (including iPad) currently supports uncompressed WAV and AIF audio, MP3 audio, and AAC-LC or HE-AAC audio. HE-AAC is the preferred format.

Would you mind going to http://hpr.dogphilosophy.net/test/ on the device it isn't working on and pressing the "click to try it" button next to the wav format and let me know the result?

[mlchevallier]

I've run the test as you asked on my iPad: the wave audio file is played correctly.
In the outputAudioFile() of the Securimage class, I've also tried to make falsy the extension_loaded('zlib') test to avoid the zlib compression, but it doesn't work better.

[dapphp]

Thanks for confirming wav on the test site played on the iPad. I don't have access to one but am having someone try it on another site with wav only to see if it works.

If you try it on your iPad at this url is it also not working? That page should present only a wav audio source and I made sure it works there using Chrome on Windows & Linux as well as Chrome on Android and the Android stock browser.

Thanks.

[dapphp]

Okay I figured out the issue. Apple devices and/or Safari sends a "Range: 0-1" header when it wants to download media and since the response doesn't reply with the appropriate range, it essentially discards the response without any indication of it.

I will be implementing a change to support range requests for audio files that will store the audio data in the session (due to open_basedir and possible file permissions issues writing to tmp or other directories on some systems) so the audio file can be sent in ranges without corrupting the audio stream since the files are dynamically generated and don't exist on the filesystem anywhere.

Stay tuned.

[mlchevallier]

Thanks for investigating about this issue. I've tried the audio provided in the page you gave me (https://www.phpcaptcha.org/securimage/example_form.php) but it doesn't work on my iPad. But it seems that you've already figured out why.
Please keep me posted about the change you are ready to make, and don't hesitate contacting me if you want me to run some tests.

[dapphp]

Hi, if you wouldn't mind running some tests I have some code ready. Unfortunately I don't have physical access to an iPod/iPhone/iPad so I've been bugging a friend remotely to hit a test URL while I run a packet sniffer to see how it works.

He says it's working fine on his end but I am observing some weird range requests from his device that aren't making much sense. When I run some command line tests simulating different range requests and scenarios they work as expected. Just can't quite figure out what his phone is doing but I want to make sure it's working reliably before I release the update.

If you are able, for starters, you can test at https://www.phpcaptcha.org/securimage/example_form.php

This url will only return WAV files (will test mp3 later) and will respond to range requests.

I think some good tests are:
Load the page, play the audio, make sure it plays back properly in full (try this 5-10 times)
Load the page, refresh the image, play the audio, make sure it plays back properly, and then refresh the image and replay the audio 5-10 times to make sure it works with refreshes.

If it seems to work well in those cases I can probably move on to clean up and release the code.

Thank you, your help and feedback is much appreciated.

[mlchevallier]

Hi, I've run the tests as you asked. Unfortunately, it doesn't work for me (tested on both iPad - iOS 9.0.2 and iPhone - iOS 9.0). When I click the audio button, it switches to the loading icon (without rotating - but this is a detail), the "network loading" icon is played at the top of this iPad (so an HTTP request is being sent), but it never stops loading and the audio isn't played. Nothing else works by then: I'm not able to refresh the image using your refresh icon, neither refresh the whole page using the refresh button of Safari. The page starts to be loaded (according to the progress bar of the browser), but it is never completed. I'm also not able to open a new tab and then access your testing page again: the browser starts to load it, but without any success (like after a refresh). I have to close the browser's tab, quit Safari (force the application to close) and then restart it to access your page again. But the audio is still not working... I've also tried as you asked to start by loading a new captcha before playing the audio, but the result is still the same...
Thanks a lot for digging this out, and let me know if I can run some other tests for you.

[dapphp]

Hi again,

I made some revisions, had someone test on an iPad running iOS 9.0.2 as well as an iPhone on 4G and they said that it worked. I also tested on an iPod touch running 9.0.2 and it worked.

Would you mind trying again at http://www.phpcaptcha.org/securimage/example_form.php when you can? HSTS may prevent it from loading over http but that's okay.

This URL is working with range requests on Android 4.4.2 using Chrome, Firefox, and the native browser. It is also working in Iron (chromium) on Linux, and Firefox on Linux which send open ended range requests.

Hopefully now it'll work for you.

Thanks!

[mlchevallier]

Hi,
I've just tested your changes. It worked! But like you asked before, I ran several refreshes of the image and then played the audio file again. It worked nice, but after a few tests (4 or 5 maybe), I wasn't able to play the audio. Like before, I had to completely close Safari to restore the access to your page. The first launch of the audio was successful then, but this was the last time. By then, refreshing the image or re-accessing completely to your site never let me play the audio again :( It sounds like an HTTP request to your site is still pending and so no other one is authorized by then. I'm so sorry to tell you that. I've run the test on my iPad with iOS 9.0.2. Maybe you'll be able to see something in your log files?
I've just tested it on my iPhone before submitting this post, but I wasn't able to make it work at all. Maybe there is something on your server's side that blocks the requests after several times?
Thanks a lot for your time...!

[dapphp]

Thanks for checking. I'm glad it worked at least partially, it's a start.

What must be happening is that after one of the requests, a PHP request doesn't end correctly (maybe specific to running as a CGI on my server) and the session stays locked which will cause subsequent requests to hang as it waits for the session file to become available.

I have observed some odd behavior I can honestly say I don't understand (especially if you are testing over a mobile network).

What I see in my tests with iOS (I can only see your basic requests since I am not running any packet logging on that server) is a sequence of requests that looks like this:

Browser request: bytes 0-1
Server response: bytes 0-1/n (n = audio file length)
Browser request: bytes 0-(n-1)
Server response: bytes 0-(n-1)
Browser request: bytes 253952-(n-1) (a chunk towards the end of file, not always the same values)
Server response: bytes 253952-(n-1)
Browser request: bytes 9576-253951 (large chunk from beginning of file towards end of file)
Server response: bytes 9576-253951/n

Every time I've had someone test with iOS I see this behavior over WiFi and mobile. My packet traces show it sends the entire file, then the two large chunks again so the entire audio file is sent almost twice (which seems inefficient especially over mobile). My best guess is that this is done as some method to try to assure reliable streaming (in case the first request for the entire file stalls or has high latency) but overall it's using almost twice the bandwidth for the client and server.

Probably in your testing of multiple refreshes and playbacks, these crossed up requests might have caused the device to keep one of the connections open. In any case, if I call session_write_close() as soon as possible in regards to audio streaming, it should prevent the hangups from occurring (this won't be an issue with database only storage either).

I may just add that session change in and make a release or see if you can test again before doing so.

Again, I really appreciate your time and feedback on the matter.

Update: I checked my server logs and I see some problems while you were testing. I am using a less-than-ideal FastCGI configuration which might explain the problems you ran into and I think are totally unrelated to the PHP code, it just happened to break your tests.

It looks like Apache tried to restart around the time you were testing and that may have caused problems. In any case these errors correspond to you and seem to be server issues.

[Mon Oct 12 00:31:55.785330 2015] [fcgid:warn] pid 24022:tid 140197538772736Connection reset by peer: [client 92.xxx.xxx.xxx:51618] mod_fcgid: error reading data from FastCGI server, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:31:55.785415 2015] [core:error] [pid 24022:tid 140197538772736] [client 92.xxx.xxx.xxx:51618] End of script output before headers: securimage_play.php, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:32:50.265132 2015] [mpm_event:notice] [pid 24739:tid 140197927483328] AH00493: SIGUSR1 received. Doing graceful restart
[Mon Oct 12 00:33:01.628354 2015] [fcgid:error] [pid 24017:tid 140197927483328] FastCGI process 24600 still did not exit, terminating forcefully
[Mon Oct 12 00:33:01.628445 2015] [fcgid:error] [pid 24017:tid 140197927483328] FastCGI process 24617 still did not exit, terminating forcefully
[Mon Oct 12 00:33:01.628464 2015] [fcgid:error] [pid 24017:tid 140197927483328] FastCGI process 24618 still did not exit, terminating forcefully
[Mon Oct 12 00:33:01.628489 2015] [fcgid:error] [pid 24017:tid 140197927483328] FastCGI process 24628 still did not exit, terminating forcefully
[Mon Oct 12 00:33:01.628501 2015] [fcgid:error] [pid 24017:tid 140197927483328] FastCGI process 24630 still did not exit, terminating forcefully
[Mon Oct 12 00:33:01.628515 2015] [fcgid:error] [pid 24017:tid 140197927483328] FastCGI process 24648 still did not exit, terminating forcefully
[Mon Oct 12 00:33:01.628527 2015] [fcgid:error] [pid 24017:tid 140197927483328] FastCGI process 24655 still did not exit, terminating forcefully
[Mon Oct 12 00:33:01.628539 2015] [fcgid:error] [pid 24017:tid 140197927483328] FastCGI process 24670 still did not exit, terminating forcefully
[Mon Oct 12 00:33:01.632377 2015] [fcgid:warn] pid 24018:tid 140197643671296Connection reset by peer: [client 92.xxx.xxx.xxx:51644] mod_fcgid: error reading data from FastCGI server, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.632452 2015] [core:error] [pid 24018:tid 140197643671296] [client 92.xxx.xxx.xxx:51644] End of script output before headers: securimage_show.php, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.632495 2015] [fcgid:emerg] pid 24018:tid 140197643671296Invalid argument: [client 92.xxx.xxx.xxx:51644] mod_fcgid: can't lock process table in pid 24018, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.632898 2015] [fcgid:warn] pid 24022:tid 140197507303168Connection reset by peer: [client 92.xxx.xxx.xxx:51640] mod_fcgid: error reading data from FastCGI server, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.632968 2015] [core:error] [pid 24022:tid 140197507303168] [client 92.xxx.xxx.xxx:51640] End of script output before headers: securimage_play.php, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.633023 2015] [fcgid:emerg] pid 24022:tid 140197507303168Invalid argument: [client 92.xxx.xxx.xxx:51640] mod_fcgid: can't lock process table in pid 24022, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.634002 2015] [fcgid:warn] pid 24020:tid 140197486323456Connection reset by peer: [client 92.xxx.xxx.xxx:51667] mod_fcgid: error reading data from FastCGI server, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.634039 2015] [core:error] [pid 24020:tid 140197486323456] [client 92.xxx.xxx.xxx:51667] End of script output before headers: securimage_play.php, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.634066 2015] [fcgid:emerg] pid 24020:tid 140197486323456Invalid argument: [client 92..xxx.xxx.xxx:51667] mod_fcgid: can't lock process table in pid 24020, referer: https://www.phpcaptcha.org/securimage/example_form.php
[Mon Oct 12 00:33:01.635497 2015] [fcgid:warn] pid 24019:tid 140197643671296Connection reset by peer: [client 92.xxx.xxx.xxx:51645] mod_fcgid: error reading data from FastCGI server
[Mon Oct 12 00:33:01.635534 2015] [core:error] [pid 24019:tid 140197643671296] [client 92.xxx.xxx.xxx:51645] End of script output before headers: example_form.php
[Mon Oct 12 00:33:01.635557 2015] [fcgid:emerg] pid 24019:tid 140197643671296Invalid argument: [client 92.xxx.xxx.xxx:51645] mod_fcgid: can't lock process table in pid 24019

[dapphp]

I went ahead and released a new version, 3.6.2, to address this issue as I think it is working.

I am going to try to upgrade my server in a couple of days to fix the CGI issues that I think were affecting your tests. In any case, you can try again at https://www.phpcaptcha.org/securimage/example_form.php and see if it's any better now if you wish.

Thanks again.

[mlchevallier]

Hi, I've just run a dozen of tests on my iPad and... all worked well! That's great! I admit I've just refresh the image a dozen of times, not fully refresh the page nor restart Safari, but I think this is enough to conclude that all is OK.
Congratulations for your patience and for all your work! I was a pleasure to help you fixing that. Don't hesitate in the future if you want me to run some other tests of this kind.

[dapphp]

Very happy to hear it, thanks again for all of your help!