[prev in list] [next in list] [prev in thread] [next in thread] 

List:       alsaplayer-devel
Subject:    Re: [Alsaplayer-devel] Track seeking
From:       The Mighty Mike Master <melanson () pcisys ! net>
Date:       2000-04-21 13:51:06
[Download RAW message or body]

On Fri, 21 Apr 2000, Andy Lo A Foe wrote:

> That's allright, there is no documentation other than the source, my fault
> :) But yes, there should be basic support for TRACKS (CHAPTERS as I like
> to call them) inside streams. I made these modification when I implemented
> the CDDA plugin. My idea of this was to add a menu to the GUI where you
> could choose the different chapters..erh track inside a given stream. I'm
> open for other GUI suggestions (it is a GUI problem, technically we can
> implement track support very easily since the plugin API supports it
> already).
	Like I mentioned earlier, I already changed the <| |> on the front
panel to support these. The callback code (in my version) looks like:

void forward_play_cb(GtkWidget *widget, gpointer data)
{ 
        CorePlayer *p = (CorePlayer *)data;
        p->NextTrack();
}

And there are methods in the CorePlayer object called NextTrack() and
ForwardTrack(), as well as a private var to track tracks for example:

int CorePlayer::NextTrack() {
        pthread_mutex_lock(&player_mutex);
        if (plugin && the_object)
                if (plugin->track_seek(the_object, current_track + 1))
                {
                        current_track++;
                }
        pthread_mutex_unlock(&player_mutex);
 
        return 0;
} 

I've taken the liberty of defining to track_seek function to return
non-zero if the track seek was successful, 0 otherwise, so that it can
adjust its internal counter accordingly. I haven't sent along any patches
for this because I wasn't sure if this is how you wanted to do it. I just
needed track support to test NSF functionality.

	So far, track seeking has a few issues to be ironed out. It works
great in NSF files, but only because there are independent songs in the
file that can only be accessed by seeking. I implemented the track  
functions in mikmod_engine.c and the problem is that the track advances
without the CorePlayer's knowledge. The CorePlayer could ask for updates
on the track position. Unfortunately, MikMod offers no facilities to get
the current track (that I can find).

	I also implemented CDDA seeking. The only caveat so far is that
the time and seek bar don't adjust accordingly. Of course, the track
counter doesn't roll over by itself yet, either.

> Again a GUI problem. There is no 'space' left for the Author. Again I'm
> open for suggestions. A srollable author/title label perhaps?
	NSF files include Title, Author, and Copyright info. Each field is
only defined to be 32 chars max. So far the time being, I've stuffed them
all on the stream_info line. That might be the best route to go: Just
ask the plugin for the stream_info and assume you'll get all the needed
info. Scrollable line might be neat, if you can do it.

	Hope this helps...
        -The Mighty Mike Master
        http://tmmm.simplenet.com




[prev in list] [next in list] [prev in thread] [next in thread]