rockbox/www/irc/rockbox-20020513.log

**** 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<42>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<42>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 ("<22> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> Info<66>v9.1<EFBFBD> Released<65>March 26, 2002<30> Channel<65>#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