**** 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 hi Hello - is anyone around? yea Hello Felix - are you still working on the win32 simulator? yea i am... Do you fancy implementing mpeg audio playback? but i've had a lot of work to do the last two weeks.. i guess i am kinda behind the x11 :) mpeg implementing is not too hard - i have already written a class for it (for another project) so i can use that. I've already written a wrapper around libmad - you just need to output the 16 bit stereo sound samples to the windows sound device. i.e. implement the functions in x11/oss_sound.c for Windows. hm - i just use the windows media player to do that :) I think it may save work if the x11 and win32 share the same mpeg decoding code Does win32 support pthreads? threads.. sure. i'll have a look ath the oss_sound.c later on... maybe i can just translate it to windows. I have started to implement a separate mpeg playing thread... ... I need to try and make it work on x11, win32 and eventually the target. do we have a startthread funciton or something liek that for the target... I also use the pthread_mutex_lock and pthread_mutex_unlock functions to lock the play queue ... as well as signals to say when the queue is no longer empty thread.c only contains a create_thread function. I can't see anything else ... ill have to write that for win32 then... i gotta go now... i'll try to continue the win32 sim code during the next week. 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 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. uh, I'm gonna watch tv now, back in 45 mins... ;-) No problem. * Bagder reads linuxstb's mail now ok, I like the suggested api in general, I only have some small details kill_playback() - "kill the mpeg playing thread" isn't that just gonna stop the audio? --- edx|away is now known as edx This is something I wasn't sure about - is the mpeg thread there constantly, or should it be created and killed as required? hey edx hi Heh: http://acmesofties.cjb.net linuxstb: I'd prefer to have it there always Will we be able to send it a signal to say "wake up and play some music"? oh sure, it would just sit waiting on a message queue or something Bagder: well a kinn thread wont be bad anyways... knn = kill arghl.. kinn = kill edx why so? meybe it needs to cleans up some stuff... maybe.. jeez - cant type today I don't believe we ever need to kill threads, at least I can't think of any good reason why well - but the thread might want to clean up stuff... sure i just say it might - it doesnt have to.. :) How about killing the thread so we can free it's memory (i.e. the play buffer) for other things but not by killing itself ;-) then rename the function. heh.. it's just called where kill_thread would be called if it existed linuxstb: I don't think we'll prioritise that OK! stop_track() could stop the playback and free the play buffer then start_playback() could allocate it again and play OK, so if are agreed that the mpeg thread is constantly there - do you have any other comments about the API? yes another minor one: what's the difference between new_track() and start_playback() ? couldn't they be the same? start_playback creates the thread. If the thread is always there, then we can change start_playback to create_thread ... good night guys ... which isn't really part of the API. night edx bye. <-- edx has quit ("l8r") right, well I have just pictured myself the play thread to be always present... yes - I agree - the play thread will always be there anyway, the thread's presence or not shouldn't be reflected in the api... so I think the rest covers everything up You're probably right about the thread's presence. My only other problem is how to implement the threads in the simulator I can use pthreads on x11, but how should this be implemented? we can't simulate the threads in the same way they work on the target we need to keep simualting the apis properly, not the exact behavior I was also thinking in terms of portability between x11 and win32. the thread stuff won't be very portable between the x11 and win32 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. I agree with that approach Another concern is the seeking inside files... ... it could be hard to implement with VBR files. But I guess we can leave that until last. yes, I've thought about that too I think we better ignore that for now I also think frame sizes can vary (by 1 byte) even in CBR files. so, we better read up on the details and see what we can do perhaps we won't be able to seek per time at all I think we can seek by time, but it may require scanning the file. The user doesn't have to use it. true Should volume control be part of the mpeg API or separate? id assume seperate I think separate too I guess it is just an implementation detail true Are you happy with the peek_next_track and get_next_track concept? do we really need two functions for it? I think so. What is the alternative? just get_next_track() uh no * Bagder wasn't thinking So you are happy then? get_next would then of course advance some kind of pointer yes - that's the difference. yes, I'm fine with it OK. I guess we're done here then. I would prefer to have Linus say something about it though, as he's the master of the MAS and mp3 playing I agree - I probably won't do any more work on it today anyway. I appreciate your work No problem. I just wished that somewhere in the UK would get the recorder 20 in stock again. I don't actually own one yet. hehe ;-) I am assuming the recorder is the best to buy - even if I never record on it. yes it has a better display and better sound (they say) Do you know if Linus is developing a driver for both MAS versions? he's doing the 3507 first, the Player one because that's the hardware he runs his gdb on ;-) both Linus and Björn have both Player and Recorder Have you discussed the 3587 with him? not very much I hope it won't be a problem then. no one thinks it will be, but we can't be sure of course I don't even want to think about the "mpeg recording API" yet :-) it'll hopefully be less messy code the 3507 needs all bytes bit-reversed 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 hi somebody out there help I need Info shoot... what can i help ywa with hi I wanted to find out which Harddrive I can use to upgrade my Recorder20 and another question is there a limit of files to download to my player also I wanted to tell u guys that I think its pretty cool that someone trys to write his own code for the box I think its pretty hard I m just trying to start programming with C and Java will see what works better for me I looked at ur site and all those files read a lot but still dont know nothing well Im really beginning beginning C wanna play tetris, too on my machine :) and Quake II grins lol I liked that Faq hehe sorry, back :) ill address what i can.. 1. FAQ thanks for the compliment :) 2. programming... projects like this are a great way to learn 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 4. upgradeing.. no idea at all. would be nice to have 60 gig or something but those 2.5 drives are pretty expensive gonna get my player today I cant await to put my 20 gig mp3z on it but its sad that is already full after that action gonna take it with me im going for a working trip to china so when I look at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rockbox/www/sh-win/ seems like an emulator under win is that right? Where could I start to understand all that probably use more of my Linux and let that windoze go then learn C and get back to the files there are a lot In that WWW dir oops rockbox dir please tell me where can I start to understand Im wiling to learn and I want to hack my Archos 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 but Im possitive it will arive today hmmm well.. the full api for the devices isn't completed yet, but we're nearly there. as for the win/lin thing, we have a user interface simulator for both platforms the idea is that until the work on metal (hardware is done, then the rest of us have something we can work for/with in the simulator. as for where to begin.. that is always a tough question to answer. best thing i could suggest is to read over the docs that are in the cvs repositiory... then try getting the simulator working on your home machine. then just play with anything that seems interesting. i worked on tetris, screensaver and the FAQ because its what caught my eye at the time. hope that helps a bit aight thanks and dont' ever be afraid to ask quesiton shere :) gonna check the docs in the cvs cool thanx gotta go sleep now have a nice day or night or whatever u have at the moment bye 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 hey 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 Bagder taht was your reply to my idea that just went out yes? no, that's Dave's reply ah... k... i still havent gotten nicks and real life names down yet :) hehe --> Zagor_ (~bjst@labb.contactor.se) has joined #rockbox --- Zagor_ is now known as Zagor morning Zagor morn morning everyone hey Tumm --> linuxstb (dave@dsl-212-23-31-215.zen.co.uk) has joined #rockbox morning Dave Morning - what time is it in Sweden? 09:41 8.41 here in London. I'm going to be here all day - "working" at home. aah, we like that ;-) "working" at home is nice I hope my boss hasn't joined this list :-) hehehe Is anyone doing anything interesting on rockbox at the moment? not me * Bagder actually works I'll be working today, but will have time to chat. Zagor: you have any thoughts on the mpeg thread and linuxstb's api suggestions? The main change from my email is that the mpeg playing thread will be there permanently. This makes start_playback and kill_playback unneccessary. well, two things: 1) we'll be using a single thread combined with an interrupt handler in target 2) the api doesn't really need to know that :-) Agreed, but that possibly means we can't share much code between the simulator and target. yes oh yes we shouldn't share code beyond the API I thought the aim was to share as much code as possible, and design the APIs with that in mind. actually, no. the aim is to share application code, not lowlevel code yes, the appplication code should run both in target and in the simulators 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 The debate is then where do we draw the line between application and low-level. true in the APIs OK - so is my suggested API at the right level? --> Linus (~linus@labb.contactor.se) has joined #rockbox HELO I'd say so, yes. except for the threading things HELO Linus MAIL FROM: Welcome Linus - just the man to talk about mpeg playing. Oh. ;-) * Linus runs for coffee :-) Sorry! Back! our coffee machine is broken again... *sigh* shaking hands, eh? the get_next_track() things are not really mpeg-playback stuff, it's part of the playlist code trembling maybe Are you talking about the mpeg playing API? Dave's proposal, yes well, the playback doesn't know which track to play so it needs to ask yes, but it's not part of the API so how should it work? the gist is right. i'm just saying it's not part of the API, it's part of the implementation It's a way to abstract the actual selection of tracks by the user. I think the playlist code needs to supply that function, and the playback thread uses it So it's part of _an_ API. yes but that selection is handled by playlist.c, not mpeg.c right We still need that function somewhere in the program - it doesn't really matter what API we say it is part of. * Bagder agrees It's part of the two-way communication needed between the "UI thread" and the "mpeg playing thread" Two-way? not the ui, the playlist but the playlist code runs in the ui thread, no? Linus: the playback thread needs to know which track to play does it? i don't know :-) The mpeg thread needs to report it's status back to the user somehow. me neither ;-) I just thought that the UI needed to be independent of the playlist somehow, but I haven't really thought about this in detail Bagder: right, but still it makes little sense to have a separate thread for playlist management right Actually, I haven't given the UI thing much thought. I have only coded an MPEG playing thread. the playlist will be a chunk of structured memory I don't think we need separate threads - just some kind of abstract data type for playlists. yup Linus: yes, but how does it know which track to play? ;-) Currently, it just opens one track. It's a test. of course, but beyond the tests... I had a queue in mind that the playlist/UI code kept up to date, and that the MPEG thread could pick from. umm, a playlist perhaps? ;) No Linus: that is what I am thinking. A play queue. The point about my API is that it doesn't matter. ... to the mpeg thread. Exactly what dou you mean when you say playlist? I thought a playlist was an M3U file or the like well no that's only one input to a playlist a playlist is anything that knows a sequence of tracks So the playlist is the play wueue? I think a play queue is a temporary play list where the "head" is deleted. linuxstb: exactly --> wavey (~wavey@dlan1431.dircon.co.uk) has joined #rockbox I would think so too I don't much see a point in having both a play list and a play queue. please enlighten me. hey wavey morning :) The play queue is what the mpeg thread sees. The playlist is a list of files created by the user. In my world :-) why can't they be the same? I'll be back in 10 minutes..... what if the user changes the playlist - does your play queue get updated? They could. But the term "playlist" has a predefined meaning to many people. we're not "many people" ;-) yeah, but the mpeg thread code isn't meant for "many people" :) wavey: it should. But the MPEG thread doesn't care. if we offer the playback thread Dave's API, then it could be made however we want queue, list, stack, whatever it is beyond what the playback thread should care So the playback thread just calls get_next_track()? yes yes Fair eneough hjgfljsrhbglobs * Bagder throws a keyboard to Linus Throw me a brain * Bagder has none ;-) So how does the MPEG thread handle the case when the playlist changes while playing? that's why there's a peek and get_next it doesn't. that's a UI problem. So what happens when it changes after the peek()? while playing track A i'm not sure i agree on the peek() idea it peeks and sees track B coming up How often should I peek? Every second? when you need the next track Every millisecond? when you need the next track So how does the MPEG thread handle the case when the playlist changes while playing? while still playing the former So what happens when it changes after the peek()? flush, restart How do I know when to do that? or what do you suggest? I = mpeg thread you're making this too complex, IMHO I suggest a "push" push? Maybe a PLAYLIST CHANGED message? maybe just play_track() ;-) instead of peek() and next(), use an index Maybe, but it will interrupt the current song when reading next_track into the buffer, check periodically (every second?) that the file is the same so how do the thread get the next song without interrupting? once the song starts, there's no turning back Bagder: get_next_track() next() sucks Why? why? why? * wavey smiles because then you need a peek Suggestion? get(int index) what's index? OK, so a separate play queue? no 0 or 1? you guys should write this down and mail instead ;-) not until we have some kind of idea... :-) Zagor: what is the index? but it sounds like we all basicly have the same idea If the user changes the currently playing track, it calls pause_playback and then new_track with the new filename. but we talk around each other it = the UI thread Linus: index is a track counter. using this index, you can ask for several tracks in advance. not just "current" and "next" why would the playback need that? to fill the buffer, in case of small tracks ah Many short tracks. right it would in fact need that, indeed Sound effects for Tetris, for example. hehe are small tracks a real problem? How many people have small tracks? or wavey's track name reader :-) it's not a problem, but it's unfortunate to design so we can't handle them I have no problem with having peek_track(n). We still only need get_next_track though. Small tracks are not a problem. At least it shouldn't. I don't like next(). you can only call it once, right? it's a volatile interface. Yes - it is for the case when the mpeg thread has finished playing that track. I much prefer a counter that the play thread increases itself get_next_track could just increment a counter. A agree with Zagor. But what to do when the playlist changes? the playlist code must get to know when it plays the next track That is, when the index is invalid Linus: give an example We should try and make the mpeg playing thread as "ignorant" as possible. If the index is inceremented by the MPEG thread, when is it reset? in stop() ? How does the mpeg_thread know how many songs are in the playlist? I doesn't it doesn't, and shouldn't if it increments a pointer, doesn't it need to know when to stop? yeah, when it gets NULL back When it reads NULL fron the get() call it stops. :) I still think my API is more flexible. how? So the "playlist" is read by the mpeg thread via get(index)? What if the playlist shrinks in size? I don't understand Linus' and Björn's suggestion then it will get NULL immediately It puts a little burden on the playlist code To be able to index the list of tracks yes, I agree. it's not the perfect idea. A question: does the UI create a playlist from the current directory automatically?