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

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

Scott,

 

The problem with CrossFadeTo as you've described it is that it makes it very complicated to implement a feature like cross fading when one song transitions to the next. What an implementer would need to do is watch every tick event until Player.Time = Song.Time - crossFadeMilliseconds, then call CrossFadeTo (source, crossFadeMilliseconds). By making the Player class "smart", it could automatically request the next song at the predetermined transition time and do the proper transition with out the need for each application implementing its own system. What could be done is to have an abstract AudioPlayer class with abstract functions GetPreviousSource and GetNextSource. Then, a class like BansheePlayer could inherit AudioPlayer and do all its management on top of it. This would simplify a lot of the event handling that players have to do.

 

- Brian

On Fri, Feb 22, 2008 at 9:27 PM, Scott Peterson <lunchtimemama gmail com> wrote:

So it seems that having a Player class is the way to go. Some thoughts
on the above:

Vladimir, I'm not sure what the Source class adds that we couldn't do
with URIs to the audio files. Ideally, an AudioSource class could
abstract the actual source of the audio (in-memory stream, file
stream, web stream) and simply provide the Player class with a stream
to play. Unfortunately, most backends (I'm thinking GStreamer,
DirectAudio, Quicktime) have no way of consuming managed streams -
they just take file URIs. In theory I like the idea of an AudioSource
class, but if it's just a wrapper for the URI of the file, it seems
unnecessary. Did you have another function in mind? Also, I think that
audio and video are sufficiently different to warrant an AudioPlayer
class and a VideoPlayer class, rather than a unified MediaPlayer
class.

Brian, I think we want to stay away from any type of queue system.
That is more the domain of a Banshee-like program. Our job will just
be playing the raw media files. Crossfading is a rare example where we
care about transitioning from one file to another. I defiantly like
your idea about controlling the crossfade time. Perhaps it could be
done something like this:

public class AudioPlayer {
   public static uint DefaultCrossFadeMilliseconds = 5000;
   public uint CrossFadeMilliseconds = DefaultCrossFadeMilliseconds;
   public void CrossFadeTo (string uri) {
       CrossFadeTo (uri, CrossFadeMilliseconds);
   }
   public void CrossFadeTo (string uri, uint crossFadeMilliseconds) { ... }
}

Another question I'd like to pose: Banshee handles media engine events
with two events: StateChanged and EventChanged. So, for example, if
the the song ends, the PlayerEngine raises a StateChanged event,
indicated that its state has changed from Playing to Idle. Similarly
with other state/event notification. Does this seem like the way to
go, rather than having separate events for each kind of state/event
change (like having a Paused event and a Stopped event and a Buffering
event and a Ready event, &c.)? With the Banshee-style system, code
that cares about the player state just needs to register one delegate,
but it has to switch() over the different states. With the other
method, code would have to register delegates for each state it cared
about, but it would only be notified of the state changes/events for
which it registered. Also, the code to handle the Stopped event would
be in a different method than the code to handle the Paused event
(rather than those routines living in adjacent switch-case clauses).

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