I looked into the stop() error message problem, and I found one way that error message could occur. Basically what could happen is that if a source finishes playing, and then several other sources play so that the channel iterator gets back to the channel which that first source was playing on, and then if stop() is called on that original source, it checks to see if the source has a channel, which it no longer does, and therefore generates the error message. I believe I can solve this problem by setting the state of the first source to "stopped" at the time a second source is queued to play on the first source's channel. That way the stop() method will simply return since the source's state is already set to "stopped", rather than trying to stop the first source's channel to which there is no longer a handle.
That being said, I do NOT think this is what caused your problem, because as you mentioned, sound output disappeared after you got the error message. That can't be explained by the scenario I mentioned above, so I will continue to try and recreate the problem you experienced. It could be explained by a bug in the channel-iterator code, so I will go back and look at that again. One thing I was wondering, are you creating your sources as "priority" sources or just regular ones? Another thing I should take a second look at is the case where enough priority sources are playing that there are no channels available, and make sure there isn't any bug there.
Thanks for the great feedback, btw. Your descriptions of the bugs are thorough, which is very helpful.
-- EDIT --
Oh, one more thing in case you come across it, I fixed a small unrelated bug where an error message about a sound skipping was occasionally being printed when a streaming source reached its end. Simple logic error on my part. I had added this message in last minute, and before I posted the library, I hadn't tested it in the case where a stream actually reached its end.