<p>Hi Justin,</p><p></p><p>while I&#39;m not a Mono or Banshee developer, so I do not know details about what&#39;s in store for Mono.Media. However, I am very interested in this project and the potential impact it will have on projects like OpenTK and the Tao framework.<br>
</p><p></p><p></p><p></p><p></p><p>To my mind, the codec / backend separation is extremely valuable. Ideally, Mono.Media will be able decode audio streams to a raw PCM data, which would then be fed to a (pluggable) audio backend. Mono.Media should probably ship with a few default backends (probably the ones currently used by Banshee), but developers should be able to write and plug in their own (e.g. OpenTK.Audio or Tao.OpenAL). <br>
</p><p>My other suggestion would be to make the library thread-safe, but *not* add any implicit threading code in Mono.Media itself. Threading should be handled on the application level, i.e. Mono.Media functions should be blocking unless users will be able to thread operations explicitly (using background workers, thread pools or some such). Take a look at JMF, where every operation executes asynchronously, as an example of what to *avoid* in the API (there&#39;s a reason that library is dead :) )</p>
<p></p><p>Gapless playback is also nice, but imho this, too, belongs at the app level.</p><p></p><p>Just my two cents :) I&#39;m definitely going to keep a close eye on this project - and once it comes to that, you can count on me writing an OpenTK.Audio backend for Mono.Media.</p>
<p>Good luck with your application!</p><p>Best wishes,</p><p>Stephen A.<br>
<br>
<br></p><br>