diff options
Diffstat (limited to 'www/irc/rockbox-20020513.log')
-rw-r--r-- | www/irc/rockbox-20020513.log | 818 |
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 @@ | |||
1 | **** BEGIN LOGGING AT Sun May 12 06:00:58 2002 | ||
2 | |||
3 | --> adiamas (~adiamas@216.194.26.49) has joined #rockbox | ||
4 | --- Topic for #rockbox is Open Source Jukebox Firmware - http://bjorn.haxx.se/rockbox/ [a.k.a. This room is too damn quiet.] | ||
5 | --- Topic for #rockbox set by adiamas at Sun May 12 02:38:43 | ||
6 | --> linuxstb (dave@dsl-212-23-31-215.zen.co.uk) has joined #rockbox | ||
7 | --> alkorr (alkorr@srs07v-5-155.n.club-internet.fr) has joined #rockbox | ||
8 | <-- alkorr has quit (Client Quit) | ||
9 | --> alkorr (alkorr@srs03v-8-46.n.club-internet.fr) has joined #rockbox | ||
10 | <-- alkorr (alkorr@srs03v-8-46.n.club-internet.fr) has left #rockbox | ||
11 | <-- Tumm has quit (Read error: 113 (No route to host)) | ||
12 | --> edx (edx@pD9EAB7BC.dip.t-dialin.net) has joined #rockbox | ||
13 | <edx> hi | ||
14 | <linuxstb> Hello - is anyone around? | ||
15 | <edx> yea | ||
16 | <linuxstb> Hello Felix - are you still working on the win32 simulator? | ||
17 | <edx> yea | ||
18 | <edx> i am... | ||
19 | <linuxstb> Do you fancy implementing mpeg audio playback? | ||
20 | <edx> but i've had a lot of work to do the last two weeks.. i guess i am kinda behind the x11 :) | ||
21 | <edx> mpeg implementing is not too hard - i have already written a class for it (for another project) so i can use that. | ||
22 | <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. | ||
23 | <linuxstb> i.e. implement the functions in x11/oss_sound.c for Windows. | ||
24 | <edx> hm - i just use the windows media player to do that :) | ||
25 | <linuxstb> I think it may save work if the x11 and win32 share the same mpeg decoding code | ||
26 | <linuxstb> Does win32 support pthreads? | ||
27 | <edx> threads.. | ||
28 | <edx> sure. | ||
29 | <edx> i'll have a look ath the oss_sound.c later on... maybe i can just translate it to windows. | ||
30 | <linuxstb> I have started to implement a separate mpeg playing thread... | ||
31 | <linuxstb> ... I need to try and make it work on x11, win32 and eventually the target. | ||
32 | <edx> do we have a startthread funciton or something liek that for the target... | ||
33 | <linuxstb> I also use the pthread_mutex_lock and pthread_mutex_unlock functions to lock the play queue | ||
34 | <linuxstb> ... as well as signals to say when the queue is no longer empty | ||
35 | <linuxstb> thread.c only contains a create_thread function. I can't see anything else | ||
36 | <edx> ... ill have to write that for win32 then... | ||
37 | <edx> i gotta go now... i'll try to continue the win32 sim code during the next week. | ||
38 | <linuxstb> OK - I'll keep working on x11. Bye. | ||
39 | --- edx is now known as edx|away | ||
40 | <-- linuxstb has quit ("using sirc version 2.211+KSIRC/1.0") | ||
41 | --> Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox | ||
42 | --> Tumm (coyote@dreamhosted.borlange.se) has joined #rockbox | ||
43 | <-- Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox | ||
44 | --> linuxstb (dave@dsl-212-23-31-215.zen.co.uk) has joined #rockbox | ||
45 | --> Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox | ||
46 | <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. | ||
47 | <Bagder> uh, I'm gonna watch tv now, back in 45 mins... ;-) | ||
48 | <linuxstb> No problem. | ||
49 | * Bagder reads linuxstb's mail now | ||
50 | <Bagder> ok, I like the suggested api in general, I only have some small details | ||
51 | <Bagder> kill_playback() - "kill the mpeg playing thread" isn't that just gonna stop the audio? | ||
52 | --- edx|away is now known as edx | ||
53 | <linuxstb> This is something I wasn't sure about - is the mpeg thread there constantly, or should it be created and killed as required? | ||
54 | <Bagder> hey edx | ||
55 | <edx> hi | ||
56 | <edx> Heh: http://acmesofties.cjb.net | ||
57 | <Bagder> linuxstb: I'd prefer to have it there always | ||
58 | <linuxstb> Will we be able to send it a signal to say "wake up and play some music"? | ||
59 | <Bagder> oh sure, it would just sit waiting on a message queue or something | ||
60 | <edx> Bagder: well a kinn thread wont be bad anyways... | ||
61 | <edx> knn = kill | ||
62 | <edx> arghl.. kinn = kill | ||
63 | <Bagder> edx why so? | ||
64 | <edx> meybe it needs to cleans up some stuff... | ||
65 | <edx> maybe.. | ||
66 | <edx> jeez - cant type today | ||
67 | <Bagder> I don't believe we ever need to kill threads, at least I can't think of any good reason why | ||
68 | <edx> well - but the thread might want to clean up stuff... | ||
69 | <Bagder> sure | ||
70 | <edx> i just say it might - it doesnt have to.. :) | ||
71 | <linuxstb> How about killing the thread so we can free it's memory (i.e. the play buffer) for other things | ||
72 | <Bagder> but not by killing itself ;-) | ||
73 | <edx> then rename the function. heh.. it's just called where kill_thread would be called if it existed | ||
74 | <Bagder> linuxstb: I don't think we'll prioritise that | ||
75 | <linuxstb> OK! | ||
76 | <Bagder> stop_track() could stop the playback and free the play buffer | ||
77 | <Bagder> then start_playback() could allocate it again and play | ||
78 | <linuxstb> OK, so if are agreed that the mpeg thread is constantly there - do you have any other comments about the API? | ||
79 | <Bagder> yes another minor one: | ||
80 | <Bagder> what's the difference between new_track() and start_playback() ? | ||
81 | <Bagder> couldn't they be the same? | ||
82 | <linuxstb> start_playback creates the thread. If the thread is always there, then we can change start_playback to create_thread | ||
83 | <edx> ... good night guys | ||
84 | <linuxstb> ... which isn't really part of the API. | ||
85 | <Bagder> night edx | ||
86 | <linuxstb> bye. | ||
87 | <-- edx has quit ("l8r") | ||
88 | <Bagder> right, well I have just pictured myself the play thread to be always present... | ||
89 | <linuxstb> yes - I agree - the play thread will always be there | ||
90 | <Bagder> anyway, the thread's presence or not shouldn't be reflected in the api... | ||
91 | <Bagder> so | ||
92 | <Bagder> I think the rest covers everything up | ||
93 | <linuxstb> You're probably right about the thread's presence. | ||
94 | <linuxstb> My only other problem is how to implement the threads in the simulator | ||
95 | <linuxstb> I can use pthreads on x11, but how should this be implemented? | ||
96 | <Bagder> we can't simulate the threads in the same way they work on the target | ||
97 | <Bagder> we need to keep simualting the apis properly, not the exact behavior | ||
98 | <linuxstb> I was also thinking in terms of portability between x11 and win32. | ||
99 | <Bagder> the thread stuff won't be very portable between the x11 and win32 | ||
100 | <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. | ||
101 | <Bagder> I agree with that approach | ||
102 | <linuxstb> Another concern is the seeking inside files... | ||
103 | <linuxstb> ... it could be hard to implement with VBR files. But I guess we can leave that until last. | ||
104 | <Bagder> yes, I've thought about that too | ||
105 | <Bagder> I think we better ignore that for now | ||
106 | <linuxstb> I also think frame sizes can vary (by 1 byte) even in CBR files. | ||
107 | <Bagder> so, we better read up on the details and see what we can do | ||
108 | <Bagder> perhaps we won't be able to seek per time at all | ||
109 | <linuxstb> I think we can seek by time, but it may require scanning the file. | ||
110 | <linuxstb> The user doesn't have to use it. | ||
111 | <Bagder> true | ||
112 | <linuxstb> Should volume control be part of the mpeg API or separate? | ||
113 | <adiamas> id assume seperate | ||
114 | <Bagder> I think separate too | ||
115 | <linuxstb> I guess it is just an implementation detail | ||
116 | <Bagder> true | ||
117 | <linuxstb> Are you happy with the peek_next_track and get_next_track concept? | ||
118 | <Bagder> do we really need two functions for it? | ||
119 | <linuxstb> I think so. What is the alternative? | ||
120 | <Bagder> just get_next_track() | ||
121 | <Bagder> uh | ||
122 | <Bagder> no | ||
123 | * Bagder wasn't thinking | ||
124 | <linuxstb> So you are happy then? | ||
125 | <Bagder> get_next would then of course advance some kind of pointer | ||
126 | <linuxstb> yes - that's the difference. | ||
127 | <Bagder> yes, I'm fine with it | ||
128 | <linuxstb> OK. I guess we're done here then. | ||
129 | <Bagder> I would prefer to have Linus say something about it though, as he's the master of the MAS and mp3 playing | ||
130 | <linuxstb> I agree - I probably won't do any more work on it today anyway. | ||
131 | <Bagder> I appreciate your work | ||
132 | <linuxstb> No problem. I just wished that somewhere in the UK would get the recorder 20 in stock again. | ||
133 | <linuxstb> I don't actually own one yet. | ||
134 | <Bagder> hehe ;-) | ||
135 | <linuxstb> I am assuming the recorder is the best to buy - even if I never record on it. | ||
136 | <Bagder> yes | ||
137 | <Bagder> it has a better display and better sound (they say) | ||
138 | <linuxstb> Do you know if Linus is developing a driver for both MAS versions? | ||
139 | <Bagder> he's doing the 3507 first, the Player one | ||
140 | <Bagder> because that's the hardware he runs his gdb on ;-) | ||
141 | <Bagder> both Linus and Björn have both Player and Recorder | ||
142 | <linuxstb> Have you discussed the 3587 with him? | ||
143 | <Bagder> not very much | ||
144 | <linuxstb> I hope it won't be a problem then. | ||
145 | <Bagder> no one thinks it will be, but we can't be sure of course | ||
146 | <linuxstb> I don't even want to think about the "mpeg recording API" yet :-) | ||
147 | <Bagder> it'll hopefully be less messy code | ||
148 | <Bagder> the 3507 needs all bytes bit-reversed | ||
149 | <linuxstb> Thanks for the chat. I'll wait for Linus to comment before going too far with the mpeg playing on the simulator. | ||
150 | <-- Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox | ||
151 | <-- linuxstb has quit ("using sirc version 2.211+KSIRC/1.0") | ||
152 | --> danaka (~k_a_d_a@pD9E4A486.dip.t-dialin.net) has joined #rockbox | ||
153 | <danaka> hi | ||
154 | <danaka> somebody out there | ||
155 | <danaka> help | ||
156 | <danaka> I need Info | ||
157 | <adiamas> shoot... | ||
158 | <adiamas> what can i help ywa with | ||
159 | <danaka> hi | ||
160 | <danaka> I wanted to find out which Harddrive I can use to upgrade my Recorder20 | ||
161 | <danaka> and another question is there a limit of files to download to my player | ||
162 | <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 | ||
163 | <danaka> I think its pretty hard | ||
164 | <danaka> I m just trying to start programming with C | ||
165 | <danaka> and Java | ||
166 | <danaka> will see what works better for me | ||
167 | <danaka> I looked at ur site and all those files read a lot but still dont know nothing | ||
168 | <danaka> well Im really beginning beginning | ||
169 | <danaka> C | ||
170 | <danaka> wanna play tetris, too on my machine :) | ||
171 | <danaka> and Quake II grins | ||
172 | <danaka> lol | ||
173 | <danaka> I liked that Faq | ||
174 | <adiamas> hehe sorry, back :) | ||
175 | <adiamas> ill address what i can.. | ||
176 | <adiamas> 1. FAQ thanks for the compliment :) | ||
177 | <adiamas> 2. programming... projects like this are a great way to learn | ||
178 | <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 | ||
179 | <adiamas> 4. upgradeing.. | ||
180 | <adiamas> no idea at all. | ||
181 | <danaka> would be nice to have 60 gig or something but those 2.5 drives are pretty expensive | ||
182 | <danaka> gonna get my player today I cant await to put my 20 gig mp3z on it | ||
183 | <danaka> but its sad that is already full after that action | ||
184 | <danaka> gonna take it with me im going for a working trip to china | ||
185 | <danaka> so when I look at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rockbox/www/sh-win/ | ||
186 | <danaka> seems like an emulator under win is that right? | ||
187 | <danaka> Where could I start to understand all that probably use more of my Linux and let that windoze go | ||
188 | <danaka> then learn C and get back to the files | ||
189 | <danaka> there are a lot In that WWW dir | ||
190 | <danaka> oops rockbox dir | ||
191 | <danaka> please tell me where can I start to understand Im wiling to learn | ||
192 | <danaka> and I want to hack my Archos | ||
193 | <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 | ||
194 | <danaka> but Im possitive it will arive today | ||
195 | <adiamas> hmmm well.. | ||
196 | <adiamas> the full api for the devices isn't completed yet, but we're nearly there. | ||
197 | <adiamas> as for the win/lin thing, | ||
198 | <adiamas> we have a user interface simulator for both platforms | ||
199 | <adiamas> the idea is that until the work on metal (hardware | ||
200 | <adiamas> is done, then the rest of us have something we can work for/with in the simulator. | ||
201 | <adiamas> as for where to begin.. that is always a tough question to answer. | ||
202 | <adiamas> best thing i could suggest is to read over the docs that are in the cvs repositiory... | ||
203 | <adiamas> then try getting the simulator working on your home machine. | ||
204 | <adiamas> then just play with anything that seems interesting. | ||
205 | <adiamas> i worked on tetris, screensaver and the FAQ because its what caught my eye at the time. | ||
206 | <adiamas> hope that helps a bit | ||
207 | <danaka> aight thanks | ||
208 | <adiamas> and dont' ever be afraid to ask quesiton shere :) | ||
209 | <danaka> gonna check the docs in the cvs | ||
210 | <danaka> cool thanx | ||
211 | <danaka> gotta go sleep now have a nice day or night or whatever u have at the moment | ||
212 | <danaka> bye | ||
213 | <adiamas> bye | ||
214 | <-- danaka (~k_a_d_a@pD9E4A486.dip.t-dialin.net) has left #rockbox | ||
215 | --> calpefrosch (~calpefros@62.52.174.30) has joined #rockbox | ||
216 | --> Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox | ||
217 | --- ChanServ gives channel operator status to Bagder | ||
218 | <adiamas> hey Bagder | ||
219 | <Bagder> howdy | ||
220 | <-- Tumm has quit (zahn.openprojects.net irc.openprojects.net) | ||
221 | <-- PsycoXul has quit (zahn.openprojects.net irc.openprojects.net) | ||
222 | --> Tumm (coyote@dreamhosted.borlange.se) has joined #rockbox | ||
223 | --> PsycoXul (psyco@adsl-63-205-40-140.dsl.lsan03.pacbell.net) has joined #rockbox | ||
224 | <adiamas> Bagder taht was your reply to my idea that just went out yes? | ||
225 | <Bagder> no, that's Dave's reply | ||
226 | <adiamas> ah... k... | ||
227 | <adiamas> i still havent gotten nicks and real life names down yet :) | ||
228 | <Bagder> hehe | ||
229 | --> Zagor_ (~bjst@labb.contactor.se) has joined #rockbox | ||
230 | --- Zagor_ is now known as Zagor | ||
231 | <Bagder> morning Zagor | ||
232 | <Zagor> morn | ||
233 | <Tumm> morning everyone | ||
234 | <Bagder> hey Tumm | ||
235 | --> linuxstb (dave@dsl-212-23-31-215.zen.co.uk) has joined #rockbox | ||
236 | <Bagder> morning Dave | ||
237 | <linuxstb> Morning - what time is it in Sweden? | ||
238 | <Bagder> 09:41 | ||
239 | <linuxstb> 8.41 here in London. | ||
240 | <linuxstb> I'm going to be here all day - "working" at home. | ||
241 | <Bagder> aah, we like that ;-) | ||
242 | <Bagder> "working" at home is nice | ||
243 | <linuxstb> I hope my boss hasn't joined this list :-) | ||
244 | <Bagder> hehehe | ||
245 | <linuxstb> Is anyone doing anything interesting on rockbox at the moment? | ||
246 | <Bagder> not me | ||
247 | * Bagder actually works | ||
248 | <linuxstb> I'll be working today, but will have time to chat. | ||
249 | <Bagder> Zagor: you have any thoughts on the mpeg thread and linuxstb's api suggestions? | ||
250 | <linuxstb> The main change from my email is that the mpeg playing thread will be there permanently. | ||
251 | <linuxstb> This makes start_playback and kill_playback unneccessary. | ||
252 | <Zagor> well, two things: 1) we'll be using a single thread combined with an interrupt handler in target | ||
253 | <Zagor> 2) the api doesn't really need to know that :-) | ||
254 | <linuxstb> Agreed, but that possibly means we can't share much code between the simulator and target. | ||
255 | <Zagor> yes | ||
256 | <Bagder> oh yes | ||
257 | <Zagor> we shouldn't share code beyond the API | ||
258 | <linuxstb> I thought the aim was to share as much code as possible, and design the APIs with that in mind. | ||
259 | <Zagor> actually, no. the aim is to share application code, not lowlevel code | ||
260 | <Bagder> yes, the appplication code should run both in target and in the simulators | ||
261 | <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 | ||
262 | <linuxstb> The debate is then where do we draw the line between application and low-level. | ||
263 | <Bagder> true | ||
264 | <Zagor> in the APIs | ||
265 | <linuxstb> OK - so is my suggested API at the right level? | ||
266 | --> Linus (~linus@labb.contactor.se) has joined #rockbox | ||
267 | <Linus> HELO | ||
268 | <Zagor> I'd say so, yes. except for the threading things | ||
269 | <Bagder> HELO Linus | ||
270 | <Linus> MAIL FROM: | ||
271 | <linuxstb> Welcome Linus - just the man to talk about mpeg playing. | ||
272 | <Linus> Oh. | ||
273 | <Bagder> ;-) | ||
274 | * Linus runs for coffee | ||
275 | <linuxstb> :-) | ||
276 | <linuxstb> Sorry! | ||
277 | <Linus> Back! | ||
278 | <Bagder> our coffee machine is broken again... *sigh* | ||
279 | <Linus> shaking hands, eh? | ||
280 | <Zagor> the get_next_track() things are not really mpeg-playback stuff, it's part of the playlist code | ||
281 | <Linus> trembling maybe | ||
282 | <Linus> Are you talking about the mpeg playing API? | ||
283 | <Zagor> Dave's proposal, yes | ||
284 | <Bagder> well, the playback doesn't know which track to play so it needs to ask | ||
285 | <Zagor> yes, but it's not part of the API | ||
286 | <Bagder> so how should it work? | ||
287 | <Zagor> the gist is right. i'm just saying it's not part of the API, it's part of the implementation | ||
288 | <linuxstb> It's a way to abstract the actual selection of tracks by the user. | ||
289 | <Bagder> I think the playlist code needs to supply that function, and the playback thread uses it | ||
290 | <linuxstb> So it's part of _an_ API. | ||
291 | <Zagor> yes but that selection is handled by playlist.c, not mpeg.c | ||
292 | <Zagor> right | ||
293 | <linuxstb> We still need that function somewhere in the program - it doesn't really matter what API we say it is part of. | ||
294 | * Bagder agrees | ||
295 | <linuxstb> It's part of the two-way communication needed between the "UI thread" and the "mpeg playing thread" | ||
296 | <Linus> Two-way? | ||
297 | <Bagder> not the ui, the playlist | ||
298 | <Zagor> but the playlist code runs in the ui thread, no? | ||
299 | <Bagder> Linus: the playback thread needs to know which track to play | ||
300 | <Bagder> does it? | ||
301 | <Zagor> i don't know :-) | ||
302 | <linuxstb> The mpeg thread needs to report it's status back to the user somehow. | ||
303 | <Bagder> me neither ;-) | ||
304 | <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 | ||
305 | <Zagor> Bagder: right, but still it makes little sense to have a separate thread for playlist management | ||
306 | <Bagder> right | ||
307 | <Linus> Actually, I haven't given the UI thing much thought. I have only coded an MPEG playing thread. | ||
308 | <Bagder> the playlist will be a chunk of structured memory | ||
309 | <linuxstb> I don't think we need separate threads - just some kind of abstract data type for playlists. | ||
310 | <Zagor> yup | ||
311 | <Bagder> Linus: yes, but how does it know which track to play? ;-) | ||
312 | <Linus> Currently, it just opens one track. It's a test. | ||
313 | <Bagder> of course, but beyond the tests... | ||
314 | <Linus> I had a queue in mind that the playlist/UI code kept up to date, and that the MPEG thread could pick from. | ||
315 | <Zagor> umm, a playlist perhaps? ;) | ||
316 | <Linus> No | ||
317 | <linuxstb> Linus: that is what I am thinking. A play queue. | ||
318 | <linuxstb> The point about my API is that it doesn't matter. | ||
319 | <linuxstb> ... to the mpeg thread. | ||
320 | <Linus> Exactly what dou you mean when you say playlist? | ||
321 | <Linus> I thought a playlist was an M3U file or the like | ||
322 | <Zagor> well no that's only one input to a playlist | ||
323 | <Bagder> a playlist is anything that knows a sequence of tracks | ||
324 | <Linus> So the playlist is the play wueue? | ||
325 | <linuxstb> I think a play queue is a temporary play list where the "head" is deleted. | ||
326 | <Linus> linuxstb: exactly | ||
327 | --> wavey (~wavey@dlan1431.dircon.co.uk) has joined #rockbox | ||
328 | <Bagder> I would think so too | ||
329 | <Zagor> I don't much see a point in having both a play list and a play queue. please enlighten me. | ||
330 | <Bagder> hey wavey | ||
331 | <wavey> morning :) | ||
332 | <Linus> The play queue is what the mpeg thread sees. The playlist is a list of files created by the user. | ||
333 | <Linus> In my world :-) | ||
334 | <Zagor> why can't they be the same? | ||
335 | <linuxstb> I'll be back in 10 minutes..... | ||
336 | <wavey> what if the user changes the playlist - does your play queue get updated? | ||
337 | <Linus> They could. But the term "playlist" has a predefined meaning to many people. | ||
338 | <Bagder> we're not "many people" ;-) | ||
339 | <Zagor> yeah, but the mpeg thread code isn't meant for "many people" :) | ||
340 | <Linus> wavey: it should. But the MPEG thread doesn't care. | ||
341 | <Bagder> if we offer the playback thread Dave's API, then it could be made however we want | ||
342 | <Bagder> queue, list, stack, whatever | ||
343 | <Bagder> it | ||
344 | <Bagder> is beyond what the playback thread should care | ||
345 | <Linus> So the playback thread just calls get_next_track()? | ||
346 | <Zagor> yes | ||
347 | <Bagder> yes | ||
348 | <Linus> Fair eneough | ||
349 | <Linus> hjgfljsrhbglobs | ||
350 | * Bagder throws a keyboard to Linus | ||
351 | <Linus> Throw me a brain | ||
352 | * Bagder has none ;-) | ||
353 | <Linus> So how does the MPEG thread handle the case when the playlist changes while playing? | ||
354 | <Bagder> that's why there's a peek and get_next | ||
355 | <Zagor> it doesn't. that's a UI problem. | ||
356 | <Linus> So what happens when it changes after the peek()? | ||
357 | <Bagder> while playing track A | ||
358 | <Zagor> i'm not sure i agree on the peek() idea | ||
359 | <Bagder> it peeks and sees track B coming up | ||
360 | <Linus> How often should I peek? | ||
361 | <Linus> Every second? | ||
362 | <Bagder> when you need the next track | ||
363 | <Linus> Every millisecond? | ||
364 | <Bagder> when you need the next track | ||
365 | <Linus> So how does the MPEG thread handle the case when the playlist changes while playing? | ||
366 | <Bagder> while still playing the former | ||
367 | <Linus> So what happens when it changes after the peek()? | ||
368 | <Bagder> flush, restart | ||
369 | <Linus> How do I know when to do that? | ||
370 | <Bagder> or what do you suggest? | ||
371 | <Linus> I = mpeg thread | ||
372 | <Zagor> you're making this too complex, IMHO | ||
373 | <Linus> I suggest a "push" | ||
374 | <Bagder> push? | ||
375 | <Linus> Maybe a PLAYLIST CHANGED message? | ||
376 | <Bagder> maybe just play_track() ;-) | ||
377 | <Zagor> instead of peek() and next(), use an index | ||
378 | <Linus> Maybe, but it will interrupt | ||
379 | <Linus> the current song | ||
380 | <Zagor> when reading next_track into the buffer, check periodically (every second?) that the file is the same | ||
381 | <Bagder> so how do the thread get the next song without interrupting? | ||
382 | <Zagor> once the song starts, there's no turning back | ||
383 | <Linus> Bagder: get_next_track() | ||
384 | <Zagor> next() sucks | ||
385 | <Linus> Why? | ||
386 | <Bagder> why? | ||
387 | <wavey> why? | ||
388 | * wavey smiles | ||
389 | <Zagor> because then you need a peek | ||
390 | <Linus> Suggestion? | ||
391 | <Zagor> get(int index) | ||
392 | <Bagder> what's index? | ||
393 | <Linus> OK, so a separate play queue? | ||
394 | <Zagor> no | ||
395 | <Bagder> 0 or 1? | ||
396 | <Bagder> you guys should write this down and mail instead ;-) | ||
397 | <Zagor> not until we have some kind of idea... :-) | ||
398 | <Linus> Zagor: what is the index? | ||
399 | <Bagder> but it sounds like we all basicly have the same idea | ||
400 | <linuxstb> If the user changes the currently playing track, it calls pause_playback and then new_track with the new filename. | ||
401 | <Bagder> but we talk around each other | ||
402 | <linuxstb> it = the UI thread | ||
403 | <Zagor> Linus: index is a track counter. using this index, you can ask for several tracks in advance. | ||
404 | <Zagor> not just "current" and "next" | ||
405 | <Bagder> why would the playback need that? | ||
406 | <Zagor> to fill the buffer, in case of small tracks | ||
407 | <Bagder> ah | ||
408 | <Linus> Many short tracks. | ||
409 | <Bagder> right | ||
410 | <Bagder> it would in fact need that, indeed | ||
411 | <Linus> Sound effects for Tetris, for example. | ||
412 | <Bagder> hehe | ||
413 | <linuxstb> are small tracks a real problem? How many people have small tracks? | ||
414 | <Zagor> or wavey's track name reader :-) | ||
415 | <Zagor> it's not a problem, but it's unfortunate to design so we can't handle them | ||
416 | <linuxstb> I have no problem with having peek_track(n). We still only need get_next_track though. | ||
417 | <Linus> Small tracks are not a problem. At least it shouldn't. | ||
418 | <Zagor> I don't like next(). you can only call it once, right? it's a volatile interface. | ||
419 | <linuxstb> Yes - it is for the case when the mpeg thread has finished playing that track. | ||
420 | <Zagor> I much prefer a counter that the play thread increases itself | ||
421 | <linuxstb> get_next_track could just increment a counter. | ||
422 | <Linus> A agree with Zagor. But what to do when the playlist changes? | ||
423 | <Bagder> the playlist code must get to know when it plays the next track | ||
424 | <Linus> That is, when the index is invalid | ||
425 | <Zagor> Linus: give an example | ||
426 | <linuxstb> We should try and make the mpeg playing thread as "ignorant" as possible. | ||
427 | <Linus> If the index is inceremented by the MPEG thread, when is it reset? | ||
428 | <Zagor> in stop() ? | ||
429 | <linuxstb> How does the mpeg_thread know how many songs are in the playlist? | ||
430 | <Linus> I doesn't | ||
431 | <Zagor> it doesn't, and shouldn't | ||
432 | <linuxstb> if it increments a pointer, doesn't it need to know when to stop? | ||
433 | <Zagor> yeah, when it gets NULL back | ||
434 | <Linus> When it reads NULL fron the get() call it stops. | ||
435 | <Zagor> :) | ||
436 | <linuxstb> I still think my API is more flexible. | ||
437 | <Zagor> how? | ||
438 | <Linus> So the "playlist" is read by the mpeg thread via get(index)? | ||
439 | <linuxstb> What if the playlist shrinks in size? | ||
440 | <Bagder> I don't understand Linus' and Björn's suggestion | ||
441 | <Zagor> then it will get NULL immediately | ||
442 | <Linus> It puts a little burden on the playlist code | ||
443 | <Linus> To be able to index the list of tracks | ||
444 | <Zagor> yes, I agree. it's not the perfect idea. | ||
445 | <Linus> A question: does the UI create a playlist from the current directory automatically? | ||
446 | <Bagder> so how do the playlist code know which entry that plays right now? | ||
447 | <linuxstb> Linus: You (i.e. the mpeg thread) shouldn't care. | ||
448 | <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 | ||
449 | <Linus> I know. I'm just trying to figure out if ZAgors idea is practical | ||
450 | <Linus> Zagor: sounds OK | ||
451 | <Bagder> Zagor: right, we need something like that | ||
452 | <linuxstb> I believe that with my API, any type of UI can be implemented. | ||
453 | <linuxstb> Zagor - I agree. All you are doing is changing the name of the function, not it's purpose. | ||
454 | <Bagder> well, these suggestsions aren't that different, if I'm understanding things | ||
455 | <Zagor> linuxstb: actually, I don't want next_track() to tell which is the next track. only peek() is used for that. | ||
456 | <linuxstb> Zagor: sorry, I misunderstood. | ||
457 | <Zagor> i want next_track() to only tell the playlist code that the playthread has advanced one step | ||
458 | <linuxstb> OK, what about get_track_name(n) | ||
459 | <Zagor> then peek() can use a relative index instead of a counter. 0=current track, 1=next, 2=nextnext etc | ||
460 | <Zagor> I think peek() is an ok name, actually | ||
461 | <linuxstb> But I think we now agree on functionality. | ||
462 | <Zagor> sure, if you all agree with me. :*D | ||
463 | <linuxstb> I think I do. | ||
464 | <Bagder> basicly, after all, this is Dave's idea with a few minor changes :-) | ||
465 | <Zagor> yes | ||
466 | <Zagor> but it's good to just go through it, even if we just wind up where we started | ||
467 | <Bagder> right | ||
468 | <Bagder> linuxstb: are you updating your original suggestion according to all this? | ||
469 | <linuxstb> :-) OK. | ||
470 | <Linus> I'll start coding an MPEG thread that supports this API | ||
471 | <Bagder> I just think it would be good to get it in "print" | ||
472 | <Bagder> neato | ||
473 | <linuxstb> I don't think I'll have time to do it immediately though. Sorry. | ||
474 | <Linus> Lazy bastard! :-) | ||
475 | <linuxstb> Work is calling... | ||
476 | <Linus> Work? What is that? | ||
477 | <linuxstb> OK, I'll do something very quickly now and send to the list. If I miss something, please modify my email. | ||
478 | <Linus> Is there working code for the Player keys? | ||
479 | <Zagor> I think so | ||
480 | <Linus> Good. | ||
481 | <Bagder> Zagor: did you try your player app on target yet? | ||
482 | <Zagor> no | ||
483 | <Zagor> I was playing have-a-life all weekend :) | ||
484 | <Bagder> would be cool to know if it works | ||
485 | <Linus> Zagor: you have a player app? | ||
486 | <Bagder> life? | ||
487 | <Zagor> Linus: the file browser | ||
488 | <Linus> Ah | ||
489 | <Bagder> yeah, you guys were missing here during the weekend ;-) | ||
490 | <Linus> I know. I was alone with my kid. I had no time... | ||
491 | <Linus> And when I joined the channel on saturday is was dead. | ||
492 | <Zagor> Linus: an excellent opportunity for that old speech about the bits and the bytes | ||
493 | <Linus> Three sleeping americans | ||
494 | <Bagder> oops ;-) | ||
495 | <Bagder> hahaha | ||
496 | <Bagder> "you see each byte consists of eight bits... " | ||
497 | <Linus> Does joining the channel on a saturday night say something about not having a life...? | ||
498 | <Bagder> noooooo | ||
499 | <Linus> Or trying to forget that you have one? | ||
500 | <Linus> "So, Rasmus, it's time to sleep now." | ||
501 | <Linus> "No, I don't want to:" | ||
502 | <Linus> "SLEEP GODDAMMIT! I need to hack the rockbox!" | ||
503 | --- Bagder has changed the topic to: Does your box rock? http://bjorn.haxx.se/rockbox/ | ||
504 | <Linus> "But it's only 4am" | ||
505 | <Linus> pm, | ||
506 | --> alkorr (alkorr@srs05v-8-132.n.club-internet.fr) has joined #rockbox | ||
507 | <alkorr> hi | ||
508 | <Bagder> hi alkorr | ||
509 | <alkorr> the guy we found in internet (DSP guy) is unreachable ? | ||
510 | <Zagor> no, he answered but declined | ||
511 | <alkorr> !? | ||
512 | <alkorr> NDA ? | ||
513 | <Zagor> i didn't ask any technical questions, just if he wanted to help. and he said "not for free" | ||
514 | <alkorr> grrr... | ||
515 | <Linus> Typical. A guy that has mouths to feed. :-) | ||
516 | <Zagor> the youth of today... :-) | ||
517 | <Bagder> he probably thinks he has a life too! ;-P | ||
518 | * Bagder curses everyone that don't agree with us | ||
519 | <alkorr> well, in fact, what we need is some infos like assembly codes or some tools. Even such a thing is impossible for him ??? | ||
520 | <Zagor> the tools are proprietary. same with the docs... | ||
521 | <alkorr> if he doesn't want to code for us is not a matter for me | ||
522 | <alkorr> and he said "not for free"... a cracker ? | ||
523 | <Zagor> that was not a quote. he said he was not interested in doing it as a spare time hobby project. | ||
524 | <Zagor> doing it == helping | ||
525 | <alkorr> ok | ||
526 | <alkorr> what his email address ? | ||
527 | <Linus> BOMB HIM! :_) | ||
528 | <alkorr> yaaah | ||
529 | <linuxstb> I've just emailed an updated API document to the list. Please amend and publish on the website. | ||
530 | <linuxstb> Now I must do some work :-). | ||
531 | <Zagor> alkorr: samar@winlab.rutgers.edu | ||
532 | <Zagor> next_track() should be "void next_track(void)" | ||
533 | <linuxstb> Can someone else take responsibility for amendments? | ||
534 | <Zagor> sure | ||
535 | <linuxstb> We also need to decide on the location of the functions - e.g. firmware/mpeg.h and firmware/playlist.h | ||
536 | <Zagor> yes | ||
537 | <Zagor> the mpeg code should probably stay in firmware, while the playlist code goes in apps | ||
538 | <Zagor> now go work! ;) | ||
539 | --- Linus is now known as Linus|lunch | ||
540 | --- Zagor is now known as Zagor|lunch | ||
541 | <-- alkorr has quit () | ||
542 | --- Linus|lunch is now known as Linus | ||
543 | --- Zagor|lunch is now known as Zagor | ||
544 | <Linus> Yo guys! | ||
545 | * Bagder awakens and blinks | ||
546 | <Linus> Do we really need the "bool" type? I think it's redundant. | ||
547 | <Bagder> it is redundant, I just kinda like having functions return 'bool' when they return only TRUE or FALSE | ||
548 | <Zagor> umm... does anyone remember why we added it? ;) | ||
549 | <Bagder> we added it because code we added used it | ||
550 | <Linus> What code | ||
551 | <Bagder> does it matter? | ||
552 | <Linus> Just curious | ||
553 | <Linus> I feel like killing the bool type. | ||
554 | <Bagder> I think it was Gary code | ||
555 | <Bagder> why "kill" it? does it harm anyone? ;-) | ||
556 | <Linus> It's ugly. | ||
557 | <Bagder> what if we paint it in bright colours? ;-P | ||
558 | <Zagor> it sort of flies in the face of the "no new types, just plain C" rule in CONTRIBUTING | ||
559 | <Bagder> we discussed it when I added it there | ||
560 | <Linus> Having a type like that automatically makes people think that we HAVE to use it. | ||
561 | <Bagder> before CONTRIBUTING even existed :-) | ||
562 | <Zagor> I know. and now we discuss it again. :-) | ||
563 | <Bagder> as I said, I am +1 on using and having bool | ||
564 | <Bagder> you may vote against me | ||
565 | * Zagor is undecided | ||
566 | <Linus> I am definitely against. | ||
567 | <Bagder> I think it improves readability | ||
568 | <Bagder> a matter of taste and opinion no doubt | ||
569 | <Zagor> well bool is part of the C99 specifiction, so I guess it should be considered as "plain C" | ||
570 | <Bagder> oh don't we just loooove C99 ;-) | ||
571 | <Linus> Maybe I'm just old and cranky... | ||
572 | <Bagder> yes you are OOOOOLD | ||
573 | <Zagor> but then we should use the built-in bool and not define it ourselves | ||
574 | <Bagder> no can do | ||
575 | <Bagder> we build with non-C99 compilers too | ||
576 | <Zagor> yeah, the simulators. but not the target. | ||
577 | <Bagder> right | ||
578 | <Zagor> so let the simulators define a bool if they need to | ||
579 | <Bagder> is the 2.95 one true C99 then? | ||
580 | <Bagder> not everyone uses gcc3 for target | ||
581 | <Zagor> I don't know, but I've seen gcc C code use internal 'bool'. can't figure out how to enable it, though :-) | ||
582 | <Bagder> oh well, let's face the problem when we get it, not assuming it on beforehand | ||
583 | <Zagor> yes | ||
584 | * Bagder noticed that edx edited out wavey's little C99'ism in the playlist code a week ago or so... | ||
585 | <Zagor> what was that? | ||
586 | <Bagder> dynamic array alloc on stack | ||
587 | <Bagder> char buffer[foo]; | ||
588 | <Zagor> ah, yes. but that's bad code (tm) too. | ||
589 | <Bagder> it depends | ||
590 | <Bagder> now it makes a malloc() instead, which isn't a lot better | ||
591 | <Zagor> well we have a lot more heap than stack :) | ||
592 | <Bagder> well, using memory in one pool or another | ||
593 | <Zagor> gcc supports bool since 2.7.0, btw | ||
594 | <Bagder> ok | ||
595 | <Linus> Zagor: your ATA/FAT code uses the stack for sector data. | ||
596 | <Bagder> how big stack are you running with atm? | ||
597 | <Zagor> #include <stdbool.h> is the C99 way | ||
598 | <Linus> 8K | ||
599 | <Zagor> Linus: yes, it's imperfect but it's also fixed size | ||
600 | <Linus> True | ||
601 | <Linus> Forgot about the dynamic size. THAT is bad code (tm) | ||
602 | <Zagor> but you're right, that should be changed | ||
603 | <Bagder> well, malloc() causes fragmentation, dynamic on the stack doesn't ;-) | ||
604 | <Bagder> *and* it is faster to get it and return it | ||
605 | * Bagder shuts up now | ||
606 | <Linus> But that forces us to use a huge stack, chich is unused most of the time. | ||
607 | <Bagder> very true | ||
608 | <Linus> And one huge stack per thread... | ||
609 | <Zagor> stdbool.h defines "bool", "true" and "false" | ||
610 | <Zagor> not TRUE and FALSE | ||
611 | <Bagder> #define TRUE true ;-) | ||
612 | <Linus> Gaah! | ||
613 | <Zagor> Linus: gaah what, the 'false' or the #define? | ||
614 | <Linus> The define | ||
615 | <Zagor> ah, agreed | ||
616 | <Linus> But I think we should use true/false if we intend to be C99 | ||
617 | <Zagor> yes | ||
618 | * Bagder disagrees | ||
619 | * Linus waits for Bagders explanation | ||
620 | <Zagor> go on | ||
621 | <Bagder> first, just because we can do C99 doesn't mean we have to | ||
622 | <Linus> ok | ||
623 | <Zagor> true | ||
624 | <Bagder> secondly, I am just so darned used to TRUE and FALSE and I like them that way ;-) | ||
625 | <Linus> And I am used to BOOL and not bool | ||
626 | <Linus> but i prefer int | ||
627 | <Bagder> BOOL? | ||
628 | <Bagder> windows? ;-) | ||
629 | <Linus> Amiga | ||
630 | <Zagor> linus wants VOID too | ||
631 | * Zagor hides | ||
632 | <Bagder> hehe | ||
633 | <Linus> It's actually quite common | ||
634 | * Linus slaps Zagor HARD | ||
635 | * Bagder can hardly remember Amiga programming ;-) | ||
636 | <Zagor> I prefer 'hard' | ||
637 | <Zagor> ;) | ||
638 | <Linus> OK so if BOOL is wrong, why is bool right? | ||
639 | <Linus> When there isn't a bool type in the first place | ||
640 | <Bagder> because bool is lowercase | ||
641 | <Linus> And having TRUE and FALSE doesn't force us to use a BOOL/bool type | ||
642 | <Bagder> no, they're not strictly related | ||
643 | <Linus> I like int and TRUE and FALSE | ||
644 | <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. | ||
645 | <Linus> That implies C99 | ||
646 | <Zagor> yes | ||
647 | <Zagor> or, rather, gcc | ||
648 | <Linus> I can go with that. | ||
649 | <Linus> What I am against is user-defined types for no reason. | ||
650 | <Bagder> C99 or gcc rather | ||
651 | <Zagor> I still reserve the right to refuse some other portions of C99 :) | ||
652 | * Linus loads his gun | ||
653 | * Bagder digs up the standard to write peculiar code ;-) | ||
654 | * Zagor changes all TRUE/FALSE to true/false | ||
655 | <Linus> Officer Zagor: must we use bool, or is it at our convenience? | ||
656 | <Zagor> If it's a bool, I say we should use a bool. it *does* make the API easier to read | ||
657 | * Bagder scores a point with the police ;-) | ||
658 | * Bagder is writing the greatest memory hog at work ;-) | ||
659 | <Bagder> incredibly stupid | ||
660 | <Linus> Tell me | ||
661 | <Bagder> "follow the spec" ;-) | ||
662 | <Bagder> we have a built-in "registry" in our boxes | ||
663 | <Bagder> a hierarchal view of lots of settings | ||
664 | <Bagder> every program can register new "nodes" | ||
665 | <Bagder> and the data is read/set with callbacks | ||
666 | <Bagder> quite neat, in general | ||
667 | <Bagder> now, this module we're working on that I'm writing this "registry" interface for is breaking all previous limits | ||
668 | <Bagder> it takes a lot to explain, but a modest calculation of used ram may end up on 30MB... | ||
669 | <Bagder> where we previously used ~3 | ||
670 | <Bagder> for the complete system | ||
671 | <Zagor> ooh, nice :) | ||
672 | <Linus> Ouch! | ||
673 | <Bagder> it is beyond all sense | ||
674 | <Linus> Code police: should we include "stdbool.h"? | ||
675 | <Bagder> connection.oDescription.X.destination.X.channel.X.sourceRoute.X | ||
676 | <Bagder> ... each X is a number between 0 and ... ;-) | ||
677 | <Bagder> say max 10, and we say 10.000 nodes ;-) | ||
678 | <Zagor> Linus: yes | ||
679 | * Bagder sighs and gets back to work | ||
680 | <Zagor> Bagder: never let reality come in the way of an elegant design! ;) | ||
681 | <Bagder> this is a perfect candidate for this | ||
682 | <Bagder> they smile very big when they think of this design ;-) | ||
683 | <Bagder> they won't smile as much when reality strikes back | ||
684 | <Bagder> you didn't change tetris | ||
685 | <Zagor> i know, i changed the firmware first. fixing the simulator now. | ||
686 | <Bagder> nice | ||
687 | <Zagor> dine | ||
688 | <Zagor> done | ||
689 | --> irony (~irony@as2-5-7.j.bonet.se) has joined #rockbox | ||
690 | <irony> hello | ||
691 | <Zagor> hi | ||
692 | <Bagder> hey irony | ||
693 | <irony> hi Bagder | ||
694 | <Zagor> how's the web design going? ;) | ||
695 | <irony> oh | ||
696 | <irony> haven' put any effort in it really | ||
697 | <irony> =) | ||
698 | <irony> hey have you guys tried gentoo? | ||
699 | <Zagor> nope | ||
700 | <irony> I like it, really. I learned a lot form the install, since it's not "automagic" | ||
701 | <irony> only downside is that it takes quite a while to install, since everything is compiled from scratch | ||
702 | <Linus> What it gentoo? | ||
703 | <irony> www.gentoo.org | ||
704 | <irony> linux distribution | ||
705 | <irony> with a ports-system | ||
706 | <Zagor> it's a linux distro that compiles everything | ||
707 | <irony> yep | ||
708 | <irony> I like the approach, it's really cool. | ||
709 | <irony> but kde takes a lifetime to compile, though. | ||
710 | <Linus> Just upgrade your computer. :-) | ||
711 | <Zagor> personally, I think it's unnecessary. but i'm glad it's there for those who want it. | ||
712 | <irony> Linus: hehe | ||
713 | --> chris1 (~flanz@62.132.155.14) has joined #rockbox | ||
714 | <irony> Zagor: Well, I can agree that a quick binary automatic install is better in one sense | ||
715 | <irony> Butit is really nice to have the possibility of choosing and optimizing, even though one does not have extensive linux knowledge | ||
716 | <chris1> hi | ||
717 | <Linus> Hi! | ||
718 | <Zagor> irony: curl -O package.tar.gz; tar xzf package.tar.gz; cd package; ./configure; make; make install | ||
719 | <Zagor> it's not like it's difficult :-) | ||
720 | <chris1> Zagor your have checkin (id3.h) .) | ||
721 | <Zagor> no, it didn't change. why? | ||
722 | <Zagor> irony: It would be very nice if you could mail me the mockup webpage you did, so I can use the colors etc. | ||
723 | <irony> Zagor: true... | ||
724 | <irony> Zagor: but still | ||
725 | <irony> i still like gentoo | ||
726 | <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. | ||
727 | <Zagor> nice for you :) | ||
728 | <irony> I am trying xfs, does anyone have experiences? | ||
729 | <Bagder> chris1: it was present yesterday too... | ||
730 | <irony> Zagor: it's just an image, but sure. Otherwise I might put some effort in and make a real page | ||
731 | <irony> Zagor: just need to wait for kde to finish compiling | ||
732 | <irony> :) | ||
733 | <Zagor> ok, if you wish | ||
734 | <Linus> Oh. A lifetime. | ||
735 | <chris1> bagder : I have se the log 2002/5/5 10:31:21 :) | ||
736 | <irony> pretty I should have done this compiling over night | ||
737 | <-- irony has quit ("Changing server") | ||
738 | <-- chris1 has quit ("r") | ||
739 | --> edx (edx@pD9EA9D41.dip.t-dialin.net) has joined #rockbox | ||
740 | <edx> hi | ||
741 | <Linus> yo | ||
742 | <Zagor> hi | ||
743 | * edx has to leave again in a sek... | ||
744 | <edx> total-school-overload :P | ||
745 | <-- Zagor (~bjst@labb.contactor.se) has left #rockbox | ||
746 | <-- Linus (~linus@labb.contactor.se) has left #rockbox | ||
747 | <Bagder> you scared them away! ;-) | ||
748 | <edx> sorry | ||
749 | <edx> hehe | ||
750 | --> Zagor_ (~bjst@labb.contactor.se) has joined #rockbox | ||
751 | <edx> (meybe it was the word "school") lol | ||
752 | <Bagder> hehe | ||
753 | --- Zagor_ is now known as Zagor | ||
754 | <Zagor> tunnel problems | ||
755 | <edx> arghl.. there i go again with the typing stuff (meybe = maybe) | ||
756 | <edx> .. gotta go - be back in like an hour. cu | ||
757 | --- edx is now known as edx|away | ||
758 | --> Linus (~linus@labb.contactor.se) has joined #rockbox | ||
759 | --> alkorr (alkorr@srs08m-8-30.n.club-internet.fr) has joined #rockbox | ||
760 | <-- calpefrosch has quit (Read error: 104 (Connection reset by peer)) | ||
761 | <alkorr> i have a contact with this guy... i'm trying to have those opcodes, he could help to provide them | ||
762 | <alkorr> (DSP coder guy) | ||
763 | <Zagor> ah, nice! | ||
764 | <Zagor> gotta go. see you tomorrow, guys | ||
765 | <-- Zagor (~bjst@labb.contactor.se) has left #rockbox | ||
766 | <-- Linus (~linus@labb.contactor.se) has left #rockbox | ||
767 | <-- alkorr has quit () | ||
768 | * Bagder takes off for home too | ||
769 | <-- Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox | ||
770 | --- edx|away is now known as edx | ||
771 | <-- wavey has quit (Read error: 110 (Connection timed out)) | ||
772 | --> wavey (~wavey@host-54.valtech.co.uk) has joined #rockbox | ||
773 | --> Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox | ||
774 | --> Linus (~linus@labb.contactor.se) has joined #rockbox | ||
775 | <Bagder> good evening | ||
776 | <Linus> evening | ||
777 | <Linus> Bagder: how is that malloc() going? | ||
778 | <Bagder> it is sitting here, I was under the impression it wasn't exactly needed | ||
779 | <Linus> Just curious. I'm using the newlib malloc now, but I assume that we will use your malloc() in the future. | ||
780 | <Bagder> it would be interesting to run a comparison on them somehow | ||
781 | <Linus> Perhaps. | ||
782 | <Bagder> I should probably start with adding the code and a couple of tests | ||
783 | <Linus> Do so. How do you tell it where the pool is? | ||
784 | <Bagder> bmalloc_add_pool() | ||
785 | <Bagder> bmalloc_add_pool(thisisourheap, AMOUNT_OF_MEMORY); | ||
786 | <Bagder> it can in fact handle multiple pools | ||
787 | <Linus> So it can have many pools? | ||
788 | <Linus> OK | ||
789 | <Bagder> not that I think we need that | ||
790 | <Linus> I think not. | ||
791 | <Bagder> committed | ||
792 | <Linus> Great! | ||
793 | <Bagder> basicly 1400 lines of code for the lot | ||
794 | <Linus> ooh | ||
795 | <Bagder> well, check the newlib one as comparison ;-) | ||
796 | <Bagder> Anja just got back home, I gotta go and talk to her | ||
797 | <Bagder> see ya | ||
798 | <-- Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox | ||
799 | <-- edx has quit (zahn.openprojects.net irc.openprojects.net) | ||
800 | <-- Linus has quit (zahn.openprojects.net irc.openprojects.net) | ||
801 | <-- PsycoXul has quit (zahn.openprojects.net irc.openprojects.net) | ||
802 | <-- Tumm has quit (zahn.openprojects.net irc.openprojects.net) | ||
803 | --> edx (edx@pD9EA9D41.dip.t-dialin.net) has joined #rockbox | ||
804 | --> Tumm (coyote@dreamhosted.borlange.se) has joined #rockbox | ||
805 | --> Linus (~linus@labb.contactor.se) has joined #rockbox | ||
806 | --> kjer (~kjer@h168n2fls21o1070.telia.com) has joined #rockbox | ||
807 | <-- wavey has quit (Read error: 104 (Connection reset by peer)) | ||
808 | <-- kjer (~kjer@h168n2fls21o1070.telia.com) has left #rockbox | ||
809 | <edx> cya guys | ||
810 | <-- edx has quit ("good night") | ||
811 | <-- Linus (~linus@labb.contactor.se) has left #rockbox | ||
812 | --> Zubster16 (none@pmchar1-45.rconnect.com) has joined #rockbox | ||
813 | <Zubster16> Hello | ||
814 | <Zubster16> anyone here? | ||
815 | <-- Zubster16 has quit ("« Ë×Çü®§îöñ » Info«v9.1» Released«March 26, 2002» Channel«#Excursion on Da") | ||
816 | --> PsycoXul (psyco@adsl-63-205-40-140.dsl.lsan03.pacbell.net) has joined #rockbox | ||
817 | **** ENDING LOGGING AT Mon May 13 22:21:16 2002 | ||
818 | |||