Interesting reading through this discussion... I'm not sure how
contribute until I get access to the iPad or the emulator, but one
thing did spring to mind.
jPlayer does not add the new Audio() object to the HTML until after
the first play command is issued. Adding the new Audio object to the
HTML is like adding an <audio> tag, but it solved a problem with the
operation in Opera, which did not like us just adding the <audio> tag
and required the new Audio() created first and then added.
So... My thinking is, the <audio> is not present when the user touches
play that first time. Once the <audio> tag is in the page once, the
iPad accepts the following play commands. Which was why Michael did a
JavaScript play and then pause for the iPad.
I am not sure why the next button works *before any other touch
command given* ie., before clicking the play button. I assume it works
after a play button was clicked because an <audio> was in the actual
page and is just being replaced when you click next and then auto-
playing via JavaScript.
In jPlayer, the <audio> HTML is not added to the page until the play
command is given, because some HTML5 browsers were pinging the audio
file the moment the <audio> element appeared in the page, regardless
of whether it was to play or not. This was annoying some jPlayer
users, who did not want the audio file touched at all before the file
was actually played. I believe it was Firefox that was the worst
offender here, pinging the OGG files 3 times before you even tried to
play it.
At the moment, jPlayer checks for IE browsers and does something
special for them... Maybe we need to review the case for the iPad and
iPhone bowsers so that the <audio> element is added to the page
immediately and not delayed until the user clicks play. This would not
affect the auto-play at initial page load, since a user touch would
still be required. ie., the external JavaScript must not try and auto-
play on the iPad.
This auto-play problem is related to the onSoundComplete auto-playing
the next song. Again, a user touch is required to cause the audio to
play.
It is not helped that the HTML5 draft spec does not allow for feedback
from the HTMLAudioElement.play() command. It simply returns a void in
all case. Unfortunately, this means that jPlayer is oblivious to
whether it actually worked or not.
Best regards,
Mark P.
On Apr 30, 4:33 am, Jordan Robert Dobson
> ...
>
> read more »