00:00:08 | amiconn | Now if I knew what penalty branches have on arm7tdmi... |
00:00:14 | | Nick bryan_ is now known as Toxicity999 (n=bryan@cpe-76-179-68-20.maine.res.rr.com) |
00:00:46 | | Join pienose [0] (i=5614aab7@gateway/web/cgi-irc/labb.contactor.se/x-a9d0956a7cba800d) |
00:01:17 | | Quit Mouser_X (Read error: 104 (Connection reset by peer)) |
00:01:29 | | Quit pienose (Client Quit) |
00:01:30 | preglow | Buschel: did you see i found out what was causing moos mpc corruption? |
00:01:51 | Buschel | preglow: he told me yesterday about pre-amp. this correct? |
00:01:54 | preglow | yeap |
00:02:01 | Buschel | :o) |
00:02:06 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
00:03:44 | Buschel | amiconn: damn! it's much faster when always clamping! |
00:03:52 | amiconn | Is it? |
00:04:10 | Buschel | yes, goes up from 8.7 -> 10.4 fps |
00:04:20 | * | amiconn remembers having seen an arm instruction cycle time table somewhere, but can't remember where :/ |
00:04:46 | amiconn | preglow? |
00:05:31 | | Quit grndslm (Remote closed the connection) |
00:08:01 | | Quit kratonator () |
00:08:09 | Buschel | hmm, my fault :/ it's faster on the test-image, but not that much. on real video it's a bit slower |
00:08:41 | | Join grndslm [0] (n=grndslm@24-116-87-97.cpe.cableone.net) |
00:08:46 | | Join japc [0] (n=japc@bl7-241-88.dsl.telepac.pt) |
00:09:04 | preglow | amiconn: i pasted you an url once, can't remember it now |
00:09:21 | amiconn | Aha, probably because the test image clips in the outer parts |
00:10:28 | | Quit desowin ("use linux") |
00:12:27 | amiconn | http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0210c/Chdbedbg.html |
00:12:27 | preglow | amiconn: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0210c/Chdbedbg.html |
00:12:30 | * | amiconn hugs grep |
00:12:30 | preglow | :) |
00:12:36 | amiconn | lol |
00:15:07 | amiconn | Ah, branch is 3 cycles when taken, so that general clamp check needs 6 cycles in the standard case |
00:18:17 | makuseru | how can i get all my songs organized by artist on my gigabeat, when i put it on there its all just in one folder and thats alot of scrolling to get to the botom, is there no way to organize by artist, than click on the artist and get to the abums and click on that to go to songs, etc etc, is there any way to do that |
00:18:36 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
00:18:47 | bluebrother | use some pc software to reorganize the files on the player or simply use the database |
00:18:56 | makuseru | how can i do that? |
00:18:58 | Buschel | amiconn: but we save a register for holding the port address |
00:19:05 | Mouser_X | makuseru: Read the manual? |
00:19:07 | * | bluebrother points to the manual |
00:19:19 | makuseru | umm, what manual? |
00:19:33 | Mouser_X | The manual linked on Rockbox's site? |
00:19:40 | | Join safetydan [0] (i=dc9d468b@rockbox/developer/safetydan) |
00:19:46 | amiconn | Buschel: where? |
00:19:48 | bluebrother | the manual that is linked on the website. You can also open it using Rockbox Utility following this strange "Manual" tab |
00:20:11 | Mouser_X | Hmmm. I should try out this new-fangled RButility... |
00:20:14 | Mouser_X | :P |
00:20:32 | Mouser_X | (No such thing existed when I got Rockbox.) |
00:21:10 | Isolinear | Same here.. :) |
00:21:32 | bluebrother | same for me ... but you should really try it ;-) |
00:21:54 | bluebrother | (and testers are always helpful −− I have the impression that quite some users don't report glitches) |
00:22:09 | | Quit davina (Remote closed the connection) |
00:22:24 | Isolinear | I got Rockbox before ipodpatcher just wanted you to pick one of three letters for input... |
00:23:07 | bluebrother | I got Rockbox even before it ran on Ipods ... wow, it's quite a while since. |
00:23:18 | Mouser_X | Wow indeed. |
00:23:19 | | Quit lee-qid ("aufwiederbyebientotsayonara") |
00:23:50 | Isolinear | Yeah, my first mp3 player was an Archos studio, but I was always afraid to Rockbox it. |
00:23:50 | amiconn | Buschel: Hmm, both stride and count can reside on the stack within the loop |
00:23:52 | amiconn | s |
00:24:00 | amiconn | So you can actually free 2 registers |
00:25:52 | amiconn | That'd be easier in an external .S file as a helper function... |
00:26:15 | Buschel | amiconn: can you port it to a .S-file? |
00:26:44 | amiconn | Shouldn't be difficult |
00:27:15 | | Quit Toxicity999 (Read error: 104 (Connection reset by peer)) |
00:27:57 | | Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) |
00:28:09 | * | amiconn actually downloads the patch |
00:28:23 | amiconn | Until now I was just reading the plain diff |
00:30:50 | | Join mirak [0] (n=mirak@m94.net81-66-75.noos.fr) |
00:31:54 | Buschel | amiconn: gotta leave now, need to go to work in 7h :/ if you can convert the change to a .S-file just post it to fs. thanks for your help and suggestions! |
00:32:27 | amiconn | Maybe I'll commit it right away with the suggested changes |
00:32:29 | | Quit HellDragon (Client Quit) |
00:32:35 | amiconn | I have a G5.5 for testing |
00:32:44 | mirak | hey |
00:32:46 | mirak | amiconn: hi |
00:32:52 | | Join HellDragon [0] (n=Nocebo@unaffiliated/helldragon) |
00:33:00 | amiconn | Buschel: Of course I'll put you into the (C) line |
00:33:04 | mirak | amiconn: I am amazed by mpegplayer, I didn't tried since a long time |
00:33:14 | | Nick Arathis|busy is now known as Arathis (n=doerk@p508A5AF5.dip.t-dialin.net) |
00:33:26 | mirak | I am surprised of the number of fps reached even with the sound. |
00:33:28 | amiconn | mirak: Yeah, it got some asm love since... |
00:33:31 | Buschel | amiconn: then please also test to switch off the 14ms delay (the whole "if finishup_needed"-sequence) and give it a try. works fine during video playback |
00:33:47 | mirak | amiconn: I guess not only idct was put in asm |
00:34:01 | amiconn | No, also some variants of the motion compensation |
00:34:06 | mirak | amiconn: idct.c I mean. are quantization parts optimised ? |
00:34:08 | mirak | ok |
00:34:11 | amiconn | (the same which are asm'ized for arm too) |
00:34:11 | Buschel | bye |
00:34:14 | | Quit Buschel () |
00:35:16 | mirak | amiconn: hum do you think that with wav sound instead of mp3 it could play 25fps without a problem ? |
00:35:37 | preglow | audio is decoded by the second core |
00:35:38 | mirak | I would be interested by this possibility |
00:35:52 | mirak | preglow: a second coldfire core ? :-D |
00:35:52 | amiconn | I will try to squeeze the y interpolation motion compensation stuff into asm too |
00:35:53 | mirak | lol |
00:35:57 | preglow | mirak: right |
00:36:11 | mirak | preglow: ?? |
00:36:19 | preglow | then you will get better fps, yes |
00:36:20 | | Part S1gn |
00:36:38 | amiconn | Might be tricky, as I will hit the d register limit - and a registers can't do all the neat things... |
00:37:27 | mirak | amiconn: mike something suggested that in idct it could be possible to optimise the byte overflow thing |
00:37:36 | amiconn | I also think that there might be some buffers hiding which should be moved into iram |
00:38:31 | mirak | amiconn: I looked at asm code for idct but don't remember exactly everything. did you used the double buffer for the 8x8 64 byte pixel block ? |
00:38:48 | amiconn | yes |
00:38:58 | amiconn | Without that, the reload would be a pita |
00:39:31 | mirak | yep. I did some weird thing also, to be able to store the bytes in reverse order |
00:39:32 | amiconn | Just compare your patch with svn :) |
00:40:02 | mirak | yes I should. I am happy you finally worked on it :D |
00:40:09 | amiconn | I found why your try at an .S file didn't work, and I also applied byte packing to the _add variant of the idct |
00:40:51 | mirak | the .S file was not of me, I didn't had enough knowledge to do that. Maybe you should credit the guy that put the inline into the file, I don't know |
00:40:52 | amiconn | There are some clever tricks hiding, involving swap, shifts and temp registers... |
00:41:18 | mirak | amiconn: that you added or that I did ? |
00:41:33 | amiconn | me |
00:41:35 | mirak | I remember I did that though, but wasn't exactly sure if it was the good way to do it |
00:42:52 | amiconn | I also shaved off 2 instructions from the second mac.w block of each loop, utilizing the fact that there are 2 pairs of macs where 2 terms are identical |
00:43:17 | amiconn | (using move.l %accM, %accN to duplicate) |
00:44:50 | mirak | (MikeS) - Tuesday, 18 September 2007, 00:04 GMT |
00:44:50 | mirak | Ok, somehow I've gotten into doing this for ARM. Will probably stick with the butterfly form there but initial results with changing the simpler routines looks promising. |
00:44:50 | mirak | There's much room for improvement in this patch since Coldfire can more efficiently 1) use emac multiplication to clamp outputs than it can use shifting. Better yet, 2) scale the emac routines to saturate themselves with no clamping stage by making all output left-justified. Coldfire core DSP uses 1), SPC codec uses 1) and 2). Another word of advice: avoid msac - it's dog slow - and mac the negative product. |
00:45:15 | amiconn | I know - and that won't work here |
00:45:28 | mirak | ah too bad. |
00:46:03 | mirak | this part is a bit furstrating, because it's like there could be an easy optimisation because it's just a poor byte, but in fact no. |
00:46:10 | amiconn | ..since you need to clamp the final output *after* adding/subtracting the 2 halves of each direction |
00:46:37 | amiconn | ...but we don't have 8 accumulators, there are just 4 |
00:46:44 | mirak | amiconn: have you tried implementing the optimised C version ? |
00:47:30 | mirak | the on with 7 mult and 8 adds or something like that. |
00:47:42 | mirak | and butterflys |
00:48:14 | mirak | It's not very well suited for EMAC but I am wondering |
00:48:38 | | Quit bluebrother ("leaving") |
00:49:47 | * | preglow pleasures himself removing some mallocs and reaping huge performance gains |
00:50:04 | amiconn | Oh, from where? :) |
00:50:08 | | Quit DogBoy ("Leaving") |
00:50:16 | amiconn | mirak: No I didn't |
00:50:24 | mirak | amiconn: I was also wondering if at some places, the algorithms works directly on ram, and if it would not be better to try to copy to Iram the subsets of data used, then work on them, and copy back the buffer to ram |
00:50:30 | | Quit ender` (" Sex is dirty - if you do it right. -- Isaac Asimov") |
00:50:52 | n1s | pixelma: could you test if that midi that gave you a data abort is fixed now with latest svn? |
00:50:54 | mirak | for motion compensation this happens. it works on blocks of 32x32 pixels I think |
00:50:56 | safetydan | preglow, speex? |
00:50:56 | Mouser_X | preglow: That sounds wrong... |
00:51:21 | preglow | safetydan: yep |
00:51:51 | preglow | safetydan: the decoder states are really small, i get both narrowband and wideband states in iram, no trouble at all |
00:51:52 | safetydan | ah at last speex is getting some love |
00:52:02 | preglow | safetydan: yeah, i have some assembler lined up too |
00:52:14 | mirak | amiconn: from what I remember the only place where there was an alternate buffer was for the idct block. But maybe it could be done for some other stages |
00:52:36 | amiconn | mirak: Motion compensation now loads longwords at once instead of bytes |
00:52:47 | pixelma | n1s: will do in a moment |
00:52:53 | preglow | it's a bitch that speex uses 16 bit arrays internally, though, that means dsp has to convert, but again, that's a reason for speex states being so small |
00:53:03 | amiconn | (well, the asm optimized variants, which are plain copying and x averaging copying) |
00:53:05 | n1s | pixelma: thanks |
00:53:44 | | Quit spiorf (Remote closed the connection) |
00:54:06 | amiconn | In fact the asm motion compensation functions load data using movem, so those working on 16x16 blocks might be luckky and even see a line burst occasionally |
00:54:10 | mirak | preglow: would it be hard to allow mpegplayer to use another audio codec ? like wav wavpack or something that really don't use a lot of ressources |
00:54:11 | mirak | ? |
00:54:29 | amiconn | wavpack is more demanding than mpeg audio on coldfire |
00:54:40 | markun | I believe ac3 is not so demanding |
00:54:45 | amiconn | libmad on coldfire is very efficient |
00:54:59 | mirak | markun: gigabeat fares well on the benchs |
00:55:24 | amiconn | I think the only compressing codecs with are faster are flac and shorten |
00:55:52 | mirak | amiconn: do you have an idea what is the repartition of % cpu usage between libmpeg2 and libmad during playback ? |
00:56:04 | amiconn | But as long as we use mpeg streams we're bound to use mpeg audio - and imho using something else doesn't make much sense |
00:56:06 | preglow | mirak: don't know, linuxstb did that |
00:56:16 | preglow | but really, though |
00:56:21 | mirak | preglow: yes right sorry |
00:56:25 | preglow | we should just optimize mpeg audio further in any case |
00:56:32 | preglow | it's already pretty fast |
00:57:07 | | Quit Arathis ("Bye, bye") |
00:57:12 | Nico_P | preglow: I was toying with the spectrum analyser plugin idea yesterday and had a look at a bit of code... does pcm_play_dma_get_peak_buffer provide the required data ? |
00:57:24 | preglow | Nico_P: no idea |
00:57:26 | mirak | amiconn: well wav allows the 25fps on iriver. But that would huge files ... |
00:57:44 | Nico_P | preglow: do you know how much data is required ? |
00:57:57 | amiconn | I'd rather like to see multiple sample rate support in mpegplayer |
00:58:14 | amiconn | Then we could use 22kHz audio for less audio decoding demand |
00:58:52 | mirak | good sound is what makes you enter in the video since image is small |
00:59:03 | | Nick _pill is now known as pill (i=pill@sloth.shellfx.net) |
00:59:08 | preglow | Nico_P: depends how you're going to get the spectrum data, if you're using filters: everything from 1 sample and up.if you're using ffts, it depends on fft block length, usually around 512 or 1024 |
00:59:25 | mirak | good night all |
00:59:35 | Nico_P | bytes? how much is asample? |
01:00 |
01:00:03 | preglow | i love the fact that speex does dynamic allocation of data on the stack as much as it can |
01:01:12 | preglow | from the map file, it looks like current speex only consumes 15kb of iram :P |
01:01:19 | preglow | nice little codec, this |
01:02:54 | safetydan | preglow, maybe size was more of a problem than speed? |
01:02:57 | | Quit kugel (SendQ exceeded) |
01:03:44 | | Quit jhMikeS (Nick collision from services.) |
01:03:47 | Nico_P | preglow: what's fastest/easiest between FFT and filters? and the questions above too |
01:03:50 | | Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) |
01:04:08 | preglow | Nico_P: fft is fastest if you want plenty of bands, and if you code a good fft |
01:04:22 | preglow | fft is probably going to be fastest anyway |
01:04:24 | | Join barrywardell [0] (n=barrywar@host-194-46-226-143.dsl-ie.utvinternet.net) |
01:04:33 | preglow | almost all spectrum analyzers use ffts |
01:04:50 | n1s | preglow: you could play with turning up the gcc optimization for speex too, currently it's built with -O |
01:05:06 | Nico_P | ok. then does the block size of 512 or 1024 mean several samples are needed ? |
01:05:07 | preglow | n1s: will do |
01:05:34 | * | n1s goes ZzZzZ |
01:05:38 | | Quit n1s () |
01:06:39 | preglow | realtime ratio is 377% for a wideband (16khz) 19kbps file |
01:07:05 | pixelma | just when I wanted to give n1s the test report... |
01:07:29 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
01:07:51 | preglow | holy shit |
01:07:57 | preglow | 427.79% realtime with -O2 |
01:08:12 | preglow | this is h120 |
01:09:11 | Nico_P | hmm apparently good FFT implementations are easy to find, even ASM ones |
01:09:20 | safetydan | preglow, bloody hell that's fast |
01:10:01 | preglow | Nico_P: they're very common, yes |
01:10:03 | rasher | preglow: how much is that compared to mpeg? |
01:10:06 | preglow | safetydan: that's not even using any asm |
01:10:39 | preglow | rasher: can't remember what mpeg is at about now, plus i don't have any 16khz mpeg files |
01:10:45 | rasher | Ah right |
01:11:17 | rasher | Just wondering if speex for voice files might be interesting? |
01:11:38 | preglow | it probably will be |
01:11:46 | preglow | checking what realtime ratio is at for pp now |
01:11:50 | preglow | probably less than coldfire |
01:12:13 | | Join saratoga [0] (i=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-5d0d09b37f2bb08b) |
01:12:23 | preglow | this is also just one channel, so it's not as impressive as it might sound |
01:12:25 | rasher | Ah, looks like mpeg is around the same speed for most bitrates on CodecPerformanceComparison |
01:12:58 | safetydan | rasher, speex should sound better for smaller files than MP3 though |
01:13:03 | | Join DogBoy [0] (n=john@66-101-59-100-static.dsl.oplink.net) |
01:13:04 | preglow | pp gets 284%, yes |
01:13:34 | rasher | safetydan: yeah, should be the right choice, if the decoding speed gets useful |
01:14:31 | *** | Saving seen data "./dancer.seen" |
01:15:15 | safetydan | preglow, I'll be interested to see what changes you made. I had a go at iramifying things a while back but had no idea what I was doing so it didn't amount to much. |
01:16:05 | preglow | safetydan: commit coming up in five minutes |
01:16:20 | | Quit roolku () |
01:16:21 | preglow | doing some more testing |
01:16:47 | | Join HSorgYves [0] (i=HSorgYve@unaffiliated/pi/x-000000001) |
01:16:55 | | Part HSorgYves |
01:17:28 | preglow | geh, arm is slower with O2 |
01:17:47 | | Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) |
01:19:00 | preglow | i'll just hack that into the makefile, then |
01:19:43 | feindbild | hi =) |
01:21:40 | feindbild | I have some hints for encoding video with mencoder. Where should I put them so others don't have to spend weeks figuring it out? the wiki? |
01:22:04 | | Join kugel|afk [0] (i=kugel@unaffiliated/kugel) |
01:22:10 | | Nick kugel|afk is now known as kugel (i=kugel@unaffiliated/kugel) |
01:22:26 | | Quit jhulst (Remote closed the connection) |
01:24:06 | preglow | safetydan: there |
01:24:13 | pixelma | feindbild: probably in the PluginMpegplayer wiki page as it already contains info about encoding (also with mencoder) |
01:24:54 | preglow | also, please test speex files now, i don't have many test files |
01:25:36 | | Quit mirak (Remote closed the connection) |
01:26:23 | safetydan | preglow, I'll take a look when I have my h120 to hand again. I have a directory of test files to go through |
01:26:52 | preglow | safetydan: excellent |
01:28:31 | preglow | wtf, my nano just idled, and now it has prefetch abort at 0xdeadbeee |
01:28:59 | preglow | amiconn: i told the speex author about the static with no inline problem and it's fixed in latest svn |
01:29:05 | | Quit barrywardell () |
01:29:11 | scorche | did the c0edbabe swat it? |
01:29:36 | feindbild | pixelma: hmmm ... somebody interested in putting it up if I post it to a pastebin? ^^ |
01:30:18 | scorche | feindbild: well, it is a wiki.. |
01:30:42 | safetydan | preglow, you didn't have a chance to look at stereo decoding did you? |
01:31:10 | preglow | safetydan: i have, and it looks like it'll be simple to at least have the inner loop fixed point-ized |
01:31:18 | preglow | it's just a simple iir filter weighting each channel |
01:31:26 | preglow | but it also contains some libm calls |
01:31:37 | feindbild | scorche: well ... one that only allows using your realname as wikiname |
01:31:38 | * | feindbild ducks |
01:32:07 | scorche | feindbild: yes?...why would that be a hindrance? |
01:32:26 | preglow | safetydan: hmm, only two sqrts, though, should be simple |
01:32:59 | feindbild | scorche: sorry, I'm kind of paranoid =P never mind ... |
01:33:54 | scorche | feindbild: well, it is just a name...attributed to technical works (or other sorts)...it isnt like you are giving your address, phone number, etc |
01:35:09 | feindbild | scorche: hrhr ... except my name is uniqe and thus I'm giving that information away^^ like I said ... never mind. |
01:36:10 | krazykit | feindbild, better not introduce yourself to anyone then ;-) |
01:36:20 | scorche | and what would a malicious person do with that name?..."Xxxx Xxxx put something on rockbox's wiki!...this is a horrible act!" |
01:37:37 | | Join jeremyb [0] (n=jeremy@unaffiliated/jeremyb) |
01:38:08 | kugel | feindbild: I dount your name is as unique as you think |
01:38:46 | Mouser_X | I searched for my name on Google. Apparently, I'm a script writer. |
01:40:05 | kugel | When I search for my name on google it shous only tracker entries^^ |
01:40:11 | kugel | shows* |
01:40:31 | * | kugel stops being off topic |
01:41:55 | safetydan | preglow, darn, doesn't look like much of those changes can be contributed back to speex |
01:43:46 | makuseru | can someone please tell me how to organize the music on a player with rockbox, i cant find anywhere where it says how |
01:44:08 | | Quit Thundercloud (Read error: 104 (Connection reset by peer)) |
01:44:12 | Mouser_X | makuseru: Use the database. |
01:44:41 | feindbild | n8 =) |
01:44:43 | | Part feindbild ("http://www.last.fm/user/_poison/") |
01:45:00 | | Part pixelma |
01:45:20 | makuseru | Mouser_X: when i click on Database it says "Database is not ready Initalize now SELECT = Yes Any Other = No" and i cant figure out which button is select, ive pressed any buitton and nothing happened |
01:46:25 | Mouser_X | makuseru: If you don't know which button is select, then you didn't read the manual... |
01:47:01 | preglow | safetydan: i wouldn't expect them to be |
01:47:11 | makuseru | i just looked all around the site that had to do with my player, i didnt want to go through 156 pages |
01:47:17 | Mouser_X | http://download.rockbox.org/manual/rockbox-gigabeatf/rockbox-buildch4.html#x7-380004.2 |
01:47:17 | preglow | safetydan: the asm will be, though |
01:47:22 | Mouser_X | ^ Database |
01:47:37 | Mouser_X | ( @ makuseru) |
01:47:59 | makuseru | thank you very much |
01:47:59 | Mouser_X | Also @ makuseru: http://download.rockbox.org/manual/rockbox-gigabeatf/rockbox-buildch3.html#x5-210003 |
01:48:36 | | Quit Sedgewick (Read error: 110 (Connection timed out)) |
01:48:47 | markun | makuseru: and you don't need to read all of the manual of course, just look for the sections you are having questions about |
01:49:24 | * | preglow wonders if profiling still works |
01:58:16 | kkurbjun | what endianness do we expect the arm targets to be running as? |
02:00 |
02:00:41 | * | amiconn wonders whether this asm code will work in the 1st try :> |
02:03:06 | preglow | my experiences with the matter indicates an almost certain "no" :D |
02:05:19 | | Quit japc (Remote closed the connection) |
02:05:51 | | Quit animeloe ("Leaving") |
02:09:45 | | Join animeloe [0] (n=animeloe@unaffiliated/animeloe) |
02:15:29 | | Quit jhMikeS (Nick collision from services.) |
02:15:35 | | Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) |
02:15:43 | amiconn | yay! :D |
02:16:41 | amiconn | 19fps with the widescreen version of elephants dream on ipod video isn't bad, is it? |
02:17:00 | amiconn | Okay, it varies somewhat, now 1.5 |
02:17:04 | amiconn | *17.5 |
02:18:53 | amiconn | Fullscreen runs at ~13fps |
02:20:19 | preglow | not bad at all! |
02:22:53 | saratoga | in 64 bit linux, do i have to import something special to get int32_t types? |
02:24:00 | Soap | 13 fps is only 1 more than the wiki claims. |
02:24:19 | Soap | and IIRC that number (12) was before the recent optimizations. |
02:25:35 | safetydan | saratoga, #include <inttypes.h> or something like that? |
02:28:06 | * | preglow wonders why his h120 sometimes boots into reatilos after using the reset button |
02:28:43 | preglow | not even sometimes, it does so quite reliably |
02:29:14 | amiconn | Soap: The numbers in the wiki are imho a bit too optimistic if they are really from be fore the C optimisation |
02:29:44 | amiconn | Maybe they're taken using just the very beginning of elephants dream, which seems to decode easier than later parts |
02:30:07 | amiconn | 160x128 is now running at 37fps |
02:30:27 | preglow | safetydan: have you ever tried decoding ultra-wideband mode files? |
02:32:14 | Soap | amiconn: they are - I did them |
02:34:08 | Soap | (they are from before the optimization) - someone tweaked the last two - but the methodology I employed was to watch the entire movie through to the end - write down the ending FPS, then watch the movie again and find two places early on in the film with a matching FPS, and use those places as my "benchmark" for all future tests. |
02:34:09 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
02:34:48 | Soap | I ASSumed this would give me decent numbers w/o having to watch the film repeatedly @ sub 20fps. |
02:38:07 | | Quit Nico_P (Remote closed the connection) |
02:41:21 | amiconn | preglow: Hmm, I hope your latest commit doesn't cause problems with voice? |
02:41:41 | safetydan | preglow, I think so and they should work. UWB is for 16 khz and higher isn't it? |
02:41:57 | preglow | safetydan: 32khz |
02:42:01 | preglow | amiconn: why should it? |
02:42:02 | amiconn | Nm, didn't look close enough |
02:42:07 | preglow | can do |
02:43:11 | preglow | safetydan: uwb files hang here, don't know if that's my fault |
02:44:27 | preglow | might also be that they use float and just seem to hang |
02:47:01 | preglow | segfault in sim, hrm |
02:49:51 | safetydan | preglow, I haven't actually tested them since the original commit for speex months ago |
02:50:11 | preglow | me neither, i thought i had a uwb file, but i see now that it is 44.1khz wb |
02:50:16 | preglow | probably why it sounds so bloody awful |
02:52:09 | | Quit tchan (Read error: 104 (Connection reset by peer)) |
02:52:48 | | Quit saratoga ("CGI:IRC") |
02:53:52 | | Join tchan [0] (n=tchan@lunar-linux/developer/tchan) |
02:56:12 | preglow | think i'll check this out tomorrow |
02:56:14 | preglow | bedtime now, nightie |
02:56:57 | | Join barrywardell [0] (n=barrywar@host-194-46-226-143.dsl-ie.utvinternet.net) |
02:57:52 | amiconn | Combining Buschel's and my own observations, I suspect that the broadcom "finishup" is in fact not a necessary finishup function, but rather a frame sync feature, that syncs transfer to the internal frame frequency |
02:58:38 | amiconn | It also seems that the broadcom has some kind of internal anti-glitch measure that delays writes if they come too slow |
02:58:39 | | Quit jhulst (Read error: 110 (Connection timed out)) |
02:59:31 | amiconn | So it might in fact be fastest to render into an intermediate ram buffer first, then transfer than. And lcd_update() can be optimised more than what that duff's device compiles into |
02:59:44 | amiconn | s/than/that/ |
03:00 |
03:00:12 | Soap | amiconn: do you think my FPS measuring methodology is flawed? |
03:00:51 | amiconn | Measuring for a too short time is bad, as well as stopping at a position where fps tend to vary |
03:01:29 | amiconn | Otherwise it should be fine, although measuring the whole video would be more precise |
03:01:54 | amiconn | If my theory is correct, that should open the door for significant fps gains... |
03:02:11 | Soap | your Broadcomm theory? |
03:02:15 | amiconn | yup |
03:02:48 | Soap | If your Broadcom theory is correct, then why has the Video long had framerates similar to the Photo (w/o a Broadcom chip)? |
03:03:08 | amiconn | ? |
03:06:33 | amiconn | Anyway, it's a theory that's worth checking. But not right now |
03:06:47 | Soap | since the processor is (basicly) the same between the Photo and the Video - why (for example) does the photo get 25 fps @ 224x176, and the Video gets 26 (identical within the margin of measuring error) |
03:07:20 | amiconn | YOu can't compare those. It's a totally different hookup. ANd the Photo will get much better frame rates soon |
03:07:22 | Soap | I would assume if the video was getting bottlenecked by the Broadcom, it would have lower FPS numbers than the Photo @ common resolutions. |
03:08:00 | * | amiconn goes to sleep |
03:08:05 | Soap | OK, I can accept that - why I asked. |
03:11:04 | | Quit barrywardell () |
03:13:27 | | Quit Soap (Read error: 104 (Connection reset by peer)) |
03:14:32 | *** | Saving seen data "./dancer.seen" |
03:15:43 | | Join amigan_ [0] (i=dcp1990@ip70-181-22-88.ri.ri.cox.net) |
03:16:45 | | Join AndrewJ [0] (n=KeyLime@70.232.140.147) |
03:16:48 | rasher | kkurbjun: m:robe sim still seems to fail |
03:18:30 | JdGordon | rasher: fail how? compiling? |
03:18:45 | rasher | Yeah |
03:18:54 | JdGordon | compiles fine here.. as long as you only do make bin |
03:18:59 | rasher | Or perhaps just when crosscompiling |
03:19:17 | rasher | Oh, make install fails? |
03:19:19 | JdGordon | haha.. the sim takes up half my deksopt! |
03:20:27 | | Join PaulJam [0] (i=PaulJam_@vpn-3002.gwdg.de) |
03:21:34 | rasher | Nope. Still doesn't build: pluginlib_actions.c:125:6: error: #error pluginlib_actions: Unsupported keypad |
03:22:06 | | Quit kugel ("Benutzer ist abwesend.") |
03:22:38 | JdGordon | ok, yeah.. fixing that now |
03:22:54 | AndrewJ | ? |
03:23:09 | | Part AndrewJ |
03:23:13 | | Quit PaulJam (Client Quit) |
03:24:05 | | Join emeraldd [0] (n=jules@h96.156.30.69.ip.alltel.net) |
03:26:05 | | Join Soap [0] (n=Soap@rockbox/staff/soap) |
03:29:24 | JdGordon | rasher: fixed, the sim comiles now |
03:32:34 | | Quit amigan_ (Connection timed out) |
03:34:46 | rasher | JdGordon: it does indeed. Crikey it's huge. Something's acting up with −−background though |
03:34:59 | JdGordon | yeah, saw that |
03:35:04 | JdGordon | it needs a proper image |
03:35:15 | * | JdGordon wonders what −−zoom would look like! |
03:35:35 | JdGordon | 480x640 is a bit huge :p |
03:36:41 | | Quit amigan (Read error: 110 (Connection timed out)) |
03:37:02 | rasher | Even ter-32b isn't terribly large |
03:44:16 | | Join psycho_maniac [0] (i=psycho_m@ppp-64-91-85-210.cam.centurytel.net) |
03:44:21 | | Quit makuseru (Read error: 104 (Connection reset by peer)) |
03:50:22 | advcomp2019 | i have an issue with r15256 on my sansa e280r.. it takes like two minutes to start playing a song when i hit resume playback from when i turn it on |
03:55:25 | emeraldd | would it be possible for someone to set the svn:ignore property to ignore build directories? |
04:00 |
04:02:36 | advcomp2019 | odd it is not doing it now |
04:02:55 | safetydan | emeraldd, which ones though? I have about 6 different build directories |
04:03:05 | safetydan | it should at least ignore build/ at the moment |
04:03:58 | | Join mrkiko [0] (n=mrkiko@adsl-ull-185-119.42-151.net24.it) |
04:04:52 | emeraldd | If I do an svn status, I get a ? build |
04:04:56 | emeraldd | for a build/ |
04:05:20 | mrkiko | Hi all! Someone knowing something about FS #8003? Has been some progress made? Anyone is free to contact me for testing purposes! |
04:05:21 | emeraldd | although it doesn't show up in svn diff |
04:19:38 | | Quit Gnu47 (Nick collision from services.) |
04:19:45 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
04:19:57 | | Quit donutman25 ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
04:25:55 | | Quit Gnu47 (Nick collision from services.) |
04:26:03 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
04:34:38 | | Join karashata [0] (n=Kimi@pool2-086.adsl.user.start.ca) |
04:36:13 | | Quit Gnu47 (Remote closed the connection) |
04:36:25 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
04:42:06 | | Quit hcs (Read error: 104 (Connection reset by peer)) |
04:42:32 | | Join hcs [0] (n=agashlin@rockbox/contributor/hcs) |
04:48:50 | | Part mrkiko ("rockbox") |
04:51:55 | | Nick EnterUse1Name is now known as EnterUserName (n=dave@ip-128.55.99.216.dsl-cust.ca.inter.net) |
04:55:14 | | Quit Gnu47 (Read error: 110 (Connection timed out)) |
04:58:15 | | Join mrkiko [0] (n=mrkiko@adsl-ull-185-119.42-151.net24.it) |
05:00 |
05:01:27 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
05:09:25 | mrkiko | rasher: regarding the problems on h300 series readers (crash): you're right. It may crash occasionally even not interrupting the voice. Aniway it happened for now only when the voice features are activated. |
05:14:34 | *** | Saving seen data "./dancer.seen" |
05:16:05 | | Quit bb (Nick collision from services.) |
05:16:10 | | Join bb_ [0] (n=bb@unaffiliated/bb) |
05:16:25 | | Join z35 [0] (n=z@149.123.33.65.cfl.res.rr.com) |
05:22:19 | | Quit emeraldd (Remote closed the connection) |
05:22:36 | | Join emeraldd [0] (n=jules@h96.156.30.69.ip.alltel.net) |
05:27:52 | | Join iamben [0] (n=ben@dpc67142179038.direcpc.com) |
05:28:51 | | Quit hannesd (Read error: 110 (Connection timed out)) |
05:29:44 | | Join FM [0] (n=fortemas@ottawa-hs-206-191-39-130.d-ip.magma.ca) |
05:31:45 | FM | I have a stupid question to ask, and I did RFTM: I booted Rockbox. I turned off the player and now it won't seem to go back on. |
05:31:59 | FM | I have a 5G iPod. |
05:32:55 | FM | ...huh. It just went back on. |
05:34:43 | | Quit nerochiaro (Remote closed the connection) |
05:35:43 | | Quit male ("User disconnected") |
05:38:07 | scorche | glad we could help! :) |
05:45:27 | emeraldd | is something up with the build process? http://build.rockbox.org/dev.cgi is claiming that a build should have happened som 779 minutes ago |
05:46:25 | psycho_maniac | where you see that? |
05:46:29 | | Quit hcs ("Leaving.") |
05:47:43 | psycho_maniac | oh ok i see it. |
05:48:30 | safetydan | someone in a european time zone will need to poke it |
05:49:22 | scorche | swedes |
05:50:49 | JdGordon | oh bugger |
05:51:19 | JdGordon | hopefully zagor comes online today then |
05:52:31 | emeraldd | does it blow up like that very often? |
05:52:38 | scorche | it hangs at times |
05:52:44 | JdGordon | not often, but enough to be annoying |
06:00 |
06:01:25 | safetydan | <off_topic>I always laugh when someone says 'swede' since my first thought is the vegetable</off_topic> |
06:02:49 | | Quit criznach ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
06:03:54 | scorche | o_O |
06:04:05 | * | scorche never heard of any swede vegetable |
06:05:20 | * | alienbiker99 never heard of it either |
06:05:38 | JdGordon | jhMikeS: you round? |
06:05:59 | safetydan | From wikipedia: # Rutabaga, a root vegetable, commonly called "swede". |
06:06:11 | scorche | ah...didnt know that |
06:06:12 | safetydan | may be an commonwealth thing |
06:06:34 | * | JdGordon never heard of the vegie swede |
06:06:39 | JdGordon | but im not a vegie man anyway |
06:07:14 | | Quit atsea-22 (Read error: 104 (Connection reset by peer)) |
06:09:23 | jhMikeS | JdGordon: yeah |
06:09:35 | JdGordon | do you tinhk http://pastebin.com/m7a5629e4 is ok? |
06:09:50 | JdGordon | for getting button data out fo the drivers |
06:10:21 | | Quit Mouser_X (Read error: 110 (Connection timed out)) |
06:10:22 | JdGordon | its adds a data variable which im hoping gcc will replace with 0 in all but the mrobe targets |
06:10:58 | jhMikeS | JdGordon: I notices a strange behavior that shows up in the 10/20 build. On my e200, if I start a database update and try to browse files, it will often hang until the database refresh is complete. Don't know if the list changes could do something. |
06:11:41 | jhMikeS | Auto-Update = off (BTW) |
06:12:15 | JdGordon | hmm... seems to happen here also :( |
06:12:20 | Calcipher | jhMikeS you have a e200 series aswell? |
06:12:46 | Calcipher | seems like a few folks here do |
06:13:05 | JdGordon | jhMikeS: i dont know why that list changes would affect it.. maybe Slasheri has an idea |
06:13:18 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
06:13:38 | jhMikeS | Calcipher: yep |
06:13:59 | Calcipher | cool what model did you get? |
06:14:12 | jhMikeS | JdGordon: That looks good at first glance. |
06:14:17 | jhMikeS | Calcipher: e260 |
06:14:47 | Calcipher | I was wondering, if tehre was any difference in the hardware between the e200 and the e200r models, or was it just software? |
06:14:50 | | Quit z35 (Read error: 104 (Connection reset by peer)) |
06:15:03 | | Quit RoC_MasterMind ("Leaving") |
06:15:04 | scorche | software |
06:15:29 | Calcipher | ah good, guess thats why the patch to use the e200 bootloader works so well |
06:15:34 | scorche | there is the matter of the fm tuner, but some e200s have them, some dont |
06:15:53 | jhMikeS | JdGordon: why bother making button data target specific? |
06:16:36 | Calcipher | ah ok |
06:17:14 | | Quit emeraldd ("using sirc version 2.211+KSIRC/1.3.12") |
06:17:44 | jhMikeS | JdGordon: I thought you were posting button data directly for m:robe like a wheel driver does |
06:17:58 | | Join z35 [0] (n=z@149.123.33.65.cfl.res.rr.com) |
06:18:59 | JdGordon | i was, but that sucked because i didnt want to redo the release/repeat handling manually |
06:19:23 | JdGordon | and its target specific because all but 3 targets actually have some data to pass |
06:20:34 | | Quit ToHellWithGA ("You know you'll miss me a lot.") |
06:20:35 | jhMikeS | yeah, you're right, it makes sense to do |
06:21:11 | | Join Leif_Erikson [0] (n=chatzill@75.139.212.31) |
06:22:00 | JdGordon | no bin difference on the ondio build, so ill put it in |
06:23:05 | jhMikeS | no increase using data anyway? |
06:23:17 | | Quit lazka (Remote closed the connection) |
06:23:18 | JdGordon | -4 bytes even |
06:23:24 | jhMikeS | heh |
06:23:37 | JdGordon | bbl |
06:25:51 | | Quit mrkiko (Remote closed the connection) |
06:26:58 | | Quit FM ("The light to the darkness; the darkness to the light.") |
06:38:07 | | Quit Mouser_X (Nick collision from services.) |
06:38:27 | | Join SkinInd95 [0] (n=chatzill@host-69-144-93-208.hln-mt.client.bresnan.net) |
06:39:05 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
06:44:54 | | Quit luckz (Remote closed the connection) |
06:44:55 | | Join makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) |
06:46:39 | | Quit SkinInd95 ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
06:46:53 | makuseru | how can i create my own wps? |
06:49:18 | karashata | http://www.rockbox.org/twiki/bin/view/Main/CustomWPS <−− read that |
06:50:13 | makuseru | thank you |
06:50:20 | karashata | you're welcome |
06:56:51 | Leif_Erikson | I'm trying to get Rockboy to work on my 5g ipod, I selected the .gbc file from the file viewer and nothing happened. Is there something I missed on the website? |
06:56:55 | BHSPitMonkey | daurnimator, yo |
06:59:01 | | Join luckz [0] (n=luckz@luckz.de) |
06:59:04 | daurnimator | BHSPitMonkey? |
06:59:24 | BHSPitMonkey | daurnimator, you still roam toc2rta? |
06:59:40 | daurnimator | uh, I went in there 2 days ago for about an hour |
07:00 |
07:00:26 | BHSPitMonkey | just trying to figure out why I can't connect |
07:01:00 | daurnimator | i just connected |
07:01:10 | daurnimator | note: no more psp channels there - just iphone |
07:01:33 | Mouser_X | Dang. |
07:01:35 | BHSPitMonkey | yeah, I know- I've been in iTouch for a couple days at home |
07:01:42 | BHSPitMonkey | wow |
07:01:46 | | Join qwm [0] (n=qwm@h38n2fls32o1010.telia.com) |
07:01:53 | BHSPitMonkey | it worked in irssi, but not in xchat. I wonder what the heck could be causing it. |
07:02:43 | | Quit XavierGr (Nick collision from services.) |
07:02:46 | | Join XavierGr [0] (n=xavier@ppp193-119.adsl.forthnet.gr) |
07:03:04 | qwm | hm, is time stretching possible with rockbox? |
07:03:40 | BHSPitMonkey | qwm, I actually used my iPod to make a boring lecture go by quicker last week |
07:03:54 | scorche | qwm! |
07:04:06 | daurnimator | I spose if you listen to a really boring audio bookj |
07:04:17 | scorche | qwm: not at the moment |
07:04:41 | karashata | if you adjust the pitch, it is |
07:04:51 | scorche | that isnt time-stretching |
07:04:55 | karashata | oh |
07:04:59 | karashata | nvm then |
07:05:00 | qwm | hehe. |
07:05:05 | qwm | i want the pitch intact. |
07:05:18 | scorche | time-stretching is with the pitch the same as normal |
07:05:23 | karashata | yeah, then it's not possible |
07:05:24 | karashata | yet |
07:05:31 | karashata | someday, who knows? |
07:05:32 | scorche | which is what i said ;) |
07:05:39 | karashata | ahh |
07:07:06 | qwm | make it happen, scorche |
07:07:07 | qwm | :p |
07:07:20 | * | scorche snaps his fingers |
07:07:22 | scorche | it is done |
07:07:39 | Mouser_X | yay! |
07:07:46 | | Join atsea-22 [0] (i=atsea-@gateway/tor/x-00a308ddff3fa4b4) |
07:12:05 | | Quit jhulst ("Konversation terminated!") |
07:14:38 | *** | Saving seen data "./dancer.seen" |
07:19:09 | | Part Leif_Erikson |
07:27:31 | | Part safetydan |
07:36:21 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
07:37:10 | | Join criznach [0] (n=chatzill@host-69-145-134-192.grf-mt.client.bresnan.net) |
07:44:20 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
07:45:22 | | Join homielowe [0] (n=chatzill@d207-81-67-190.bchsia.telus.net) |
07:47:27 | | Quit Mouser_X (Read error: 104 (Connection reset by peer)) |
07:48:26 | | Quit qweru ("moo") |
07:55:12 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
07:56:25 | makuseru | if i wanted to just changed a background on a theme could i not just replace the image that the config file points to? |
07:57:08 | karashata | depends, some of what's displayed might be part of the background image |
07:57:51 | karashata | and that would only change the background that's used in the menus anyway, you'd have to replace the background file (whatever it's name is) in the WPS folder to change the WPS background |
07:57:52 | Mouser_X | makuseru: As long as it was the right resolution. Of course, as karashata said, this will only work if it's the backdrop, and not part of the WPS screen. |
07:58:22 | makuseru | im in the backdrop folder |
07:58:39 | makuseru | oooooh |
07:58:46 | makuseru | i was wondering why it wouldnt work |
07:58:58 | makuseru | i had the size mixed um |
07:58:59 | makuseru | up* |
08:00 |
08:07:03 | | Part toffe82 |
08:15:16 | | Quit psycho_maniac (" HydraIRC -> http://www.hydrairc.com <- The alternative IRC client") |
08:15:20 | | Join ddalton [0] (n=Daniel@203-214-76-97.dyn.iinet.net.au) |
08:15:46 | ddalton | JdGordon: what code is executed when the user presses up or down in the file browser? |
08:16:02 | | Quit lids ("leaving") |
08:17:23 | | Join advcomp2019_ [0] (n=advcomp2@66.172.231.192) |
08:17:37 | | Quit advcomp2019 (Nick collision from services.) |
08:17:43 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@66.172.231.192) |
08:18:34 | | Join spiorf [0] (n=spiorf@host98-168-dynamic.6-79-r.retail.telecomitalia.it) |
08:19:56 | | Quit Mouser_X (Read error: 110 (Connection timed out)) |
08:23:27 | | Quit BigBambi (Read error: 113 (No route to host)) |
08:26:34 | | Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) |
08:26:58 | jhMikeS | ddalton: I think he's away for a bit |
08:27:19 | ddalton | jhMikeS: ah ok |
08:32:20 | | Join GodEater_ [0] (n=bryan@rockbox/staff/GodEater) |
08:39:58 | | Join Rob2222 [0] (n=Miranda@p54B1671C.dip.t-dialin.net) |
08:40:34 | | Quit XavierGr (Nick collision from services.) |
08:40:37 | | Join XavierGr [0] (n=xavier@ppp176-207.adsl.forthnet.gr) |
08:44:19 | | Quit spiorf (Read error: 110 (Connection timed out)) |
08:44:30 | | Quit darkless ("Leaving") |
08:44:53 | * | amiconn had an idea how to squeeze quite some cycles out of the libdemac filter math for arm :) |
08:45:31 | amiconn | Unfortunately this won't help to get it playable on PP, as there even -c1000 is too slow, but it will help the gigabeat |
08:45:50 | amiconn | (-c1000 doesn't use that filtering at all) |
08:46:38 | JdGordon | amiconn: do you see any problems with http://pastebin.com/m7a5629e4 ? |
08:47:02 | JdGordon | its that or more IF_xx() inline macros :( |
08:47:22 | ddalton | JdGordon: do you know what is executed when moving through the file browser? |
08:47:26 | ddalton | up and down |
08:48:09 | JdGordon | ddalton: you keep asking the same bloody question... look in the file where the code for the screen is.. then look for the ACTION_STD_ if/switches... |
08:48:36 | | Join ender` [0] (i=krneki@84-255-206-8.static.dsl.t-2.net) |
08:48:39 | | Join miepchen^schlaf [0] (n=hihi@p54BF7726.dip.t-dialin.net) |
08:49:31 | | Quit makuseru (Read error: 104 (Connection reset by peer)) |
08:50:12 | amiconn | JdGordon: What kind of problems? |
08:50:24 | JdGordon | with how the ifdeffing is done |
08:50:47 | ddalton | ok... |
08:50:49 | JdGordon | also, is that extra data varilable going to add to bin size? |
08:51:14 | JdGordon | i checked and dont think so, but the build serer is donw now so i figured id get another pair of eyes while we wait |
08:51:32 | amiconn | No its not |
08:51:38 | amiconn | ...since it's always 0 |
08:51:53 | JdGordon | k great, thats what i was hoping |
08:51:58 | amiconn | You could give the compiler one more hint that it will stay 0 all the time |
08:52:14 | | Quit karashata ("Leaving.") |
08:52:23 | JdGordon | adding const? |
08:52:43 | amiconn | #ifdef HAVE_BUTTON_DATA / int data = 0; / #else / const int data = 0; / #endif |
08:53:04 | JdGordon | not pretty, but could save hassle later if somone tries modifing it accidently |
08:53:16 | amiconn | yes |
08:54:07 | | Nick bb_ is now known as bb (n=bb@unaffiliated/bb) |
08:54:51 | | Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) |
08:56:04 | ddalton | JdGordon: re my tree question. every button is there except down up left and right. |
08:56:16 | ddalton | there is rec, menu, long menu, and context. |
08:56:40 | JdGordon | up/down is handled in do_synclist_button |
08:56:45 | * | ddalton Hasn't had a compile error yet... |
08:56:47 | JdGordon | left is _CANCEL and right is _OK |
08:56:56 | ddalton | oh ok |
08:57:13 | ddalton | is do_synclist_button in tree.c? |
08:58:30 | | Quit Rob222241 (Read error: 110 (Connection timed out)) |
08:58:50 | JdGordon | gui_synclist_do_button() is gui/list.c |
08:59:23 | * | JdGordon thinks the touchpad driver is ready for svn :) |
09:00 |
09:00:58 | | Join merbanan [0] (n=banan@83.233.242.209) |
09:09:05 | | Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) |
09:10:04 | | Quit sup (Read error: 104 (Connection reset by peer)) |
09:11:08 | | Join MattBatt [0] (i=482893ed@gateway/web/cgi-irc/labb.contactor.se/x-8ce691e062d413d4) |
09:11:36 | | Quit Isolinear (Read error: 110 (Connection timed out)) |
09:12:38 | | Join sup [0] (i=1000@80.216.235.247) |
09:13:23 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
09:14:03 | MattBatt | Hi I'm MattBatt I was told by this page http://www.rockbox.org/twiki/bin//view/TWiki/TWikiRegistration to come here and ask for write permissions on the Twiki Thanks |
09:14:39 | *** | Saving seen data "./dancer.seen" |
09:14:56 | | Part MattBatt |
09:15:39 | ddalton | JdGordon: can you tell me what I am not voicing in the patch I just uploaded? FS #8012. it is about the info list. |
09:15:43 | ddalton | I can't work it out... |
09:19:33 | | Join petur [0] (n=petur@rockbox/developer/petur) |
09:19:36 | * | ddalton Is wondering why JdGordon won't talk to him |
09:20:53 | | Quit bertrik ("bye") |
09:28:07 | | Join LinusN [0] (i=linus@rockbox/developer/LinusN) |
09:29:34 | ddalton | LinusN: what do you think Of FS #8007 and FS #8006? |
09:30:18 | LinusN | ddalton: i just came back from a week in china, so i haven't looked at flyspray yet |
09:32:43 | ddalton | LinusN: ah ok |
09:32:45 | | Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) |
09:36:23 | | Join pondlife [0] (n=Steve@rockbox/developer/pondlife) |
09:36:52 | | Join webguest52 [0] (i=dcef09c8@gateway/web/cgi-irc/labb.contactor.se/x-c8e802fa4fea9641) |
09:38:07 | | Quit webguest52 (Client Quit) |
09:40:45 | | Quit TMM (Read error: 110 (Connection timed out)) |
09:41:30 | | Quit ddalton ("leaving") |
09:42:56 | | Quit iamben (Read error: 104 (Connection reset by peer)) |
09:46:08 | | Join ddalton [0] (n=Daniel@203-214-76-97.dyn.iinet.net.au) |
09:47:30 | | Join iamben [0] (n=ben@dpc67142179038.direcpc.com) |
09:47:39 | JdGordon | welcome back LinusN, ho was the trip? |
09:48:01 | LinusN | wonderful! |
09:48:19 | JdGordon | mind kicking the build server please? |
09:48:36 | | Join B4gder [0] (n=daniel@rockbox/developer/bagder) |
09:50:37 | ddalton | can all players play a beep? |
09:51:57 | | Join TotallyInfected [0] (n=ebola@pool-70-110-242-209.phil.east.verizon.net) |
09:52:14 | | Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) |
09:52:38 | ddalton | Can someone give me an url to get a build for h300 of rev 15226? |
09:52:49 | ddalton | im trying to track down a small problem... |
09:54:37 | GodEater_ | ddalton: can't you just build one yourself ? |
09:55:15 | B4gder | 15236 and 15216 are available |
10:00 |
10:01:04 | | Quit criznach ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
10:02:08 | ddalton | GodEater_: I guess I am now but it takes for ever... |
10:02:57 | ddalton | GodEater_: are you having any problem where you lose settings on a shutdown... |
10:02:57 | pondlife | Nico_P: Good progress over the weekend it seems. Are you planning to rebase soon? |
10:03:10 | Nico_P | pondlife: probably, yes |
10:03:37 | Nico_P | pondlife: have you tested the latest versions ? |
10:03:51 | pondlife | OK, I might wait until you've done that before testing further - given that I was having crashes with SVN too on Friday. |
10:03:59 | pondlife | Not since Friday |
10:04:03 | Nico_P | ok |
10:04:06 | pondlife | But should have a good play today |
10:04:22 | * | Nico_P tries rebasing now |
10:04:34 | pondlife | I've not checked IRC logs yet, but did you and jhMikeS discuss threading much more? |
10:04:48 | * | pondlife wants to read and learn |
10:05:00 | Nico_P | not much more I think |
10:05:15 | pondlife | OK |
10:05:25 | | Join miepchen^schlaf [0] (n=hihi@p54BF44F7.dip.t-dialin.net) |
10:05:57 | pondlife | Nico_P: One thing that looks odd to me - do you really need playback.c to have a "buffering" bool ? |
10:06:10 | pondlife | I'd think it should come out in the wash in buffering.c |
10:06:15 | Nico_P | it only reads the one from buffering.c |
10:06:28 | pondlife | Does that have to be public? |
10:06:47 | pondlife | i.e. calllers shouldn't need to know the internal state |
10:06:57 | pondlife | It should "just work" |
10:07:01 | Nico_P | othere threads can find it useful to know the status... I'll try to find something better though |
10:07:16 | Nico_P | I think that atone point I'll have to rethink the audio thread logic |
10:07:26 | Nico_P | rebasing is done btw |
10:07:33 | pondlife | Cheers, will rebuild |
10:07:50 | pondlife | I'd think that the mod in http://repo.or.cz/w/Rockbox.git?a=commit;h=df2f17234ba1fec7518733b5187a52c5e53d90ca should be inside buffering.c |
10:08:14 | pondlife | i.e. so that it just ignores extraneous requests |
10:08:45 | Nico_P | it does ignore them but the audio thread will just keep posting them in a loop, which is a bit of a waste |
10:08:51 | Nico_P | and is annoying in the sim too |
10:09:11 | pondlife | Ah, but not actually causing a crash or corruption? |
10:09:21 | Nico_P | no |
10:09:23 | pondlife | So this is an optimisation, not a fix? |
10:09:35 | Nico_P | basically, yes |
10:10:15 | JdGordon | hey B4gder (welcome back), can you kick the build server please? |
10:10:33 | * | Nico_P has to go to class |
10:10:41 | JdGordon | no you dont |
10:10:46 | JdGordon | class is bad for you... |
10:10:51 | Nico_P | hehe :) |
10:10:53 | * | B4gder kicks |
10:10:59 | pondlife | Hehe, from holidaying in China to kicking a build server... welcome back to real life :) |
10:11:25 | pixelma | it wasn't holidays ;) |
10:11:44 | | Quit Nico_P (Remote closed the connection) |
10:12:31 | | Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) |
10:12:41 | pondlife | Well, I was trying to emphasize something or other... :) |
10:12:59 | * | ddalton Is having great fun debugging rockbox :-) |
10:14:50 | | Join safetydan [0] (n=safetyda@rockbox/developer/safetydan) |
10:15:20 | | Join obo [0] (n=obo@rockbox/developer/obo) |
10:18:42 | * | ddalton Can't be bother debugging any more. He will just let someone else complain... |
10:21:55 | pondlife | Nico_P: Quick class? |
10:22:33 | pondlife | When you get back, your current code isn't rebuffering, it just runs out of data |
10:23:09 | pondlife | If I stop and restart, it buffers one track |
10:25:23 | * | GodEater_ won't bother building that then |
10:27:12 | | Quit merbanan (Remote closed the connection) |
10:29:42 | pondlife | GodEater_: Actually, it only happened once... is now buffering... weird! |
10:29:57 | pondlife | I implore you to reconsider |
10:31:42 | GodEater_ | perhaps I shall then ;) |
10:31:58 | * | GodEater_ just wants to get his FS7738 into the build too. |
10:33:50 | | Join webguest82 [0] (i=50bb6b01@gateway/web/cgi-irc/labb.contactor.se/x-f43f57bac5911da4) |
10:34:35 | | Join Sedgewick [0] (n=10334AEF@host99-233-dynamic.15-87-r.retail.telecomitalia.it) |
10:35:23 | webguest82 | hi, would it possible to reset the running time to zero automatically each time the players charger is plugged in ?, |
10:35:53 | LinusN | webguest82: it is supposed to do that, afaik |
10:36:10 | webguest82 | er nope not on my H140 |
10:39:05 | webguest82 | by the way LinusN, have you seen CC's patches 7898 and 7911, ? I like the way he has simplified the playlist Insert menus |
10:42:11 | LinusN | webguest82: remember that it can only reset it if you plug in the charger while rockbox is running |
10:42:46 | webguest82 | aha, thanks for the info |
10:44:11 | ddalton | LinusN: had a chance to take a look at the tracker? |
10:44:58 | | Part webguest82 |
10:47:17 | | Quit ddalton ("no one wants to talk to me") |
10:54:44 | amiconn | LinusN: It *is* supposed to do that, but it's broken for quite some time now :/ |
10:54:55 | LinusN | oops, bad |
10:55:05 | amiconn | (some time == months) |
10:55:55 | LinusN | how come? |
11:00 |
11:00:19 | | Join igorr [0] (n=igorr@oinn.ifi.uio.no) |
11:02:30 | igorr | Hi, I have just tried rockbox last night on my iRiver-iHP140 and I am really impressed with it. I see that there are some plugins that it does not support, albeit newer players do. One of them is the clock plugin. Does anyone know if there is something in the architecture fundamentally preventing iHP-140 from something like that being supported? |
11:03:08 | GodEater_ | igorr: yes - the H1x0 hardware has no RTC chip |
11:03:32 | igorr | Ah, so basically, no clock due to architectural limits of the player, then? |
11:03:37 | GodEater_ | correct |
11:03:49 | igorr | Thanks for the pointer |
11:03:55 | GodEater_ | although there are some brave souls that have hardware mod'd their players to include this |
11:04:01 | GodEater_ | and the process is documented in our wiki somewhere |
11:04:19 | GodEater_ | in which case the RB build can also be modified to allow use of this component |
11:04:55 | pixelma | http://www.rockbox.org/twiki/bin/view/Main/RTCModH1x0 |
11:05:15 | igorr | ok, I admit −− the player is now a iHP-160, waiting to become a iHP-180 (with a new battery), but I am not sure I have the skills necessary for more invasive procedures :) |
11:05:19 | GodEater_ | pixelma is our personal "search our wiki for you" service. Please tip her on the way out. :) |
11:05:57 | pixelma | :) |
11:06:19 | igorr | pixelma: whoa. Thanks for the tip (where is your tip jar, by the way?), but that modification is way out of my league. |
11:06:22 | GodEater_ | igorr: allegedly it's not that tricky if you have some skills with a soldering iron, though I couldn't comment personally |
11:06:31 | igorr | I do not :( |
11:06:39 | GodEater_ | know anyone who does ? |
11:06:44 | igorr | Sure |
11:07:03 | | Quit TotallyInfected (Remote closed the connection) |
11:07:19 | pixelma | maybe you could try the Rockbox fund ;) |
11:07:40 | igorr | But I think I will stick to replacing the hdd, getting a high-capacity battery and trying to get comfortable with the humongous number of features of the firmware :) |
11:07:43 | | Join TotallyInfected [0] (n=ebola@pool-70-110-242-209.phil.east.verizon.net) |
11:08:41 | igorr | pixelma: bjorn@haxx.se? |
11:09:33 | GodEater_ | igorr: that's Zagor - one of the original RB developers |
11:09:35 | GodEater_ | he manages the fund |
11:09:57 | igorr | Goodie then. Do I need a paypal account, or can I just transfer funds from a credit card? |
11:10:30 | GodEater_ | I think you need a paypal account too - but to be honest I don't remember =/ |
11:11:39 | pixelma | Zagor is joined, he should be able to tell you more if he has the time |
11:12:05 | Zagor | you can donate without an account. just enter the amount and then click "Use your credit card or bank account (where available). Continue" in the lower right of the page |
11:13:04 | Zagor | not very obvious, but then I guess they want you to sign up... |
11:14:42 | *** | Saving seen data "./dancer.seen" |
11:14:49 | igorr | pixelma: ok then, you have been tipped :) |
11:14:54 | pondlife | Zagor: How's USB doing, btw? |
11:15:03 | pixelma | igorr: thanks :) |
11:15:14 | igorr | GodEater_: I was a bit blind there. No paypal account necessary. |
11:15:18 | igorr | And thanks again for the pointers |
11:15:24 | GodEater_ | no problem |
11:16:02 | Zagor | pondlife: slowly. it seems the chip protests everything I want to do with it :) |
11:16:07 | pondlife | :/ |
11:18:13 | pondlife | LinusN: Welcome back! I've been using the H300 wake-up alarm ( SVN bootloader + http://www.rockbox.org/tracker/task/7814 ) and it works well. Aside from the production of a new bootloader, do you know of anything holding up this being committable? |
11:18:35 | pondlife | hint :) |
11:18:46 | LinusN | pondlife: one small thing, peturs problem with his 80gb disk |
11:18:58 | pondlife | Ah, yes |
11:19:09 | LinusN | not a problem if it is only him, but how do we know? |
11:19:21 | pondlife | I guess nobody but petur can diagnose it either |
11:20:09 | pondlife | Maybe make a V7 bootloader available, but leave V6 there in case? It's not as if it prevents use of the OF. |
11:20:37 | LinusN | my thinking as well |
11:21:02 | pondlife | Until we do that, we probably won't get any more info on the issue. |
11:24:13 | LinusN | probably no |
11:24:36 | LinusN | i discussed this with daniel last week, and we came to the same conclusion |
11:28:20 | igorr | btw, another question −− does anyone have any tips for where one could get iHP-140 batteries? |
11:28:34 | | Quit idnar (Nick collision from services.) |
11:28:36 | | Join idnar_ [0] (i=mithrand@unaffiliated/idnar) |
11:32:25 | | Join Frazz [0] (n=Fraser@thelawsons.plus.com) |
11:33:48 | | Quit rvvs89 (Remote closed the connection) |
11:35:07 | petur | LinusN, pondlife: would it help if I attach my 80GB disk to my h320 and/or my old 40GB to my h380 to see if the problem is related to the disk or my player? |
11:35:20 | LinusN | petur: good idea |
11:35:23 | pondlife | Guess so |
11:35:48 | petur | I'll try tonight... real life is flooding my time schedule atm :/ |
11:35:50 | pondlife | Do the bootloaders share the same init sequence still? |
11:36:52 | | Join afterwar [0] (n=IceChat7@bzq-219-183-200.static.bezeqint.net) |
11:37:04 | LinusN | partly |
11:37:28 | pondlife | Nico_P: MoB is looking good, all known crashes seem resolved. |
11:37:41 | LinusN | the h300 has a special sequence, because the hard disk power works a little differently |
11:42:32 | | Join Thundercloud [0] (n=thunderc@resnet02.nat.lancs.ac.uk) |
11:42:40 | | Quit amiconn (Nick collision from services.) |
11:42:46 | | Join amiconn [0] (n=jens@rockbox/developer/amiconn) |
11:44:54 | | Join barrywardell [0] (n=barrywar@host-194-46-226-143.dsl-ie.utvinternet.net) |
11:58:46 | afterwar | how i open my g3 |
11:59:21 | | Quit TotallyInfected () |
12:00 |
12:06:03 | | Join agm3nt [0] (n=opera@bartek.tu.kielce.pl) |
12:07:06 | GodEater_ | what's a g3 ? |
12:07:14 | afterwar | iaudio g3 |
12:07:21 | JdGordon | with a g3 opener.... duh! |
12:07:51 | GodEater_ | no idea - never seen one |
12:08:44 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
12:09:34 | GodEater_ | looks like you need nothing more exciting that a screwdriver though |
12:09:41 | GodEater_ | from the pics I can find of it |
12:10:06 | afterwar | where i get screwdriver in that size |
12:10:18 | GodEater_ | a tool shop ? |
12:10:46 | afterwar | do u have url ? |
12:11:25 | afterwar | I tried some small screwdrivers for it, but none fit |
12:11:47 | GodEater_ | what sort of screw is it ? Does it have a special head? Or is it just a philips ? |
12:11:59 | afterwar | philips |
12:12:51 | GodEater_ | http://www.maplin.co.uk/ <−− where I got all my tiny screw drivers from |
12:13:12 | afterwar | thnka |
12:16:21 | Nico_P | pondlife: nice :) |
12:16:33 | Nico_P | pondlife: the no rebuffering bug is weird though |
12:16:40 | pondlife | Only happened once |
12:16:51 | pondlife | I think it's related to enabling crossfeed during playback |
12:16:56 | pondlife | I had some white noise too |
12:17:00 | pondlife | But rebooting fixed |
12:17:09 | Nico_P | ah I need to do some testing with crossfade |
12:17:15 | GodEater_ | also running here with no problems |
12:17:59 | pondlife | Nico_P: Regarding the progress bar issue, do you retain the previous track's ID3 data until the WPS has moved on? |
12:18:11 | Nico_P | there's still a major bug in the USB handling. if you plug USB in, handles won't get deleted and playback can't resum |
12:18:30 | pondlife | Pop a mention on the wiki.. |
12:19:51 | | Join Jeton [0] (n=chatzill@79.126.188.204) |
12:20:02 | Nico_P | pondlife: I can't be sure of that |
12:20:46 | pondlife | That might explain some oddness I saw then |
12:21:03 | Nico_P | what kind of oddness ? |
12:21:19 | pondlife | WPS displaying rubbish for a second |
12:21:34 | Nico_P | oh ? when ? |
12:21:35 | pondlife | Only on H300, but I'm still researching |
12:21:37 | pondlife | Today |
12:21:54 | pondlife | Literally for a second, at track transition |
12:22:10 | pondlife | (Or just before.) |
12:23:26 | pondlife | I guess a call to audio_current_track() with a race condition? |
12:23:27 | Jeton | Nico_P: will MoB enable jpeg support for Album Art? And what do you mean in the wiki by "Clean implementation of Album art"? |
12:24:06 | GodEater_ | Jeton: MoB has nothing to do with jpeg album art |
12:24:07 | Nico_P | Jeton: jpeg is a different problem. by clean I mean "that doesn't spin the disk on every track change" |
12:25:01 | GodEater_ | so hopefully will improve battery life somewhat ;) |
12:25:03 | Jeton | i see. So ne JPEG support in sight ? But still BMP will be supported in a more "clean" fashion . |
12:25:14 | Jeton | nice. |
12:25:27 | Nico_P | Jeton: yes, that's it. jpeg probably won't happen anytime soon |
12:26:00 | GodEater_ | not until someone writes is anyway :) |
12:26:02 | Nico_P | it'd require having a jpeg decoder in the core, which is bloat |
12:26:22 | Nico_P | GodEater_: even if someone writes it, I doubt it'd get accepted |
12:27:16 | Jeton | will this also enable better resizing for the Album Art? Now resizing makes the .bmp look jagged, not smooth. |
12:27:21 | GodEater_ | true - but unless someone writes it, there's nothing to accept ;) |
12:27:25 | LinusN | i think support for embedded jpeg album art would be really nice |
12:27:28 | Nico_P | pondlife: the problem with the track transition is the use of curtrack_id3 |
12:27:45 | GodEater_ | LinusN: embedded too ? You don't want much do you? :) |
12:27:48 | Nico_P | Jeton: resizing is another problem too |
12:27:55 | pondlife | I reckon there's such demand for JPEG Album Art, it might get into SVN. Maybe as a plugin call to do the decode and resize...? |
12:28:30 | pondlife | Personally, I'd not use it, but I'd like to see the number of "custom" builds reduced ;) |
12:28:31 | Nico_P | pondlife: a plugin would be fine, yeah |
12:28:42 | LinusN | i'd rather have it in the core |
12:28:50 | pondlife | And AA seems to be one of the main drivers behind custom builds |
12:28:58 | Jeton | i think the demand for jpeg is that 'almost' all DAP's use JPEG for album art, and converting stuff from jpeg to .bmp . |
12:28:59 | * | LinusN goes to lunch |
12:29:11 | Nico_P | LinusN: really? I'm not against it but I know a few people who will be |
12:29:14 | Jeton | pondlife: you're right about that. |
12:29:22 | LinusN | Nico_P: yes, really |
12:29:43 | | Join hasmind [0] (n=harry@203.129.58.209) |
12:29:56 | GodEater_ | how will embedded work anyway ? |
12:30:05 | GodEater_ | does each track in an album have to include the artwork ? |
12:30:06 | GodEater_ | or just one ? |
12:30:19 | Nico_P | GodEater_: it's embedded in each track |
12:30:23 | GodEater_ | yuk |
12:30:35 | pondlife | Yuk indeed |
12:30:44 | GodEater_ | what a waste of disc space |
12:30:50 | pondlife | And buffer |
12:30:52 | hasmind | hey, i didn't think i was a noob with C until i saw the "rc->watever" |
12:31:01 | hasmind | wat is that? |
12:31:05 | Nico_P | Jeton: most daps use a database for album art and convert the art to a more practical format |
12:31:05 | hasmind | wats the ->??? |
12:31:27 | Nico_P | hasmind: rc->smthg is like (*rc).smthg |
12:31:32 | GodEater_ | hasmind, dereferencing a pointer |
12:31:35 | hasmind | o right, ty |
12:31:52 | Jeton | Nico_P: yeah, but they use JPEG mostly (?) |
12:31:59 | pondlife | I'd like cover.jpg in the folder if I was to use it. |
12:32:03 | hasmind | is that just normal C syntax? |
12:32:06 | Nico_P | Jeton: they read the jpeg but don't use it internally |
12:32:10 | GodEater_ | hasmind: yes very normal |
12:32:14 | pondlife | hasmind: Absolutely |
12:32:20 | hasmind | lolz kk |
12:32:35 | hasmind | guess i am a total noob |
12:32:40 | Nico_P | Jeton: I'm pretty sure the conversion is done by the computer before transferring the track over to the DAP |
12:32:49 | * | GodEater_ would agree with Nico_P |
12:33:02 | Jeton | pondlife: that would be much better than embedded, or Track Name.jpg etc. |
12:33:25 | * | Jeton agrees with Nico_P too |
12:33:51 | GodEater_ | pondlife: how would that work for database users though ? |
12:34:05 | pondlife | Every file lives in a directory, no? |
12:34:25 | GodEater_ | would be interesting to see one that didn't :) |
12:34:33 | hasmind | god is my name ACTUALLY irc? lame. damn Gaim |
12:34:37 | Nico_P | we could probably cache the resulting bitmaps to avoid having to do the decoding everytime |
12:34:56 | pondlife | Let's get MoB done first... ;) |
12:35:02 | Nico_P | indeed |
12:35:03 | Jeton | you could also use TrackName.mp3 with TrackName.jpg for that matter. |
12:35:19 | | Join Redbreva [0] (n=chatzill@host86-138-16-226.range86-138.btcentralplus.com) |
12:35:21 | GodEater_ | Jeton: that's no longer album art then |
12:35:22 | Nico_P | Jeton: the AA patch already has TrackName.bmp |
12:35:24 | GodEater_ | that's track art |
12:35:32 | Jeton | oh. |
12:35:47 | pondlife | Track art is where we're headed though - album art is a special case of that |
12:35:55 | Jeton | why do they call it Album Art then? :P |
12:36:07 | GodEater_ | pondlife: so you *do* want one pic per track in the buffer then |
12:36:28 | Nico_P | pondlife: I'm thinking I should commit MoB soonish. once I'll have fixed the usb bug I'll add comments and start seriously considering committing it |
12:36:40 | GodEater_ | yay |
12:36:51 | pondlife | yayay |
12:37:07 | markun | Jeton: because it's usually the cover of the CD/Album |
12:37:15 | Nico_P | it mostly depends on you guys though... if you find showstopper bugs I'll refrain from committing ;) |
12:37:27 | * | GodEater_ hasn't found any bugs at all =/ |
12:37:51 | pondlife | Nico_P: As long as you make sure you have a light week afterwards - may be a need for some ninja bugsquishing |
12:37:55 | GodEater_ | pondlife is clearly better at breaking it than me |
12:37:55 | | Quit J3TC- (Read error: 110 (Connection timed out)) |
12:37:58 | * | Jeton is off. Later |
12:38:02 | | Quit Jeton ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
12:38:03 | hasmind | testing... |
12:38:09 | hasmind | yay im hasmind |
12:38:39 | GodEater_ | I assume the usb bug won't show up on ipods Nico_P ? |
12:38:44 | Nico_P | pondlife: hmm I'm going back home next week end for a week... I'll have a bit of time to code but less than ATM |
12:38:51 | GodEater_ | since it effectively reboots ? |
12:38:52 | Nico_P | GodEater_: no |
12:39:46 | Nico_P | pondlife: but I'm thinking it would be nice to commit before the week end so that people can start reviewing and maybe even helping |
12:40:02 | Nico_P | I'm hoping Slasheri will have things to say |
12:40:08 | Nico_P | maybe even lostlogic! |
12:40:26 | Soap | Zagor: This _might_ be a minor security hole in the wiki: |
12:40:47 | Zagor | Soap: private, please |
12:41:09 | pondlife | Nico_P: I won't object |
12:41:39 | markun | Nico_P: will you be arround a lot to help fix any serious bugs? |
12:41:53 | Nico_P | markun: I sure won't disappear |
12:41:58 | markun | good :) |
12:42:24 | markun | it's always nice to commit something big just before going on a long holiday :) |
12:42:26 | pondlife | Nico_P: I think you should sort out the progress bar before commmit |
12:42:48 | pondlife | Any ideas on how? |
12:42:52 | Nico_P | yeah I keep forgetting about that :/ the fix isn't trivial |
12:43:04 | Nico_P | jhMikeS suggested timestamping the PCM buffer |
12:43:28 | pondlife | The info should come from pcmbuf.c, but a simpler fix might be possible |
12:43:30 | amiconn | Does MoB fix the wps bug related to next track info, btw? |
12:43:48 | Nico_P | amiconn: what bug exactly ? |
12:44:18 | amiconn | Well, current track metadata is synced to the track change at the pcm level, even if decoding already went ahead |
12:44:50 | Nico_P | I think that's the same issue we're discussing |
12:45:05 | pondlife | Not quite... |
12:45:18 | amiconn | But next track metadata isn't, so for around 2 seconds up to the end of a track, "next track" info contains info from 2 tracks ahead |
12:45:26 | pondlife | Ah, yes |
12:45:33 | pondlife | Similar issu |
12:45:34 | pondlife | e |
12:46:16 | pondlife | playback.c needs to move the current track along only when it gets the PCM callback to denote track change |
12:46:30 | | Quit JdGordon ("Konversation terminated!") |
12:46:49 | Nico_P | amiconn: the bug is most probably still there |
12:47:25 | pondlife | Nico_P: The solution to both bugs could be the same... |
12:47:50 | Nico_P | pondlife: I agree, and I hadn't thought of the pcm callback... thanks for mentioning it :) |
12:48:04 | | Join JdGordon [0] (n=Miranda@c210-49-113-143.smelb1.vic.optusnet.com.au) |
12:48:10 | pondlife | That's the first time that playback knows the track has changed. |
12:50:47 | Nico_P | pondlife: it happens precisley when the track has changed at PCM level, right ? |
12:51:46 | pondlife | I think so, yes |
12:51:53 | pondlife | Sim logfs? |
12:51:55 | Nico_P | that's what it seems |
12:52:40 | Nico_P | I think I could have a static prevtrack_id3 and make the WPS display that during the track transition |
12:53:08 | Nico_P | and use the callback like in SVN to update it |
12:53:21 | pondlife | Yes |
12:53:50 | pondlife | What about the next track problem? |
12:54:21 | Nico_P | hopefully it will be solved with the same fix |
12:54:24 | pondlife | Why not make the audio_current_track() and audio_next_track() return static copies at this point? |
12:54:38 | amiconn | In theory you wouldn't need special measures. Just don't update track related wps info until you receive track change notification from pcm |
12:54:41 | Nico_P | they do, but not the right ones |
12:55:00 | pondlife | amiconn: That's what I meant. |
12:55:10 | pondlife | Hopefully this could simplify code. |
12:55:15 | Nico_P | amiconn: the problem is that the WPS uses curtrack_id3, which changes too eraly for the WPS |
12:57:05 | pondlife | You need to name the variables carefully - i.e. whether they are decoding or playback related. |
12:59:13 | | Quit JdGordon (Read error: 104 (Connection reset by peer)) |
12:59:31 | Nico_P | the codec and the WPS need to use the same struct mp3entry, otherwise the elapsed info doesn't get updated |
13:00 |
13:00:46 | pondlife | Good point |
13:01:05 | | Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) |
13:01:17 | Nico_P | the codec can't use the one in the main buffer because it can move around |
13:01:54 | Nico_P | that's why I was thinking of moving elapsed out of struct mp3entry, but it's a big change |
13:02:16 | pondlife | Doesn't this apply to the whole structure really anyway - the timing I mean. |
13:02:21 | Nico_P | and it's probably not even the best fix |
13:02:26 | Nico_P | yes |
13:03:00 | Nico_P | I think the best and maybe only solution is to use a prevtrack_id3 struct and to manage it carefully |
13:03:17 | pondlife | Just a placeholder for the transition window? |
13:03:22 | Nico_P | yes |
13:03:36 | pondlife | i.e. a static to replace prev_ti |
13:03:43 | Nico_P | exactly |
13:04:10 | pondlife | OK, back later |
13:08:21 | | Join rvvs89 [0] (n=rvvs89@martello.ucc.gu.uwa.edu.au) |
13:14:38 | pondlife | Nico_P: One thing I've noticed is that it seems codec transitions are much slower with MoB... |
13:14:46 | *** | Saving seen data "./dancer.seen" |
13:14:54 | pondlife | Crossfade from MP3 to WMA is not smooth |
13:14:58 | pondlife | ({or back) |
13:15:31 | hasmind | is there a crossfade setting? |
13:15:41 | pondlife | There are many! |
13:15:44 | hasmind | haha |
13:15:46 | Nico_P | pondlife: OK I'll try to have a look... how is it with the same codec ? |
13:15:46 | hasmind | where? |
13:16:02 | pondlife | Nico_P: Fine, very quick track transitions in general |
13:16:09 | pondlife | Possibly better than SVN |
13:17:00 | Nico_P | even with crossfade on ? |
13:17:31 | pondlife | Yes |
13:17:39 | Nico_P | cool |
13:17:54 | Nico_P | I'll have a look at the codec transitions |
13:18:06 | Nico_P | hmm even in SVN the playlist index is updated too early |
13:18:57 | pondlife | Wooh, White Noise |
13:19:22 | pondlife | OK, set up a slow-ish crossfade, but leave crossfading disabled |
13:19:38 | pondlife | Then enable it during playback (which stops playback, a bug that's already in SVN). |
13:19:49 | pondlife | Press play, and wait a while - white noise! |
13:20:06 | GodEater_ | define slowish |
13:20:07 | Nico_P | :/ |
13:20:13 | pondlife | 5 seconds |
13:20:29 | GodEater_ | at both ends ? |
13:21:01 | pondlife | Ah no. Try params: 0 / 0 / 1 / 1 / Crossfade |
13:21:04 | pondlife | Still does it |
13:21:44 | GodEater_ | 0011 ? |
13:21:49 | | Part hasmind |
13:22:01 | GodEater_ | no fade in delay, no fade in duration ? |
13:22:09 | GodEater_ | and then only 1 second of each to fade out ? |
13:22:11 | pondlife | Correct |
13:22:26 | pondlife | Straight in with the new track, quick fade the old |
13:22:39 | pondlife | Perfectly valid... |
13:22:39 | | Quit B4gder ("It is time to say moo") |
13:22:53 | pondlife | Might only give white noise after a codec transition too. |
13:23:12 | pondlife | I have a test playlist alternating MP3 and WMA |
13:23:22 | GodEater_ | I'm getting no noise at all |
13:23:40 | | Quit barrywardell () |
13:24:05 | safetydan | preglow, the uwb speex file I have locks up when played with the latest svn |
13:24:15 | GodEater_ | and then trying to rebuffer, I've just got "loading" |
13:24:19 | * | safetydan goes digging for a paper clip |
13:24:20 | GodEater_ | and it won't go away |
13:24:27 | pondlife | That's what happened to me earleir |
13:24:35 | pondlife | When I could spell :) |
13:24:55 | GodEater_ | yep - complete hard lockl |
13:25:09 | pondlife | I could press STOP, but had to reboot to get playback |
13:25:13 | preglow | safetydan: and it didn't use to lock up? |
13:25:24 | * | preglow really wouldn't mind seeing jpeg support in the core |
13:25:37 | safetydan | preglow, no these were test files that all played successfully before, but I'll verify that |
13:26:02 | preglow | it would add what, 10kb to the binary? i think it would be worth it on the targets where user would expect it to work |
13:26:04 | | Quit afterwar ("I cna ytpe 300 wrods pre mniuet!!!") |
13:27:24 | Nico_P | pondlife: I've manage dto get something good going |
13:27:53 | preglow | safetydan: i've got a hunch what's wrong |
13:27:56 | GodEater_ | hmm - doing anything with crossfade appears to break playback |
13:28:19 | Nico_P | I haven't done any real testing with crossfade :/ |
13:29:28 | safetydan | preglow, yeah all good with a build before your changes |
13:29:29 | pondlife | I recommend you do! |
13:29:39 | preglow | safetydan: yeah, i've found the bug |
13:30:07 | pondlife | To be honest most of the crossfade problems I'm seeing are a result of changing settings during playback rather than crossfade per se. |
13:30:55 | pondlife | Wooh! Resumed from reboot and now I have wacky times on the WPS. Total track time −−293:-45 (and counting down) |
13:31:13 | pondlife | Current position: 4:57:51 (in a 2 minute track) |
13:31:53 | | Join barrywardell [0] (n=barrywar@host-194-46-226-143.dsl-ie.utvinternet.net) |
13:32:55 | pondlife | Nico_P: After a reboot, the buffering debugging screen shows track_count: -1. Is this correct? |
13:33:06 | pondlife | Handle count = 0, as expected. |
13:33:08 | Nico_P | pondlife: yes |
13:33:13 | pondlife | OK |
13:34:57 | preglow | safetydan: like i thought, uwb mode really uses TWO wb decoder state structs, so my current static allocated one will be used twice |
13:35:00 | preglow | now, how to deal with this |
13:35:48 | amiconn | preglow: The problem with jpeg decoding is that you need a buffer to decode into. And unlike with preconverted BMP album art, you don't know how big an image the track will have embedded |
13:35:57 | safetydan | preglow, cheat and change speex_alloc to work out of a buffer in iram? |
13:36:32 | preglow | safetydan: i guess that would work |
13:36:35 | amiconn | ..and embedded jpegs should *really* not be called album art, imo |
13:36:52 | preglow | amiconn: i agree there, but it is a solution that exists :/ |
13:37:12 | preglow | and i am as usual opposed to people having to alter their files for rockbox to be able to use them |
13:37:13 | * | amiconn thinks of it more as a problem than a solution :( |
13:37:20 | preglow | anyway |
13:37:27 | preglow | all the album art i have seen has been in jpeg |
13:37:30 | preglow | even if it isn't embedded |
13:37:40 | amiconn | And imo jpeg decoding should not be part of the core |
13:38:01 | amiconn | Why wasting binsize if a user never wants to use album art? |
13:38:13 | preglow | amiconn: why is the image size a problem, btw? we'll have mob |
13:38:17 | pixelma | I've seen other formats there as well (png IIRC) in my very few tracks that has them |
13:38:21 | amiconn | It could be a plugin that decodes the jpeg and shows it in a viewport on the wps |
13:38:25 | preglow | pixelma: blerhg :/ |
13:38:49 | Nico_P | amiconn: I just fixed the next track info bug in SVN... the playlist index is still incremented too early though |
13:38:55 | Nico_P | err not SVN, MoB |
13:38:58 | amiconn | preglow: Do you really want to store the *decoded* jpeg in the playback buffer?? |
13:39:23 | Nico_P | amiconn: decoded an resized, why not ? |
13:39:38 | amiconn | Resized? __where__??? |
13:40:02 | amiconn | You can predecode at 1/2, 1/4, or 1/8, but that's it |
13:40:20 | preglow | making a simple resizing function is a piece of cake |
13:40:28 | LinusN | amiconn: in the same way we resize the bmp's today i guess |
13:40:37 | Nico_P | LinusN: we do? |
13:40:48 | LinusN | in the bmp resize patch |
13:40:55 | Nico_P | hahaha |
13:40:56 | amiconn | LinusN: We resize BMPs? Not that I know of |
13:41:36 | preglow | anyway, that's not a problem |
13:41:39 | amiconn | BMP resizing is way easier than resizing jpeg. BMP can be resized on load because it's uncompressed |
13:41:40 | preglow | it won't even each much bin size |
13:41:53 | preglow | eat... |
13:41:57 | amiconn | And btw, the bmp resizing patch is a crappy implementation |
13:42:00 | | Quit safetydan ("Leaving") |
13:42:02 | LinusN | sure it is |
13:42:13 | amiconn | (or at least was the last time I looked at it) |
13:42:37 | amiconn | preglow: You need some buffer to work on... |
13:42:57 | preglow | amiconn: yeah, but not a full size one |
13:43:11 | preglow | amiconn: album art files usually aren't 1600x1200 |
13:43:24 | preglow | you can resize as you decode, even if you don't do it the way we currently do |
13:44:42 | pondlife | For non-embededed art it would be reasonable to put a small limit on the dimensions anyway |
13:44:43 | preglow | the core will always waste bin size on features some people will never use |
13:44:48 | preglow | and quite some people WILL use jpeg album art |
13:44:54 | pixelma | preglow: 3 pngs, 11 jpgs - I extracted them and deleted them all in the mp3 |
13:45:25 | preglow | silly people... |
13:47:21 | * | preglow tries to figure out if he likes the speex_alloc() out of iram idea... |
13:47:45 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
13:49:05 | | Join Arathis [0] (n=doerk@p508A650D.dip.t-dialin.net) |
13:50:24 | Nico_P | pondlife: committed |
13:50:33 | Nico_P | ... and pushed too |
13:54:29 | | Quit Xerion (Read error: 104 (Connection reset by peer)) |
13:55:24 | | Join Xerion [0] (i=xerion@cp198589-d.landg1.lb.home.nl) |
13:56:08 | | Quit barrywardell () |
13:56:08 | * | Nico_P is off to class again |
13:56:28 | | Quit Nico_P (Remote closed the connection) |
14:00 |
14:02:02 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
14:02:35 | * | preglow shaves 40kb off speex.codec |
14:06:42 | preglow | does sectioned functions have to be enabled for the linker to remove unneeded stuff? |
14:06:58 | preglow | wouldn't really work in this case, but... |
14:07:28 | | Join lee-qid [0] (n=liqid@p54966122.dip.t-dialin.net) |
14:14:36 | | Join Rob2222 [0] (n=Miranda@p54B1671C.dip.t-dialin.net) |
14:18:18 | | Join Genre9mp3 [0] (n=yngwiejo@athedsl-84948.home.otenet.gr) |
14:20:14 | * | JdGordon is touchpad king! |
14:22:09 | * | preglow bows to the king of touchpad |
14:23:46 | | Part LinusN |
14:24:54 | | Quit kubiix (Read error: 104 (Connection reset by peer)) |
14:31:05 | | Join spiorf [0] (n=spiorf@host98-168-dynamic.6-79-r.retail.telecomitalia.it) |
14:33:38 | | Quit XavierGr () |
14:34:09 | | Join egolost [0] (i=egolost@soll3-41.cust.blixtvik.net) |
14:34:34 | egolost | what is the smallest mp3 player that support rockbox or another linux firmware? |
14:34:55 | JdGordon | either the sansa c200 or the nano |
14:35:40 | egolost | but sansa is better supported? |
14:35:55 | JdGordon | they are supported the same |
14:36:22 | JdGordon | the sansa has the sd slot which the nano doesnt ... |
14:36:46 | pixelma | the _c200_ it's quite a new port - the only big thing missing is the microSD support |
14:36:59 | pixelma | hopefully to come soonish |
14:37:00 | JdGordon | msd isnt working on the c200 yet? |
14:37:07 | pixelma | nope |
14:37:18 | JdGordon | oh.. /me thought it was :p |
14:37:21 | egolost | is it c2xx or just the c200? |
14:37:42 | egolost | cause i'm thinking about a c250R. |
14:37:45 | | Join PaulJam [0] (i=PaulJam_@vpn-3104.gwdg.de) |
14:37:51 | JdGordon | DONT buy an r |
14:38:02 | pixelma | with c200 we mean the series, there is no c200 |
14:38:36 | pixelma | I didn't even no that there was also an R version... *puzzled* |
14:38:43 | pixelma | *know |
14:39:04 | egolost | So, the radio isn't supported then? :D |
14:39:24 | pixelma | the radio is supported |
14:40:02 | egolost | so why should'nt I buy an R? |
14:40:32 | JdGordon | because if its anything like the e200R its a pita to get rockbox on it |
14:40:41 | JdGordon | and by pita, i mean we dont know how to do it |
14:41:07 | pixelma | because you caused us confusion... with the Sansa e-series there are the so-called "Rhapsody" models which are called e250R for example |
14:41:20 | JdGordon | the e200r was a fair few months behind the regular e200 to get rockbox |
14:41:44 | pixelma | I have a c250 with radio and the box only says "c250" nothing more |
14:42:22 | | Join nicktastic [0] (n=nick@unaffiliated/nicktastic) |
14:42:47 | pixelma | so just a misunderstanding with the name... |
14:42:54 | | Join XavierGr [0] (n=xavier@ppp176-207.adsl.forthnet.gr) |
14:43:54 | egolost | is there sansa c250R with rapsody? |
14:44:00 | * | JdGordon wonders what the heck the c250r is... google only brings hits from .sk and .cz |
14:45:04 | amiconn | [14:34:34] <egolost> what is the smallest mp3 player that support rockbox or another linux firmware? <== fyi: Rockbox is *not* linux based |
14:45:05 | | Join B4gder [0] (n=daniel@rockbox/developer/bagder) |
14:45:33 | B4gder | there are random talks about a Rhapsody c200 model, called "v2" at places |
14:48:05 | | Quit Sedgewick (Read error: 110 (Connection timed out)) |
14:59:16 | pixelma | I found a german webshop that has a "c250R" and a "c250 with radio" (the latter is like 4 eur. cheaper) but I can't figure out what the difference should be. Besides that there info is a bit wrong anyways, they say their display is 128x96... |
14:59:33 | pixelma | s/there/their |
15:00 |
15:01:03 | preglow | what size is the c200 lcd, again? |
15:01:21 | pixelma | haha, the description text says it would have an fm tuner but the table doesn't... |
15:01:28 | pixelma | preglow: 132x80 |
15:01:45 | preglow | that sure isn't much |
15:01:48 | preglow | but it looks cute :) |
15:02:08 | krazykit | oh, my e200 battery bench is done! i should check it and add the info today |
15:02:20 | preglow | i wonder how mpegplayer looks on that thing |
15:02:34 | pixelma | it's not that bad |
15:02:45 | egolost | this is the one I'm considering buying.. if it runs rockbox that is : http://www.webhallen.com/prod.php?id=67646 |
15:02:56 | JdGordon | krazykit: about 15h? |
15:03:11 | krazykit | JdGordon, i don't know. refresh database :-(. i need to build the svn bootloader |
15:05:52 | krazykit | what the crap. 4 hours? that can't be right. i KNOW it gets more than that. |
15:07:01 | krazykit | hm, the battery claims to start at 50% full, which is strange |
15:08:14 | | Join Sedgewick [0] (n=10334AEF@host99-233-dynamic.15-87-r.retail.telecomitalia.it) |
15:08:55 | krazykit | it's strange: the device claimed "low battery: shutting down" when i turned it on, and the 2 minutes of being plugged in, rockbox now reports 49% charge |
15:09:16 | pixelma | egolost: if the mean radio with the "R" then yes this one should run rockbox |
15:09:41 | pondlife | JdGordon: Did you enable touchpad/mouse support for all sims in the end? |
15:11:20 | krazykit | in 3 minutes, the battery has gone from 49 to 38%. i think this battery is shot. |
15:11:36 | JdGordon | pondlife: not yet |
15:12:16 | pondlife | OK, I'm not convinced that you should do! |
15:12:46 | * | JdGordon doesnt see the harm in it.. but probably wont enable it anyway |
15:13:31 | pondlife | In case we end up using #ifdef HAVE_TOUCHPAD in more places to decide which UI to use... the sim should match the target as closely as possible |
15:13:43 | JdGordon | yeah, true |
15:14:49 | *** | Saving seen data "./dancer.seen" |
15:27:42 | | Join webguest78 [0] (i=a8d89499@gateway/web/cgi-irc/labb.contactor.se/x-1f9fb898dfcf12f2) |
15:30:20 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
15:30:25 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
15:30:30 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
15:31:09 | | Part webguest78 |
15:32:02 | | Quit Frazz (Read error: 104 (Connection reset by peer)) |
15:40:30 | | Quit Gnu47 (Remote closed the connection) |
15:40:42 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
15:44:03 | | Join kugel [0] (i=kugel@unaffiliated/kugel) |
15:48:07 | | Join n1s [0] (n=nils@nl104-209-90.student.uu.se) |
15:49:46 | | Join desowin [0] (n=desowin@hdp186.internetdsl.tpnet.pl) |
15:50:52 | | Quit Gnu47 (Remote closed the connection) |
15:51:05 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
15:55:08 | | Join jgarvey [0] (n=jgarvey@cpe-069-134-102-044.nc.res.rr.com) |
15:57:28 | | Part Redbreva |
15:58:31 | * | pixelma wonders why commited r.15267 |
15:58:36 | pixelma | *who |
15:59:32 | n1s | JdGordon: did |
15:59:54 | pixelma | yeah, found it |
15:59:58 | * | n1s pats svn log |
16:00 |
16:00:05 | JdGordon | whats 15267? |
16:00:29 | pixelma | I just wondered how one managed to put that in between my 2 commits... |
16:00:32 | | Quit Mouser_X (Read error: 110 (Connection timed out)) |
16:00:42 | JdGordon | ah |
16:01:15 | | Quit Gnu47 (Remote closed the connection) |
16:01:16 | n1s | pixelma: how did the midi test go last night? |
16:01:27 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
16:02:48 | n1s | sorry for disappearing... |
16:03:13 | pixelma | n1s: didn't get data aborts on the c200 with the one file if that's what you mean :) |
16:03:32 | n1s | was that the file that gave data aborts before? |
16:03:51 | pixelma | the one I sent you still doesn't play right |
16:04:14 | n1s | pixelma: yeah, that is some other issue... |
16:04:32 | | Join J3TC- [0] (n=jetc123@dhcp75-19.njit.edu) |
16:05:20 | pixelma | I tested with the midi that caused data aborts but this is not the one I sent you |
16:05:50 | n1s | so the data aborts are fixed? |
16:05:59 | * | n1s is a bit slow today |
16:06:19 | pixelma | wouldn't have made much sense because it was well on my M5 even before... yes, seems to be fixed now :) |
16:06:24 | | Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) |
16:06:50 | J3TC- | :O |
16:06:54 | J3TC- | I'm at history class |
16:07:02 | pixelma | oops |
16:07:04 | J3TC- | Compiling rockbox |
16:07:06 | J3TC- | :3 |
16:07:20 | n1s | good, there was a bug that caused memory corruption with certain files because I forgot to check the size before writing to memory... |
16:08:44 | | Quit B4gder ("It is time to say moo") |
16:08:53 | pondlife | Nico_P: Any idea how we can detect the user rewinding during the last seconds of a track? |
16:09:09 | Nico_P | not really |
16:09:20 | Nico_P | maybe with the wps_offset |
16:09:37 | Nico_P | the WPS not displaying the right track after the seek is a refreshing problem |
16:10:13 | pondlife | I was thinking you might be able to do something in the same window now you have a test anyway |
16:10:37 | Nico_P | same window ? |
16:11:29 | | Quit qwm (Remote closed the connection) |
16:11:36 | | Quit Gnu47 (Remote closed the connection) |
16:11:40 | | Join qwm [0] (n=qwm@h38n2fls32o1010.telia.com) |
16:11:49 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
16:11:56 | Nico_P | JdGordon: regarding mouse in the sim I still think a command line switch would be nice |
16:12:27 | pondlife | I mean the window between decode and WPS track transitions. |
16:12:46 | pondlife | Currently, a rewind in that window results in the WPS being one track out |
16:12:53 | Nico_P | ah, right. well yeah, now it's quite well defined |
16:12:54 | pondlife | Until you stop and restart playback |
16:13:16 | | Quit GodEater_ (Read error: 110 (Connection timed out)) |
16:13:16 | pondlife | So I'm not sure it's just a refresh issue |
16:13:22 | Nico_P | pondlife: it's just a refresh problem. show another screen then return to the WPS and it's fixed |
16:13:31 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
16:13:33 | Nico_P | unless that changed with my latest commit |
16:14:14 | pondlife | Well if I get in that state, then go to the settings screen and back it remains wrong |
16:14:24 | pondlife | It stays wrong over track transitions too |
16:14:34 | pondlife | Only stopping completely works |
16:14:49 | pondlife | I thought that was how it had always been. |
16:15:02 | Nico_P | ah yes, that's new to my commit and it's probably due to the use of wps_offset |
16:15:17 | Nico_P | IIRC before it was less serious |
16:15:49 | pondlife | Hmm, at least it's consistent now |
16:16:15 | Nico_P | yeah, not sure it's better :s |
16:16:31 | Nico_P | well I know what code isn't executed |
16:17:23 | Nico_P | I'm starting to feel the need to rethink playback.c |
16:17:57 | Nico_P | but I have no idea how I would do it so it's not very productive... |
16:18:07 | pondlife | I'd wait until MoB is in |
16:18:21 | pondlife | Although whilst you have the knowledge that would be nice |
16:18:23 | Nico_P | of course |
16:18:56 | pondlife | Even your latest one does the track transition too early in the playlist viewer |
16:19:11 | Nico_P | yeah what I want to do is commit when there are no major regressions and then maybe refactor more deeply... what I've done up till now is basically a translation |
16:19:15 | pondlife | i.e. it moves down the list at the decode transition |
16:19:36 | Nico_P | yes, that is consistent with the playlit index being updated too early |
16:19:47 | Nico_P | maybe I can improve that though |
16:20:18 | pondlife | We need to make all external transition happen when triggered by the PCM callback |
16:20:25 | | Quit JdGordon (Read error: 110 (Connection timed out)) |
16:20:26 | Nico_P | the problem is that most of the track transition is handled by audio_check_new_track, which is triggered by the codec requesting a new track |
16:20:39 | pondlife | Ah, that's the DECODE transition |
16:20:52 | pondlife | Need to go though that code and split it up? |
16:21:17 | pondlife | decode transition = internal only |
16:21:59 | | Quit Gnu47 (Remote closed the connection) |
16:22:09 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
16:22:09 | Nico_P | I'll try to move the playlist_next() call, even though I don't really know how important it is |
16:22:44 | pondlife | The main problem is that some callbacks occur in an interrupt... |
16:22:57 | Nico_P | which ? |
16:23:03 | pondlife | Not sure |
16:25:18 | | Quit Zagor ("Client exiting") |
16:27:21 | | Part agm3nt |
16:27:32 | Nico_P | pondlife: have you by any chance noticed gapless breaking ? |
16:27:38 | | Join mrkiko [0] (n=mrkiko@adsl-ull-185-119.42-151.net24.it) |
16:27:45 | mrkiko | Hi all! |
16:28:02 | pondlife | Nico_P: Not tested it |
16:28:04 | Nico_P | ok |
16:28:18 | Nico_P | it's probably just the tracks I listened to |
16:28:26 | Nico_P | I'll double check of course |
16:28:28 | mrkiko | Since I should do many homeworks, if someone has something to tell me and would like to be sure I'll read it, he is pleased to open a private window. thank! |
16:29:58 | pondlife | Nico_P: Breaking news, I just had playback stall again - i.e. it failed to rebuffer. |
16:30:17 | Nico_P | :/ |
16:30:25 | pondlife | I'm in the debugging screen - useful = 8059 bytes and not decreasing. |
16:30:26 | Nico_P | what kind of situation was it ? |
16:30:36 | pondlife | Right in the middle of a track |
16:30:49 | Nico_P | and how full is the buffer ? |
16:30:56 | pondlife | alloc = full |
16:31:15 | Nico_P | that's very strange |
16:31:18 | pondlife | real = 345k |
16:31:26 | pondlife | usefl = 8059 bytes |
16:31:44 | pondlife | It's just sitting there, not locked but not buffering |
16:31:57 | Nico_P | yeah so the codec is starving |
16:31:59 | pondlife | Anything you'd like me to try? |
16:32:10 | pondlife | I suspect your !buffering test... |
16:32:15 | mrkiko | ... has rockbox allways been so crashful? |
16:32:18 | Nico_P | maybe skip backwards. you can do it by pressing up in the debug screen |
16:32:20 | | Quit Gnu47 (Remote closed the connection) |
16:32:20 | pondlife | i.e. race condition |
16:32:35 | pondlife | Nico_P: Yes, that rebuffered |
16:32:48 | Nico_P | pondlife: did "buff:" have an y next to it ? |
16:33:03 | pondlife | Sorry, I didn't see |
16:33:08 | Nico_P | pondlife: it shouldn't have rebuffered, just gone back to the prev track which should be in mem |
16:33:36 | Nico_P | ie normally usefl should have increased without the disk starting or anything |
16:34:07 | pondlife | Ah, well I saw an increase in real too, so that indicates buffering, yes? |
16:34:24 | pondlife | Now real is back up to 25MB |
16:34:31 | Nico_P | ah yes if real or alloc change, that means buffering is happening |
16:34:51 | Nico_P | pondlife: I'm thinking maybe the !pcmbuf_is_lowdata() condition is the cause. |
16:35:05 | pondlife | Hmm, PCM was at 0 |
16:35:30 | Nico_P | yeah so refilling wasn't about to happen. strange the pcm buffer was already low when data was first needed though |
16:36:09 | Nico_P | what codec was it ? |
16:36:20 | pondlife | Ah, it won't rebuffer if PCM is starved so as to allow it to refill? That should only be true if there's useful data... |
16:36:23 | pondlife | MP3 |
16:36:24 | kugel | do I need to build the bootloader without checking out the whole source |
16:36:55 | kugel | i checked out /trunk/bootloader, but make doesn't work |
16:37:40 | Nico_P | kugel: I think the bootloader relies on firmware/ |
16:37:55 | | Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) |
16:37:56 | kugel | ah, damn |
16:38:08 | Nico_P | you can just check that out though |
16:38:42 | kugel | that's pain with cygwin |
16:38:44 | kugel | imo |
16:38:48 | Nico_P | pondlife: I now have the playlist index being incremented when pcm changes tracks |
16:39:27 | kugel | does anyone know what "No original firmware found at 0xeed15200" means? |
16:39:39 | kugel | that's the error when I do sansapatcher -of OF.mi4 |
16:39:40 | * | pixelma hopes that everything's back to normal now... :\ |
16:41:23 | pondlife | Nico_P: Would you agree with me that to the outside world, the "WPS track transition" should be the only one? |
16:41:24 | Nico_P | pondlife: I think I'll simply disable seeking in the transition window |
16:41:35 | Nico_P | totally |
16:41:59 | pondlife | Nico_P: You might find that has more side-effects than fixing the problem ... |
16:42:18 | | Quit pill (Nick collision from services.) |
16:42:35 | | Join pill [0] (i=pill@sloth.shellfx.net) |
16:42:43 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
16:42:49 | Nico_P | pondlife: why? to me it makes sense. during the transition window we're already in the new track. seeking in the WPS-current but codec-previous is impossible |
16:43:16 | Nico_P | unless we skip back again and then seek |
16:43:38 | | Quit pill (Nick collision from services.) |
16:43:46 | pondlife | Yes, and with your new algorithm, the chance is the track will be buffered still |
16:43:50 | | Join _pill [0] (i=pill@sloth.shellfx.net) |
16:43:52 | pondlife | So it should work smoothly |
16:44:03 | pondlife | Ah, just stalled again |
16:45:56 | pondlife | pcm = 0/882000 handles=4 tracks=1, data_rem=1907759, alloc=25,164,228/25,191,824, real=2,517,976/.., usefl=8166/... |
16:46:01 | pondlife | buff: |
16:46:04 | pondlife | i.e. no y |
16:46:57 | Nico_P | are you managing to make it happen ? |
16:47:12 | pondlife | I just left it playing |
16:47:35 | pondlife | I skipped one track a while back, but otherwise just let it play |
16:47:38 | Nico_P | I think the !pcmbuf_is_lowdata can and should go |
16:47:50 | pondlife | Not so sure. |
16:48:03 | pondlife | It should have triggered the rebuffer earlier anyway. |
16:48:18 | Nico_P | I agree but I really see no reason why it didn't |
16:48:28 | pondlife | PCM lowdata would only have occurred a second or so beforehand anyway I expect |
16:49:08 | pondlife | Could you perhaps remove the !buffering? I can try it here if you want... |
16:49:18 | Nico_P | yeah why not |
16:49:32 | Nico_P | where in the playlist is the track? not last ? |
16:49:53 | pondlife | Nope |
16:49:56 | pondlife | Nothing special |
16:50:09 | pondlife | Again, we were mid track |
16:50:16 | pondlife | Nowhere near a transition |
16:50:39 | Nico_P | yeah but it's probably simply the first track that isn't completely buffered |
16:50:45 | | Join scorche|w [0] (n=8dc5049d@ircby.iptel.by) |
16:50:53 | pondlife | Indeed, it is |
16:51:28 | pondlife | Hmm, is audio_initialize_buffer_fill() needed still? |
16:51:36 | pondlife | And the filling variable? |
16:51:47 | Nico_P | not quite sure actually |
16:51:52 | pondlife | I would think that complexity should have vanished into buffering |
16:52:40 | pondlife | audio_fill_file_buffer() is still called lots |
16:52:54 | | Quit Gnu47 (Remote closed the connection) |
16:53:08 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
16:53:21 | Nico_P | yeah that's why I was saying I want to refactor the playback code... this one should basically disappeatr |
16:53:58 | pondlife | Absolutely. playback.c should end up with only the playback in (i.e. reading from the buffer) |
16:54:42 | | Join GodEater_ [0] (n=bryan@rockbox/staff/GodEater) |
16:55:14 | Calcipher | pondlife, hows it going |
16:55:24 | Nico_P | I'm really pleased I used git for all this. I would've gone crazy without it |
16:55:39 | pondlife | Calcipher: Not that well :) |
16:56:42 | | Join barrywardell [0] (n=barrywar@dhcp-892b9af6.ucd.ie) |
16:56:52 | Nico_P | oh? what's wrong? |
16:57:11 | pondlife | Busy Real Life mainly |
16:57:49 | pondlife | OK, buffering check removed - testing continues... |
16:58:17 | Nico_P | it doesn't seem to happen on my sim. trying on the gigabeat |
16:58:41 | Nico_P | have you tried using the debug screen to skip to the first partial song and waiting to see if it rebuffers ? |
16:58:47 | pondlife | Will do |
16:59:01 | Nico_P | it's most probably in that case that the problem happends |
17:00 |
17:00:47 | pondlife | OK, it rebuffered ok that time |
17:01:11 | Nico_P | for me too... did it happen with the same track each time ? |
17:01:18 | pondlife | No |
17:01:31 | mrkiko | is steve here? |
17:02:14 | | Part Calcipher |
17:02:47 | pondlife | OK, and worked ok again.. I think that !buffering test should go |
17:02:53 | Nico_P | it's a pity the scrollbar widget can't display a ringbuffer. it's be nice to have in the debug screen |
17:02:56 | JdGordon | oy joy! looks like i got battery measurements working, but broke the touchscreen values :( |
17:03:17 | Nico_P | pondlife: I have the !buffering test and it's not hurting |
17:03:18 | | Quit Gnu47 (Remote closed the connection) |
17:03:26 | pondlife | Nico_P: How does A-B repeat display work? |
17:03:29 | Nico_P | pondlife: I don't see why it would hurt |
17:03:31 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
17:03:40 | pondlife | Race condition.. |
17:03:47 | Nico_P | how? |
17:04:04 | Nico_P | pondlife: it displays some triangles. but I would like to have exactly like a scrollbar except it could wrap |
17:04:04 | pondlife | Not sure, but you shouldn't access the buffering thread variables |
17:04:35 | pondlife | Thread safety is not to be trifled with, I'm afraid. |
17:04:58 | Nico_P | ont thread writes the var, others read it... isn't that safe ? |
17:05:13 | Nico_P | s/ont/one |
17:07:26 | pondlife | May be, but there's always a chance for threads to lock each other out if there are further dependencies. |
17:07:38 | pondlife | Best to keep them totally independent. |
17:07:50 | Nico_P | yeah |
17:08:08 | pondlife | codec_advance_buffer_counters() has a similar test |
17:08:30 | pondlife | Problem is, that is in the codec thread, deciding if it's worth trying buffering. |
17:08:39 | Nico_P | that's where I thought you had removed the !buffering test, where have you? |
17:08:45 | pondlife | We should let the buffering thread have a chance to decide |
17:08:49 | | Quit PaulJam (".") |
17:08:51 | pondlife | The other one, that you put in recently |
17:09:13 | Nico_P | ok |
17:09:14 | pondlife | In audio_thread |
17:09:31 | pondlife | I'd make buffering a static bool |
17:09:35 | pondlife | Hide it away |
17:09:46 | pondlife | (Maybe include it in the debug info.) |
17:10:07 | Nico_P | it's of no use if it's static. I put it there only so that other threads know whether buffering is in progress |
17:10:20 | pondlife | OK, scrap it! |
17:10:21 | Nico_P | yeah it's only be useful for debugging |
17:10:36 | Nico_P | but I need it! :p |
17:10:50 | pondlife | OK, you need it, but playback.c doesn't :p |
17:11:38 | Nico_P | the best would of course be to remove the Q_AUDIO_FILL_BUFFER business and maybe give the buffering thread a callback to signal data is low |
17:12:04 | pondlife | Absolutely |
17:12:04 | Nico_P | hmm I got confused but I mean "do things differently) |
17:12:47 | pondlife | Actually, shouldn't the buffering thread deal with this automatically, assuming playback yields.. |
17:12:51 | Nico_P | I've just pished my commit for the playlist position |
17:13:04 | pondlife | i.e. why need to have any artificial control |
17:13:10 | pondlife | Thanks |
17:13:13 | Nico_P | you mean the buffering thread could deal with the playlist directly ? |
17:13:33 | pondlife | No |
17:13:42 | | Quit Gnu47 (Remote closed the connection) |
17:13:46 | pondlife | I mean it should realise that the buffer is low automatically |
17:13:55 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
17:14:07 | pondlife | Ah, it doesn't know which file to get, does it? |
17:14:21 | Nico_P | the problem is that there are two different definitions of low buffer. low in files or low in buffered data |
17:14:36 | pondlife | Low in files shouldn't be relevant much |
17:14:42 | pondlife | It's low in data that matters |
17:14:46 | Nico_P | I agree |
17:14:54 | *** | Saving seen data "./dancer.seen" |
17:15:05 | Nico_P | but currently the audio thread actively tries to fill the buffer with files. |
17:15:21 | Nico_P | maybe I should change it so that it provides files when requested by the buffering thread |
17:15:31 | pondlife | Yes, that would be better |
17:15:52 | Nico_P | I'll try implementing that |
17:17:57 | Nico_P | pondlife: I'm thinking users of the API could register callbacks, kinda like with register_ata_idle_func |
17:18:14 | Nico_P | and those get called by the buffering thread when the buffer is low |
17:20:35 | pondlife | Are you going to scrap those !buffering tests? |
17:20:43 | * | pondlife fears git non-synced-ness |
17:21:11 | Nico_P | you want me to scrap them now before implementing a proper solution? |
17:21:25 | Nico_P | I wasn't really planning on it |
17:21:26 | pondlife | Well, I'm fairly sure they're not required |
17:21:36 | pondlife | I don't see what good they do |
17:22:02 | pondlife | They may save a bit of calling, but nothing that would fail. |
17:22:36 | pondlife | And I've had 3 successful rebuffers since removing them |
17:22:54 | Nico_P | I'll test without them |
17:23:17 | pondlife | Only the buffering thread should decide if there's buffering to do. |
17:23:52 | Nico_P | in the audio thread it's used to decide if it's useful to start file filling |
17:24:03 | kugel | did anyone read my question i asked about an hour ago? |
17:24:05 | | Quit Gnu47 (Remote closed the connection) |
17:24:06 | kugel | does anyone know what "No original firmware found at 0xeed15200" means? that's the error when I do sansapatcher -of OF.mi4 |
17:24:14 | Nico_P | it's useless to do file filling if the buffering thread is filling |
17:24:15 | pondlife | You have "filling" for that |
17:24:18 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
17:24:19 | | Join japc [0] (n=japc@194.65.73.69) |
17:24:27 | pondlife | i.e filling is for file filling, buffering for buffering. |
17:24:37 | pondlife | Not the same thing, timing wise |
17:24:42 | Nico_P | filling is different |
17:24:59 | Nico_P | I do agree a better solution is needed anyway |
17:26:13 | | Quit J3TC- (Read error: 110 (Connection timed out)) |
17:27:19 | Nico_P | pondlife: done |
17:27:41 | Nico_P | what do you think of the callback idea? |
17:29:31 | kugel | nevermind guys, I solved the problem |
17:31:26 | preglow | hrmf |
17:31:35 | preglow | doesn't look like speex asm will help us much |
17:34:29 | | Quit Gnu47 (Remote closed the connection) |
17:34:39 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
17:36:54 | | Join Rondom [0] (n=Rondom@p57A95747.dip.t-dialin.net) |
17:37:41 | | Nick idnar_ is now known as idnar (i=mithrand@unaffiliated/idnar) |
17:38:38 | | Quit JdGordon ("Konversation terminated!") |
17:44:51 | | Quit Gnu47 (Remote closed the connection) |
17:45:04 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
17:48:49 | | Quit scorche|w ("CGI:IRC (EOF)") |
17:49:08 | | Join Calcipher [0] (n=Calciphe@ool-18bab657.dyn.optonline.net) |
17:51:43 | pondlife | Nico_P: I like the callback idea |
17:52:08 | pondlife | One minor bug (which might be in SVN too)... You shouldn't be checking !filling before putting Q_AUDIO_FILL_BUFFER in the queue |
17:52:15 | egolost | hmm.. seems like my sandisk sansa c250 hangs when i plug in into the USB. |
17:52:20 | pondlife | That test is done on the audio thread anyway |
17:52:21 | egolost | with rockbox. |
17:52:36 | Nico_P | pondlife: hopefully I'll be able to get rid of it |
17:52:55 | pondlife | filling is now an audio-thread only var anyway |
17:53:55 | pondlife | So things are definitely clearing up lots |
17:53:58 | pixelma | egolost: that happens with some builds and you plug in usb with rockbox running. Try switching it off and then connect usb, your sansa should boot into the original firmware |
17:55:02 | | Join J3TC- [0] (n=jetc123@dhcp75-19.njit.edu) |
17:55:14 | | Quit Gnu47 (Remote closed the connection) |
17:55:19 | | Join Davide-NYC [0] (n=chatzill@user-12hdtj8.cable.mindspring.com) |
17:55:26 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
17:55:32 | egolost | pixelma: thank you.. that seems to work fine. |
17:55:37 | preglow | 215% -> 220% for an ultra-wideband 32khz file with iir_mem16 asmified, very disappointing :/ |
17:56:18 | pondlife | Nico_P: I suspect today was the day MoB got better than S |
17:56:20 | pondlife | VN :) |
17:56:25 | Nico_P | :) |
17:56:49 | pondlife | On the pondlife-entirely-subjective scale, of course |
17:57:35 | | Join scorche|w [0] (n=8dc5049d@st.iptel.by) |
17:57:45 | J3TC- | Which file is the iaudio rockbox boot image? |
17:58:22 | Davide-NYC | jhMikeS: could the recent thread_wait commit solve the test_codec crashing bug? should I be upgrading and testing? |
17:58:40 | | Join criznach [0] (n=chatzill@host-69-145-134-192.grf-mt.client.bresnan.net) |
17:58:46 | preglow | test_codec crashes again? |
18:00 |
18:01:00 | | Quit ivan` (Read error: 104 (Connection reset by peer)) |
18:01:49 | | Join ivan` [0] (n=ivan`@unaffiliated/ivan/x-000001) |
18:02:02 | Davide-NYC | it has always crashed. It'll crash after a certain number of files are tested using the speed test folder option. |
18:04:05 | Davide-NYC | FS #7954 |
18:04:25 | preglow | right, never tried that |
18:05:36 | | Quit Gnu47 (Remote closed the connection) |
18:05:49 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
18:15:57 | | Quit Gnu47 (Remote closed the connection) |
18:16:09 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
18:16:12 | | Join MethoS- [0] (n=clemens@pD955C296.dip.t-dialin.net) |
18:20:05 | n1s | hmm, I can't spot any obvious places to use the emac in midiplayer since the loop change... |
18:21:17 | | Quit obo ("bye") |
18:21:44 | preglow | i don't expect emac will play a big role in midiplayer |
18:22:03 | preglow | it's just not the right application for it |
18:22:13 | n1s | preglow: so what do you expect will play a big role for midiplayer? |
18:24:43 | | Quit nicktastic ("Leaving") |
18:25:24 | | Join nicktastic [0] (n=nick@unaffiliated/nicktastic) |
18:26:20 | | Quit Gnu47 (Remote closed the connection) |
18:26:33 | | Join Gnu47 [0] (i=Gnu47@private.ntwk.thita.net) |
18:26:43 | Nico_P | pondlife: seems to be working nicely |
18:26:54 | | Join ilgufo [0] (n=matteo@host109-178-dynamic.5-87-r.retail.telecomitalia.it) |
18:27:47 | | Nick parafin|away is now known as parafin (i=parafin@paraf.in) |
18:27:51 | pondlife | yEP |
18:27:54 | pondlife | Oops |
18:27:56 | pondlife | Yep, even |
18:28:06 | Mode | "#rockbox +o scorche|w " by ChanServ (ChanServ@services.) |
18:28:10 | Mode | "#rockbox +b *!*Gnu47@private.ntwk.thita.net " by scorche|w (n=8dc5049d@rockbox/administrator/scorche) |
18:28:17 | pondlife | Not had a rebuffering failure since. |
18:28:20 | Nico_P | just one thing... to calcuate the useful data amount, I need to know which handle is currently used by the codec |
18:28:23 | scorche|w | just for a little bit ;) |
18:28:38 | preglow | n1s: *shrug*, other optimization methods |
18:28:56 | preglow | n1s: emac is good for filtering and bulk mixing |
18:29:01 | pondlife | Nico_P: What use is the "useful" amount? Just debugging? |
18:29:01 | n1s | heh, |
18:29:12 | preglow | midi does mixing, but that is far from the bottleneck |
18:29:23 | Nico_P | pondlife: sadly no, it's used to know whether the buffer is low |
18:29:42 | Kick | (#rockbox Gnu47 :message me when you arent disconnecting so much) by scorche|w!n=8dc5049d@rockbox/administrator/scorche |
18:29:42 | pondlife | Ah, ok... You can guess where I was going.. :) |
18:29:54 | preglow | so even if you did use emac for mixing in the old midiplayer code, i doubt it would have any performance effect nearing what the loop rewrite did |
18:30:05 | Nico_P | because the handles are kept in memory, we assume the ones before the one being decoded are useless |
18:30:09 | preglow | i suspect it wouldn't even be noticable |
18:30:56 | pondlife | Nico_P: I assume they also need to have been bufclosed, right? |
18:31:11 | pondlife | i.e. bufclosed, but not yet overwritten? |
18:31:14 | Nico_P | pondlife: precisely no, they are buclosed as late as possible |
18:31:19 | pondlife | Ah, ok |
18:31:32 | | Part pondlife ("Gone") |
18:31:38 | Nico_P | the playback code keeps them open as long as possible |
18:31:52 | Nico_P | pondlife: how safe is it to have a static var in the buffering code and give the playback code an accessor to set it? |
18:32:37 | Nico_P | maybe the accessor could be a queue event to make things safe |
18:36:07 | | Quit desowin (Remote closed the connection) |
18:37:40 | | Join BigBambi [0] (n=alex@rockbox/staff/BigBambi) |
18:38:53 | | Join pondlife [0] (n=Steve@rockbox/developer/pondlife) |
18:39:18 | Nico_P | pondlife: the teddybear effect worked, I did it via a queue event and I'm testing now |
18:39:34 | pondlife | Sorry, lost my internet |
18:39:51 | Nico_P | I talked without even noticing you were gone ;) |
18:39:56 | pondlife | lol |
18:40:06 | pondlife | What was the change? |
18:40:40 | pondlife | Guess I'll check gut |
18:40:49 | Nico_P | I added a static var in buffering.c telling which handle is currently decoded |
18:41:11 | Nico_P | the playback thread sets it via an accessor that sends an event to the buffering queue |
18:41:26 | pondlife | Ah yes, that should definitely be internal to buffering |
18:41:56 | Nico_P | sure but only the user knows, so a bit of a twist is required |
18:42:25 | | Quit BHSPitMonkey (Remote closed the connection) |
18:43:05 | * | preglow hates playing register allocator |
18:43:35 | | Join A_M [0] (n=anon3141@fw.dormnet.his.se) |
18:43:48 | preglow | amiconn: i hate it when i can't find anything to fill in the emac stall time with :/ |
18:43:53 | | Join lazka [0] (n=lazka@85.127.153.108) |
18:44:51 | | Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) |
18:50:46 | mrkiko | ey guys: the iRiver crash seems not to happen with voice menus disabled |
18:50:50 | | Quit mrkiko ("leaving") |
18:53:17 | | Join spiorf_ [0] (n=spiorf@host6-210-dynamic.14-87-r.retail.telecomitalia.it) |
18:54:11 | Nico_P | pondlife: I'll commit and push very soon. it seems to work fine |
18:55:08 | pondlife | OK, will carry on testing |
18:56:08 | Nico_P | done |
18:56:20 | Nico_P | I think "filling" is useless now |
18:58:09 | * | amiconn found a way to further speed up the ape filters |
18:58:51 | amiconn | Found that while trying a similar method as the one I impelented for coldfire on arm: that method gave a data abort 'cause the filter pointers aren't aligned |
18:59:21 | amiconn | That means they aren't aligned on coldfire as well, which doesn't crash but performance suffers |
18:59:28 | preglow | amiconn: have you used mac.w or msac.w? it seems either gas or objdump has a bug |
18:59:39 | amiconn | where? |
18:59:42 | | Part ataxic |
19:00 |
19:00:05 | preglow | amiconn: msac.w with load seems to be bugged in either objdump or gas |
19:00:25 | * | preglow finds cfprm.pdf |
19:00:28 | amiconn | I doubt that. Do you have an example? |
19:00:46 | amiconn | I mean your source vs. what objdump outputs |
19:01:45 | preglow | "msac.w %%a0l, %%d1l, (%[den])+, %%a0, %%acc1;" -> msacw %a6l,%a1l,%fp@+,%a1,%acc |
19:02:05 | preglow | check the first two regs there |
19:02:37 | preglow | i'm decoding by hand now to see if objdump messes up |
19:02:40 | | Quit spiorf_ (Remote closed the connection) |
19:02:40 | | Quit spiorf (Read error: 101 (Network is unreachable)) |
19:03:22 | amiconn | The only coldfire related bug I'm aware of in objdump is that it doesn't know move.w #IMM, %sr |
19:03:46 | | Join webguest02 [0] (i=410848ee@gateway/web/cgi-irc/labb.contactor.se/x-854af2a533b1ae28) |
19:04:36 | | Join spiorf [0] (n=spiorf@host6-210-dynamic.14-87-r.retail.telecomitalia.it) |
19:04:50 | preglow | objdump bug |
19:05:00 | amiconn | But what easily happens is that if you forget one % sign when using asm-in-C, gcc+gas mangle it into something different without warning |
19:05:12 | amiconn | Had that with the ape filters... |
19:06:36 | | Quit Davide-NYC ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
19:06:48 | | Quit J3TC- (Read error: 110 (Connection timed out)) |
19:10:22 | | Join webguest61 [0] (i=4fb36408@gateway/web/cgi-irc/labb.contactor.se/x-254429942a891cab) |
19:10:30 | webguest61 | help please |
19:11:12 | krazykit | we're not psychic, you have to ask a question before you can get helped |
19:11:30 | webguest61 | ohh right :) |
19:11:41 | webguest61 | my sansa san disk stuck |
19:11:46 | webguest61 | when |
19:11:51 | preglow | ok, i'm thorougly confused now |
19:11:53 | webguest61 | i triend to open a game |
19:12:01 | webguest61 | *tried |
19:12:03 | krazykit | webguest61, please, the enter key is not the spacebar |
19:12:22 | webguest61 | explain please? |
19:12:38 | bertrik | pressing the power button for 15 seconds or more should do a hard shutdown of the sansa |
19:13:00 | webguest61 | thanks |
19:13:04 | krazykit | webguest61, i was just asking you to ask the question on a single line instead of multiple lines. it makes it easier to comprehend. |
19:13:05 | webguest61 | u helped me alot |
19:13:14 | webguest61 | ohhh sorry krazykit |
19:13:42 | webguest61 | thanks again betrick |
19:14:10 | krazykit | webguest61, if this is one of rockbox's games, if you can reproduce the problem and describe how to do it, you could open a bug, if you're using the current build |
19:14:57 | *** | Saving seen data "./dancer.seen" |
19:14:58 | preglow | amiconn: it looks like gas encodes the two multiplicands in mac/msac in the wrong order, lucky us multiplication is commutative ;) |
19:15:12 | webguest61 | yea it's some game bug ,,, the game called mazze or mazam |
19:15:50 | webguest61 | how i can store my TXT files in regular sansa sandisk firmware? |
19:16:05 | krazykit | webguest61, you just copy them over like any other file |
19:16:16 | | Join mf0102 [0] (n=michi@85.127.180.92) |
19:16:48 | webguest61 | does sansa supports reading txt files? |
19:17:04 | n1s | in rockbox it does |
19:17:23 | pondlife | Nico_P: Did you see the MEM > 8 checks in playback.c... They might need moving into buffering.c? |
19:17:42 | webguest61 | yeah i know but i want to ungrade my firm ver |
19:17:52 | | Quit webguest61 ("CGI:IRC") |
19:18:00 | pondlife | Nico_P: Basically it only rebuffers when needed, not on ATA callback |
19:18:06 | Nico_P | pondlife: they have been moved |
19:18:09 | pondlife | Cool |
19:18:22 | Nico_P | it will also rebuffer on ata callback |
19:19:02 | pondlife | I'm building now... |
19:19:15 | Nico_P | I haven't seen any problems yet |
19:19:33 | Nico_P | and IMO it's much much cleaner |
19:19:54 | pondlife | I was hoping that nearly all of the "filling" code could vanish |
19:20:03 | Nico_P | I'm hoping that too. looking |
19:21:38 | preglow | amiconn: this is starting to look like a gas bug |
19:22:16 | | Join hcs [0] (n=agashlin@rockbox/contributor/hcs) |
19:22:49 | preglow | yeah |
19:22:51 | preglow | almost certainly |
19:24:01 | preglow | using msac, i get hangs, using the exact same code, but with neg + mac, no hangs |
19:24:41 | | Quit barrywardell (Remote closed the connection) |
19:25:52 | | Quit webguest02 ("CGI:IRC (EOF)") |
19:27:15 | Nico_P | preglow: two new commits |
19:27:57 | Nico_P | or pondlife maybe |
19:28:28 | pondlife | Two more!? |
19:28:34 | pondlife | I only just built... |
19:28:57 | Nico_P | heh, you're going to have another one |
19:29:06 | pondlife | Already on it... good work there again |
19:30:51 | pondlife | Did you resolve that USB problem you mentioned? |
19:31:01 | Nico_P | not yet |
19:31:36 | pondlife | OK. I've not seen problems there |
19:31:40 | Nico_P | the problem is that with the buclose calls now being queue events, they get to the buffering queue after the usb event |
19:31:56 | Nico_P | but the audio thread thinks they succeeded, somehow |
19:32:31 | Nico_P | so maybe I should just remove all the handles after the usb connection, but that feels a bit extreme and wrong |
19:33:16 | preglow | arghg |
19:33:32 | Nico_P | pondlife: I hope you're enjoying the perfect automatic track skip transitions :) |
19:34:49 | pondlife | Perfect? What improved? |
19:35:21 | Nico_P | since earlier, not much, but I still find them nice to look at :) |
19:35:22 | pondlife | Ah, I've just had the little-bit-of-silence at the start of playback issue. |
19:35:28 | Nico_P | damn |
19:35:50 | pondlife | I'd guess buffering needs to yield more? |
19:36:00 | Nico_P | maybe there should be a yield or short sleep after loading each track in audio_fill_file_buffer |
19:36:12 | | Join obo [0] (n=obo@rockbox/developer/obo) |
19:36:21 | Nico_P | I think buffering yields enough |
19:36:24 | pondlife | Ah, ok |
19:36:45 | pondlife | Is the audio thread waiting for buffering at that point? |
19:36:55 | pondlife | I'd have thought not, as playback has started |
19:37:01 | Nico_P | would you mind trying to add a sleep(1) in the "do ... while" loop in audio_fill_file_buffer? to see if it solves it |
19:37:26 | Nico_P | no but maybe the audio thread is keeping the codec thread from running |
19:37:38 | | Quit spiorf (Read error: 110 (Connection timed out)) |
19:37:51 | pondlife | OK, it's reproducible, will try that |
19:37:59 | | Join spiorf [0] (n=spiorf@host178-222-dynamic.8-87-r.retail.telecomitalia.it) |
19:39:37 | Nico_P | thanks |
19:40:16 | pondlife | Yep, seems better |
19:40:33 | pondlife | I put a sleep(1) at the end of the loop |
19:40:34 | Nico_P | yield or sleep? |
19:40:36 | Nico_P | ok |
19:40:42 | | Join stevenm [0] (n=stevenm@129-2-175-80.wireless.umd.edu) |
19:41:06 | stevenm | n1s, log stalking mentions a midi data abort? |
19:41:09 | pondlife | Wooh, audio_load_track() is only called in on place now |
19:41:27 | pondlife | You could put that inline and scrap continue_buffering? |
19:41:45 | Nico_P | what do you mean ? |
19:41:46 | n1s | stevenm: yep, pixelma reported it but it seems to be fixed after my commit yesterday |
19:41:54 | stevenm | n1s, aah, yay. |
19:42:16 | amiconn | preglow: Hmmmm, this is with 2.16.1? |
19:42:19 | pondlife | Nico_P: The routine audio_load_track() could be scrapped, and it's contents put into audio_fill_file_buffer() |
19:42:35 | pondlife | Same for audio_initialize_buffer_fill() |
19:42:39 | amiconn | Because, I didn't have msac.w problems in the libmpeg2 idct |
19:43:03 | stevenm | n1s, where do we go from here, besides that numberOfSamples thing? Increase number of voices on coldfire, or the sample rate? |
19:43:10 | Nico_P | pondlife: I agree for the latter, but audio_load_track is quite long... I prefer to have audio_fill_file_buffer compact as it is |
19:43:45 | stevenm | n1s, I found it is easy to see if a file will play right on 44100: plug in USB during midi playback and it will set the sample rate to 44100. I don't know how, but that's what happens. |
19:44:01 | n1s | stevenm: I think going 44.1kHz would be nice but dunno if we're running fast enough... |
19:44:04 | stevenm | At the moment, I think all 24 voices active cannot run at 44100 in real time. Just barely under |
19:44:39 | stevenm | And if this thing is to become a codec, it would need to be fast enough to handler other tasks at the same time, like UI. 44100 sounds better but not really all THAT much. |
19:45:22 | pondlife | Nico_P: Hmm, I just went into View Playlist and the marked track was way out.. |
19:45:44 | Nico_P | pondlife: after doing what? |
19:45:45 | n1s | but if it becomes a codec the output will have to be resampled if it's not 44kHz... |
19:46:14 | pondlife | Not much... but stop/resume went back to the wrong track too (the same one shown in Playlist Viewer) |
19:46:22 | | Quit sslashes (Client Quit) |
19:46:23 | pondlife | I may have tried to rewind at the end of track |
19:46:27 | stevenm | n1s, I was at one point thinking about trying to figure out seeking. Forward is easy enough, but backwards is more complicated.. haven't been able to think of anything other than rewinding the tracks and running them from the start (ticks only, not voices) |
19:47:09 | stevenm | to get a constant number of seconds, it would have to take tempo changes into account and all. when I am done with GRE and this other exam this week, I can try to look into it |
19:47:09 | | Quit scorche|w ("CGI:IRC (EOF)") |
19:47:19 | pondlife | The playlist and resume point were 4 tracks earlier! |
19:47:46 | | Join sslashes [0] (n=sslashes@209.67.252.122) |
19:47:53 | Nico_P | pondlife: have you seen my latest commit? |
19:48:02 | stevenm | as for resampling, something like linear interpolation (or other methods) is a lot faster than rendering at twice the sample rate |
19:48:04 | Nico_P | "Forgot this one :(" |
19:48:36 | pondlife | Ah, that might be it |
19:49:09 | | Join scorche|w [0] (n=8dc5049d@st.iptel.by) |
19:49:13 | Nico_P | that's most probably it. on each auto track skip it would decrement the playlist position instead of incrementing it |
19:49:27 | Nico_P | dumb mistake on my part |
19:49:59 | pondlife | That would explain my symptoms perfectly. |
19:50:10 | | Join Llorean [0] (n=llorean@cpe-70-113-103-34.austin.res.rr.com) |
19:50:13 | Nico_P | sorry for the high commit rate |
19:50:32 | pondlife | No problem, they are (mostly) good things |
19:50:34 | pondlife | :) |
19:50:41 | | Join stripwax [0] (n=Miranda@i-83-67-214-206.freedom2surf.net) |
19:51:00 | | Quit stripwax (Client Quit) |
19:51:10 | pondlife | Do you know if anyone else is testing much? GodEater_ , JdGordon, anyone else..? |
19:51:34 | Nico_P | n1s: has been doing a bit of testing, but not fulltime I think |
19:51:44 | | Join Crash91 [0] (n=evil91@196.218.80.170) |
19:51:53 | Crash91 | hi |
19:51:58 | pondlife | Do you know if any Archos users have tried it, just in case? |
19:52:07 | Nico_P | no |
19:52:18 | pondlife | I would see if you can round one up ;) |
19:52:39 | pondlife | They shouldn't notice any change at all, but worth checking before commit |
19:52:45 | Nico_P | indeed |
19:52:48 | egolost | hmm.. how do i save a filename/path in rockbox? |
19:53:48 | | Join mrkiko [0] (n=mrkiko@adsl-ull-185-119.42-151.net24.it) |
19:54:08 | egolost | is it a button on the virtual keyboard or something? |
19:54:26 | stevenm | n1s, well, battery is running out. I will be back later. Bye! |
19:54:27 | pondlife | Nico_P: Ah, I need to add my sleep(1) again? |
19:54:28 | | Quit stevenm ("Connection reset by beer") |
19:54:49 | Nico_P | pondlife: I added it, so no but you might get a conflict |
19:55:07 | amiconn | pondlife: That won't easily be possible |
19:55:19 | amiconn | Atm the hwcodec and swcodec playback engines are disjuct |
19:55:23 | amiconn | *disjunct |
19:55:47 | pondlife | Indeed, I just wanted to ensure there had been no negative impact on HWCODEC |
19:55:53 | amiconn | And I don't think it makes sense to start converting archos playback now |
19:56:17 | pondlife | No, I wasn't suggesting any HWCODEC changes |
19:56:18 | amiconn | It will once MoB is in, and proven stable and compact enough |
19:56:30 | pondlife | Just to ensure that nothing had been broken |
19:56:47 | | Quit hcs ("Leaving.") |
19:57:05 | Nico_P | I've just made sure it compiles |
19:57:35 | Nico_P | and of course none of the buffering code is compiled |
19:58:27 | pondlife | Rewind at track end still gets confused btw, but no worse than SVN now |
19:58:52 | Nico_P | I fear there's no trivial fix for this |
19:59:25 | pondlife | Must be detectable |
19:59:34 | Nico_P | ouch I have nearly 1k added to the gigabeat binary |
19:59:39 | pondlife | Ooer |
19:59:49 | | Join hcs [0] (n=agashlin@rockbox/contributor/hcs) |
19:59:58 | pondlife | How did that happen? Debugging? |
20:00 |
20:00:23 | Nico_P | yeah the debugging menu code probably adds a bit |
20:00:34 | | Quit japc (Read error: 104 (Connection reset by peer)) |
20:00:47 | pondlife | Ah, something else for someone to test - cuesheets |
20:00:51 | Nico_P | and apparently the removals in playback.c don't compensate the addition of buffering.c |
20:01:13 | pondlife | I'd expect a modest increase for the separation, but not much |
20:01:20 | n1s | stevenm: (for the logs) 22kHz upsampled to 44 will sound worse than just playing at 22kHz so IMHO 44kHz is a worthy goal :-) |
20:01:29 | pixelma | egolost: on the c200 currently you accept the entered name/path with one of the both volume buttons in the virtual keyboard (accept and exit). I hope to improve the keymap soon (and if that happens update the manual) but I got two versions both have their upsides and downsides and am a bit undecided |
20:01:44 | | Quit hcs (Client Quit) |
20:02:49 | pondlife | Nico_P: The rebuffer parameter for audio_fill_file_buffer() and audio_load_track() can be scrapped |
20:03:00 | pondlife | It's not used any more |
20:03:05 | pixelma | egolost: with the power button you can exit without saving the changes |
20:03:09 | | Join Frazz [0] (n=Fraser@thelawsons.plus.com) |
20:03:45 | Nico_P | pondlife: very true |
20:05:21 | pondlife | Is the audio_flush_and_reload_tracks() stuff still needed? |
20:05:58 | Nico_P | I'm not sure |
20:06:22 | pondlife | We seem to have multiple mechanisms for reloading after a playlist change. |
20:06:41 | pondlife | i.e. methods to invalidate the track list |
20:08:00 | pondlife | audio_invalidate_tracks() vs. audio_new_playlist() |
20:08:01 | | Join TMM [0] (n=hp@c5147518c.cable.wanadoo.nl) |
20:10:33 | preglow | amiconn: yeap |
20:10:56 | preglow | amiconn: would newer binutils work out of the box for us? |
20:11:07 | amiconn | I don't know... |
20:11:26 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
20:11:27 | preglow | there's something about new arch flags and all, but i don't know if they've kept the old ones |
20:11:31 | Nico_P | pondlife: you're right, they seem a bit duplicate |
20:14:06 | egolost | pixelma: is there a stop button or paus only? |
20:14:48 | | Join TotallyInfected [0] (n=ebola@pool-70-110-242-209.phil.east.verizon.net) |
20:15:24 | | Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) |
20:15:32 | | Join nomel [0] (i=4782332a@gateway/web/cgi-irc/labb.contactor.se/x-0f9cd5d323cef609) |
20:15:48 | pondlife | Nico_P: I'd suggest you change the parameter names of buffering_init(); the current ones are global vars too |
20:15:55 | pixelma | egolost: for playing music? |
20:16:39 | pondlife | playback.c doesnt' need high_watermark any more |
20:16:43 | egolost | pixelma: found it.. long play. |
20:17:53 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
20:18:13 | nomel | where's the best way to report a rockbox bug for a device? |
20:18:33 | nomel | zagor: hey. |
20:18:35 | pondlife | nomel: Confirm it in the forums, then report on Flypray |
20:18:38 | pondlife | Flyspray |
20:18:43 | nomel | k. |
20:18:43 | BigBambi | Nico_P: I can do testing on H1x0 or gigabeat if you like/need it |
20:19:02 | Zagor | hi |
20:19:15 | nomel | zagor: i'm 90% sure it's a problem with the button code. i found that pressing pause then play again increases the volume and changes the radio station :) |
20:19:21 | Nico_P | BigBambi: testing on H100 would be useful, yeah |
20:19:26 | BigBambi | OK, will do |
20:19:34 | nomel | that shouldn't have anything to do with initialization of the radio chip |
20:19:38 | Zagor | nomel: ! |
20:19:42 | * | BigBambi goes to look for the wiki page to find the repo |
20:19:44 | nomel | seriously! |
20:19:47 | pixelma | nomel: on what player? |
20:19:51 | nomel | c200 |
20:20:02 | nomel | us w/radio version. |
20:20:09 | pondlife | BigBambi: http://repo.or.cz/w/Rockbox.git?a=shortlog;h=mob might be useful |
20:20:19 | BigBambi | pondlife: Cheers |
20:20:35 | pixelma | I don't think it has anything to do with the initialisation just button action interference |
20:20:51 | Zagor | nomel: confirmed |
20:21:40 | Zagor | pixelma: it's more than just a button bug. the frequency changes but rockbox doesn't think so |
20:21:44 | nomel | :-o |
20:22:36 | Zagor | however it's not the only radio bug. it still takes several seconds to just enter the radio screen for me. it was instant on my other c200. |
20:23:09 | pixelma | but the volume change at the same time probably is ("play" is the same as "up" used for volume on some players, thought I kept an eye on that) |
20:23:21 | Zagor | pixelma: i agree |
20:24:36 | nomel | i'll be looking at the LO signal with a spectrum analyzer later today to see if there's any relation between what frequency the player is on and the actual. |
20:25:07 | nomel | lunch time. |
20:25:18 | pondlife | Nico_P: Hmm, conf_preseek isn't used... might be the same in SVN |
20:25:30 | Nico_P | no, it's used in svn |
20:25:46 | pondlife | and conf_filechunk |
20:25:50 | Nico_P | I'm not sure whether it's useful to readd it |
20:25:55 | amiconn | preglow: Btw, another objdump bug: trapf.w is disassembled as "sf %d2" (!) |
20:26:01 | Nico_P | conf_filechunk is used in the buffering loop |
20:26:14 | pondlife | Ah yes |
20:27:03 | pondlife | It's not used in playback.c though |
20:27:09 | amiconn | Zagor: How are the endpoints today? :) |
20:27:50 | Nico_P | pondlife: it's used in codec_configure_callback |
20:28:06 | pondlife | Yes, it's set, but never read |
20:28:29 | pondlife | It's passed through perhaps to dsp_configure |
20:28:37 | pondlife | Ah, not even that |
20:28:47 | Nico_P | yeah, you're right :) |
20:29:03 | pondlife | conf_preseek too, right? |
20:29:33 | Nico_P | yes, it's the same |
20:30:04 | Nico_P | I think I need to look into that callback. maybe I need to add something similar to buffering.c |
20:30:21 | pondlife | Find out if it's really needed first |
20:30:36 | pondlife | Codecs should be irrelevant to buffering.c |
20:30:37 | preglow | amiconn: marvelous |
20:30:54 | pondlife | Any needed fudging should still be in playback.c, I'd think |
20:31:02 | Zagor | amiconn: very ... annoying. |
20:31:18 | | Quit FOAD (Remote closed the connection) |
20:31:37 | Nico_P | pondlife: the codec still needs a way to set these though |
20:32:09 | pondlife | Yes, but buffering.c should definitely not be involved |
20:33:06 | | Join FOAD [0] (n=dok@dinah.blub.net) |
20:33:35 | pondlife | Maybe you'll have to add a per-handle filechunk though |
20:33:51 | pondlife | A global value for a mix of codecs won't work |
20:34:07 | pondlife | Ideally it can be dropped. |
20:36:01 | | Join petur2 [0] (n=petur@rockbox/developer/petur) |
20:36:17 | Zagor | amiconn: in fact I'm starting to wonder if the reason for my trouble is that the usb module isn't the same as in the i.mx31 |
20:37:27 | | Quit jhMikeS ("Meow!") |
20:39:26 | Nico_P | pondlife: I don't see how I can make these conf_* vars configurable by the codec without making them global or adding code to buffering.c to allow changing them |
20:39:27 | * | BigBambi will start testing as soon as he can persuade Ubuntu to automount his iriver as anything other than read only |
20:39:38 | Nico_P | pondlife: and they can't stay in playback.c either |
20:40:18 | | Quit Sedgewick (Connection timed out) |
20:41:13 | preglow | Zagor: they might have tweaked it subtly |
20:41:35 | preglow | this is what we have disassemblers for :V |
20:41:57 | Zagor | preglow: there are also many variations of this module. for example the MPC8349 contains a similar module, but which supports fewer endpoints etc. |
20:42:07 | | Quit ompaul (Client Quit) |
20:43:40 | preglow | Zagor: well, in that case it's not veru likely it's the exact same one as in the imx31 |
20:44:14 | amiconn | I would not be surprised anymore if portalplayer introduced some extra bugs... :> |
20:44:26 | | Join linuxstb [0] (n=chatzill@copernic-sda.pck.nerim.net) |
20:44:27 | Zagor | preglow: exactly. and it would explain some of my headaches |
20:45:45 | preglow | hell, if they can manage to mess up an _instruction_, then this is surely right in their usual ballpark |
20:46:39 | amiconn | I don't think they messed the instruction in the core |
20:46:57 | preglow | probably an interface issue |
20:46:58 | preglow | but still |
20:47:03 | amiconn | The problem is that swp(b) must lock the bus between the read and the write |
20:47:03 | preglow | it speaks volumes about their testing |
20:47:17 | amiconn | ...and most probably that locking is what is broken, in the bus controller |
20:47:44 | | Join TotallyInfected_ [0] (n=ebola@pool-70-110-242-209.phil.east.verizon.net) |
20:47:56 | preglow | yes, they probably don't mess with what they get from arm, but like i said... |
20:48:04 | preglow | messing up bus locking requires some kind of a genious |
20:48:07 | | Join Rob2222 [0] (n=Miranda@p54B1671C.dip.t-dialin.net) |
20:49:39 | | Join mirak [0] (n=mirak@m94.net81-66-75.noos.fr) |
20:50:16 | | Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) |
20:51:35 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
20:54:33 | pondlife | Nico_P: Sorry, off now. I'm not sure what those configuration parameters are needed for exactly. Do you know? |
20:55:01 | Nico_P | enough I think |
20:55:13 | pondlife | So they are definitely needed? |
20:55:37 | pondlife | Is it to ensure that buffer wrap is handled correctly? |
20:55:48 | pondlife | i.e. that we always have enough data? |
20:56:01 | Nico_P | yeah I think they are. no, it's not exaclty that |
20:56:18 | Nico_P | conf_filechunk is the amount of data read per loop |
20:56:48 | pondlife | How is that relevant to the codec? |
20:56:51 | Nico_P | conf_watermark is the low buffer watermark. it depends on the codec and audio file |
20:57:25 | Nico_P | well apparently the codec will expect to be able to set it |
20:57:47 | Nico_P | same for preseek |
20:57:50 | Zagor | confirmed. DCIVERSION is '1' on the sansa, but '0' on the mx31 |
20:58:06 | BigBambi | Nico_P: Turning cross fade off whilst playing, track stopped (expected), restarted briefly (second or two), then stopped again. Resume playback then started that track from the beginning again |
20:58:21 | BigBambi | Nico_P: And exactly the same thing turning crossfade on again |
20:58:34 | pondlife | I got a bit of white noise, about 5 mins later |
20:58:40 | pondlife | After playing for a while ok |
20:58:45 | BigBambi | Nico_P: Is there somewhere you would like me to note things rather than spamming you here? |
20:59:07 | pondlife | BigBambi: http://www.rockbox.org/twiki/bin/view/Main/MetadataOnBufferTesting might help |
20:59:12 | mirak | what do IDE do you use ? |
20:59:14 | Nico_P | what pondlife said :) |
20:59:15 | BigBambi | Cheers |
20:59:45 | pondlife | So, those codec params, how do they affect data availability later? |
21:00 |
21:00:13 | pondlife | I can only think that they might mean the codec expects to be able to read data in chunks of a minimum size... |
21:00:43 | pondlife | Perhaps find out which codecs set those parameters to wacky values ;) |
21:00:59 | pondlife | Then ask the relevant codec guru |
21:01:08 | pondlife | Or perhaps amiconn knows...? |
21:03:11 | Nico_P | pondlife: rgrep "configure" apps/codecs |
21:03:36 | mirak | crap eclipse doesn't work un ubuntu gutsy |
21:03:44 | | Quit TotallyInfected (Read error: 110 (Connection timed out)) |
21:04:31 | * | BigBambi takes idiot hat off |
21:04:53 | Nico_P | pondlife: I agree the filechunk setting is probably a bit useless, but the watermark at least is important and the preseek might be needed for proper seeking |
21:05:03 | BigBambi | I was going to say switching between tracks with different codecs takes ages, like 5 seconds, then I remembered I'd just turned crossfade on to test it |
21:05:15 | | Quit jhulst (No route to host) |
21:05:23 | pondlife | Ah, yes, but it's much slower than SVN |
21:05:30 | BigBambi | Yes, it still is |
21:05:31 | Nico_P | pondlife: and now these settings are used by the buffering thread, so it needs a way to make them changeable by the codec |
21:05:32 | pondlife | Something is still sub-optimal there |
21:05:34 | BigBambi | Couple of seconds |
21:06:03 | pondlife | Nico_P: I guess they need to be per handle at least.. |
21:06:16 | amiconn | hrmph |
21:06:20 | Nico_P | pondlife: yeah maybe |
21:06:28 | Nico_P | BigBambi: skipping? |
21:07:03 | pondlife | Seems silly to have them as globals when buffering is time-independent of playback. |
21:07:17 | BigBambi | NicoP; yeah, skipping from one track to another with different codecs |
21:07:28 | Nico_P | ok, I'll look |
21:07:29 | BigBambi | Sometimes quite quick, sometimes slow |
21:07:37 | Nico_P | pondlife: conf_watermark shouldn't be per handle |
21:07:44 | BigBambi | And this is all in the first 3 or 4 tracks, so should be in the buffer |
21:08:09 | * | BigBambi is liking the Buffereing debug screen |
21:08:47 | pondlife | Nico_P: Why not, what if you have an MP3 and an SPC track buffering; they have different watermark values... |
21:08:52 | bertrik | would it help if i mapped the I2C space of the AS3514 (read-only)? or did someone already do that? |
21:08:55 | preglow | Zagor: and DCIVERSION is what? |
21:08:57 | Nico_P | pondlife: meh, I don't know anymore. I need to think of something else. I'll go make supper for myself |
21:09:07 | pondlife | Good idea, it's been a productive day |
21:09:11 | pondlife | Speak tomorrow, maybe |
21:09:18 | Nico_P | hope so :) |
21:09:30 | | Quit criznach ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
21:10:06 | Zagor | preglow: Device Controller Interface version. it's a hardcoded read-only identification register that never changes. |
21:10:32 | preglow | Zagor: so ours is actually newer than in the imx31? |
21:11:02 | | Part egolost |
21:11:15 | BigBambi | Nico_P: Skipping from MPC to OGG, 1st and 2nd tracks in playlist, All buffers full playing first track, skip to next track, continues playing while pcm buffer empties, then playback stops for a short time, then it all kicks back in, pcm buffer refills, next track starts |
21:11:30 | Zagor | I don't know what the number actually means. all I know is that the imx31 specs say the register should be all zeros, and the mpc8349 docs say their module should return 0x01 in that register. as the sansa does. |
21:11:57 | amiconn | pondlife: There's an even more complicated case: if there are several *very* small tracks with different format in the buffer ... |
21:12:22 | bertrik | did someone already map the values on the I2C of the AS3514? |
21:12:27 | | Join webguest06 [0] (i=415fa842@gateway/web/cgi-irc/labb.contactor.se/x-46eb71ee1624f099) |
21:12:37 | amiconn | ..so that e.g. the first track stays below the low watermark entirely, and the second one has a different watermark. What to use in such a case? |
21:12:41 | | Join J3TC- [0] (n=jetc123@dhcp78-127.njit.edu) |
21:13:24 | BigBambi | Nico_P: Interesting, I am watching the debug screen on the main unit, music is playing back fine, and the LCD remote has a splash saying Codec failure! |
21:13:35 | webguest06 | hi |
21:14:13 | amiconn | BigBambi: The splash is just not erased, as the debug screen doesn't handle the remote |
21:14:17 | | Join Tavnos [0] (n=tavnos@lju91-5-88-174-161-25.fbx.proxad.net) |
21:14:24 | Tavnos | Hi there |
21:14:30 | webguest06 | will you make a sleep mode (like the apple firmwar, cause thats the only reason i'm staying on apple's firmware |
21:14:33 | Zagor | also the sansa DCCPARAMS register contains 0x387, which means it's neither the same as in i.mx31 (should have 'f' last) or mpc8349 (should have '6' last) |
21:14:38 | BigBambi | amiconn: So there was an earlier codec failure I didn't notice? |
21:14:50 | amiconn | I would think so |
21:14:52 | BigBambi | OK |
21:14:58 | *** | Saving seen data "./dancer.seen" |
21:16:12 | webguest06 | they will? |
21:16:23 | BigBambi | webguest06: Patience grasshopper |
21:16:32 | BigBambi | Firstly, which iPod |
21:16:32 | amiconn | Zagor: Do you know the meaning of those values? |
21:16:52 | pondlife | amiconn: Can we maybe chat about the codec parameters tomorrow? I have to go now, sadly. |
21:16:54 | amiconn | You said that the mpc8349 has fewer endpoints than the i.mx31? |
21:17:27 | | Part pondlife ("Gone") |
21:17:28 | Zagor | amiconn: yes, the lowest five bits in dccparams is the number of endpoints |
21:17:32 | amiconn | pondlife: I really don't know how this currently works. I just know that there is a low watermark, and it's different per codec |
21:17:53 | webguest06 | well, i have an iPod video (5g,old school) |
21:17:59 | BigBambi | And seondly I don't think anyone is working on one. I believe amiconn is looking at suspend for the 1st and 2nd gens as they physically cannot be turned off, but other than that I don't think anyone is working on it. Therefore there won't be one until someone does work on it. |
21:18:14 | webguest06 | oh ok |
21:18:18 | webguest06 | :( |
21:18:19 | | Quit webguest06 ("CGI:IRC") |
21:18:29 | | Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) |
21:19:28 | | Quit A_M () |
21:21:24 | | Quit TMM (Read error: 110 (Connection timed out)) |
21:21:47 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
21:21:56 | | Join miepchen^schlaf [0] (n=hihi@p54BF44F7.dip.t-dialin.net) |
21:23:31 | Zagor | hmm, scratch that confirmation. the i.mx31 docs are a bit fuzzy what the registers are supposed to contain. |
21:23:42 | amiconn | Meh. The demac filters are nasty. Not only v1 and v2 can be unaligned in the vector operations, but they can also be unaligned wrt each other :( |
21:24:00 | bertrik | oh you have docs now, nice |
21:24:20 | | Join Sedgewick [0] (n=10334AEF@host99-233-dynamic.15-87-r.retail.telecomitalia.it) |
21:24:50 | Zagor | bertrik: I had docs all along. but I'm starting to doubt they are the right ones. |
21:24:52 | amiconn | So that means in order to always fetch aligned, there need to be 4 cases. The effect might not be worth the overhead of checking :( |
21:25:04 | | Join Buschel [0] (n=AndreeBu@p54A3F90F.dip.t-dialin.net) |
21:25:58 | J3TC- | So which bmp file is the bootlogo for iaudio x5? |
21:26:06 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
21:26:22 | J3TC- | rockboxlogo.160x50x16.bmp ? |
21:28:02 | | Quit spiorf (Remote closed the connection) |
21:28:33 | | Quit ilgufo ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") |
21:30:52 | mirak | amiconn: have you tried something on slice.c ? |
21:30:58 | Zagor | oh no... |
21:30:59 | | Join ilgufo [0] (n=matteo@host109-178-dynamic.5-87-r.retail.telecomitalia.it) |
21:32:35 | Zagor | 387 was decimal. in hex it's... 183. three endpoints. |
21:32:57 | amiconn | Oh wow |
21:33:11 | amiconn | A bit...limited, eh? |
21:33:15 | Zagor | quite |
21:33:28 | Zagor | no wonder i couldn't get #5 and #6 working |
21:33:46 | amiconn | How many endpoints do you need for ums? |
21:33:56 | Zagor | just two, so that's fine (plus one for control) |
21:34:18 | amiconn | The control endpoint is fixed, correct? |
21:34:31 | * | amiconn doesn't know much about usb, just a little bit |
21:34:35 | Zagor | but I added test endpoints higher up, which obviously didn't work very well |
21:34:51 | Zagor | amiconn: yes ep0 is always control |
21:35:14 | Zagor | but I think it is included in the three. size 0 means "device mode not supported" |
21:35:15 | amiconn | Hmm, for compound devices we would need more endpoints? |
21:36:11 | Zagor | no there's something called "configurations", where the host can select what type of device it wants us to be. but I haven't read up on it much. bertrik, do you know more? |
21:36:18 | bertrik | amiconn: yes |
21:36:37 | bertrik | Zagor: as far as i know, there is in practice only one configuration |
21:36:51 | bertrik | but it is possible to have more interfaces |
21:37:04 | bertrik | an interface is a set of endpoints |
21:37:35 | Zagor | ah, I mixed them up |
21:37:36 | bertrik | so for example, one interface consisting of 2 EPs for MSC and another 2 EPs for virtual COM |
21:38:16 | bertrik | I mean, two interface of two EPs each |
21:38:54 | Zagor | I obviously need to read up on this |
21:39:37 | amiconn | Hmm, the USB stack for my Amiga USB card (not open source, unfortunately) shows quite some details about that stuff |
21:40:18 | bertrik | there is a very nice introductory text called usb-in-a-nutshell, I'll look it up |
21:40:32 | Zagor | bertrik: thanks, I've read it already :) |
21:41:09 | bertrik | If you read that, and chapter 9 of the USB spec, you know almost everything you need to know about USB |
21:41:33 | bertrik | http://www.beyondlogic.org/usbnutshell/usb1.htm |
21:41:37 | Zagor | well I may have skimmed some sections... |
21:42:06 | Zagor | http://www.beyondlogic.org/usbnutshell/usb5.htm#ConfigurationDescriptors |
21:42:08 | | Join japc [0] (n=japc@bl7-241-88.dsl.telepac.pt) |
21:42:14 | bertrik | the usbnutshell document is also available somewhere as a pdf (in case you want to print it) |
21:42:38 | Zagor | "Each configuration could be powered in the same way and draw the same current, yet have different interface or endpoint combinations." |
21:43:06 | | Quit FOAD ("I'll be back") |
21:43:28 | Zagor | sounds like it should be possible to have MSC and COM in two different configurations |
21:44:51 | mrkiko | Can playing with USB be a dangerous activity on some situations? |
21:45:07 | bertrik | I think it is very unusual to have more than one configuration, I vaguely remember that windows does not even support it |
21:45:11 | Zagor | mrkiko: you mean aside from corrupting your disk? |
21:45:33 | n1s | mrkiko: if you play with it in the wrong neighbourhood? |
21:46:15 | Zagor | bertrik: do you remember if does not support as in bluescreen or as in ignores it? |
21:46:46 | bertrik | Zagor: i don't know. I can't find the link anymore. |
21:47:13 | amiconn | Zagor: Very interesting: The Amiga USB stack shows the number of endpoints for each connected device. |
21:47:16 | n1s | Zagor: couldn't we have a setting on the device that controls which configuration is presented to the host? |
21:47:26 | bertrik | Can't we just drop off the bus and reappear as another device with another device id? |
21:47:29 | Zagor | n1s: yes we can |
21:47:46 | amiconn | If I connect a mass storage device with a hardware controller (e.g. Iriver H300 or Iomega ZIP USB), they use 3 endpoints |
21:47:47 | Zagor | bertrik: I guess that's an option |
21:47:57 | amiconn | But if I connect a PP device, it only uses 2 |
21:48:02 | Zagor | amiconn: yes, lsusb on linux also shows all descriptors |
21:48:15 | amiconn | Note that this is fullspeed, not highspeed |
21:48:29 | mrkiko | I meant playing with it in general. |
21:48:30 | | Quit Crash91 ("Bye Bye!") |
21:48:30 | | Join DGMurdockIII [0] (i=DGMurdoc@64-184-11-103.bb.hrtc.net) |
21:48:34 | DGMurdockIII | hi |
21:48:54 | mrkiko | ... can I accidentally burn a device for example ? |
21:48:55 | Zagor | amiconn: are those 3 control + interrupt + bulk endpoints? |
21:49:05 | Zagor | mrkiko: not likely |
21:49:13 | amiconn | That's not shown, only the total number |
21:49:16 | Zagor | ok |
21:49:18 | DGMurdockIII | when is the creative vision M firmware going to be out |
21:49:47 | Zagor | DGMurdockIII: is there anyone working on a port for that? |
21:50:39 | | Join FOAD [0] (n=dok@dinah.blub.net) |
21:50:43 | DGMurdockIII | it says in the Development page that its a new port |
21:50:55 | alienbiker99 | there is no set time |
21:51:08 | * | bertrik is mapping the I2C space of the AS3514 |
21:51:34 | n1s | DGMurdockIII: it will likely be available when (if) it works somewhat (for example boots the player) |
21:52:07 | rasher | DGMurdockIII: That could mean anything from "almost usable" to "only information has been gathered - no code has been written" |
21:52:40 | | Quit mrkiko ("bye bye - thank all!") |
21:53:07 | Zagor | from the CreativeZVMPort page: "Status: To-Do: Figure out how to put our own firmware on." |
21:53:18 | Zagor | that's rather early |
21:53:56 | * | amiconn found a simple way of checking whether a specific asm code path is taken on coldfire |
21:53:58 | bertrik | I2C data repeats every 0x40 bytes |
21:54:11 | pixelma | maybe there's more info in the "new ports" section in the forums? Haven't looked but I think I read something there |
21:54:26 | amiconn | Just put 'illegal' in that path. If it fires an illegal instruction exception, it is reached... |
21:55:04 | amiconn | One could also put line A or line F emulation instructions for that... |
22:00 |
22:05:15 | | Quit Xerion (Read error: 104 (Connection reset by peer)) |
22:06:16 | | Quit ompaul (Client Quit) |
22:09:03 | | Join bluebrother [0] (i=Mq34Y4EG@rockbox/staff/bluebrother) |
22:10:41 | | Quit mf0102 ("Verlassend") |
22:10:50 | | Join barrywardell [0] (n=barrywar@89-125-27-44.dhcp-ripwave.irishbroadband.ie) |
22:11:22 | | Join Xerion [0] (i=xerion@cp198589-d.landg1.lb.home.nl) |
22:12:48 | | Quit Lear ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
22:13:06 | | Quit atsea-22 (Read error: 104 (Connection reset by peer)) |
22:14:41 | Buschel | amiconn: thanks for converting my patch to an .S-file and do the missing optimizations :o) now i have 8.9fps @30MHz |
22:17:35 | | Quit amiconn (Nick collision from services.) |
22:17:41 | | Join amiconn [0] (n=jens@rockbox/developer/amiconn) |
22:18:16 | barrywardell | bertrik: have you got the AS3514 datasheet? |
22:18:29 | bertrik | no, don't tell there is one |
22:19:42 | | Join atsea-22 [0] (i=atsea-@gateway/tor/x-594c7638856a2f47) |
22:19:45 | barrywardell | yeah, we have access to it |
22:20:46 | bertrik | so I justed wasted some time ... |
22:24:10 | | Part igorr |
22:26:04 | | Quit Buschel () |
22:26:40 | | Quit Toxicity999 ("Leaving") |
22:27:02 | | Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) |
22:27:06 | | Quit ilgufo ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") |
22:29:44 | | Join p3tur [0] (n=petur@rockbox/developer/petur) |
22:31:05 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
22:31:32 | | Quit petur (Nick collision from services.) |
22:31:37 | | Nick p3tur is now known as petur (n=petur@rockbox/developer/petur) |
22:32:06 | | Join petur3 [0] (n=petur@ip-212-239-214-166.dsl-static.scarlet.be) |
22:32:10 | | Quit petur (Nick collision from services.) |
22:32:12 | | Nick petur3 is now known as petur (n=petur@ip-212-239-214-166.dsl-static.scarlet.be) |
22:32:26 | | Join p3tur [0] (n=petur@rockbox/developer/petur) |
22:33:19 | | Quit petur (Nick collision from services.) |
22:33:23 | | Nick p3tur is now known as petur (n=petur@rockbox/developer/petur) |
22:33:37 | | Part DGMurdockIII |
22:33:53 | | Join petur3 [0] (n=petur@ip-212-239-214-166.dsl-static.scarlet.be) |
22:33:57 | | Quit petur (Nick collision from services.) |
22:33:59 | | Nick petur3 is now known as petur (n=petur@ip-212-239-214-166.dsl-static.scarlet.be) |
22:34:13 | | Join p3tur [0] (n=petur@rockbox/developer/petur) |
22:34:36 | p3tur | petur: who the hell are you that you managed to steal my nick? |
22:34:57 | | Quit Sedgewick (Remote closed the connection) |
22:35:09 | | Quit petur (Nick collision from services.) |
22:35:13 | | Nick p3tur is now known as petur (n=petur@rockbox/developer/petur) |
22:35:32 | | Quit nicktastic ("Leaving") |
22:35:43 | | Join petur3 [0] (n=petur@ip-212-239-214-166.dsl-static.scarlet.be) |
22:36:36 | petur | any channel op around please? |
22:36:41 | japc | lol |
22:36:44 | petur | scorche? |
22:36:46 | scorche|w | ? |
22:36:50 | scorche|w | what? |
22:36:56 | petur | can you ban petur3? |
22:37:00 | | Quit japc (Remote closed the connection) |
22:37:08 | scorche|w | he will still be on the network |
22:37:19 | petur | he stole my nick, I just managed to change my password |
22:38:00 | scorche|w | but what would banning him accomplish? |
22:38:00 | preglow | how can i know you are you :P |
22:38:23 | petur | ask something? |
22:38:31 | scorche|w | beer? |
22:38:41 | * | petur grabs a bottle to kick petur3 |
22:38:47 | | Quit petur2 (Read error: 110 (Connection timed out)) |
22:38:47 | petur | empty of course |
22:38:56 | Mode | "#rockbox +o preglow " by ChanServ (ChanServ@services.) |
22:39:00 | pixelma | especially since it's also a .be provider.. ;) |
22:39:01 | Kick | (#rockbox petur3 :preglow) by preglow!n=thomj@rockbox/developer/preglow |
22:39:01 | | Join petur3 [0] (n=petur@ip-212-239-214-166.dsl-static.scarlet.be) |
22:39:06 | preglow | right |
22:39:27 | petur | I'm on telenet anyway, not scarlet |
22:39:27 | scorche|w | i can ban him, i am just trying to see what that would accomplish as he would be able to do the same thing, as he is still on the network |
22:39:34 | Mode | "#rockbox +b *!*@ip-212-239-214-166.dsl-static.scarlet.be " by preglow (n=thomj@rockbox/developer/preglow) |
22:39:36 | Kick | (#rockbox petur3 :preglow) by preglow!n=thomj@rockbox/developer/preglow |
22:39:48 | * | petur sens preglow beer of his choice |
22:39:55 | petur | *sends |
22:40:02 | * | scorche|w shrugs... |
22:40:16 | preglow | sure, but at least he won't be here pissing petur off :> |
22:40:34 | Mode | "#rockbox -o preglow " by ChanServ (ChanServ@services.) |
22:40:52 | * | preglow blinks at chanserv |
22:41:21 | * | scorche|w blinks at preglow |
22:41:27 | petur | I have seen my nick logged in in the past but thought it was just somebody using it unregistered, and ghosted him. But now he ghosted me, so somehow got hold of my password :( |
22:41:30 | * | BigBambi blinks at /me |
22:41:45 | Zagor | petur: nasty |
22:41:48 | * | petur makes note of using stronger passwords |
22:41:48 | rasher | petur: take it up with freenode staff |
22:42:03 | rasher | or is it resolved now? |
22:42:03 | scorche|w | petur: well, irc does send passwords over plaintext |
22:42:23 | rasher | scorche|w: not if you use ssl connections |
22:42:28 | scorche|w | but yes...if you have any network issues like that, join #freenode, and see what they can do (typically not much) |
22:42:31 | preglow | i keep sending my password to this guy called "nickserv" on efnet all the time :P |
22:42:39 | scorche|w | rasher: freenode doesnt accept ssl |
22:42:59 | rasher | scorche|w: ah, forgot. Why on the earth not |
22:43:25 | pixelma | Zagor: made an interesting observation re. radio and the "play" button on my c250... when the tuner is "confused" as I would call it, unpausing takes longer than when everythings alright |
22:43:32 | scorche|w | too complex...pretty much all ssl connections on other servers are flawed anyway...from what i understand, it is just hard to do with the prototcol |
22:43:53 | scorche|w | on freenode, there is a tor/gpg combination |
22:44:00 | preglow | tor :/ |
22:44:16 | Bagder | tor is... annoying at best |
22:44:32 | scorche|w | Bagder: welcome back :) |
22:44:32 | preglow | tor would work well if people weren't so shitty |
22:44:36 | preglow | but they are |
22:44:44 | rasher | Never had a problem with ssl on other networks. Anyway, freenode happily gave me my password when I forgot it once. |
22:44:44 | * | Bagder bows |
22:44:53 | rasher | Which was somewhat scary |
22:44:55 | preglow | over half the people using it are trolls |
22:45:02 | | Part TotallyInfected_ |
22:45:14 | Bagder | and the non-trolls think tor is encryption ;-O |
22:45:22 | scorche|w | rasher: yes, but those implementations have large flaws...if you want to find out more, join #freenode and ask BearPerson |
22:45:44 | | Join crashmatrix [0] (n=crashmat@s5590785f.adsl.wanadoo.nl) |
22:45:47 | scorche|w | he is one of the main ircd devs |
22:45:59 | Bagder | I don't buy that |
22:46:21 | * | scorche|w shrugs...i am just repeating what i hear |
22:46:31 | nomel | pixelma, it doesn't change frequencies? |
22:46:37 | crashmatrix | evening, here with a quick question regarding my iPod health, is it okay to dd the entire disk, and reparition it, keeping firmware considerations in mind? |
22:46:38 | nomel | on my c200, it changes frequencies after unpausing. |
22:46:47 | rasher | Freenode also has a habit of making issues where there are none. But all this is off-topic anyway. |
22:47:00 | nomel | well, it changes relative to the frequency that it's displaying. |
22:47:14 | bb | Hi. I showed Rockbox on my Sansa e280 to a friend and he really liked it. Now he wants to know if it runs on his car stereo, but I have no clue. It's called "995DVD Car Entertainment System". Any idea were I could search for more detailed information what it really is? |
22:47:15 | nomel | not sure if it changes when pausing also. |
22:47:19 | | Quit DogBoy (Read error: 104 (Connection reset by peer)) |
22:47:31 | | Join donutman25 [0] (n=chatzill@65.75.87.48) |
22:47:34 | crashmatrix | bb: tough luck, probably not |
22:47:39 | BigBambi | bb: Rockbox supported players are on the front page of the website |
22:48:03 | BigBambi | bb: And that definitely isn't one |
22:48:50 | bb | BigBambi: it's a no name product and seems to be available under lots of different names and I guess I haven't found all names yet |
22:49:02 | | Join Sedgewick [0] (n=Sedgewic@host99-233-dynamic.15-87-r.retail.telecomitalia.it) |
22:49:09 | BigBambi | bb: Have a look at the front page |
22:49:23 | pixelma | nomel: not that I can tell (doesn't display a frequency change) and can't here it because frequencies are wide off and I only get static either way |
22:49:36 | BigBambi | bb: I can can guarantee whatever it's names, rockbox does not run on any car radios. |
22:49:40 | J3TC- | Anyone playing with the sudoku patch? |
22:49:49 | Zagor | pixelma: it doesn't display a new frequency, it just hops |
22:49:51 | J3TC- | The one where you can pick the difficulty patch? |
22:50:14 | | Join TotallyInfected [0] (n=ebola@pool-70-110-242-209.phil.east.verizon.net) |
22:50:30 | pixelma | nomel: ah... yes I could hear it now after a few tries it suddenly had a station |
22:50:48 | pixelma | but it doesn't change volume anymore :) |
22:51:38 | rasher | J3TC-: I believe that's one I wrote, but it was reported to have bugs. Why? |
22:52:58 | J3TC- | Ah awesome |
22:52:59 | J3TC- | Well |
22:53:37 | J3TC- | It crashes upon compiling and it gives the error of structure has no member 'menu_init' and 'menu_show' |
22:54:01 | J3TC- | So I'm assuming there is no more function for those two |
22:54:31 | rasher | Ah, it'll need to be changed to use the same menu functions as the rest of the plugin, I guess |
22:56:13 | J3TC- | sudoku_menu_cb is also undeclared |
22:56:14 | J3TC- | Hrmm |
22:56:28 | J3TC- | Let me go look at the run through and see if I can make sense with this |
22:57:53 | rasher | It should probably be a matter of mimicking the rest of the plugin |
23:00 |
23:00:02 | J3TC- | Hrmm, ok. Anyone know a command to just build the sudoku folder? |
23:00:02 | J3TC- | :3 |
23:00:30 | J3TC- | This computer is slow and takes like 10mins or so just to get to compiling the sudoku |
23:02:47 | | Nick parafin is now known as parafin|away (i=parafin@paraf.in) |
23:04:26 | | Quit sounddude (Read error: 104 (Connection reset by peer)) |
23:04:58 | J3TC- | Hrmm |
23:04:59 | J3TC- | That's odd |
23:05:19 | J3TC- | Menu_init is in the original sudoku.c |
23:05:24 | n1s | J3TC-: if you do a "make" it will only build what's changed |
23:05:26 | J3TC- | I wonder why it was crashing |
23:05:43 | rasher | n1s: given a slow enough computer and cygwin, that can still take ages |
23:05:43 | | Join Isolinear [0] (n=A@c-76-105-254-119.hsd1.or.comcast.net) |
23:05:49 | J3TC- | Ah cool |
23:06:56 | n1s | rasher: right, forgot it was _that_ slow, been years since I used it |
23:07:33 | n1s | J3TC-: in which case "make rocks" should be slightly faster (will only make plugins and maybe codecs) |
23:08:33 | | Join saratoga [0] (i=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-9e668ceb15790785) |
23:08:42 | J3TC- | Hrmm |
23:08:44 | J3TC- | That's odd |
23:08:48 | saratoga | looks like sandisk is about to refresh the e200 series: http://audible.custhelp.com/cgi-bin/audible.cfg/php/enduser/std_adp.php?p_faqid=3648&p_created=1192116189&p_sid=XU6j3AOi&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MiZwX3Byb2RzPTAmcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3NlYXJjaF90eXBlPWFuc3dlcnMuc2VhcmNoX25sJnBfcGFnZT0xJnBfc2VhcmNoX3RleHQ9ZTIwMA**&p_li=&p_topview=1 |
23:08:59 | J3TC- | Still crashes even though I did svn revert -R . |
23:08:59 | J3TC- | :3 |
23:09:20 | Zagor | saratoga: ah, so it's not a rumor |
23:10:20 | n1s | seems like a pure firmware upgrade though |
23:10:22 | saratoga | i wonder if they're ditching PP or just updating the design |
23:10:48 | saratoga | i don't think its just a firmware update, it'd be a little odd to stamp a new revision on the hardware if they're just patching the software |
23:10:57 | saratoga | though who knows |
23:12:00 | preglow | man, emac is so nice |
23:12:00 | Bagder | "I called Sansa and was told it will be a different player " |
23:12:01 | n1s | if they are still called e200 and the only major difference (to users) is support for another drm format my guess is on new firmware, they already did it with the rhapsody version... |
23:12:08 | Bagder | => http://forums.sandisk.com/sansa/board/message?board.id=e200&thread.id=3477&view=by_date_ascending&page=2 |
23:13:17 | rasher | Wasn't it also said (rumoured) that the v2 would support sdhc? |
23:13:27 | Bagder | yes |
23:13:29 | saratoga | hard to imagine it wouldn't |
23:13:38 | saratoga | sandisk is selling a lot of SDHC stuff |
23:13:50 | rasher | saratoga: it's also hard to imagine why the firmware updates don't |
23:13:55 | rasher | for the 1 |
23:14:06 | saratoga | they want you to buy the 16GB v2 they'll release eventually |
23:14:46 | rasher | Well yes. I still wonder why they didn't launch with sdhc support |
23:14:53 | saratoga | that or maybe they're just not updating the firmware for the e200 anymore, if you prefer lazy over greedy |
23:15:02 | *** | Saving seen data "./dancer.seen" |
23:16:07 | saratoga | the lack of a 16GB e290 is a bit odd anyway |
23:16:17 | saratoga | they 280 is so cheap now, you'd think they'd do something about that |
23:16:41 | | Quit saratoga ("CGI:IRC") |
23:19:57 | | Quit Tavnos () |
23:20:14 | | Join xregininflame [0] (i=48927114@gateway/web/cgi-irc/labb.contactor.se/x-9370de3a2b309f3b) |
23:20:22 | xregininflame | hey guys |
23:20:39 | xregininflame | i have a quick build question |
23:21:09 | Bagder | ask away |
23:21:17 | xregininflame | ok i just got subversion |
23:21:22 | xregininflame | im running it on windows xp |
23:21:30 | xregininflame | yes i read the wiki and manual and everything |
23:21:35 | xregininflame | and im confused |
23:21:51 | xregininflame | like how do i get the trunk of rockbox? |
23:21:53 | scorche|w | what are you trying to do? |
23:22:28 | xregininflame | right now i just wanna checkout the source code |
23:22:29 | scorche|w | are you just trying to get the source? compile? patch? |
23:22:32 | xregininflame | but i dont know how |
23:23:02 | xregininflame | just trying to get the source im working on getting an enviroment thats c friendly right now |
23:24:10 | scorche|w | the wiki suggests many ways of creating a dev environment...cygin, vmware, colinux, linux, etc |
23:24:18 | xregininflame | oh i know |
23:24:24 | scorche|w | if that is your end goal, you likely want to get that set up before getting the source |
23:24:44 | | Join saratoga [0] (i=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-b74e2a50b64286fe) |
23:25:04 | xregininflame | well is there a way to set up subversion so like all i have 2 do is click something and i get the source? |
23:25:11 | xregininflame | i have hte .net framework right now |
23:25:20 | scorche|w | you cant build rockbox with that |
23:25:21 | xregininflame | i dont like it too much but i can use it |
23:25:28 | xregininflame | .net? really |
23:25:33 | xregininflame | its c coding right? |
23:25:38 | | Quit Arathis ("Bye, bye") |
23:25:38 | scorche|w | rockbox isnt .net...it is C |
23:25:44 | | Join japc [0] (n=japc@bl7-241-88.dsl.telepac.pt) |
23:25:59 | xregininflame | right but the .net can compile c as well as c++ |
23:26:07 | scorche|w | if you want to compile, etc on windows, you need cygwin, vmware, or colinux |
23:26:09 | Zagor | xregininflame: not for arm it can't |
23:26:17 | xregininflame | ohh |
23:26:19 | xregininflame | ok |
23:26:21 | scorche|w | or m68k, or sh |
23:26:24 | | Quit jgarvey ("Leaving") |
23:26:27 | xregininflame | see im horribly new at this |
23:26:33 | xregininflame | sorry... |
23:26:45 | xregininflame | ill probably run colinux |
23:27:01 | scorche|w | any specific reason of choosing that? |
23:27:35 | scorche|w | i would recommend vmware, myself |
23:27:36 | | Quit MethoS- (Read error: 101 (Network is unreachable)) |
23:27:40 | xregininflame | umm i remebered the name |
23:27:40 | rasher | scorche|w: Why? |
23:27:41 | xregininflame | lol |
23:27:47 | xregininflame | vmware is better? |
23:27:59 | scorche|w | it is easier to set up than colinux |
23:28:06 | | Quit jhulst (Read error: 110 (Connection timed out)) |
23:28:07 | xregininflame | thats helpful |
23:28:12 | scorche|w | rasher: why what? |
23:28:28 | petur | or try virtualbox, it's lighter than vmware |
23:28:44 | saratoga | has NicoP said anything about the status of MOB? I'm wondering if he think it'll be committed to svn soon |
23:28:48 | xregininflame | i have to buy it?? |
23:28:54 | rasher | scorche|w: why vmware over colinux? I'd imagine colinux being slightly faster, and perhaps slighly better integrated into Windows, whereas vmware is just a closed box |
23:28:57 | scorche|w | buy what? |
23:29:07 | xregininflame | vmware |
23:29:10 | xregininflame | oh god |
23:29:15 | xregininflame | i didnt mean to start a debate.... |
23:29:17 | xregininflame | lol |
23:29:25 | saratoga | maybe you should just read the instructions |
23:29:25 | scorche|w | rasher: just for the easy to set up factor, which seems to be a bit important |
23:29:46 | scorche|w | xregininflame: vmware player or vmware server are both free and will work |
23:29:55 | scorche|w | but yes, please read the wiki page about it |
23:29:59 | xregininflame | ..oh ok |
23:30:11 | rasher | scorche|w: how about the other points? I've never used colinux myself.. perhaps I should try some time |
23:30:24 | xregininflame | ok so which is the better enviroment |
23:30:33 | rasher | xregininflame: go with vmware |
23:30:48 | xregininflame | ok |
23:30:57 | preglow | saratoga: it's getting there now |
23:31:13 | scorche|w | rasher: i havent used it myself either...i just know it is harder to set up, but is much easier on resource demands |
23:31:21 | xregininflame | should i get the sever or player |
23:31:35 | xregininflame | <−− blushes cause he is a complete noob.... |
23:31:39 | rasher | xregininflame: Player is simpler. |
23:31:47 | scorche|w | xregininflame: it doesnt matter...server has additional options which you probably wont need |
23:31:57 | saratoga | preglow: looking at the page theres only one bug outstanding, is that because its getting stable or because not many people have tested it? |
23:32:07 | | Quit Sedgewick ("Money can't buy happiness but it can provide a better class of enemy.") |
23:32:26 | preglow | saratoga: i wouldn't know, but i see nico_p working on it almost daily here now |
23:32:52 | preglow | saratoga: plus, i saw some comments indicating it is pretty stable now |
23:33:01 | xregininflame | ok im downloading the installer |
23:33:27 | xregininflame | ok so about using subversion |
23:33:31 | scorche|w | you dont need to update us :) |
23:33:42 | scorche|w | the wiki tells you how to use svn |
23:33:44 | Nico_P | preglow: yeah, it's very colose from being committable :) |
23:33:50 | xregininflame | i thought u might like to know scorche :) |
23:33:57 | scorche|w | Nico_P: dont jinx it ;) |
23:34:39 | scorche|w | xregininflame: http://www.rockbox.org/twiki/bin/view/Main/DocsIndex#For_Developers |
23:34:42 | pixelma | don't remind scorche|w... ;) |
23:34:49 | | Quit barrywardell (Read error: 110 (Connection timed out)) |
23:35:18 | saratoga | Nico_P: what do you need to do before it can be committed? |
23:35:26 | preglow | what samplerate does our voice files use, again? |
23:35:54 | Nico_P | saratoga: there are a fex issues left, like an USB connection bug I need to find a good solution for |
23:36:04 | xregininflame | yea im still at a loss.... |
23:36:07 | Nico_P | saratoga: apart from that it's mostly testing and cleanup |
23:36:18 | xregininflame | do i use if from the run command from windows? |
23:36:39 | scorche|w | no...you use it in the terminal of the vmware image when you get it set up |
23:36:47 | xregininflame | ahh |
23:37:01 | xregininflame | so svn runs parrell with vm |
23:37:09 | xregininflame | wow speelling sucks |
23:37:10 | xregininflame | lol |
23:37:18 | Nico_P | saratoga: you're welcome to have a look at the code ;) |
23:37:24 | scorche|w | no...it runs inside the vm....it is a program running inside the image |
23:37:30 | | Join Sedgewick [0] (n=Sedgewic@host99-233-dynamic.15-87-r.retail.telecomitalia.it) |
23:37:31 | xregininflame | ok |
23:38:04 | * | bluebrother wonders if it makes sense to /ignore lols |
23:38:06 | xregininflame | sorry im such an idot when it comes to this kind of stuff..ive never really dont it before :( |
23:38:19 | scorche|w | just dont keep reminding us you are l;) |
23:38:35 | xregininflame | ...love ya 2 man |
23:38:36 | | Quit iamben (Read error: 104 (Connection reset by peer)) |
23:38:41 | bluebrother | scorche|w: but we might forget about it ... *g* |
23:38:47 | xregininflame | totally not in the sexual way.... |
23:39:04 | xregininflame | :) |
23:39:08 | saratoga | ugh stop posting |
23:39:24 | xregininflame | sorry.. |
23:39:29 | scorche|w | xregininflame: have you, by chance, read the IRC guidelines linked in the topic? |
23:39:56 | | Quit Frazz (Read error: 110 (Connection timed out)) |
23:40:16 | | Quit jhMikeS (Nick collision from services.) |
23:40:22 | | Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) |
23:40:37 | xregininflame | yes |
23:40:37 | xregininflame | oh |
23:40:37 | xregininflame | whoops |
23:40:37 | DBUG | Enqueued KICK xregininflame |
23:40:37 | xregininflame | ill be quite now |
23:40:49 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
23:40:49 | * | bluebrother is annoyed by his upcoming relocation |
23:40:54 | preglow | hrmph, big hunk of asm: 215% -> 225% for uwb file :/// |
23:41:45 | saratoga | we really need to figure out what broke codec profiling |
23:41:52 | saratoga | it would be useful for this sort of thing |
23:42:44 | preglow | so it is broken? |
23:42:47 | xregininflame | thanks guys |
23:42:50 | xregininflame | for the help |
23:43:54 | | Quit xregininflame ("CGI:IRC (EOF)") |
23:44:18 | saratoga | preglow: at least I can't get it to work and no one seems to have tried it recently |
23:44:26 | saratoga | the last time i did it was sept 2006 |
23:44:34 | preglow | it never worked on arm, i think |
23:44:45 | saratoga | it worked on the pp5002 |
23:44:52 | preglow | hmm, ok |
23:45:10 | saratoga | though there perl script never worked so it was impossible to make sense of the results |
23:45:31 | saratoga | i started fixing it a while back but gave up when i realized profiling itself wasn't working |
23:45:44 | saratoga | though maybe i'm just doing something wrong |
23:45:55 | preglow | 884% -> 937% (nb), 401% -> 423% (wb). i guess at least it's worth commiting |
23:48:35 | amiconn | What target is that? |
23:48:39 | preglow | amiconn: coldfire |
23:48:41 | n1s | saratoga: I ran a profiling build on my h300 maybe 2 months ago and it created output and all but the script seemed to have trouble so it couldn't match any symbols to the addresses which made the output less than usefull |
23:48:42 | rasher | Would nb be acceptable for voicefiles? |
23:48:49 | preglow | rasher: i would seriously want wb |
23:49:04 | rasher | Still slower than mp3 then |
23:49:10 | rasher | or at least not faster |
23:49:24 | preglow | there are a couple of places here that will want some more asm |
23:49:28 | preglow | i think i'll hack qmf_filter next |
23:49:40 | rasher | Hrm.. now I got duplicate entries in Database |
23:49:41 | preglow | rasher: these are pretty high quality files, though |
23:50:02 | rasher | preglow: so are the files used on the codec testing page for mp3 |
23:50:19 | amiconn | preglow: Do you happen to know whether the penalty for unaligned memory accesses also applies to mac with parallel load from iram? |
23:50:19 | preglow | amiconn: i managed to fit the entire mem[] array in registers (evem for order 10), so i expected better performance than this |
23:50:31 | amiconn | I would think it does, but I'm not sure... |
23:50:35 | preglow | amiconn: well, i would certainly expect it to |
23:50:58 | amiconn | That means it might be possible to get ape -c3000 usable on coldfire then |
23:51:22 | saratoga | n1s: thanks, maybe its just me then, i'll try it again on arm and see if i can get output |
23:51:25 | preglow | i would be surprised if the parallel load was unaffected by alignment |
23:52:03 | amiconn | That is, if the penalty for fetching word-word instead of longword is really 2 cycles, sclarproduct() takes almost twice as long as it could in 75% of all cases |
23:52:29 | n1s | saratoga: the only other problem I had was that ggc ICEs on anything compiled with O3 with profiling enabled but that is probably a gcc 3.4.6 bug |
23:54:10 | preglow | amiconn: could you have a quick look and tell me if i'm doing something obviously stupid? http://www.pvv.org/~thomj/rockbox/filters_cf.S |
23:54:12 | amiconn | And I found that it's possible to fetch values into one of the registers currently processed in the mac instruction |
23:54:23 | preglow | amiconn: yeah, i've been doing that for ages :) |
23:54:29 | preglow | i even do it in this .S file, heh |
23:54:38 | saratoga | hurray for pipelining |
23:54:41 | amiconn | That allows me to give one register back for gcc to play with |
23:55:02 | amiconn | I can also give back one register in the vector add / sub functions |
23:55:25 | saratoga | i want an arm target with EMAC or something similar |
23:55:38 | preglow | i THINK i can squeeze the den array into registers too, for .order_8, but not .order_10 |
23:55:38 | saratoga | beating gcc in plain armv4 is harder then i like |
23:55:53 | preglow | saratoga: yeah, it's slightly easier for coldfire |
23:57:36 | | Join safetydan [0] (i=dc9d468b@rockbox/developer/safetydan) |