updating irc logs

git-svn-id: svn://svn.rockbox.org/rockbox/trunk@996 a1c6a512-1295-4272-9138-f99709370657

1 files changed, 818 insertions, 0 deletions

diff --git a/www/irc/rockbox-20020513.log b/www/irc/rockbox-20020513.log
new file mode 100644
index 0000000000..c3356b2319
--- /dev/null
+++ b/www/irc/rockbox-20020513.log
@@ -0,0 +1,818 @@
+**** BEGIN LOGGING AT Sun May 12 06:00:58 2002
+
+-->     adiamas (~adiamas@216.194.26.49) has joined #rockbox
+---     Topic for #rockbox is Open Source Jukebox Firmware - http://bjorn.haxx.se/rockbox/     [a.k.a. This room is too damn quiet.]
+---     Topic for #rockbox set by adiamas at Sun May 12 02:38:43
+-->     linuxstb (dave@dsl-212-23-31-215.zen.co.uk) has joined #rockbox
+-->     alkorr (alkorr@srs07v-5-155.n.club-internet.fr) has joined #rockbox
+<--     alkorr has quit (Client Quit)
+-->     alkorr (alkorr@srs03v-8-46.n.club-internet.fr) has joined #rockbox
+<--     alkorr (alkorr@srs03v-8-46.n.club-internet.fr) has left #rockbox
+<--     Tumm has quit (Read error: 113 (No route to host))
+-->     edx (edx@pD9EAB7BC.dip.t-dialin.net) has joined #rockbox
+<edx>   hi
+<linuxstb>      Hello - is anyone around?
+<edx>   yea
+<linuxstb>      Hello Felix - are you still working on the win32 simulator?
+<edx>   yea
+<edx>   i am...
+<linuxstb>      Do you fancy implementing mpeg audio playback?
+<edx>   but i've had a lot of work to do the last two weeks.. i guess i am kinda behind the x11 :)
+<edx>   mpeg implementing is not too hard - i have already written a class for it (for another project) so i can use that.
+<linuxstb>      I've already written a wrapper around libmad - you just need to output the 16 bit stereo sound samples to the windows sound device.
+<linuxstb>      i.e. implement the functions in x11/oss_sound.c for Windows.
+<edx>   hm - i just use the windows media player to do that :)
+<linuxstb>      I think it may save work if the x11 and win32 share the same mpeg decoding code
+<linuxstb>      Does win32 support pthreads?
+<edx>   threads..
+<edx>   sure.
+<edx>   i'll have a look ath the oss_sound.c later on... maybe i can just translate it to windows.
+<linuxstb>      I have started to implement a separate mpeg playing thread...
+<linuxstb>      ... I need to try and make it work on x11, win32 and eventually the target.
+<edx>   do we have a startthread funciton or something liek that for the target...
+<linuxstb>      I also use the pthread_mutex_lock and pthread_mutex_unlock functions to lock the play queue
+<linuxstb>      ... as well as signals to say when the queue is no longer empty
+<linuxstb>      thread.c only contains a create_thread function.  I can't see anything else
+<edx>   ... ill have to write that for win32 then...
+<edx>   i gotta go now... i'll try to continue the win32 sim code during the next week.
+<linuxstb>      OK - I'll keep working on x11.  Bye.
+---     edx is now known as edx|away
+<--     linuxstb has quit ("using sirc version 2.211+KSIRC/1.0")
+-->     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox
+-->     Tumm (coyote@dreamhosted.borlange.se) has joined #rockbox
+<--     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox
+-->     linuxstb (dave@dsl-212-23-31-215.zen.co.uk) has joined #rockbox
+-->     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox
+<linuxstb>      Hello Daniel - I have just sent a (long) message to the mailing list about the mpeg API.  I'm happy to discuss here, or by email.
+<Bagder>        uh, I'm gonna watch tv now, back in 45 mins... ;-)
+<linuxstb>      No problem.
+*       Bagder reads linuxstb's mail now
+<Bagder>        ok, I like the suggested api in general, I only have some small details
+<Bagder>        kill_playback() - "kill the mpeg playing thread" isn't that just gonna stop the audio?
+---     edx|away is now known as edx
+<linuxstb>      This is something I wasn't sure about - is the mpeg thread there constantly, or should it be created and killed as required?
+<Bagder>        hey edx
+<edx>   hi
+<edx>   Heh: http://acmesofties.cjb.net
+<Bagder>        linuxstb: I'd prefer to have it there always
+<linuxstb>      Will we be able to send it a signal to say "wake up and play some music"?
+<Bagder>        oh sure, it would just sit waiting on a message queue or something
+<edx>   Bagder: well a kinn thread wont be bad anyways...
+<edx>   knn = kill
+<edx>   arghl.. kinn = kill
+<Bagder>        edx why so?
+<edx>   meybe it needs to cleans up some stuff...
+<edx>   maybe..
+<edx>   jeez - cant type today
+<Bagder>        I don't believe we ever need to kill threads, at least I can't think of any good reason why
+<edx>   well - but the thread might want to clean up stuff...
+<Bagder>        sure
+<edx>   i just say it might - it doesnt have to.. :)
+<linuxstb>      How about killing the thread so we can free it's memory (i.e. the play buffer) for other things
+<Bagder>        but not by killing itself ;-)
+<edx>   then rename the function. heh.. it's just called where kill_thread would be called if it existed
+<Bagder>        linuxstb: I don't think we'll prioritise that
+<linuxstb>      OK!
+<Bagder>        stop_track() could stop the playback and free the play buffer 
+<Bagder>        then start_playback() could allocate it again and play
+<linuxstb>      OK, so if are agreed that the mpeg thread is constantly there - do you have any other comments about the API?
+<Bagder>        yes another minor one:
+<Bagder>        what's the difference between new_track() and start_playback() ?
+<Bagder>        couldn't they be the same?
+<linuxstb>      start_playback creates the thread.  If the thread is always there, then we can change start_playback to create_thread
+<edx>   ... good night guys
+<linuxstb>      ... which isn't really part of the API.
+<Bagder>        night edx
+<linuxstb>      bye.
+<--     edx has quit ("l8r")
+<Bagder>        right, well I have just pictured myself the play thread to be always present...
+<linuxstb>      yes - I agree - the play thread will always be there
+<Bagder>        anyway, the thread's presence or not shouldn't be reflected in the api...
+<Bagder>        so
+<Bagder>        I think the rest covers everything up
+<linuxstb>      You're probably right about the thread's presence.
+<linuxstb>      My only other problem is how to implement the threads in the simulator
+<linuxstb>      I can use pthreads on x11, but how should this be implemented?
+<Bagder>        we can't simulate the threads in the same way they work on the target
+<Bagder>        we need to keep simualting the apis properly, not the exact behavior
+<linuxstb>      I was also thinking in terms of portability between x11 and win32.
+<Bagder>        the thread stuff won't be very portable between the x11 and win32
+<linuxstb>      OK - I'll start implementing it in the x11 subdirectory, and the person who writes the win32 can see if we can share any code.
+<Bagder>        I agree with that approach
+<linuxstb>      Another concern is the seeking inside files...
+<linuxstb>      ... it could be hard to implement with VBR files.  But I guess we can leave that until last.
+<Bagder>        yes, I've thought about that too
+<Bagder>        I think we better ignore that for now
+<linuxstb>      I also think frame sizes can vary (by 1 byte) even in CBR files.
+<Bagder>        so, we better read up on the details and see what we can do
+<Bagder>        perhaps we won't be able to seek per time at all
+<linuxstb>      I think we can seek by time, but it may require scanning the file.
+<linuxstb>      The user doesn't have to use it.
+<Bagder>        true
+<linuxstb>      Should volume control be part of the mpeg API or separate?
+<adiamas>       id assume seperate
+<Bagder>        I think separate too
+<linuxstb>      I guess it is just an implementation detail
+<Bagder>        true
+<linuxstb>      Are you happy with the peek_next_track and get_next_track concept?
+<Bagder>        do we really need two functions for it?
+<linuxstb>      I think so.  What is the alternative?
+<Bagder>        just get_next_track()
+<Bagder>        uh
+<Bagder>        no
+*       Bagder wasn't thinking 
+<linuxstb>      So you are happy then?
+<Bagder>        get_next would then of course advance some kind of pointer
+<linuxstb>      yes - that's the difference.
+<Bagder>        yes, I'm fine with it
+<linuxstb>      OK.  I guess we're done here then.
+<Bagder>        I would prefer to have Linus say something about it though, as he's the master of the MAS and mp3 playing
+<linuxstb>      I agree - I probably won't do any more work on it today anyway.
+<Bagder>        I appreciate your work
+<linuxstb>      No problem.  I just wished that somewhere in the UK would get the recorder 20 in stock again.
+<linuxstb>      I don't actually own one yet.
+<Bagder>        hehe ;-)
+<linuxstb>      I am assuming the recorder is the best to buy - even if I never record on it.
+<Bagder>        yes
+<Bagder>        it has a better display and better sound (they say)
+<linuxstb>      Do you know if Linus is developing a driver for both MAS versions?
+<Bagder>        he's doing the 3507 first, the Player one
+<Bagder>        because that's the hardware he runs his gdb on ;-)
+<Bagder>        both Linus and Björn have both Player and Recorder
+<linuxstb>      Have you discussed the 3587 with him?
+<Bagder>        not very much
+<linuxstb>      I hope it won't be a problem then.
+<Bagder>        no one thinks it will be, but we can't be sure of course
+<linuxstb>      I don't even want to think about the "mpeg recording API" yet :-)
+<Bagder>        it'll hopefully be less messy code
+<Bagder>        the 3507 needs all bytes bit-reversed
+<linuxstb>      Thanks for the chat.  I'll wait for Linus to comment before going too far with the mpeg playing on the simulator.
+<--     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox
+<--     linuxstb has quit ("using sirc version 2.211+KSIRC/1.0")
+-->     danaka (~k_a_d_a@pD9E4A486.dip.t-dialin.net) has joined #rockbox
+<danaka>        hi
+<danaka>        somebody out there
+<danaka>        help
+<danaka>        I need Info
+<adiamas>       shoot...
+<adiamas>       what can i help ywa with
+<danaka>        hi
+<danaka>        I wanted to find out which Harddrive I can use to upgrade my Recorder20
+<danaka>        and another question is there a limit of files to download to my player
+<danaka>        also I wanted to tell u guys that I think its pretty cool that someone trys to write his own code for the box
+<danaka>        I think its pretty hard
+<danaka>        I m just trying to start programming with C
+<danaka>        and Java
+<danaka>        will see what works better for me
+<danaka>        I looked at ur site and all those files read a lot but still dont know nothing
+<danaka>        well Im really beginning beginning
+<danaka>        C
+<danaka>        wanna play tetris, too on my machine :)
+<danaka>        and Quake II grins
+<danaka>        lol
+<danaka>        I liked that Faq
+<adiamas>       hehe sorry, back :)
+<adiamas>       ill address what i can..
+<adiamas>       1. FAQ thanks for the compliment :)
+<adiamas>       2. programming... projects like this are a great way to learn
+<adiamas>       3. file limit.  I don't believe their is a file limit on the size or number o files you can have, but not 100 percent positive
+<adiamas>       4. upgradeing.. 
+<adiamas>       no idea at all.
+<danaka>        would be nice to have 60 gig or something but those 2.5 drives are pretty expensive
+<danaka>        gonna get my player today I cant await to put my 20 gig mp3z on it
+<danaka>        but its sad that is already full after that action
+<danaka>        gonna take it with me im going for a working trip to china
+<danaka>        so when I look at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rockbox/www/sh-win/
+<danaka>        seems like an emulator under win is that right?
+<danaka>        Where could I start to understand all that probably use more of my Linux and let that windoze go
+<danaka>        then learn C and get back to the files
+<danaka>        there are a lot In that WWW dir
+<danaka>        oops rockbox dir
+<danaka>        please tell me where can I start to understand Im wiling to learn
+<danaka>        and I want to hack my Archos
+<danaka>        damn its already 6.45 in the morning here in Germany and Im still checking all Info I can get about the player without even holding it in my hands
+<danaka>        but Im possitive it will arive today
+<adiamas>       hmmm well..
+<adiamas>       the full api for the devices isn't completed yet, but we're nearly there.
+<adiamas>       as for the win/lin thing,
+<adiamas>       we have a user interface simulator for both platforms
+<adiamas>       the idea is that until the work on metal (hardware
+<adiamas>       is done, then the rest of us have something we can work for/with in the simulator.
+<adiamas>       as for where to begin.. that is always a tough question to answer.
+<adiamas>       best thing i could suggest is to read over the docs that are in the cvs repositiory...
+<adiamas>       then try getting the simulator working on your home machine.
+<adiamas>       then just play with anything that seems interesting.
+<adiamas>       i worked on tetris, screensaver and the FAQ because its what caught my eye at the time.
+<adiamas>       hope that helps a bit
+<danaka>        aight thanks 
+<adiamas>       and dont' ever be afraid to ask quesiton shere :)
+<danaka>        gonna check the docs in the cvs
+<danaka>        cool thanx
+<danaka>        gotta go sleep now have a nice day or night or whatever u have at the moment
+<danaka>        bye
+<adiamas>       bye
+<--     danaka (~k_a_d_a@pD9E4A486.dip.t-dialin.net) has left #rockbox
+-->     calpefrosch (~calpefros@62.52.174.30) has joined #rockbox
+-->     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox
+---     ChanServ gives channel operator status to Bagder
+<adiamas>       hey Bagder
+<Bagder>        howdy
+<--     Tumm has quit (zahn.openprojects.net irc.openprojects.net)
+<--     PsycoXul has quit (zahn.openprojects.net irc.openprojects.net)
+-->     Tumm (coyote@dreamhosted.borlange.se) has joined #rockbox
+-->     PsycoXul (psyco@adsl-63-205-40-140.dsl.lsan03.pacbell.net) has joined #rockbox
+<adiamas>       Bagder taht was your reply to my idea that just went out yes?
+<Bagder>        no, that's Dave's reply
+<adiamas>       ah... k...
+<adiamas>       i still havent gotten nicks and real life names down yet :)
+<Bagder>        hehe
+-->     Zagor_ (~bjst@labb.contactor.se) has joined #rockbox
+---     Zagor_ is now known as Zagor
+<Bagder>        morning Zagor
+<Zagor> morn
+<Tumm>  morning everyone
+<Bagder>        hey Tumm
+-->     linuxstb (dave@dsl-212-23-31-215.zen.co.uk) has joined #rockbox
+<Bagder>        morning Dave
+<linuxstb>      Morning - what time is it in Sweden?
+<Bagder>        09:41
+<linuxstb>      8.41 here in London.
+<linuxstb>      I'm going to be here all day - "working" at home.
+<Bagder>        aah, we like that ;-)
+<Bagder>        "working" at home is nice
+<linuxstb>      I hope my boss hasn't joined this list :-)
+<Bagder>        hehehe
+<linuxstb>      Is anyone doing anything interesting on rockbox at the moment?
+<Bagder>        not me
+*       Bagder actually works
+<linuxstb>      I'll be working today, but will have time to chat.
+<Bagder>        Zagor: you have any thoughts on the mpeg thread and linuxstb's api suggestions?
+<linuxstb>      The main change from my email is that the mpeg playing thread will be there permanently.
+<linuxstb>      This makes start_playback and kill_playback unneccessary.
+<Zagor> well, two things: 1) we'll be using a single thread combined with an interrupt handler in target
+<Zagor> 2) the api doesn't really need to know that :-)
+<linuxstb>      Agreed, but that possibly means we can't share much code between the simulator and target.
+<Zagor> yes
+<Bagder>        oh yes
+<Zagor> we shouldn't share code beyond the API
+<linuxstb>      I thought the aim was to share as much code as possible, and design the APIs with that in mind.
+<Zagor> actually, no. the aim is to share application code, not lowlevel code
+<Bagder>        yes, the appplication code should run both in target and in the simulators
+<Zagor> there is no point in trying to make the simulator drivers behave the same as the target drivers, as long as the API is the same
+<linuxstb>      The debate is then where do we draw the line between application and low-level.
+<Bagder>        true
+<Zagor> in the APIs
+<linuxstb>      OK - so is my suggested API at the right level?
+-->     Linus (~linus@labb.contactor.se) has joined #rockbox
+<Linus> HELO
+<Zagor> I'd say so, yes. except for the threading things
+<Bagder>        HELO Linus
+<Linus> MAIL FROM:
+<linuxstb>      Welcome Linus - just the man to talk about mpeg playing.
+<Linus> Oh.
+<Bagder>        ;-)
+*       Linus runs for coffee
+<linuxstb>      :-)
+<linuxstb>      Sorry!
+<Linus> Back!
+<Bagder>        our coffee machine is broken again... *sigh*
+<Linus> shaking hands, eh?
+<Zagor> the get_next_track() things are not really mpeg-playback stuff, it's part of the playlist code
+<Linus> trembling maybe
+<Linus> Are you talking about the mpeg playing API?
+<Zagor> Dave's proposal, yes
+<Bagder>        well, the playback doesn't know which track to play so it needs to ask
+<Zagor> yes, but it's not part of the API
+<Bagder>        so how should it work?
+<Zagor> the gist is right. i'm just saying it's not part of the API, it's part of the implementation
+<linuxstb>      It's a way to abstract the actual selection of tracks by the user.
+<Bagder>        I think the playlist code needs to supply that function, and the playback thread uses it
+<linuxstb>      So it's part of _an_ API.
+<Zagor> yes but that selection is handled by playlist.c, not mpeg.c
+<Zagor> right
+<linuxstb>      We still need that function somewhere in the program - it doesn't really matter what API we say it is part of.
+*       Bagder agrees
+<linuxstb>      It's part of the two-way communication needed between the "UI thread" and the "mpeg playing thread"
+<Linus> Two-way?
+<Bagder>        not the ui, the playlist
+<Zagor> but the playlist code runs in the ui thread, no?
+<Bagder>        Linus: the playback thread needs to know which track to play
+<Bagder>        does it?
+<Zagor> i don't know :-)
+<linuxstb>      The mpeg thread needs to report it's status back to the user somehow.
+<Bagder>        me neither ;-)
+<Bagder>        I just thought that the UI needed to be independent of the playlist somehow, but I haven't really thought about this in detail
+<Zagor> Bagder: right, but still it makes little sense to have a separate thread for playlist management
+<Bagder>        right
+<Linus> Actually, I haven't given the UI thing much thought. I have only coded an MPEG playing thread.
+<Bagder>        the playlist will be a chunk of structured memory
+<linuxstb>      I don't think we need separate threads - just some kind of abstract data type for playlists.
+<Zagor> yup
+<Bagder>        Linus: yes, but how does it know which track to play? ;-)
+<Linus> Currently, it just opens one track. It's a test.
+<Bagder>        of course, but beyond the tests...
+<Linus> I had a queue in mind that the playlist/UI code kept up to date, and that the MPEG thread could pick from.
+<Zagor> umm, a playlist perhaps? ;)
+<Linus> No
+<linuxstb>      Linus: that is what I am thinking.  A play queue.
+<linuxstb>      The point about my API is that it doesn't matter.
+<linuxstb>      ... to the mpeg thread.
+<Linus> Exactly what dou you mean when you say playlist?
+<Linus> I thought a playlist was an M3U file or the like
+<Zagor> well no that's only one input to a playlist
+<Bagder>        a playlist is anything that knows a sequence of tracks
+<Linus> So the playlist is the play wueue?
+<linuxstb>      I think a play queue is a temporary play list where the "head" is deleted.
+<Linus> linuxstb: exactly
+-->     wavey (~wavey@dlan1431.dircon.co.uk) has joined #rockbox
+<Bagder>        I would think so too
+<Zagor> I don't much see a point in having both a play list and a play queue. please enlighten me.
+<Bagder>        hey wavey
+<wavey> morning :)
+<Linus> The play queue is what the mpeg thread sees. The playlist is a list of files created by the user.
+<Linus> In my world :-)
+<Zagor> why can't they be the same?
+<linuxstb>      I'll be back in 10 minutes.....
+<wavey> what if the user changes the playlist - does your play queue get updated?
+<Linus> They could. But the term "playlist" has a predefined meaning to many people.
+<Bagder>        we're not "many people" ;-)
+<Zagor> yeah, but the mpeg thread code isn't meant for "many people" :)
+<Linus> wavey: it should. But the MPEG thread doesn't care.
+<Bagder>        if we offer the playback thread Dave's API, then it could be made however we want
+<Bagder>        queue, list, stack, whatever
+<Bagder>        it
+<Bagder>        is beyond what the playback thread should care
+<Linus> So the playback thread just calls get_next_track()?
+<Zagor> yes
+<Bagder>        yes
+<Linus> Fair eneough
+<Linus> hjgfljsrhbglobs
+*       Bagder throws a keyboard to Linus
+<Linus> Throw me a brain
+*       Bagder has none ;-)
+<Linus> So how does the MPEG thread handle the case when the playlist changes while playing?
+<Bagder>        that's why there's a peek and get_next
+<Zagor> it doesn't. that's a UI problem.
+<Linus> So what happens when it changes after the peek()?
+<Bagder>        while playing track A
+<Zagor> i'm not sure i agree on the peek() idea
+<Bagder>        it peeks and sees track B coming up
+<Linus> How often should I peek?
+<Linus> Every second?
+<Bagder>        when you need the next track
+<Linus> Every millisecond?
+<Bagder>        when you need the next track
+<Linus> So how does the MPEG thread handle the case when the playlist changes while playing?
+<Bagder>        while still playing the former
+<Linus> So what happens when it changes after the peek()?
+<Bagder>        flush, restart
+<Linus> How do I know when to do that?
+<Bagder>        or what do you suggest?
+<Linus> I = mpeg thread
+<Zagor> you're making this too complex, IMHO
+<Linus> I suggest a "push"
+<Bagder>        push?
+<Linus> Maybe a PLAYLIST CHANGED message?
+<Bagder>        maybe just play_track() ;-)
+<Zagor> instead of peek() and next(), use an index
+<Linus> Maybe, but it will interrupt
+<Linus> the current song
+<Zagor> when reading next_track into the buffer, check periodically (every second?) that the file is the same
+<Bagder>        so how do the thread get the next song without interrupting?
+<Zagor> once the song starts, there's no turning back
+<Linus> Bagder: get_next_track()
+<Zagor> next() sucks
+<Linus> Why?
+<Bagder>        why?
+<wavey> why?
+*       wavey smiles
+<Zagor> because then you need a peek
+<Linus> Suggestion?
+<Zagor> get(int index)
+<Bagder>        what's index?
+<Linus> OK, so a separate play queue?
+<Zagor> no
+<Bagder>        0 or 1?
+<Bagder>        you guys should write this down and mail instead ;-)
+<Zagor> not until we have some kind of idea... :-)
+<Linus> Zagor: what is the index?
+<Bagder>        but it sounds like we all basicly have the same idea
+<linuxstb>      If the user changes the currently playing track, it calls pause_playback and then new_track with the new filename.
+<Bagder>        but we talk around each other
+<linuxstb>      it = the UI thread
+<Zagor> Linus: index is a track counter. using this index, you can ask for several tracks in advance.
+<Zagor> not just "current" and "next"
+<Bagder>        why would the playback need that?
+<Zagor> to fill the buffer, in case of small tracks
+<Bagder>        ah
+<Linus> Many short tracks.
+<Bagder>        right
+<Bagder>        it would in fact need that, indeed
+<Linus> Sound effects for Tetris, for example.
+<Bagder>        hehe
+<linuxstb>      are small tracks a real problem?  How many people have small tracks?
+<Zagor> or wavey's track name reader :-)
+<Zagor> it's not a problem, but it's unfortunate to design so we can't handle them
+<linuxstb>      I have no problem with having peek_track(n).  We still only need get_next_track though.
+<Linus> Small tracks are not a problem. At least it shouldn't.
+<Zagor> I don't like next(). you can only call it once, right? it's a volatile interface.
+<linuxstb>      Yes - it is for the case when the mpeg thread has finished playing that track.
+<Zagor> I much prefer a counter that the play thread increases itself
+<linuxstb>      get_next_track could just increment a counter.
+<Linus> A agree with Zagor. But what to do when the playlist changes?
+<Bagder>        the playlist code must get to know when it plays the next track
+<Linus> That is, when the index is invalid
+<Zagor> Linus: give an example
+<linuxstb>      We should try and make the mpeg playing thread as "ignorant" as possible.
+<Linus> If the index is inceremented by the MPEG thread, when is it reset?
+<Zagor> in stop() ?
+<linuxstb>      How does the mpeg_thread know how many songs are in the playlist?
+<Linus> I doesn't
+<Zagor> it doesn't, and shouldn't
+<linuxstb>      if it increments a pointer, doesn't it need to know when to stop?
+<Zagor> yeah, when it gets NULL back
+<Linus> When it reads NULL fron the get() call it stops.
+<Zagor> :)
+<linuxstb>      I still think my API is more flexible.
+<Zagor> how?
+<Linus> So the "playlist" is read by the mpeg thread via get(index)?
+<linuxstb>      What if the playlist shrinks in size?
+<Bagder>        I don't understand Linus' and Björn's suggestion
+<Zagor> then it will get NULL immediately
+<Linus> It puts a little burden on the playlist code
+<Linus> To be able to index the list of tracks
+<Zagor> yes, I agree. it's not the perfect idea.
+<Linus> A question: does the UI create a playlist from the current directory automatically?
+<Bagder>        so how do the playlist code know which entry that plays right now?
+<linuxstb>      Linus: You (i.e. the mpeg thread) shouldn't care.
+<Zagor> peek(int index) is good, but I don't want get_next() to do the same. how about a next_track(void) that the play thread calls when the playthread moves into the next track
+<Linus> I know. I'm just trying to figure out if ZAgors idea is practical
+<Linus> Zagor: sounds OK
+<Bagder>        Zagor: right, we need something like that
+<linuxstb>      I believe that with my API, any type of UI can be implemented.
+<linuxstb>      Zagor - I agree.  All you are doing is changing the name of the function, not it's purpose.
+<Bagder>        well, these suggestsions aren't that different, if I'm understanding things
+<Zagor> linuxstb: actually, I don't want next_track() to tell which is the next track. only peek() is used for that.
+<linuxstb>      Zagor: sorry, I misunderstood.
+<Zagor> i want next_track() to only tell the playlist code that the playthread has advanced one step
+<linuxstb>      OK, what about get_track_name(n)
+<Zagor> then peek() can use a relative index instead of a counter. 0=current track, 1=next, 2=nextnext etc
+<Zagor> I think peek() is an ok name, actually
+<linuxstb>      But I think we now agree on functionality.
+<Zagor> sure, if you all agree with me. :*D
+<linuxstb>      I think I do.
+<Bagder>        basicly, after all, this is Dave's idea with a few minor changes :-)
+<Zagor> yes
+<Zagor> but it's good to just go through it, even if we just wind up where we started
+<Bagder>        right
+<Bagder>        linuxstb: are you updating your original suggestion according to all this?
+<linuxstb>      :-) OK.
+<Linus> I'll start coding an MPEG thread that supports this API
+<Bagder>        I just think it would be good to get it in "print"
+<Bagder>        neato
+<linuxstb>      I don't think I'll have time to do it immediately though.  Sorry.
+<Linus> Lazy bastard! :-)
+<linuxstb>      Work is calling...
+<Linus> Work? What is that?
+<linuxstb>      OK, I'll do something very quickly now and send to the list.  If I miss something, please modify my email.
+<Linus> Is there working code for the Player keys?
+<Zagor> I think so
+<Linus> Good.
+<Bagder>        Zagor: did you try your player app on target yet?
+<Zagor> no
+<Zagor> I was playing have-a-life all weekend :)
+<Bagder>        would be cool to know if it works
+<Linus> Zagor: you have a player app?
+<Bagder>        life?
+<Zagor> Linus: the file browser
+<Linus> Ah
+<Bagder>        yeah, you guys were missing here during the weekend ;-)
+<Linus> I know. I was alone with my kid. I had no time...
+<Linus> And when I joined the channel on saturday is was dead.
+<Zagor> Linus: an excellent opportunity for that old speech about the bits and the bytes
+<Linus> Three sleeping americans
+<Bagder>        oops ;-)
+<Bagder>        hahaha
+<Bagder>        "you see each byte consists of eight bits... "
+<Linus> Does joining the channel on a saturday night say something about not having a life...?
+<Bagder>        noooooo
+<Linus> Or trying to forget that you have one?
+<Linus> "So, Rasmus, it's time to sleep now."
+<Linus> "No, I don't want to:"
+<Linus> "SLEEP GODDAMMIT! I need to hack the rockbox!"
+---     Bagder has changed the topic to: Does your box rock? http://bjorn.haxx.se/rockbox/
+<Linus> "But it's only 4am"
+<Linus> pm,
+-->     alkorr (alkorr@srs05v-8-132.n.club-internet.fr) has joined #rockbox
+<alkorr>        hi
+<Bagder>        hi alkorr
+<alkorr>        the guy we found in internet (DSP guy) is unreachable ?
+<Zagor> no, he answered but declined
+<alkorr>        !?
+<alkorr>        NDA ?
+<Zagor> i didn't ask any technical questions, just if he wanted to help. and he said "not for free"
+<alkorr>        grrr...
+<Linus> Typical. A guy that has mouths to feed. :-)
+<Zagor> the youth of today... :-)
+<Bagder>        he probably thinks he has a life too! ;-P
+*       Bagder curses everyone that don't agree with us
+<alkorr>        well, in fact, what we need is some infos like assembly codes or some tools. Even such a thing is impossible for him ???
+<Zagor> the tools are proprietary. same with the docs...
+<alkorr>        if he doesn't want to code for us is not a matter for me
+<alkorr>        and he said "not for free"... a cracker ?
+<Zagor> that was not a quote. he said he was not interested in doing it as a spare time hobby project.
+<Zagor> doing it == helping
+<alkorr>        ok
+<alkorr>        what his email address ?
+<Linus> BOMB HIM! :_)
+<alkorr>        yaaah
+<linuxstb>      I've just emailed an updated API document to the list.  Please amend and publish on the website.
+<linuxstb>      Now I must do some work :-).
+<Zagor> alkorr: samar@winlab.rutgers.edu
+<Zagor> next_track() should be "void next_track(void)"
+<linuxstb>      Can someone else take responsibility for amendments?
+<Zagor> sure
+<linuxstb>      We also need to decide on the location of the functions - e.g. firmware/mpeg.h and firmware/playlist.h
+<Zagor> yes
+<Zagor> the mpeg code should probably stay in firmware, while the playlist code goes in apps
+<Zagor> now go work! ;)
+---     Linus is now known as Linus|lunch
+---     Zagor is now known as Zagor|lunch
+<--     alkorr has quit ()
+---     Linus|lunch is now known as Linus
+---     Zagor|lunch is now known as Zagor
+<Linus> Yo guys!
+*       Bagder awakens and blinks
+<Linus> Do we really need the "bool" type? I think it's redundant.
+<Bagder>        it is redundant, I just kinda like having functions return 'bool' when they return only TRUE or FALSE
+<Zagor> umm... does anyone remember why we added it? ;)
+<Bagder>        we added it because code we added used it
+<Linus> What code
+<Bagder>        does it matter?
+<Linus> Just curious
+<Linus> I feel like killing the bool type.
+<Bagder>        I think it was Gary code
+<Bagder>        why "kill" it? does it harm anyone? ;-)
+<Linus> It's ugly.
+<Bagder>        what if we paint it in bright colours? ;-P
+<Zagor> it sort of flies in the face of the "no new types, just plain C" rule in CONTRIBUTING
+<Bagder>        we discussed it when I added it there
+<Linus> Having a type like that automatically makes people think that we HAVE to use it.
+<Bagder>        before CONTRIBUTING even existed :-)
+<Zagor> I know. and now we discuss it again. :-)
+<Bagder>        as I said, I am +1 on using and having bool
+<Bagder>        you may vote against me
+*       Zagor is undecided
+<Linus> I am definitely against.
+<Bagder>        I think it improves readability
+<Bagder>        a matter of taste and opinion no doubt
+<Zagor> well bool is part of the C99 specifiction, so I guess it should be considered as "plain C"
+<Bagder>        oh don't we just loooove C99 ;-)
+<Linus> Maybe I'm just old and cranky...
+<Bagder>        yes you are OOOOOLD
+<Zagor> but then we should use the built-in bool and not define it ourselves
+<Bagder>        no can do
+<Bagder>        we build with non-C99 compilers too
+<Zagor> yeah, the simulators. but not the target.
+<Bagder>        right
+<Zagor> so let the simulators define a bool if they need to
+<Bagder>        is the 2.95 one true C99 then?
+<Bagder>        not everyone uses gcc3 for target
+<Zagor> I don't know, but I've seen gcc C code use internal 'bool'. can't figure out how to enable it, though :-)
+<Bagder>        oh well, let's face the problem when we get it, not assuming it on beforehand
+<Zagor> yes
+*       Bagder noticed that edx edited out wavey's little C99'ism in the playlist code a week ago or so...
+<Zagor> what was that?
+<Bagder>        dynamic array alloc on stack
+<Bagder>        char buffer[foo];
+<Zagor> ah, yes. but that's bad code (tm) too.
+<Bagder>        it depends
+<Bagder>        now it makes a malloc() instead, which isn't a lot better
+<Zagor> well we have a lot more heap than stack :)
+<Bagder>        well, using memory in one pool or another
+<Zagor> gcc supports bool since 2.7.0, btw
+<Bagder>        ok
+<Linus> Zagor: your ATA/FAT code uses the stack for sector data.
+<Bagder>        how big stack are you running with atm?
+<Zagor> #include <stdbool.h> is the C99 way
+<Linus> 8K
+<Zagor> Linus: yes, it's imperfect but it's also fixed size
+<Linus> True
+<Linus> Forgot about the dynamic size. THAT is bad code (tm)
+<Zagor> but you're right, that should be changed
+<Bagder>        well, malloc() causes fragmentation, dynamic on the stack doesn't ;-)
+<Bagder>        *and* it is faster to get it and return it
+*       Bagder shuts up now
+<Linus> But that forces us to use a huge stack, chich is unused most of the time.
+<Bagder>        very true
+<Linus> And one huge stack per thread...
+<Zagor> stdbool.h defines "bool", "true" and "false"
+<Zagor> not TRUE and FALSE
+<Bagder>        #define TRUE true ;-)
+<Linus> Gaah!
+<Zagor> Linus: gaah what, the 'false' or the #define?
+<Linus> The define
+<Zagor> ah, agreed
+<Linus> But I think we should use true/false if we intend to be C99
+<Zagor> yes
+*       Bagder disagrees
+*       Linus waits for Bagders explanation
+<Zagor> go on
+<Bagder>        first, just because we can do C99 doesn't mean we have to
+<Linus> ok
+<Zagor> true
+<Bagder>        secondly, I am just so darned used to TRUE and FALSE and I like them that way ;-)
+<Linus> And I am used to BOOL and not bool
+<Linus> but i prefer int
+<Bagder>        BOOL?
+<Bagder>        windows? ;-)
+<Linus> Amiga
+<Zagor> linus wants VOID too
+*       Zagor hides
+<Bagder>        hehe
+<Linus> It's actually quite common
+*       Linus slaps Zagor HARD
+*       Bagder can hardly remember Amiga programming ;-)
+<Zagor> I prefer 'hard'
+<Zagor> ;)
+<Linus> OK so if BOOL is wrong, why is bool right?
+<Linus> When there isn't a bool type in the first place
+<Bagder>        because bool is lowercase 
+<Linus> And having TRUE and FALSE doesn't force us to use a BOOL/bool type
+<Bagder>        no, they're not strictly related
+<Linus> I like int and TRUE and FALSE
+<Zagor> As the code police, I like to have firm ground to stand on when telling people not to create new types. 'bool' is built-in, which means we no longer create any new types.
+<Linus> That implies C99
+<Zagor> yes
+<Zagor> or, rather, gcc
+<Linus> I can go with that.
+<Linus> What I am against is user-defined types for no reason.
+<Bagder>        C99 or gcc rather
+<Zagor> I still reserve the right to refuse some other portions of C99 :)
+*       Linus loads his gun
+*       Bagder digs up the standard to write peculiar code ;-)
+*       Zagor changes all TRUE/FALSE to true/false
+<Linus> Officer Zagor: must we use bool, or is it at our convenience?
+<Zagor> If it's a bool, I say we should use a bool. it *does* make the API easier to read
+*       Bagder scores a point with the police ;-)
+*       Bagder is writing the greatest memory hog at work ;-)
+<Bagder>        incredibly stupid
+<Linus> Tell me
+<Bagder>        "follow the spec" ;-)
+<Bagder>        we have a built-in "registry" in our boxes
+<Bagder>        a hierarchal view of lots of settings
+<Bagder>        every program can register new "nodes" 
+<Bagder>        and the data is read/set with callbacks
+<Bagder>        quite neat, in general
+<Bagder>        now, this module we're working on that I'm writing this "registry" interface for is breaking all previous limits
+<Bagder>        it takes a lot to explain, but a modest calculation of used ram may end up on 30MB...
+<Bagder>        where we previously used ~3
+<Bagder>        for the complete system
+<Zagor> ooh, nice :)
+<Linus> Ouch!
+<Bagder>        it is beyond all sense
+<Linus> Code police: should we include "stdbool.h"?
+<Bagder>        connection.oDescription.X.destination.X.channel.X.sourceRoute.X
+<Bagder>        ... each X is a number between 0 and ... ;-)
+<Bagder>        say max 10, and we say 10.000 nodes ;-)
+<Zagor> Linus: yes
+*       Bagder sighs and gets back to work
+<Zagor> Bagder: never let reality come in the way of an elegant design! ;)
+<Bagder>        this is a perfect candidate for this
+<Bagder>        they smile very big when they think of this design ;-)
+<Bagder>        they won't smile as much when reality strikes back
+<Bagder>        you didn't change tetris
+<Zagor> i know, i changed the firmware first. fixing the simulator now.
+<Bagder>        nice
+<Zagor> dine
+<Zagor> done
+-->     irony (~irony@as2-5-7.j.bonet.se) has joined #rockbox
+<irony> hello
+<Zagor> hi
+<Bagder>        hey irony
+<irony> hi Bagder 
+<Zagor> how's the web design going? ;)
+<irony> oh
+<irony> haven' put any effort in it really
+<irony> =)
+<irony> hey have you guys tried gentoo?
+<Zagor> nope
+<irony> I like it, really. I learned a lot form the install, since it's not "automagic"
+<irony> only downside is that it takes quite a while to install, since everything is compiled from scratch
+<Linus> What it gentoo?
+<irony> www.gentoo.org
+<irony> linux distribution
+<irony> with a ports-system
+<Zagor> it's a linux distro that compiles everything
+<irony> yep
+<irony> I like the approach, it's really cool.
+<irony> but kde takes a lifetime to compile, though.
+<Linus> Just upgrade your computer. :-)
+<Zagor> personally, I think it's unnecessary. but i'm glad it's there for those who want it.
+<irony> Linus: hehe
+-->     chris1 (~flanz@62.132.155.14) has joined #rockbox
+<irony> Zagor: Well, I can agree that a quick binary automatic install is better in one sense
+<irony> Butit is really nice to have the possibility of choosing and optimizing, even though one does not have extensive linux knowledge
+<chris1>        hi 
+<Linus> Hi!
+<Zagor> irony: curl -O package.tar.gz; tar xzf package.tar.gz; cd package; ./configure; make; make install
+<Zagor> it's not like it's difficult :-)
+<chris1>        Zagor your have checkin (id3.h) .)
+<Zagor> no, it didn't change. why?
+<Zagor> irony: It would be very nice if you could mail me the mockup webpage you did, so I can use the colors etc.
+<irony> Zagor: true...
+<irony> Zagor: but still
+<irony> i still like gentoo
+<chris1>        oh sorry , I have get the update now. I have test the compile from last th.day. The win32 build fail. this file was not found.
+<Zagor> nice for you :)
+<irony> I am trying xfs, does anyone have experiences?
+<Bagder>        chris1: it was present yesterday too...
+<irony> Zagor: it's just an image, but sure. Otherwise I might put some effort in and make a real page
+<irony> Zagor: just need to wait for kde to finish compiling
+<irony> :)
+<Zagor> ok, if you wish
+<Linus> Oh. A lifetime.
+<chris1>        bagder : I have se the log 2002/5/5 10:31:21 :)
+<irony> pretty I should have done this compiling over night
+<--     irony has quit ("Changing server")
+<--     chris1 has quit ("r")
+-->     edx (edx@pD9EA9D41.dip.t-dialin.net) has joined #rockbox
+<edx>   hi
+<Linus> yo
+<Zagor> hi
+*       edx has to leave again in a sek...
+<edx>   total-school-overload :P
+<--     Zagor (~bjst@labb.contactor.se) has left #rockbox
+<--     Linus (~linus@labb.contactor.se) has left #rockbox
+<Bagder>        you scared them away! ;-)
+<edx>   sorry
+<edx>   hehe
+-->     Zagor_ (~bjst@labb.contactor.se) has joined #rockbox
+<edx>   (meybe it was the word "school") lol
+<Bagder>        hehe
+---     Zagor_ is now known as Zagor
+<Zagor> tunnel problems
+<edx>   arghl.. there i go again with the typing stuff (meybe = maybe)
+<edx>   .. gotta go - be back in like an hour. cu
+---     edx is now known as edx|away
+-->     Linus (~linus@labb.contactor.se) has joined #rockbox
+-->     alkorr (alkorr@srs08m-8-30.n.club-internet.fr) has joined #rockbox
+<--     calpefrosch has quit (Read error: 104 (Connection reset by peer))
+<alkorr>        i have a contact with this guy... i'm trying to have those opcodes, he could help to provide them
+<alkorr>        (DSP coder guy)
+<Zagor> ah, nice!
+<Zagor> gotta go. see you tomorrow, guys
+<--     Zagor (~bjst@labb.contactor.se) has left #rockbox
+<--     Linus (~linus@labb.contactor.se) has left #rockbox
+<--     alkorr has quit ()
+*       Bagder takes off for home too
+<--     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox
+---     edx|away is now known as edx
+<--     wavey has quit (Read error: 110 (Connection timed out))
+-->     wavey (~wavey@host-54.valtech.co.uk) has joined #rockbox
+-->     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox
+-->     Linus (~linus@labb.contactor.se) has joined #rockbox
+<Bagder>        good evening
+<Linus> evening
+<Linus> Bagder: how is that malloc() going?
+<Bagder>        it is sitting here, I was under the impression it wasn't exactly needed
+<Linus> Just curious. I'm using the newlib malloc now, but I assume that we will use your malloc() in the future.
+<Bagder>        it would be interesting to run a comparison on them somehow
+<Linus> Perhaps.
+<Bagder>        I should probably start with adding the code and a couple of tests
+<Linus> Do so. How do you tell it where the pool is?
+<Bagder>        bmalloc_add_pool()
+<Bagder>          bmalloc_add_pool(thisisourheap, AMOUNT_OF_MEMORY);
+<Bagder>        it can in fact handle multiple pools
+<Linus> So it can have many pools?
+<Linus> OK
+<Bagder>        not that I think we need that
+<Linus> I think not.
+<Bagder>        committed
+<Linus> Great!
+<Bagder>        basicly 1400 lines of code for the lot
+<Linus> ooh
+<Bagder>        well, check the newlib one as comparison ;-)
+<Bagder>        Anja just got back home, I gotta go and talk to her
+<Bagder>        see ya
+<--     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox
+<--     edx has quit (zahn.openprojects.net irc.openprojects.net)
+<--     Linus has quit (zahn.openprojects.net irc.openprojects.net)
+<--     PsycoXul has quit (zahn.openprojects.net irc.openprojects.net)
+<--     Tumm has quit (zahn.openprojects.net irc.openprojects.net)
+-->     edx (edx@pD9EA9D41.dip.t-dialin.net) has joined #rockbox
+-->     Tumm (coyote@dreamhosted.borlange.se) has joined #rockbox
+-->     Linus (~linus@labb.contactor.se) has joined #rockbox
+-->     kjer (~kjer@h168n2fls21o1070.telia.com) has joined #rockbox
+<--     wavey has quit (Read error: 104 (Connection reset by peer))
+<--     kjer (~kjer@h168n2fls21o1070.telia.com) has left #rockbox
+<edx>   cya guys
+<--     edx has quit ("good night")
+<--     Linus (~linus@labb.contactor.se) has left #rockbox
+-->     Zubster16 (none@pmchar1-45.rconnect.com) has joined #rockbox
+<Zubster16>     Hello
+<Zubster16>     anyone here?
+<--     Zubster16 has quit ("« Ë×Çü®§îöñ » Info«v9.1» Released«March 26, 2002» Channel«#Excursion on Da")
+-->     PsycoXul (psyco@adsl-63-205-40-140.dsl.lsan03.pacbell.net) has joined #rockbox
+**** ENDING LOGGING AT Mon May 13 22:21:16 2002
+