On Wed, Mar 11, 2015 at 5:28 PM, David DeHaven <david.deha...@oracle.com> wrote:
> > > No, thanks for the hint. I just did and the behavior is a bit better in > the sense that the sample start is not cut off on subsequent play > invocations (behaves more or less line instantiating a new mediaplayer for > each invocation, which is good) but when I loop using setCycleCount the > sample start is also not clean (seams to be varying, though). > > > > For my uses case I will probably need both MediaPlayer and Audioclip, > because I have typical cases for AudioClip (e.g. short notification sounds) > and long looping background samples. > > > > Wow, I just discovered, that the behavior with the sample start sounding > different on the first invocation also happens when I play the sample using > the player integrated in Finder, so I owe you a big apology. I am sorry! I > can also no longer reproduce the looping failure after my last reboot :-S. > > No worries, these things just aren’t supposed to behave that way ;) > > > > Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low > enough to implement something like a drum kit using the keyboard. I don't > know if that is the benchmark you are after or if that is also a limitation > of the hosting system. I need to test that with other applications. The > latency I get with AudioClip is good enough for my current use case, though. > > Yeah, the current AudioClip implementation actually uses the same engine > as MediaPlayer, just in a slightly different way. The biggest difference > (aside from the one-shot interface) is it caches all the audio data in > memory. If you use uncompressed audio (aiff) it will be a bit faster. > > -DrD- > > One more question regarding this. Is it OK to have many instances of AudioClip or MediaPlayer if only a few of them actually play stuff or do they block audio resources even when they are stopped?
