Re: [Banshee-List] Thinking about Mono.Media

["Brian Kerrick Nickel" <brian nickel gmail com>]

I would imagine MediaPlayer.Play would work best as an asynchronous function, calling a worker thread to handle playback. Rather than signaling CrossFadeTo after every song, we could queue up songs and mark a standard transition.

 

AudioSource a = new AudioSource("/home/test/Music/song.mp3");
AudioSource b = new AudioSource("/home/test/Music/song2.mp3");

MediaPlayer m = new MediaPlayer();

m.Transition = Transitions.CrossFade;

m.TransitionTime = TimeSpan.FromSeconds (5);

m.QueueSource (a);

m.QueueSource (b);
m.Play ();

 

- Brian
 

On 22/02/2008, "Andrés G. Aragoneses" <knocte gmail com> wrote:

My 2c: I agree with Vladimir because I was going to propose something
similar (the basic idea is to have in mind the Responsability Pattern:
an audiosource object should not know how to "play" or "crossfade"
something, so a Player class is created for that). The last thing I
guess Vlad forgot to tell about this proposal is the immutability of the
AudioSource object (it's somewhat predictable from his code snippet).

Keep up the good work!

Regards,

       Andrés  [ knocte ]


Vladimir Dimitrov escribió:
> Hello guys,
> I am very excited about the idea of having this library and just wanted to
> give an idea how things might be designed
> 1. We can have a general base class for a media source (MediaSource for
> example) that can supply information about the audio (video) file and
> possibly about the codecs and backends used to play it.
> 2. Then we can have an AudioSource object that inherits that class and is
> used like this:
>
>         AudioSource a = new AudioSource("/home/test/Music/song.mp3");
>
> 3. The MediaPlayer class can have a propery "Source" that you set with the
> created audio source. This way the MediaSource object can have a singleton
> collection of all the backends that are currently loaded and reuse them
> respectively. This way we separate the player and the media source and it
> sound clearer to me when we call.
>
>       AudioSource a = new AudioSource("/home/test/Music/song.mp3");
>       AudioSource b = new AudioSource("/home/test/Music/song2.mp3");
>
>       MediaPlayer m = new MediaPlayer();
>       m.Source = a;
>       m.Play ();
>       m.CrossFadeTo(b);
>       m.Stop();
>
> Of course somebody can try doing cross fading of videos with this which can
> be a little more difficult :).
>
>
> -----Original Message-----
> From: banshee-list-bounces gnome org [mailto:banshee-list-bounces gnome org]
> On Behalf Of Scott Peterson
> Sent: Thursday, February 21, 2008 10:38 PM
> To: banshee-list gnome org
> Subject: [Banshee-List] Thinking about Mono.Media
>
> Equipped with my shiny new copy of Framework Design Guidelines, I've
> begun to mentally revisit the idea of a Mono.Media design. This is
> just a rough idea about how things could work. I've got some broad
> goals for the namespace, then ideas about the shape of the API. I'll
> present the API ideas in the form of code that a Mono.Media user would
> write to accomplish some task.
>
> Briefly, I think the scope of Mono.Media should include three major
> areas and two domains. The domains are audio and video, and the areas
> are playback, transcoding, and profile description (audio profiles,
> &c.). Brief indeed! So those are the goals I had in mind. Others are
> welcome.
>
> API design: I've given the most thought to the audio playback API b/c
> I think that will be the top use of the framework (and it's
> predominantly what Banshee will consume).
>
> Idea 1: The Audio Object
> Objects for each atomic unit of audio. You new up an Audio object,
> passing it some atomic unit of audio (probably filename, maybe streams
> or byte arrays). It would work something like this:
>
> Audio a = new Audio ("/home/scott/Music/song.mp3");
> a.Play ();
>
> The constructor would acquire a backend appropriate to the audio file.
> This allows for multiple audio files to play simultaneously:
>
> Audio a = new Audio ("/home/scott/Music/song1.mp3");
> Audio b = new Audio ("/home/scott/Music/song2.wav");
> a.Play ();
> b.Play ();
>
> I like this approach for its simplicity and strong correlation between
> the object model and "real world" objects (songs). An open question in
> my mind is whether the Audio object is mutable. For example, should
> you be able to do this?:
>
> Audio a = new Audio ("/home/scott/Music/song1.mp3");
> a.Play ();
> // Begin playing another file
> a.AudioFile = "/home/scott/Music/song2.wav";
>
> I'm thinking no, but it's an option. Doing so might require the same
> Audio object to switch backends. Then there are problems with concepts
> like crossfading (assuming it's supported by the backend). If an Audio
> object is mutable, you could do this:
>
> Audio a = new Audio ("/home/scott/Music/song1.mp3");
> a.Play ();
> a.CrossfadeTo ("/home/scott/Music/song2.wav");
>
> On the other hand, if Audio objects are immutable, it could be a
> little trickier:
>
> Audio a = new Audio ("/home/scott/Music/song1.mp3");
> a.Play ();
> // This method returns a new Audio object and stops the
> // instance on which it was called after the fade
> Audio b = a.CrossfadeTo ("/home/scott/Music/song2.wav");
>
> There is also the option of:
>
> Audio a = new Audio ("/home/scott/Music/song1.mp3");
> a.Play ();
> // This constructor will attempt to crossfade from the
> // provided Audio object
> Audio b = new Audio (a, "/home/scott/Music/song2.wav");
>
> The trouble with this is, the constructor of one object is affecting
> another other (calling a.Stop () once the crossfade is complete). This
> could also be problematic if the backend gives us only a single audio
> stream during the crossfade: there are two objects representing the
> same sound.
>
> Another major issue with this API is the matter of backend handling.
> Initializing a new backend for each Audio object has a performance
> impact, as does disposing it. Ideally we would have a singleton of
> each backend, but that might not allow playing multiple audio streams
> at once. And even if we were able to manage a pool of backend
> instances to be used by Audio objects, disposal still remains a
> problem. Having some disposal boilerplate code does not seem idea:
>
> Audio a = new Audio ("/home/scott/Music/song1.mp3");
> a.Play ();
> a.Stop ();
> // This is stupid:
> Mono.Media.BackendPool.DisposeAllBackends ();
>
>
> Idea 2: The AudioPlayer Object
> An AudioPlayer object is used to play audio. Each audio player
> maintains its own backend pool (as needed) and it implements
> IDisposable, so backend disposal is easy. An AudioPlayer can only play
> one audio file at a time (with support for crossfading, if the backend
> provides it):
>
> using (AudioPlayer p = new AudioPlayer()) {
>     p.Open ("/home/scott/Music/song1.mp3");
>     p.Play ();
>     p.CrossfadeTo ("/home/scott/Music/song2.mp3");
>     p.Pause ();
>     p.Close ();
>     p.OpenAndPlay ("/home/scott/Music/song1.mp3");
>     p.Open ("/home/scott/Music/song2.mp3");
>     p.Play ();
> }
>
> You can have multiple AudioPlayers playing at the same time:
>
> AudioPlayer p1 = new AudioPlayer ();
> p1.OpenAndPlay ("/home/scott/Music/song1.mp3");
> AudioPlayer p2 = new AudioPlayer ();
> p2.OpenAndPlay ("/home/scott/Music/song2.mp3");
> p1.Dispose ();
> p2.Dispose ();
>
> This object model also maps rather nicely to real-world objects. Thoughts?
>

_______________________________________________
Banshee-list mailing list
Banshee-list gnome org
http://mail.gnome.org/mailman/listinfo/banshee-list