> 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-
