fixed streaming issues - #1
Conversation
* Add serverUrl option for the NetConnection * Add oncomplete callbacks for when the connection is made * Updated README
… interface tries to play, but it needs a resume.
…ays being 0 for RTMP stream.
Fix skipping into the song when paused should play the song.
Add script to copy files into project.
…bugging is still enabled.
* Call onfailure once on failure & show message * Fix "pause before track load" problem by allowing the autoPlay variable to be set from JS * Simplify buffering. Initial buffer increased to 4 seconds, then 15 seconds.
Get streams working.
Fix resume for auto-loaded streams Remove some comments
Modify play() to take an extra option that skips updating the UI
… src/ for parsed source files.
…error can be thrown if a sound connects and goes to play while it is being destroyed. I think the event handlers are unbound and in play() we try to set the position which throws the error.
* More cleanup
|
There are a lot of changes in here, which I'll ultimately need to merge and test if I'm going to implement them. I'm not certain about Flash 10 at this point, among other things, but I need to review things altogether. I'll follow up with updates as applicable, etc. |
|
Ok cool. I wanted to keep my changes to a minimum, but one thing I did refactor was to move all the NetStatus and NetConnection management functions into SMSound. I remove/dummy the handlers when the sound is destroyed so that the logs aren't cluttered with info around a destroy. I noticed that you have a newer build out already. I was hoping to get the HTML5 changes etc. Any tips on the best way to go about trying to do that? Sometimes it's easiest to just compare the diffs on individual files and merge file by file. |
|
Keeping all your current changes (90 commits as above) and merging in the HTML5 stuff will be pretty difficult, I think. All HTML5 features are in soundmanager2.js, however, so you should be able to isolate the merging to that one file. I need to review all of your commits and see what makes most sense for the library as far as merging features - maybe it's worth having an RTMP-enabled build of the SWF, for example, to keep file size down a bit (or not, depending on how much it adds to file size) and so on. |
|
Hey Scott, Git lists 90 commits, but i don't think you want to go through all of them. 8af2dde: Merge with V2.96a.20100624: Incorporate latest SM2 JS which includes code to keep the Flash movie visible on mobile platforms. This is the point that I merged with V2.96a.20100624 JS. Then the next commit e0d152 I merged in the AS3. I think the commits from that point are fairly important because they are what I had to do to get it working with our streams. Regarding the HTML5 stuff, if it's all in the JS file then it should be pretty easy to merge in...the HTML5 stuff is quite well segregated in that file. |
|
Ah, good - that will save me some time then, getting it down to ~35 commits? ;) The RTMP bug fixes in particular will be most helpful. I'll review other changes to see what else is appropriate to merge back in - at this point, not sure about a Flash 10 build etc. If RTMP code grows a lot, I'm going to need to think about an RTMP-enabled SWF vs. keeping a single flash 9 SWF given it is still an experimental feature with a small number of users. |
|
Gah, OK, after much reading, this is looking pretty good, your changes look pretty reasonable, assuming I haven't missed a bunch of stuff. :) Nice. I've obviously never handled a pull request before, so I'm learning here. Will follow up once I figure out how the hell all of this works! I will need to do some QA on the API to make sure all the flash 8/9 MP3/MP4 (non-RTMP) stuff works after the merge etc., before I push all updates and so on. I assume you did some testing of the basics, but let me know if not and I'll go over things with a fine-tooth comb. |
|
This should be merged now, and hopefully I got everything merged correctly - there were a lot of conflicts to sift through between soundmanager2.js and the .AS files. I found one bug with multiShotEvents not firing for Flash 9 MP3 content, so I made a small change for firing onfinish() there.. Otherwise, I didn't see any obvious regressions. I had no idea how to merge a pull request, so I ended up finding and doing this. :D I think I can close out this request now, but let me know if there are obvious bugs etc. |
|
Awesome! I'm glad the merge went ok. It's a real pain sometimes I know. And thanks for the link. Regarding my testing. I've tested thoroughly with progressive-download MP3s and RTMP(e) streams. I tested things like changing volume, seeking, auto-playing, auto-loading, failures in streams & destroying sounds. I paid a lot of attention to playing & pausing at edge cases like before the sound has loaded or while it's being created but before connected (most of that applies only to streams cause MP3s load super fast). I haven't tested multiShotEvents for any sounds. I've confirmed mobile is working on Android; but HTML5 wasn't working "out of the box" on iPhone. I'm not sure if I need to enable HTML5 or not? Or do anything else? I'm hoping that we can open source our player code some day. It would be useful to the SM2 community. Cheers, |
|
Nice. I'm not familiar with pull requests as I mentioned, but it sounds like if you do a rebase with my repository before the pull request, then the merge should effectively be seamless and effortless on my part (?) If rebase does what I think it does (applying your commits one at a time to my latest?), that'd be very helpful in future as I spent a few hours merging everything manually and wasn't sure if I got absolutely everything, etc. :D the entirety of soundmanager2.js was marked as a conflict, for example, so I ended up going through it by hand. Apparently the YUI guys ask that people rebase before making pull requests for this reason, as it helps avoid these conflict situations. Re: Testing, that sounds great, thanks. I found one edge case with multiShot which I think I fixed, that was about it. Didn't notice anything else with the standard API, RTMP looked to be consistent from what I could tell. iOS4 (that is, firmware 4.0) on iPhone, and 3.2 on iPad should support HTML5. SM2 has useHTML5Audio = false by default, but flips it on for iPhone/iPad and the Palm Pre as they don't do Flash. The homepage demos should work on those devices. |
…layered / "chorused" playback if play() is called and multiShot: true has been specified to either createSound() or play(). Behaviour should mimic that of Flash 9. If multiShotEvents: true is specified, onfinish() will fire for each instance. Implementation summary: A new Audio(src) instance is created, with an onfinish listener, and played immediately. It is unloaded and destroyed when playback finishes. Caveat #1: If a position argument is provided eg., play({ position: 1000 }), the cloned Audio() instance must wait for a HTML5 "canplay" event before a seek and playback can begin. This may mean playback *could* have a slight delay vs. playing without the position offset. Caveat #2: The from/to parameters used for "sound sprites", e.g., { from: 500, to: 1500 }, are not presently supported under multiShot. Caveat #3: multiShot is not supported where only a single audio instance can be playing at once, e.g., iOS (iPhone/iPad) and some Android devices. Secondary instances are "fire-and-forget", similar to the Flash 9 implementation, and fire no events other than onfinish(). They do not respond to position, volume etc. after playback has begun. HTML5 unloading: Firefox was supposed to like assigning '' to Audio().url for canceling requests, unloading and destroying the decoder (perhaps only on <audio>, in retrospect?) - similarly, .src = null did not seem to work, possible request to ./ - undesirable. Now using more-conservative Audio().url = (isSafari && !is_iDevice ? null : (isFirefox ? emptyURL : null)); where emptyURL is user-customizable, 'about:blank' by default.
Added support for component.js
2 participants
Hi Scott,
This is a version V2.96a.20100624 merge with various bugfixes and changes.
See what you think. It's very stable. There were a number of problems that I fixed like instanceCount being too high, load() being called multiple times, and missing auto-load feature for streams (requires play then pause on buffer full).
I've added support for the 'position' option for streams to start a stream at a certain position. There is also a new bufferTimes option, onstats callback and ondebuglog callback. The README.rdoc has some info.
I hope that you're doing well. It's been a rainy past few days here.
Cheers,
Karl