| 00:01:50 | amiconn | Bagder: The MEMORYSIZE selection isn't included in the simulator makefiles :( |
| 00:02:46 | Bagder | want me to fix? |
| 00:02:57 | amiconn | Yes please, if possible. |
| 00:03:11 | amiconn | I need this for making the size in buffer.c variable |
| 00:04:25 | Bagder | done |
| 00:05:10 | amiconn | :) |
| 00:05:30 | amiconn | I guess I need to reconfigure? |
| 00:06:02 | Bagder | yes |
| 00:10:29 | HCl | whatcha working on? |
| 00:10:31 | HCl | *curious* |
| 00:11:39 | amiconn | HCl: Making the simulator mp3 buffer size variable, for building rockboy... |
| 00:12:03 | amiconn | (well, not only) |
| 00:20:50 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 00:20:54 | amiconn | Bagder: Rockbox info -> Buffer: 1.676 MB :) |
| 00:21:06 | Bagder | neat |
| 00:21:21 | amiconn | Trying the same with iRiver sim... |
| 00:23:51 | HCl | ok :) |
| 00:26:03 | Bagder | time for sleep here, have fun! |
| 00:26:06 | amiconn | Bagder: I get a strange effect: |
| 00:26:14 | Bagder | what? |
| 00:26:36 | amiconn | I added -DMEM=${MEMORYSIZE} to the DEFINES in both X11 and Win32 sim makefile |
| 00:26:49 | amiconn | While this works for X11, it doesn't for Win32 |
| 00:27:02 | amiconn | I get a parse error in plugin.c line 501 |
| 00:28:08 | amiconn | Hmm, it's not the Win32 sim, but the iRiver sims |
| 00:28:25 | amiconn | Is MEMORYSIZE unset in the iRiver makefiles? |
| 00:28:46 | Bagder | no |
| 00:28:51 | Bagder | export MEMORYSIZE=32 |
| 00:28:59 | amiconn | Ah, I'm silly.... |
| 00:29:04 | amiconn | Didn't reconfigure... |
| 00:29:09 | Bagder | ah |
| 00:29:16 | amiconn | Nite Bagder |
| 00:29:21 | Bagder | gnight |
| 00:30:58 | XShocK | night |
| 00:31:44 | amiconn | Funny: Buffer: -9.-283MB |
| 00:31:56 | linuxstb | FLAC decoding is working in the simulator, but I think it's crashing on the target. |
| 00:34:01 | HCl | how big are flac files in general? |
| 00:34:05 | HCl | like, the music files |
| 00:34:12 | gromit` | <−−−−−−−−- like this −−−−−−−−−−−−−−> |
| 00:34:17 | gromit` | (sorry) |
| 00:34:37 | sneakums | about 50% of the wav, i found in a brief test |
| 00:35:20 | preglow | ahh, i notice how terribly unfamiliar i am with inline asm in gcc |
| 00:35:31 | HCl | sneakums: ok. |
| 00:36:17 | linuxstb | In reality about 60% of a WAV. But obviously, they sound identical. |
| 00:36:20 | preglow | would anyone happen to know how to format a mac instruction in inline asm? :P |
| 00:37:31 | XShocK | about FLAC files. wouldn't it be not really reliable to play them in player? i mean batteries will be dead very quickly |
| 00:37:51 | XShocK | i mean discharged, not dead |
| 00:38:05 | preglow | weell, you can pump quite a few hours out of it |
| 00:38:06 | sneakums | it'd use more battery, but i don't see a reliability problem as such |
| 00:40:21 | linuxstb | But FLAC may even be lighter on a CPU than MP3 or OGG - we don't know that yet. |
| 00:40:34 | HCl | mhm. |
| 00:40:49 | linuxstb | But I agree, it's probably not the most efficient format. |
| 00:41:40 | lImbus | depends on what is wanted, I think. battery life is the price to pay for that quality |
| 00:42:25 | amiconn | Whee, Buffer: 31.679 MB |
| 00:42:37 | lImbus | and I doubt the iRiver analog-hardware is of such high quality that one can hear the difference between any of the other codecs (with decend bitrate of course) and FLAC |
| 00:42:45 | lImbus | amiconn: congratz :-) |
| 00:43:21 | linuxstb | lImbus: Don't forget the digital output... |
| 00:43:31 | lImbus | of course |
| 00:43:38 | amiconn | @iRiver owners: What does Info->Rockbox info currently tell you about the buffer size? |
| 00:43:42 | lImbus | that's why I added the word "analog" |
| 00:44:06 | linuxstb | lImbis: sorry :-). |
| 00:44:28 | lImbus | linuxstb: the iRiver after all is a portable music player. I don't know of any digital-input headphones :-9 |
| 00:45:33 | XShocK | -9..... |
| 00:45:36 | lImbus | and battery life does not matter if you are stationary with a high-quality digital equipment |
| 00:46:11 | amiconn | XShocK: It will soon be fixed in cvs :) |
| 00:46:23 | XShocK | :) |
| 00:46:46 | amiconn | (It's a simple overflow btw, calculating the "true" MB from the # of bytes) |
| 00:46:47 | preglow | i'd guess the decoding itself is pretty light compared to the mdct based formats |
| 00:47:02 | linuxstb | I agree that I probably couldn't tell the difference between a well-encoded MP3 or OGG and FLAC on the iRiver, but I just prefer to keep my collection in one format, and not go to the effort of evaluating lossy codecs. At least with FLAC I can be 100% I am getting the best out of the hardware. |
| 00:47:04 | preglow | everything is time domain in flac |
| 00:47:37 | lImbus | linuxstb: Full ACK. |
| 00:47:49 | lImbus | this is the advantage of having portable flac. |
| 00:48:08 | lImbus | otherwise the compression ratio would kill any argument as well |
| 00:49:51 | linuxstb | amiconn: Buffer: -10, -298MB |
| 00:52:50 | amiconn | linuxstb: I couldn't fit my entire music collection on the largest capacity iRiver in FLAC format, while I can do so in MP3. That's a kiler argument for me. |
| 00:53:24 | DMJC-L | all my cds are ripped as ogg at 6.5 quality |
| 00:53:25 | *** | Saving seen data "./dancer.seen" |
| 00:53:25 | | Join bagawk [0] (~Lee@bagawk.user) |
| 00:53:31 | DMJC-L | I'm not redoing em, nuff said |
| 00:53:54 | linuxstb | That's going to be the great thing about Rockbox on the iRiver - everyone will be happy :-) |
| 00:54:22 | amiconn | I have pretty much everything as MP3 (guess why!), and some OGGs |
| 00:56:03 | HCl | i have everything as mp3 |
| 00:56:12 | HCl | but i want rockbox to be as compatible as possible |
| 00:56:58 | | Quit Hohoman ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 00:57:24 | linuxstb | I think I've said it before, but the "big three" codecs in my mine are MP3 (and MP2 for my digital radio recordings), OGG and FLAC. Unless someone else gets there first, I'm going to be working on those. |
| 00:57:34 | linuxstb | *my mind |
| 00:58:17 | amiconn | XShocK, linuxstb: Fix for buffer display committed. |
| 00:58:40 | | Quit jyp ("poof!") |
| 00:58:54 | lImbus | amiconn: I can't fit my music-collection in mp3 on any avaiable hdd-hard disk :-| |
| 00:59:02 | lImbus | bagawk: Hi lee |
| 00:59:11 | bagawk | lImbus, hey |
| 00:59:13 | lImbus | intrested in pictures of the cf-hdd-adapter ? |
| 00:59:20 | XShocK | ok. rebuilding |
| 00:59:30 | amiconn | lImbus: Really? I have an 80 GB disk in my archos... |
| 00:59:38 | XShocK | isn't the CF already ata compatible? |
| 00:59:53 | lImbus | bagawk: I did not find it, so I could not scan it, but I still have a picture (photo) of it |
| 01:00 |
| 01:00:15 | sneakums | my vorbis collection is 6200 files at q2, fits nicely in my iriver |
| 01:00:31 | bagawk | lImbus, OK I might go out and get parts to make one, if i get school work done (which I have a lot fo...) |
| 01:00:32 | lImbus | amiconn: I got about 160 GB. I admit, there a part of it I virtually never listen to. |
| 01:00:46 | amiconn | Okkkayyy.... |
| 01:00:52 | bagawk | Wow |
| 01:00:56 | lImbus | :-)) |
| 01:00:57 | bagawk | My HD is 160gb |
| 01:01:10 | sneakums | my biggest disk is 80GB, and it has 40G free |
| 01:01:12 | bagawk | What format/quality? |
| 01:01:44 | amiconn | Too bad that anything about 128 GB (137 GB in "manufacturer gigabytes") won't work in either mobile player... |
| 01:01:52 | amiconn | s/about/above/ |
| 01:01:53 | linuxstb | amiconn: info->rockbox info now showing a buffersize of 30.664MB (I have a 1MB plugin area configured). |
| 01:02:07 | lImbus | quality is mp3 vbr min 192 max 360 or what the real max is |
| 01:02:20 | amiconn | MP3 max is 320 kbps |
| 01:02:42 | lImbus | bagawk: it's not worth the work of getting the parts and soldering the hdd-cf-adpater yourself. I got one cheapo at ebay (about 10 euro) |
| 01:02:51 | | Quit bagawk ("Leaving") |
| 01:03:15 | lImbus | ug. I hope he saw that one before going out and spending that money |
| 01:03:37 | XShocK | amiconn: now it shows Buffer: 21.632MB |
| 01:03:42 | XShocK | 31.632 |
| 01:03:52 | amiconn | As it should be... |
| 01:04:30 | lImbus | amiconn: I still cannot build a Gmini or iRiver Sim, not even on a completely new installed BlueChip-cygwin |
| 01:04:58 | amiconn | Hmm, strange |
| 01:05:02 | lImbus | just for info as you all had some problems these days getting sim building |
| 01:05:11 | lImbus | the problem existed before, and still does |
| 01:05:35 | amiconn | I only had problems building the iriver sim. I fixed that issue. |
| 01:06:01 | amiconn | If you update to current cvs, you need to reconfigure all your sim build directories |
| 01:06:08 | lImbus | it sounds very simple: while compiling apps/recoder/widgets.c, the include file limits.h cannot be found, thus the symbol MAX_INT is not found and blablabla |
| 01:06:43 | lImbus | I installed a new cygwin (BlueChip style), cvs checkout, build tools, configured new build directory, build, daaang |
| 01:07:07 | amiconn | *when* did you checkout exactly? |
| 01:07:25 | amiconn | There was a problem (jyp caused it, jyp fixed it) for a while |
| 01:07:28 | lImbus | mhmm. it was either yesterday in the late evening or today |
| 01:08:31 | Ctcp | Ignored 2 channel CTCP requests in 1 minute and 2 seconds at the last flood |
| 01:08:31 | * | lImbus is doing cvs update and tools-build and reconfigure and all that on his existing build environment |
| 01:08:38 | lImbus | again... |
| 01:08:48 | lImbus | (win32 sim that is) |
| 01:09:50 | XShocK | win32 sim does not build. error on buffer.c:23 :) |
| 01:10:26 | lImbus | I'm tempted to delete the include instruction and replace the MAX_INT by (unsigned) -1 |
| 01:10:37 | amiconn | XShocK: You need to reconfigure |
| 01:11:44 | lImbus | uh. even more strange. I think it's worth a multiline-paste. BRACE ! |
| 01:11:50 | XShocK | amiconn: just reconfigured, the smae error. |
| 01:11:52 | amiconn | lImbus: Works just fine here. Checkout again, reconfigure and retry |
| 01:12:07 | lImbus | CC ../../apps/settings.c |
| 01:12:07 | lImbus | ../../apps/settings.c:23:20: limits.h: No such file or directory |
| 01:12:07 | lImbus | ../../apps/settings.c: In function `set_int': |
| 01:12:07 | DBUG | Enqueued KICK lImbus |
| 01:12:07 | lImbus | ../../apps/settings.c:1338: error: `INT_MAX' undeclared (first use in this funct |
| 01:12:07 | lImbus | ion) |
| 01:12:08 | *** | Alert Mode level 1 |
| 01:12:08 | lImbus | ../../apps/settings.c:1338: error: (Each undeclared identifier is reported only |
| 01:12:10 | lImbus | once |
| 01:12:12 | lImbus | ../../apps/settings.c:1338: error: for each function it appears in.) |
| 01:12:14 | lImbus | make[1]: *** [/home/guest/GminiSim/settings.o] Error 1 |
| 01:12:16 | lImbus | make[1]: Leaving directory `/home/guest/uisimulator/win32' |
| 01:12:18 | lImbus | make: *** [sim] Error 2 |
| 01:12:38 | lImbus | I SWEAR it was on widget.c before. |
| 01:13:24 | lImbus | amiconn: I really updated and reconfigured (I created a new build directory GminiSim7th |
| 01:14:30 | amiconn | Now that is strange. I have no idea what's going on then. I'm using pretty much up to date cygwin and it works... |
| 01:14:52 | amiconn | Official builds are fine as well.... |
| 01:15:32 | XShocK | hmm. where MEM is declared? |
| 01:15:50 | lImbus | official sim builds ? going to download it... |
| 01:15:51 | amiconn | It's declared in the Makefile generated by configure (now) |
| 01:16:01 | amiconn | That's why you need to reconfigure |
| 01:16:24 | amiconn | ...and before rebuilding, probably need to 'make clean' |
| 01:16:43 | | Join jyp [0] (~jp@98.203-200-80.adsl.skynet.be) |
| 01:16:51 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 01:17:08 | HCl | hey linus |
| 01:17:12 | LinusN | ho |
| 01:17:18 | preglow | LinusN: i've got a bug for you |
| 01:17:28 | LinusN | now nice, just what i needed |
| 01:17:31 | preglow | :-) |
| 01:17:38 | amiconn | hi LinusN |
| 01:17:45 | LinusN | hi amiconn |
| 01:18:43 | XShocK | hi Linus |
| 01:19:09 | lImbus | hi Linus |
| 01:19:40 | preglow | i hate to interrupt the greet list, but the bug is as follows: plug in usb, start rockbox, now stop rockbox, and behold, it never shuts off |
| 01:19:47 | HCl | yea |
| 01:19:50 | HCl | it doesn't shut off |
| 01:19:51 | preglow | insert 'plug out usb' some place in there |
| 01:19:52 | HCl | till you remove usb |
| 01:20:00 | preglow | it doesn't shut off then either |
| 01:20:04 | HCl | it did for me o.o |
| 01:20:06 | HCl | hm. |
| 01:20:08 | amiconn | One needs to be careful with <tab> completion these days... There are now 3 nicks starting with 'li' |
| 01:20:25 | LinusN | preglow: will have a look |
| 01:20:33 | XShocK | amiconn: sorry, just deleted everything and checked out again, everything worked |
| 01:20:42 | preglow | LinusN: no worries, i don't think this is something people do often |
| 01:21:05 | lImbus | XShocK: If I could only pretend this. |
| 01:21:27 | lImbus | amiconn: are there official sim builds to download, or did I misunderstand you ? |
| 01:21:29 | | Quit jyp ("poof!") |
| 01:22:09 | *** | Alert Mode OFF |
| 01:22:22 | amiconn | lImbus: Afaik you can't download them (and Win32 builds are only done for player and recorder), but the automated builds are doing them, so one can see whether something is broken |
| 01:22:24 | LinusN | ok, i found the bug |
| 01:22:40 | amiconn | LinusN: That was fast :) |
| 01:22:49 | LinusN | i knew where to look |
| 01:23:02 | LinusN | and it isn't very easy to fix... |
| 01:23:26 | preglow | i apologize :/ |
| 01:23:31 | amiconn | LinusN: If I would go getting a H3xx, I would surely run into problems. I don't have a wiggler... |
| 01:23:43 | preglow | LinusN: so this is an archos problem as well? |
| 01:24:00 | LinusN | preglow: not really, archos handles it a little differently |
| 01:24:31 | lImbus | amiconn: absolutely. I suppose it has to do with the resting environment. cygwin, env$, microsoft-devstudio installed on the same machine... |
| 01:25:12 | preglow | LinusN: on a positive note, it seems binutils support the mac/emac extensions |
| 01:25:20 | LinusN | yes it does |
| 01:25:36 | amiconn | preglow: No problem on archos |
| 01:25:58 | preglow | i am yet to discover their syntaxes, but i'll probably arrive at the solution given a day or three of intense study |
| 01:26:10 | LinusN | preglow: my first patch to the binutils project concerned the emac |
| 01:26:28 | preglow | that's right, i think i remember reading about that |
| 01:26:31 | LinusN | preglow: there are example source codes on the motorola site |
| 01:26:40 | preglow | then that's where i'll turn my attention, heh |
| 01:27:17 | LinusN | http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SCF5249 |
| 01:28:09 | preglow | i don't seem to have to do anything by myself today ;) thanks |
| 01:30:28 | LinusN | hmm, the bug i found wasn't a bug after all... :-) |
| 01:31:09 | preglow | ahh, it's a feature? :P |
| 01:31:54 | LinusN | but i think i found "your" bug |
| 01:32:56 | LinusN | fix committed |
| 01:34:45 | | Quit mecraw () |
| 01:38:57 | LinusN | time to sleep, nit guys |
| 01:39:11 | | Part LinusN |
| 01:44:06 | | Join etienne [0] (~fezzzz@S01060080c8abf427.cg.shawcable.net) |
| 01:44:25 | lImbus | salut |
| 01:44:58 | etienne | anybody have an idea why my power adapter overheats? (fm recorder) |
| 01:45:17 | etienne | i also managed to fry my roomate's power adapter for his archos |
| 01:47:43 | lImbus | uhh. |
| 01:48:20 | lImbus | there are not much of those techies in here atm. are you able to measure the power drain ? |
| 01:48:52 | etienne | nope, i have no idea how to do that |
| 01:49:09 | lImbus | do you own a multimeter ? |
| 01:49:19 | etienne | yes i do |
| 01:49:45 | etienne | how do i do it |
| 01:49:46 | lImbus | did you ever do anything by setting it to the DC-A -mode |
| 01:50:38 | etienne | no...i tried looking through the menus for some settings |
| 01:50:43 | amiconn | Hehe, snow on the player... |
| 01:50:46 | etienne | but i could only find the battery capacity setting |
| 01:50:55 | lImbus | amiconn: crazy guy :-) |
| 01:51:05 | etienne | amiconn....i won't mind using it for snowboarding tomorrow actually :) |
| 01:51:58 | lImbus | etienne: the fmrecorder has charging control in hardware, I don't think there is a lot to see and configure in rockbox |
| 01:52:12 | etienne | damn |
| 01:52:51 | etienne | no quick fix i guess then |
| 01:53:08 | etienne | what will draining measurement tell me? |
| 01:53:23 | amiconn | etienne: No offense, but check the following: (1) Do you have the correct adapter? What parameters does it tell you? (2) Is it for the correct mains voltage? |
| 01:54:02 | etienne | no offense taken. |
| 01:54:27 | etienne | The thing is, my roomate have the exact same model and because my adapter (9v 700mA) overheated i borrowed his |
| 01:54:39 | lImbus | a |
| 01:54:41 | etienne | and ended up buring it out |
| 01:54:54 | amiconn | The fm/v2 adapter should be 6 V / 700 mA ... |
| 01:54:55 | etienne | so he borrowed mine...and it didn't overheat and work fine for him |
| 01:54:58 | lImbus | etienne: the measurment would tell you the current that flows |
| 01:55:18 | etienne | amiconn, the one that burnt out was 6v/700mA |
| 01:55:33 | etienne | but apparently you can go up to 12v....10 v being desired |
| 01:55:50 | amiconn | Nope, not for the v2/fm |
| 01:55:51 | lImbus | nononoooo. that's not v2 |
| 01:55:52 | amiconn | The 9V adapters are for the V1 and the player |
| 01:56:09 | etienne | i see |
| 01:56:16 | etienne | so the 9v is too high for it? |
| 01:56:18 | lImbus | damn. I just thought half an hour ago that we should clarify this in the battery and charging faq |
| 01:56:31 | lImbus | yes, it is |
| 01:56:52 | lImbus | in my humble opinion, this should still not fry the charger |
| 01:57:10 | etienne | and it doesn't charge by USb either does it (looks on the screen like it does...but doesn't tend to keep a charge long" |
| 01:57:24 | lImbus | it "should" fry the archos, as far as I understood electronics |
| 01:57:54 | etienne | i'm glad the adapter fried and not the archos then....but it makes me wonder why the 6v adapter died |
| 01:58:20 | DMJC | safety mechanism blew perhaps? |
| 01:58:36 | amiconn | Charging via usb will take rather long, because the current is lower. And the doesn't hold-charge-long problem may be the battery contacts |
| 01:59:05 | amiconn | This is *not* the same problem as the v1/player battery contacts. |
| 01:59:22 | etienne | i just tried opening it and it looks like i need to solder to get to the battery (the rockbox website only have dissasembly photos for different models) |
| 01:59:52 | amiconn | I don't know there very details, as I don't own a fm or v2 |
| 02:00 |
| 02:00:01 | etienne | ok |
| 02:00:17 | etienne | i hate getting haused by ebay sellers *sigh* |
| 02:00:19 | lImbus | me neither |
| 02:00:43 | amiconn | etienne: eBay? Okay, I ask again: What mains voltage the 6V charger is for? |
| 02:00:52 | lImbus | lol |
| 02:00:58 | lImbus | I thought about it for a moment |
| 02:01:04 | amiconn | Plus, what is the actual mains voltage where you live? |
| 02:01:05 | etienne | it is for 110 |
| 02:01:20 | etienne | it worked fine on my room mates archos, which is exactly the same as mine |
| 02:02:02 | amiconn | Hmm, strange. As you told he has a 9V charger, I thought he would have a v1 recorder or a player |
| 02:02:04 | etienne | actually, both worked for him, and neither for me |
| 02:02:24 | etienne | no, i got the 9v charger with mine.....baught it over ebay |
| 02:02:46 | etienne | my charger (9v) is a lot bigger than his(the real archos 6v charger) |
| 02:03:02 | etienne | mine is a 9v 600mA |
| 02:03:11 | lImbus | oh, so you bought a archos device with a universal power supply |
| 02:03:34 | amiconn | etienne: The 9V 600mA charger is the one for rec. v1/ player |
| 02:03:51 | lImbus | amiconn: should it overheat ? |
| 02:03:56 | etienne | its not universal, no settings on it and such and only one plug that fits the thing perfectly....won't be surprised if it came with the archos |
| 02:04:25 | lImbus | and why died the other one, if it was the original delivered with another fmrecorder ? |
| 02:04:36 | | Join iSheep [0] (~a@dpc691997050.direcpc.com) |
| 02:04:48 | amiconn | lImbus: No it shouldn't. But as the 6V charger overheated as well, I suspect a problem with the box. Perhaps a short circuit in the socket. |
| 02:05:15 | amiconn | Plus the box came with the wrong charger... |
| 02:05:31 | etienne | are all fm recorders V2? |
| 02:06:00 | etienne | because this one is definitely fm recorder, doesn't say much else "Jukebox FM Recorder" |
| 02:06:05 | amiconn | The fm and v2 recorders are the same hw design (LiIon battery), only the v2 doesn't have a radio |
| 02:06:06 | lImbus | all recorders having a radio are version2 recorders, yes. |
| 02:06:17 | etienne | ok |
| 02:06:29 | amiconn | The v1 recorders and player have AA size NiMH batteries |
| 02:07:42 | iSheep | Anyone familiar with the FM Recorder and issues with the headphone jack? |
| 02:07:47 | | Quit preglow ("and thusly") |
| 02:08:22 | lImbus | etienne: see http://www.rockbox.org/docs/devicechart.html |
| 02:09:45 | etienne | i see what you mean about the charger spec |
| 02:09:56 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 02:09:56 | * | lImbus nods |
| 02:10:59 | etienne | i wonder if having dead batterys can cause the charger to overheat? |
| 02:11:22 | etienne | it just never charges enough/constant drain.....i'm speculating here :) |
| 02:12:31 | etienne | anyways....thanks for the help guys |
| 02:12:42 | etienne | and ladies...possibly |
| 02:12:52 | etienne | at least i now know not to use the 9v one |
| 02:12:56 | etienne | cheers |
| 02:13:07 | | Quit etienne () |
| 02:14:08 | amiconn | Eeeek! CPUAdrErr in snow.rock |
| 02:14:19 | iSheep | I'm having a problem with no audio on my Jukebox. Coincidentally, the LCD screen recently died, so I'm in bad shape. I think the audio is not working, because I think I'm blindly getting a song playing when Rockbox starts up and would (presumably) ask if I want to resume playback |
| 02:16:40 | lImbus | mhmm. that sounds hard to check, iSheep |
| 02:16:59 | iSheep | Yeah... not a good combo :( |
| 02:17:29 | iSheep | But I'm almost positive a song would be playing, because if I press the right button, the hard drive light flickers as if it were switching songs |
| 02:18:45 | iSheep | For a little bit after the screen died, the audio was still working. I could play a song blindly. But now, for some reason, I can't seem to do that |
| 02:20:05 | lImbus | mhmm. having a broken screen should be no big problem with rockbox, as you're still having voice-feedback like many blind users. but NOT having audio renders a music player somehwat userless |
| 02:20:25 | lImbus | it's still a battery powered external hard drive though |
| 02:21:10 | iSheep | right. well, what I'm trying to decide is if I should buy a new LCD screen so I can see what's going on |
| 02:21:10 | iSheep | I don't understand how the audio could just go out like that |
| 02:21:29 | lImbus | if it's just the connector that's broken, that should be fixeable cheaper |
| 02:21:36 | | Quit iSheep (Read error: 104 (Connection reset by peer)) |
| 02:23:32 | lImbus | poof |
| 02:24:42 | | Join iSheep [0] (~a@dpc691997050.direcpc.com) |
| 02:24:50 | iSheep | Sorry about that |
| 02:24:52 | DMJC | lol |
| 02:24:56 | DMJC | he didn't even see it |
| 02:25:07 | iSheep | Internet woes. :) What did I miss? |
| 02:25:20 | DMJC | nothing worth seeing |
| 02:25:32 | iSheep | oh ok |
| 02:26:13 | iSheep | well, anyone with any ideas on where I should go from here? I could go buy a new screen, but I would hate to do that if I'll never have sound anyway. or is there a way to fix the sound? |
| 02:26:16 | lImbus | wb iSheep :-) |
| 02:26:26 | iSheep | thanks |
| 02:27:07 | lImbus | well, if you feel handy to open the box (or a friend of you), do it, and look what's wrong with the audio connector |
| 02:27:21 | lImbus | these wore out from time to times |
| 02:27:41 | | Quit edx (Read error: 110 (Connection timed out)) |
| 02:27:53 | iSheep | yeah, actually I have the thing opened and totally taken apart, really |
| 02:28:01 | iSheep | I just don't know what to look for, because things seem to be okay |
| 02:28:16 | lImbus | first you should try if you can't fix it (at least some rumble and crackle) by turning and shifting/pushing the headphone-plug softly |
| 02:28:26 | lImbus | ok |
| 02:28:51 | iSheep | I tried that while I *think* I was listening to a song. I didn't hear anything at all in the headphones |
| 02:28:52 | lImbus | it may be very very tiny cracks in the soldering joint of the headphone jack |
| 02:28:54 | iSheep | woops |
| 02:29:31 | iSheep | would that be near where the green and yellow wires connect? |
| 02:29:40 | lImbus | please have a look at the wiki (or the mailinglist-archive), iirc, there is a article about such a problem |
| 02:30:13 | lImbus | I dunno, I never saw a fm recorder |
| 02:30:28 | iSheep | yeah, I'll check it out. should I just search the wiki? |
| 02:30:42 | lImbus | try to, as well as the mailinglistarchive. |
| 02:30:56 | lImbus | i have to go to bed now anyways |
| 02:31:16 | iSheep | all right. well, thanks for the lead. I appreciate it |
| 02:31:18 | lImbus | iirc, somebody documented his replacment work of a damaged socket |
| 02:31:34 | lImbus | that's all included in rockbox :-) you're welcome, anytime |
| 02:31:45 | iSheep | have a good one |
| 02:31:57 | lImbus | tnx |
| 02:32:04 | | Quit linuxstb (Read error: 60 (Operation timed out)) |
| 02:32:20 | lImbus | good luck while searching. start with the docsindex maybe |
| 02:32:36 | iSheep | ok, will do |
| 02:32:45 | * | lImbus is detaching from computer-related stuff |
| 02:32:49 | lImbus | will go to bed now |
| 02:32:57 | lImbus | bood nite #rockbox |
| 02:32:57 | iSheep | All righty. See ya later |
| 02:33:20 | lImbus | yeah, see ya. hope to see that I was right :-) |
| 02:33:37 | iSheep | same here! |
| 02:33:56 | | Quit lImbus ("initiating bed-mount sequence") |
| 02:34:55 | HCl | HCl->sleep(); |
| 02:35:12 | HCl | night |
| 02:47:00 | | Quit _aLF ("Leaving") |
| 02:53:29 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:03:41 | | Quit amiconn (" while(night) amiconn.sleep();"") |
| 03:03:46 | | Quit iSheep (Read error: 54 (Connection reset by peer)) |
| 03:25:47 | | Join ashridah [0] (ashridah@220-253-118-46.VIC.netspace.net.au) |
| 03:32:02 | | Quit XShocK (Read error: 104 (Connection reset by peer)) |
| 03:33:37 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 03:43:42 | | Quit jpburton5150 (Read error: 110 (Connection timed out)) |
| 03:47:32 | | Part CrunchyWhiteMeat |
| 03:50:09 | | Join coob [0] (pen0r@82-44-227-205.cable.ubr11.haye.blueyonder.co.uk) |
| 04:00 |
| 04:00:19 | | Quit Cassandra_ (Read error: 60 (Operation timed out)) |
| 04:06:11 | | Join QT_ [0] (as@area51.users.madwifi) |
| 04:08:34 | | Join edx [0] (edx@pD9EAA5E3.dip.t-dialin.net) |
| 04:09:01 | | Join Cassandra_ [0] (~christi@213.78.160.83) |
| 04:09:59 | | Quit cYmen ("leaving") |
| 04:16:01 | | Quit QT (Read error: 110 (Connection timed out)) |
| 04:53:33 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:20:34 | | Join jpburton5150 [0] (knoppix@cpe-24-94-54-216.stny.res.rr.com) |
| 06:00 |
| 06:41:23 | | Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) |
| 06:42:01 | | Quit midk (Client Quit) |
| 06:49:55 | | Quit jpburton5150 (Read error: 60 (Operation timed out)) |
| 06:51:02 | | Part hubble |
| 06:53:36 | *** | Saving seen data "./dancer.seen" |
| 06:59:29 | | Quit Taxi|3 (Read error: 110 (Connection timed out)) |
| 07:00 |
| 07:16:38 | | Join webguest52 [0] (~18090074@labb.contactor.se) |
| 07:17:54 | webguest52 | anyone willing to answer a qestion about flashing a daily build on recorder? |
| 07:19:27 | | Join pcngss [0] (~avedsdf@c-24-9-0-116.client.comcast.net) |
| 07:20:34 | pcngss | ? |
| 07:20:45 | | Join Shulberry [0] (Taxi@oslo-dhcp-248-180.bluecom.no) |
| 07:21:39 | | Quit pcngss (Client Quit) |
| 07:21:53 | | Quit webguest52 ("CGI:IRC (EOF)") |
| 08:00 |
| 08:40:04 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 08:48:37 | | Quit Shulberry (Read error: 60 (Operation timed out)) |
| 08:53:38 | *** | Saving seen data "./dancer.seen" |
| 08:53:56 | | Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) |
| 08:56:56 | | Quit XShocK (Read error: 104 (Connection reset by peer)) |
| 08:56:58 | | Join midk_ [0] (~midk@c-67-161-124-8.client.comcast.net) |
| 09:00 |
| 09:00:52 | | Join sneakums_ [0] (~sneakums@doublethink.psax.org) |
| 09:03:11 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 09:05:28 | | Quit sneakums (Read error: 60 (Operation timed out)) |
| 09:22:02 | | Join Shulberry [0] (Taxi@oslo-dhcp-248-180.bluecom.no) |
| 09:34:46 | | Join Lynx_ [0] (HydraIRC@134.95.189.59) |
| 09:45:40 | | Quit midk_ ("Leaving") |
| 10:00 |
| 10:02:05 | | Join fizze [0] (~fizze@N596P017.adsl.highway.telekom.at) |
| 10:17:11 | | Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- \o/") |
| 10:20:54 | | Join Lynx_ [0] (HydraIRC@134.95.189.59) |
| 10:34:50 | | Quit fizze (Read error: 110 (Connection timed out)) |
| 10:43:01 | | Join ze__ [0] (ze@adsl-69-231-211-103.dsl.irvnca.pacbell.net) |
| 10:53:40 | *** | Saving seen data "./dancer.seen" |
| 10:57:32 | | Quit ze (Read error: 110 (Connection timed out)) |
| 10:57:32 | | Nick ze__ is now known as ze (ze@adsl-69-231-211-103.dsl.irvnca.pacbell.net) |
| 11:00 |
| 11:03:01 | | Join GnagelRam [0] (~chatzilla@gnagelram.olf.sgsnet.se) |
| 11:04:07 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 11:12:50 | | Join Patr3ck [0] (~patr3ck@pD9E5C0C9.dip.t-dialin.net) |
| 11:15:00 | rasher | What does "Can't find entry point" mean? (getting it in the recorderv2-sim |
| 11:15:29 | Lynx_ | rasher: I'll tell you when you are older ;)) |
| 11:15:44 | * | rasher beats up Lynx_ |
| 11:16:13 | Lynx_ | and rightly so ;) |
| 11:37:21 | | Part GnagelRam |
| 11:38:12 | rasher | ah, got it |
| 11:38:24 | rasher | had my preprocessor directives messed up |
| 11:49:31 | rasher | bmp2rb is so not getting it |
| 11:54:20 | | Join ze__ [0] (ze@adsl-69-231-197-30.dsl.irvnca.pacbell.net) |
| 11:58:43 | Lynx_ | still working on the bumping logo? |
| 12:00 |
| 12:00:06 | rasher | yes |
| 12:00:21 | rasher | I made a smaller version that will fit on the recorder with room to spare |
| 12:00:37 | Lynx_ | cool, then i can try it too, when it's done |
| 12:00:51 | rasher | well it worked on the recorder |
| 12:00:54 | rasher | just didn't move sideways :) |
| 12:01:01 | Lynx_ | ah |
| 12:01:15 | rasher | but I have messed up .. something |
| 12:01:30 | rasher | so now the bmps are totally corrupted |
| 12:04:14 | linuxstb | Morning all. My iRiver FLAC decoder is working perfectly in the SIM (converting a FLAC file to raw PCM file), but on the iRiver itself it is crashing in a read() command - on about the 3rd or 4th read(), the hard drive LED stays on and the read() function never returns... |
| 12:06:48 | rasher | Hurray! And also, aww! |
| 12:08:10 | | Quit ze (Read error: 110 (Connection timed out)) |
| 12:08:10 | | Nick ze__ is now known as ze (ze@adsl-69-231-197-30.dsl.irvnca.pacbell.net) |
| 12:11:43 | | Quit DMJC (zelazny.freenode.net irc.freenode.net) |
| 12:11:43 | NSplit | zelazny.freenode.net irc.freenode.net |
| 12:11:43 | | Quit Ka (zelazny.freenode.net irc.freenode.net) |
| 12:12:09 | NHeal | zelazny.freenode.net irc.freenode.net |
| 12:12:09 | NJoin | DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 12:12:09 | NJoin | Ka [0] (~tkirk@pcp0010733332pcs.howard01.md.comcast.net) |
| 12:16:16 | * | rasher sighs |
| 12:20:16 | | Quit coob (Read error: 60 (Operation timed out)) |
| 12:30:55 | | Join R3nTiL [0] (~zorroz@83.69.98.141) |
| 12:32:48 | rasher | Hurray, I have a bouncing logo on the recorderv2-sim |
| 12:35:40 | | Join muesli- [0] (muesli_tv@1Cust116.tnt9.hnr2.deu.da.uu.net) |
| 12:36:23 | linuxstb | Nice one. Still no joy with my FLAC decoder - but it's now displaying some nice stats on the screen whilst it's decoding (up until it crashes). |
| 12:37:05 | | Nick sneakums_ is now known as sneakums (~sneakums@doublethink.psax.org) |
| 12:37:45 | | Join R3nTiL_ [0] (~zorroz@217.30.249.99) |
| 12:38:06 | | Quit R3nTiL (Read error: 54 (Connection reset by peer)) |
| 12:43:15 | | Quit Patr3ck () |
| 12:43:47 | rasher | hrm, can't bring up the menu on the ondiofm-sim |
| 12:43:55 | | Join jyp [0] (~jp@98.203-200-80.adsl.skynet.be) |
| 12:51:01 | HCl | why does it crash? |
| 12:51:19 | HCl | oh |
| 12:51:36 | HCl | linuxstb: check what memory address that read is writing to? |
| 12:52:00 | * | HCl yawns |
| 12:52:13 | rasher | do I have to seed rb->rand() ? |
| 12:52:36 | | Join amiconn [0] (~jens@pD95D199F.dip.t-dialin.net) |
| 12:52:58 | amiconn | hi |
| 12:53:26 | rasher | Hi there |
| 12:53:41 | *** | Saving seen data "./dancer.seen" |
| 12:53:48 | amiconn | rasher: On the Ondio, bringing up the menu requires a long press of the MODE button |
| 12:54:03 | rasher | ah |
| 12:54:05 | linuxstb | HCl: Yes, I've done that, and it looks fine. |
| 12:54:12 | amiconn | That's because there are so few buttons... |
| 12:54:27 | linuxstb | I'm now trying to read the whole file into the MP3 buffer first, and then set the decoder going on that. |
| 12:56:30 | amiconn | rasher: If your bouncing logo works on on the recorder, it should also work on the Ondio. The lcd is identical. |
| 12:56:44 | rasher | yeah, I'm still failing to bring up the menu though |
| 12:56:56 | amiconn | X11 or Win32 sim? |
| 12:57:00 | rasher | x11 |
| 12:57:42 | rasher | As a side product, I have a 91x32 rockbox logo |
| 12:57:47 | rasher | if that's of any use anywhere |
| 12:58:08 | * | amiconn is building an Ondio X11 sim |
| 12:58:17 | | Quit DMJC (zelazny.freenode.net irc.freenode.net) |
| 12:58:17 | NSplit | zelazny.freenode.net irc.freenode.net |
| 12:58:17 | | Quit Ka (zelazny.freenode.net irc.freenode.net) |
| 12:58:28 | rasher | it doesn't give me a "received ev xxxxx" on the console |
| 12:58:33 | rasher | so it looks right |
| 12:58:46 | NHeal | zelazny.freenode.net irc.freenode.net |
| 12:58:46 | NJoin | DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 12:58:46 | NJoin | Ka [0] (~tkirk@pcp0010733332pcs.howard01.md.comcast.net) |
| 12:58:58 | amiconn | Perhaps the X11 sim doesn't handle the button repeat correctly. |
| 12:59:01 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 12:59:03 | rasher | could be |
| 12:59:05 | rasher | oh well |
| 13:00 |
| 13:00:13 | linuxstb | Hurray! It seems to be working. Slowly... |
| 13:00:20 | * | HCl grumbles at hp |
| 13:00:22 | rasher | at 11mhz :) |
| 13:00:25 | HCl | don't you hate it when like |
| 13:00:28 | amiconn | Hmm, it doesn't work. It does definitely work in the Win32 sim though |
| 13:00:31 | HCl | you have a serious problem with a laptop |
| 13:00:36 | HCl | and they just treat you like an idiot |
| 13:00:39 | HCl | at an helpdesk |
| 13:01:16 | rasher | I don't think I've ever bothered with manufacturer helpdesks |
| 13:01:30 | linuxstb | It's currently taking about 11 seconds to decode 1 second of audio.... |
| 13:01:54 | rasher | heh |
| 13:02:35 | * | HCl blinks at his installer as it says amd confidential o.o |
| 13:02:46 | linuxstb | When is Linux going to inject steroids into our iRivers? :-) |
| 13:02:48 | rasher | amiconn: do you know if rand() always returns the same first time on the sims? |
| 13:02:49 | linuxstb | ^Linus |
| 13:03:23 | amiconn | rasher: I don't know |
| 13:04:24 | rasher | okay, it looks like the logo always starts in the same direction |
| 13:04:29 | rasher | but not on my iRiver |
| 13:04:33 | rasher | *shrug* |
| 13:04:41 | rasher | Alright, rasher.dyndns.org/~rasher/logo.c">http://rasher.dyndns.org/~rasher/logo.c if you want a bouncing logo :) |
| 13:09:31 | amiconn | Do you use the X11 sim on windows/ cygwin, or on linux? |
| 13:09:40 | rasher | linux |
| 13:10:00 | amiconn | Hmm. Could you check something for me? |
| 13:11:09 | amiconn | Open uisimulator/x11/screenhack.c, change lines 270 and 287 to read '#if 1' instead of '#if 0' and recompile the sim. |
| 13:11:17 | rasher | okay |
| 13:12:04 | amiconn | Then start the sim and hold down the INS key. The interesting question is: Do you also get keyrelease events between each 2 keypress events? |
| 13:12:04 | rasher | done |
| 13:12:29 | rasher | yup |
| 13:12:41 | rasher | wait |
| 13:12:44 | rasher | yes |
| 13:12:45 | rasher | I do |
| 13:13:20 | amiconn | Hmm. SO the release/repeat handling in the x11 sim is broken, and the Ondio sim can't call the menu because of this. |
| 13:15:06 | rasher | Curious |
| 13:15:30 | amiconn | You are the first to notice this... |
| 13:16:01 | amiconn | I usually use the Win32 sim, because it's more convenient on windows. Button repeat is working there. |
| 13:16:02 | rasher | Maybe it's caused by versions of libraries? |
| 13:16:38 | amiconn | I don't know. The X11 sim is rather old code, and I'm not much of an X11 expert. |
| 13:16:45 | | Quit muesli- (Read error: 113 (No route to host)) |
| 13:17:04 | amiconn | However, I get the same behaviour with cygwin X11 on windows. |
| 13:17:10 | rasher | okay |
| 13:18:49 | amiconn | Hmm. It looks like this situation should be handled by the code... |
| 13:19:02 | | Join bsec [0] (~bsec@host11-118.pool80180.interbusiness.it) |
| 13:24:42 | rasher | don't look at me :) |
| 13:25:32 | | Join webguest84 [0] (~5163d8f5@labb.contactor.se) |
| 13:27:21 | | Quit webguest84 (Client Quit) |
| 13:30:30 | | Join Hohoman [0] (~inte@hohoman.olf.sgsnet.se) |
| 13:30:53 | amiconn | rasher: I found the actual problem. |
| 13:31:17 | rasher | Oh boy |
| 13:31:19 | rasher | and a fix? |
| 13:31:30 | amiconn | The repeat handling works *almost* correct in the X11 sim in that it properly detects repeats |
| 13:32:15 | amiconn | However, the target button driver is supposed to send keydown, and when repeat kicks in continue with sending keyrepeat |
| 13:32:31 | amiconn | It should only send keyup at the very end of the sequence. |
| 13:32:42 | rasher | Makes sense |
| 13:32:52 | amiconn | The x11 driver sends keydown, keyup, the keyrepeat.... |
| 13:32:56 | amiconn | *then |
| 13:33:09 | rasher | oh ah |
| 13:33:31 | amiconn | This cannot work with the event loops in rockbox code, as they need to tell the difference between short & long press |
| 13:34:12 | | Join Quelsaruk [0] (~kvirc@80.103.137.139) |
| 13:34:17 | amiconn | They do this by looking at the next event after a keydown. If this is keyup, it was a short press, if it is keyrepeat, it is a long press |
| 13:34:47 | amiconn | The x11 driver breaks this by sending keyup before the repeat, hence rockbox always counts this as a short press |
| 13:35:05 | Quelsaruk | hi |
| 13:35:20 | | Join Sucka [0] (~NNSCRIPT@host81-156-215-25.range81-156.btcentralplus.com) |
| 13:35:27 | amiconn | hi Quelsaruk |
| 13:35:44 | amiconn | rasher: Fixing this might be difficult, but I'll look into it. |
| 13:36:35 | rasher | okay |
| 13:36:52 | rasher | don't rush it for my sake |
| 13:43:47 | | Join funkymonkey [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 13:43:47 | | Quit methangas (Read error: 104 (Connection reset by peer)) |
| 13:44:43 | rasher | Another Dane! |
| 13:46:12 | sneakums | down with denmark. |
| 13:46:53 | DMJC | can someone fix rockblox on iriver/ |
| 13:46:53 | rasher | Nay! |
| 13:46:56 | DMJC | ? |
| 13:47:06 | rasher | Fix? |
| 13:47:15 | rasher | it works afaics |
| 13:47:26 | DMJC | it's tiny |
| 13:47:31 | DMJC | and comes across not down |
| 13:47:31 | rasher | ah |
| 13:47:51 | rasher | I thought you meant there was a bug |
| 13:48:09 | DMJC | the bug is, it's tiny and the iriver display is huge? |
| 13:49:10 | sneakums | sounds like a good first project |
| 13:49:22 | rasher | sneakums: Get on it |
| 13:49:26 | sneakums | no thanks. |
| 13:49:33 | DMJC | my first project was fixing snake |
| 13:49:56 | sneakums | then you're the perfect person to fix rockblox! |
| 13:50:04 | DMJC | er.. no |
| 13:50:21 | linuxstb | Someone who knows about these things needs to fix the battery status on the iRiver. But the TODO list for the iRiver is getting smaller each day... |
| 13:50:37 | sneakums | it's scary how fast it's shrinking |
| 13:50:43 | DMJC | ? |
| 13:51:22 | linuxstb | I was amazed during the "flashing party" last Sunday at how much "just worked" (I know that's unfair to Linus and others!). |
| 13:51:26 | DMJC | still waiting on the audio stuff |
| 13:51:51 | sneakums | patience |
| 13:52:17 | * | rasher ponders trying to change snake2 |
| 13:52:17 | linuxstb | I think Linus wants to make the rest of Rockbox stable before tacking the audio. Which is good, because there is no new audio systerm written yet for him to use. |
| 13:52:29 | linuxstb | ^tackling |
| 13:52:43 | DMJC | the rest of it seems stable enough |
| 13:52:51 | sneakums | a reasonable approach |
| 13:54:08 | linuxstb | DMJC: Yes, it is. I think the main thing left (outside the audio) is a function to change the CPU speed. |
| 13:54:09 | rasher | Does anyone know if lcd_clear_display() is expensive? |
| 13:54:32 | amiconn | Not that expensive |
| 13:54:39 | rasher | compared to clearing a rectangle the size of the logo |
| 13:54:50 | amiconn | It's a simple memset() for the whole framebuffer |
| 13:54:57 | DMJC | has rockboy been uploaded into cvs? |
| 13:55:00 | rasher | won't bother then |
| 13:55:25 | amiconn | rasher: Clearing a rectangle is way more expensive with the current implementation |
| 13:55:34 | rasher | Heh, alright |
| 13:55:47 | amiconn | ...because it clears each pixel individually. Sic! |
| 13:56:04 | rasher | cute |
| 13:56:43 | HCl | DMJC: not yet.. *looks at amiconn* :x |
| 13:56:50 | HCl | i think it should work in sim first? |
| 13:56:56 | HCl | before its allowed to be added to cvs? |
| 13:57:24 | DMJC | rockboy worked on my iriver |
| 13:57:40 | HCl | yes, it works on irivers, but not in the simulators yet |
| 13:57:41 | DMJC | it's just that I want to build it against my fbuild |
| 13:58:08 | linuxstb | HCl: How big does PLUGIN_RAMSIZE need to be for your rockboy now? |
| 13:58:08 | HCl | *stares at his cat walking very determined into his room* |
| 13:58:14 | HCl | hold on, let me check what he's doing >.> |
| 13:58:19 | HCl | linuxstb: 700k should be enough |
| 13:58:21 | HCl | for now |
| 13:58:22 | HCl | anyways |
| 13:58:55 | * | R3nTiL_ slaps DMJC-L around a bit with a large trout |
| 13:59:06 | DMJC | ? |
| 13:59:23 | | Join webguest85 [0] (~5393a206@labb.contactor.se) |
| 13:59:25 | linuxstb | HCl: Can you decrease that by moving any buffers to the mp3_buffer ? People have been taking about a 512K plugin size on the iRiver. |
| 13:59:33 | amiconn | If I manage to get it running in the sim, I'll try to make it run on the archos as well. Should work, and probably even a bit faster than it currently does on the iRiver. |
| 13:59:41 | linuxstb | ^talking about (linuxstb can't type today) |
| 13:59:50 | HCl | linuxstb: i did my best, i moved most buffers to the mp3 buffer by making a malloc implementation |
| 14:00 |
| 14:00:08 | amiconn | Of course this wouldn't be able to handle all roms, because of the ram size, and the display needs to be shrinked to 1/2 |
| 14:00:24 | | Quit R3nTiL_ () |
| 14:00:36 | HCl | :p |
| 14:01:15 | amiconn | I also have some ideas how to speed up lcd refresh, but I'll have to look in what order gnuboy spits out the scanlines |
| 14:01:45 | amiconn | The badness is that gnuboy produces scanlines, but the bytes in the rockbox framebuffer are aligned vertically |
| 14:01:47 | | Quit webguest85 (Client Quit) |
| 14:01:58 | rasher | you'll have to do pretty evil screen-chopping though |
| 14:02:13 | HCl | mhm.. |
| 14:02:33 | amiconn | So you do one lcd_update_rect() for each scanline, total of 8 per framebuffer "byte line" |
| 14:02:45 | HCl | yeae. |
| 14:02:46 | HCl | yea* |
| 14:03:08 | amiconn | If gnuboy always writes sequentially, it's sufficient to lcd_update_rect() in the last scanline of each block |
| 14:03:30 | HCl | i set it to the first, at the moment.. |
| 14:03:36 | HCl | i think |
| 14:03:38 | HCl | hm |
| 14:03:46 | DMJC | where is the gnuboy src kept? |
| 14:03:52 | HCl | no, i just set it to the scanline |
| 14:03:55 | DMJC | I mean the rockboy src heh |
| 14:04:12 | HCl | there's a pretty recent one on my ftp server, but hold on |
| 14:04:19 | HCl | i'll make a more recent zip |
| 14:04:45 | amiconn | rasher: I don't need more chopping than on iRiver if I leave out every 2nd scanline & column |
| 14:05:12 | HCl | there |
| 14:05:46 | HCl | on ftp://titania.student.utwente.nl |
| 14:06:00 | amiconn | If this really works, I could go a bit further... |
| 14:06:53 | amiconn | Since it makes no sense to set away 1/3 of all ram (on the archos) as plugin ram, I could make a special build, which does only gameboy emulation. |
| 14:07:37 | amiconn | Since there is RoLo on the archos (starting another firmware file from within the current one), this would be simple to use... |
| 14:08:30 | rasher | yeah |
| 14:08:47 | amiconn | It could even 're-RoLo' standard rockbox on exit |
| 14:09:21 | rasher | that'd be a nice way to do it |
| 14:09:50 | amiconn | You know that I must be crazy... |
| 14:10:55 | | Join elinenbe [0] (elinenbe_@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 14:11:17 | elinenbe | hello... what's this with the gamboy emulator I see on the misticriver forum? is that for real? |
| 14:11:29 | * | HCl grins |
| 14:11:31 | HCl | yea, i made it :3 |
| 14:11:37 | HCl | its still rather slow |
| 14:11:44 | HCl | but i'm hoping to get it running properly |
| 14:11:48 | elinenbe | HCl: what is it based off of? gnuboy? |
| 14:11:51 | HCl | yup |
| 14:11:59 | elinenbe | HCl: fabulous work! |
| 14:12:10 | HCl | thanks :p |
| 14:12:21 | elinenbe | you know I would always joke about a gamboy emulator on the archos, but wow! you really made it happen! |
| 14:12:28 | elinenbe | do you have any other screenshots? |
| 14:12:37 | * | rasher watches jyp go insane with the "long policy" fixes |
| 14:12:40 | HCl | um, there are 4 on rockbox's site.. |
| 14:13:05 | HCl | i managed to get a decent screen with pokemon yellow |
| 14:13:07 | elinenbe | I am looking now... |
| 14:13:10 | HCl | but since its still black and white |
| 14:13:20 | elinenbe | is the screen large enough (in pixels)? |
| 14:13:21 | HCl | most color roms mess up since they need at least 4 bit grayscale |
| 14:13:34 | HCl | its 16 rows too small |
| 14:13:44 | elinenbe | ah... |
| 14:13:46 | HCl | but that needn't be a problem |
| 14:13:51 | elinenbe | why is that? |
| 14:13:53 | HCl | several solutions have been suggested for that... |
| 14:14:21 | rasher | Bagder: shouldn't the codecs be removed from IriverPort now that they're on a seperate page? |
| 14:14:21 | elinenbe | 2 buttons on the side for up/down scrolling? |
| 14:14:26 | HCl | switching between dropping top 16 and bottom 16 pixels with the hold button.. dropping 8 at the top and 8 at the bottom.. dropping a line every 9 lines |
| 14:14:37 | elinenbe | HCl: I am so impressed −− amazing work! |
| 14:14:42 | HCl | the biggest problem is not being able to press two buttons at the same time |
| 14:14:56 | elinenbe | HCl: is it a plugin? how does it currently work? |
| 14:15:05 | HCl | last version is built as a viewer |
| 14:15:12 | HCl | you can just select gameboy roms in the browse thing |
| 14:15:54 | elinenbe | wow! wow! wow! |
| 14:16:12 | elinenbe | oh... one more thing. what is the speed (percentage of real-time)? |
| 14:16:34 | HCl | at the moment it does about one screen update per second... |
| 14:16:46 | HCl | it needs to be at least 30 times faster to be actually playable |
| 14:17:24 | elinenbe | eh... hehe |
| 14:17:33 | elinenbe | so, you need some nice optimizations! |
| 14:17:42 | HCl | yea |
| 14:17:45 | HCl | out of sheer curiousity |
| 14:17:57 | HCl | where's the thread/stuff on rockboy on misticriver? |
| 14:18:46 | elinenbe | the link was from dapreview.net |
| 14:18:46 | elinenbe | http://www.misticriver.net/boards/showthread.php?t=5331&page=22&pp=20 |
| 14:19:29 | HCl | ah :) |
| 14:20:15 | rasher | it's linked from the wiki somewhere |
| 14:20:22 | rasher | that and another thread |
| 14:21:25 | DMJC | wicked! |
| 14:21:35 | DMJC | someone rigged up an 80gb ihp-140 |
| 14:21:43 | DMJC | they used a 3.5" hdd |
| 14:21:49 | DMJC | but the thing worked |
| 14:21:51 | sneakums | sick |
| 14:21:55 | linuxstb | rasher: I've been thinking about moving the codec info from iRiverBoot to the codec page - I'll do it now. |
| 14:22:09 | DMJC | http://www.misticriver.net/boards/showthread.php?t=11568 |
| 14:22:16 | rasher | linuxstb: Bagder did it an hour ago |
| 14:22:23 | rasher | but didn't remove it fromt he iriverport page |
| 14:22:27 | rasher | see the recent changes |
| 14:23:04 | linuxstb | rasher: I should keep up to date... |
| 14:23:04 | rasher | ah, I think he removed it now |
| 14:23:06 | rasher | :) |
| 14:23:15 | rasher | oh |
| 14:23:18 | rasher | it wasn't an hour ago |
| 14:23:22 | Sucka | just thought i'd mention, on the rockbox site in the 'features' section it says iriver cant display txt files natively, but it can |
| 14:23:25 | rasher | the GMT times keep confusing me |
| 14:23:32 | bsec | is e the super mario rom playable ? (ultra slow) |
| 14:23:39 | Sucka | incase anyone cares ;D |
| 14:25:36 | HCl | nice |
| 14:25:46 | HCl | that means the 1.8" drives will work |
| 14:25:47 | bsec | HCl: what are the buttons for controlling ? |
| 14:26:08 | bsec | the play button? |
| 14:26:09 | DMJC | haha someone is creating new parts for their ihp-120 so they can get a 140's hdd into it |
| 14:26:23 | HCl | rec = start play = A stop = B |
| 14:26:29 | HCl | mode = select |
| 14:26:32 | HCl | joystick button = quit |
| 14:26:41 | bsec | ah thx |
| 14:26:41 | rasher | DMJC: that is just WRONG |
| 14:26:41 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 14:28:23 | bsec | woho its starts after 3 minutes =) |
| 14:28:41 | HCl | what rom did you load? |
| 14:28:41 | HCl | heh |
| 14:28:47 | bsec | mario |
| 14:29:11 | HCl | loads fairly ok here |
| 14:29:24 | preglow | after three minutes? |
| 14:29:29 | preglow | isn't that a bit much? heh |
| 14:29:33 | HCl | it is |
| 14:29:47 | bsec | strange |
| 14:29:50 | HCl | the first screenoutput is after 14 emu cycles |
| 14:30:03 | * | HCl yawns and goes to fetch his iriver |
| 14:31:14 | bsec | yeah first screenoutput is at 14 |
| 14:31:41 | preglow | my iriver does the tremendous task of multiplying five by four, left shifting the result by one and printing the result right now |
| 14:31:44 | preglow | heh |
| 14:31:49 | * | HCl times it |
| 14:32:00 | bsec | game start 56, strange |
| 14:32:06 | bsec | it really toke 3 minutes before |
| 14:32:12 | HCl | hrm. |
| 14:32:16 | HCl | something is wrong with it. |
| 14:32:22 | HCl | it crashed on loading rom |
| 14:32:27 | preglow | usb support in rockbox really bloody rocked |
| 14:32:29 | HCl | maybe my last memory optimalization causes trouble |
| 14:32:35 | preglow | it's five times faster than on the old os |
| 14:32:41 | bsec | im using your latest dev sources |
| 14:33:02 | rasher | preglow: transfer times? Or just response to plugin/out? |
| 14:33:12 | HCl | yea, it seems to be malfunctioning |
| 14:33:14 | preglow | rasher: the last |
| 14:33:16 | HCl | hold on |
| 14:33:22 | rasher | preglow: yeah, it's very snappy |
| 14:33:30 | preglow | rasher: when you plugged out with iriver firmware, it had to rescan the entire disk, rockbox doesn't |
| 14:33:43 | preglow | it's wonderful for development |
| 14:34:14 | rasher | Yes, I love it |
| 14:34:33 | bsec | and finally u can create directorys, delete files etc on the player |
| 14:34:40 | bsec | and see all files |
| 14:34:42 | amiconn | preglow: Scanning the whole disk on boot/ usb unplug is really silly design, imho |
| 14:34:48 | preglow | amiconn: i agree |
| 14:35:10 | rasher | It's beyond silly. |
| 14:35:11 | preglow | amiconn: especially in irivers case, since they turn on the disk when you browse files anyway |
| 14:35:17 | rasher | It's probably beyond fucking stupid as well. |
| 14:36:19 | * | HCl yawns |
| 14:36:29 | * | rasher jumps |
| 14:36:57 | HCl | oka |
| 14:36:57 | HCl | y |
| 14:37:03 | HCl | that was one memory optimalization that messed up |
| 14:37:39 | HCl | takes less than 30 secs to start now |
| 14:37:56 | HCl | bsec: reget it from my ftp |
| 14:38:00 | bsec | ok |
| 14:39:58 | DMJC | why is the emulation so slow? |
| 14:40:29 | preglow | interpreter core, 10mhz cpu with bogged down ram |
| 14:40:32 | preglow | that's probably why |
| 14:41:26 | bsec | the real cpu power is something with 140mhz? |
| 14:41:26 | DMJC | k |
| 14:41:55 | preglow | yes |
| 14:42:26 | bsec | should be enough for gb emulation |
| 14:42:29 | preglow | yes |
| 14:42:33 | preglow | but we'll see |
| 14:42:55 | linuxstb | What percentage speed-up do people think we will get with a full-speed Rockbox? |
| 14:43:23 | preglow | well, it should scale linearly |
| 14:43:24 | HCl | at least 11 times as fast.. |
| 14:43:25 | preglow | perhaps even less |
| 14:43:30 | preglow | depends on the ram |
| 14:43:37 | HCl | yup. |
| 14:43:50 | preglow | but yes, 11 times as fast isn't a bad estimate |
| 14:44:01 | preglow | but we'll just have to wait and see on this one, might be several other factors |
| 14:44:23 | HCl | yup. |
| 14:44:28 | | Quit jyp ("poof!") |
| 14:44:34 | HCl | i'm eager to start on dynarec |
| 14:44:45 | HCl | but i'll refrain myself till the iriver actually runs at full speed |
| 14:44:51 | HCl | restrain* |
| 14:45:06 | linuxstb | At the current speed of my FLAC decoder, I'm looking for about a 15 times as fast increase from Linus... |
| 14:45:49 | linuxstb | But I haven't looked at optimising it in any way yet, so it's looking good. |
| 14:46:18 | bsec | cu |
| 14:46:20 | | Quit bsec ("quork!") |
| 14:50:23 | Lynx_ | linuxstb: can flac be more processing intensive to decode than ogg? |
| 14:50:57 | preglow | rockbox doesn't care whether a file is binary or not, no? |
| 14:51:02 | linuxstb | Lynx_: I have no idea. There is more (compressed) data to process, but I'm guessing the actual decoding for FLAC is simpler. |
| 14:51:15 | Lynx_ | ok... |
| 14:51:37 | linuxstb | I'm about finished with FLAC, and will move on to libmad and then Tremor (ogg), so I can do some speed comparisons then. |
| 14:52:15 | Lynx_ | linuxstb: libmad is kinda important ;) |
| 14:52:40 | linuxstb | Yes, but I'm already familiar with libmad, so that should be quick to get running on the iRiver. |
| 14:53:44 | *** | Saving seen data "./dancer.seen" |
| 14:55:32 | preglow | it's very easy to build, at least |
| 14:56:19 | linuxstb | preglow: it depends if all the libc functions it uses are implemented, and how it manages memory. |
| 14:56:59 | preglow | linuxstb: a couple of mallocs, requires almost no libc, i've built it myself |
| 14:57:09 | preglow | my iriver locked up in usb mode, woop |
| 14:57:41 | linuxstb | preglow: should be very quick to implement a test decoder then. |
| 14:57:50 | preglow | linuxstb: indeed |
| 14:59:35 | | Quit gromit` (Remote closed the connection) |
| 15:00 |
| 15:01:07 | preglow | is there some kind of limit on how big my internal arrays can be in a plugin? |
| 15:01:41 | | Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
| 15:02:16 | ashridah | i'd imagine that declaring huge amounts ofthings on the stack wouldn't be a good idea |
| 15:02:39 | linuxstb | preglow: If you are using the standard firmware, the plugin size is 32KB maximum - code and data. |
| 15:03:02 | linuxstb | This needs to be increased in CVS for the iRiver - HCl needs about 700K for rockboy. |
| 15:03:10 | preglow | well, i'm below that, but my plugin quite obviously crashes rockbox |
| 15:04:47 | preglow | ashridah: i happen to to use a 8kb array on the stack, yes :P |
| 15:05:03 | preglow | ashridah: so i have to declare these things as static globals? |
| 15:05:23 | linuxstb | preglow: I think I saw somewhere that the stack size is 2K, but I could be wrong. |
| 15:07:40 | preglow | yup, that was it |
| 15:07:44 | preglow | after making it static it works fine |
| 15:07:47 | preglow | it's just for testing anyway |
| 15:08:12 | preglow | wee, my h120 is making a sawtooth |
| 15:08:22 | HCl | ? |
| 15:08:32 | preglow | like a sound |
| 15:08:51 | sneakums | sweet as |
| 15:09:05 | HCl | with hdd or what? |
| 15:09:14 | sneakums | with the audio hardware, i assume |
| 15:09:34 | preglow | nono |
| 15:09:38 | sneakums | oh. |
| 15:09:41 | preglow | i'm working on making emac macros |
| 15:09:45 | preglow | so i'm diskwriting right now |
| 15:10:16 | preglow | i don't think linus is done mapping out the audio hardware yet |
| 15:10:22 | sneakums | what's emac? |
| 15:10:31 | preglow | extended multiply accumulate unit |
| 15:10:38 | preglow | good for digital signal processing |
| 15:10:52 | preglow | can be put to good use in more or less all of the codecs |
| 15:11:05 | preglow | and in stuff like equalizers and spectrum analyzers |
| 15:11:13 | preglow | which i suspect people will start asking for sooner or later |
| 15:11:28 | sneakums | ah |
| 15:14:16 | | Join jyp [0] (~jp@98.203-200-80.adsl.skynet.be) |
| 15:19:12 | linuxstb | preglow: based on current performance, FLAC is going to need a lot of optimising before it can be used at the same time as equalizers, cross-fading etc |
| 15:19:27 | linuxstb | So we will need an emac expert on the team... |
| 15:20:59 | preglow | yes, i'm experimenting with it now to find out how it works |
| 15:21:21 | preglow | but what makes you say this, btw? have you done any tests? |
| 15:22:11 | linuxstb | Yes, I have a FLAC "viewer" running on the iRiver - it currently reads the .flac file into RAM, and then decodes it. Current speed is about 8% of real-time. |
| 15:22:32 | rasher | are you writing to disk? |
| 15:22:43 | linuxstb | rasher: No, just discarding the decoded samples. |
| 15:22:48 | rasher | ah |
| 15:22:48 | preglow | ahh |
| 15:22:51 | preglow | then bad news for us |
| 15:23:11 | preglow | that comes as a surprise, really, i'd have thought flac was really fast |
| 15:23:23 | linuxstb | But I have made zero effort at any optimisation. |
| 15:23:38 | sneakums | and is that with the iriver running at 11mhz? |
| 15:23:52 | rasher | when you say current speed, is that speed *after* having read the file? |
| 15:24:14 | linuxstb | rasher: Yes. It reads all the file into RAM, then closes the file, then starts decoding. |
| 15:24:22 | rasher | okay |
| 15:25:25 | preglow | i hope the ram is severely bogged down |
| 15:25:30 | preglow | that would explain things |
| 15:25:36 | linuxstb | preglow: So do it. |
| 15:26:00 | preglow | i know it's running with far more wait states than required, but not how many |
| 15:26:20 | linuxstb | Also, the 8% is with a 16-bit/44.1KHz file - 48KHz or higher files will obviously be slightly slower. |
| 15:26:41 | preglow | but still, we've got something to work on now |
| 15:26:42 | preglow | good job |
| 15:28:43 | linuxstb | Also, memory usage for FLAC is quite reasonable - the .rock itself is about 69000 bytes, and it needs about 140K of malloc'd RAM to decode a file. |
| 15:30:06 | rasher | Sounds very good |
| 15:30:26 | preglow | i'm quite optimistic with regard to cpu usage |
| 15:30:33 | preglow | i think we'll be able to cut that severely |
| 15:30:43 | HCl | mrf. |
| 15:31:04 | HCl | how does the audio interface work anyways? |
| 15:31:08 | HCl | maybe i can add sound |
| 15:31:12 | preglow | dunno |
| 15:32:14 | linuxstb | I haven't investigated whether these can be changed, but libFLAC uses a lot of 64-bit integers internally. |
| 15:32:28 | linuxstb | Which could be another cause of the lack of speed. |
| 15:32:46 | rasher | linuxstb: did you see the neuros-forum? |
| 15:33:05 | rasher | A FLAC developer is working on removing the need for 64 bit |
| 15:33:22 | linuxstb | rasher: Yes. Last thing I read there was that the developer was going to investigage the 64-bit integers, but I don't think he has yet. |
| 15:33:44 | rasher | Same here |
| 15:33:56 | linuxstb | I'll need to keep an eye on the FLAC CVS. |
| 15:35:19 | preglow | linuxstb: that's quite nasty, the coldfire doesn't support those directly |
| 15:35:52 | preglow | but that is an area where the emac will come in handy, the accumulators are 48 bits |
| 15:36:08 | preglow | which _might_ be enough |
| 15:36:09 | linuxstb | I'm impressed I'm getting 8% with all these problems :-) |
| 15:36:40 | preglow | hrmf, anyone really handy with preprocessor macros? |
| 15:38:19 | | Part amiconn |
| 15:40:27 | jyp | Is there an emac programming guide or the like somewhere ? |
| 15:41:27 | rasher | ah, I do have to seed rand() |
| 15:41:39 | rasher | with srand(), amazingly :) |
| 15:41:57 | rasher | looking more random |
| 15:42:57 | preglow | jyp: i haven't found anything for the emac unit apart from the motorola programming guide |
| 15:43:12 | preglow | jyp: there's a paper on the mac unit, but that's a pretty much scaled down version of the emac unit |
| 15:43:13 | jyp | You have an url ? |
| 15:43:20 | preglow | sure, gimme a sec |
| 15:43:46 | preglow | jyp: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SCF5249 |
| 15:43:48 | jyp | I want to see how similar it is to the CalmMAC which is in gminis |
| 15:43:55 | | Join elinenbe_ [0] (~elinenbe@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 15:44:19 | preglow | the reference manuals would be your thing |
| 15:45:00 | preglow | CFPRM.pdf |
| 15:45:04 | preglow | that's got an opcode reference |
| 15:45:36 | jyp | alright |
| 15:48:32 | jyp | We have CalmMAC2424 on the gmini |
| 15:48:49 | jyp | so, multiplication operands are 24 bits wide |
| 15:49:03 | jyp | whereas EMAC can use either 16 or 32 |
| 15:49:06 | preglow | yes |
| 15:49:37 | preglow | and they've also got some additional load magic |
| 15:49:48 | preglow | maintaining compatability will be more or less impossible |
| 15:50:07 | jyp | The 'load magic' is probably similar |
| 15:50:28 | preglow | i went through the fixed point macros of libmad and concluded that it will be impossible to ease the coldfire mac instructions efficiently in |
| 15:50:45 | preglow | since gcc doesn't now of the new accumulator registers |
| 15:52:11 | jyp | Yup, to do this you'll need a coldfire aware gcc |
| 15:52:55 | | Quit elinenbe_ (" HydraIRC -> http://www.hydrairc.com <- Try something fresh") |
| 15:53:04 | jyp | Is there a compiler for emac ? |
| 15:53:13 | jyp | (even non-gcc) |
| 15:54:13 | preglow | surely |
| 15:54:16 | preglow | but not freely |
| 15:54:22 | | Quit ashridah ("sleep") |
| 15:54:25 | preglow | available |
| 15:54:47 | jyp | m'kay |
| 15:54:56 | preglow | it wouldn't help us anyway |
| 15:55:04 | jyp | why ? |
| 15:55:24 | preglow | ahh, if there was one freely available, yes |
| 15:55:32 | preglow | but i'm willing to bet money that's not the case |
| 15:55:47 | | Quit elinenbe (Read error: 104 (Connection reset by peer)) |
| 15:57:54 | jyp | What about this ? |
| 15:57:55 | jyp | http://www.elec.canterbury.ac.nz/c4x/ |
| 15:58:10 | | Join Tino_ [0] (~chatzilla@pD9E7285B.dip.t-dialin.net) |
| 16:00 |
| 16:00:28 | jyp | mm, not what I thought it is |
| 16:02:35 | preglow | but yes, the macros i'm making now will be pretty high level |
| 16:02:49 | preglow | which is really pretty necessary, since gcc doesn't know of the acc registers |
| 16:03:07 | HCl | whats emac? |
| 16:03:09 | preglow | hmm, can preprocessor macros have default arguments? ;P |
| 16:03:14 | HCl | the coldfire? |
| 16:03:16 | preglow | yes |
| 16:03:19 | HCl | okay |
| 16:03:20 | preglow | dsp unit |
| 16:03:28 | HCl | ah |
| 16:04:56 | jyp | Is anything of mad & the like in cvs yet ? |
| 16:05:19 | preglow | nope |
| 16:05:33 | preglow | it's not really needed yet, mad compiles fine out of the box |
| 16:06:29 | jyp | On an unrelated note, is the random number generator performance-critical ? |
| 16:08:55 | HCl | you'd want anything as optimized as possible |
| 16:13:35 | preglow | gcc inline asm is really friggin wicked |
| 16:13:35 | | Join jpburton5150 [0] (knoppix@cpe-24-94-54-216.stny.res.rr.com) |
| 16:13:57 | HCl | mm? |
| 16:14:38 | preglow | mm what? |
| 16:14:45 | HCl | how is it wicked? |
| 16:14:50 | HCl | wicked as in evil or wicked as in cool? |
| 16:14:54 | preglow | cool, heh |
| 16:15:01 | HCl | ok :p |
| 16:15:05 | preglow | as in it really ties the asm statements in with the c codes |
| 16:15:09 | preglow | shares registers and everything |
| 16:16:34 | HCl | mhm |
| 16:16:52 | HCl | how many registers does the coldfire have? |
| 16:17:14 | preglow | eight data register, eight address registers |
| 16:17:21 | preglow | where the eight address register is the stack pointer |
| 16:17:23 | HCl | k... |
| 16:17:37 | preglow | they can pretty much be used interchangably, with address registers carrying data |
| 16:17:51 | preglow | in our case it also has four 48 bit wide accumulator registers |
| 16:18:24 | preglow | remarkably nice assemby language for this cpu |
| 16:22:14 | jpburton5150 | has anyone succesfully compiled on Cygwin? |
| 16:25:17 | | Part Nibbler ("Leaving") |
| 16:27:30 | | Join pill [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
| 16:29:03 | | Join muesli- [0] (muesli_tv@1Cust165.tnt8.hnr2.deu.da.uu.net) |
| 16:29:51 | muesli- | g'day mates |
| 16:29:54 | HCl | hi |
| 16:30:30 | muesli- | nice nick hcl, are you sour like an acid? ;) |
| 16:34:14 | | Quit Tino_ ("no reason") |
| 16:34:59 | HCl | :P |
| 16:35:04 | HCl | naw, i'm rather cheery |
| 16:35:39 | muesli- | yummy :-D |
| 16:36:26 | | Join HELPME [0] (~54ee108a@labb.contactor.se) |
| 16:37:25 | rasher | HELPME HELPYOU |
| 16:37:45 | HELPME | i have Rockbox installed on my H140, if think Rockbox messed up the disk. |
| 16:37:47 | muesli- | hihi |
| 16:37:48 | HELPME | Now I can´t load the iRiver firmware!!! |
| 16:38:21 | HELPME | USB connection still works with Rockbox though |
| 16:38:33 | HELPME | and I can still write to disk |
| 16:39:05 | linuxstb | HELPME: What happens if you hold the record button when you turn on your H140? |
| 16:39:23 | HELPME | but original firmware stalls at "Read File" (red led off) |
| 16:39:47 | HELPME | linuxstb: it launches iRiver firmware |
| 16:40:40 | HELPME | I tried running checkdisk in Windows (when booted from Rockbox) |
| 16:40:48 | HELPME | it still does not work :( |
| 16:41:23 | preglow | HELPME: read file system? |
| 16:41:32 | preglow | HELPME: what's the status on the battery? |
| 16:41:38 | HELPME | iRiver firmware stills hangs at startup when loading "read file system" |
| 16:41:50 | preglow | HELPME: have you done a full battery charge? |
| 16:42:08 | HELPME | preglow: battery should be ok |
| 16:42:24 | preglow | HELPME: yes, should, but is it? we have had another one of these, and the battery was the problem |
| 16:42:32 | linuxstb | I think Rockbox uses less power than the iRiver firmware, so that could be problem. |
| 16:42:32 | HELPME | i can't really check it because Rockbox still don't show it correctly |
| 16:42:48 | preglow | HELPME: well, then charge it for an hours time and try again |
| 16:43:16 | preglow | HELPME: the hardware charges itself, so doesn't depend on whether you run rockbox or original firmware |
| 16:43:32 | HELPME | iRiver firmware normally just says "low battery" or does not turn on |
| 16:43:45 | HELPME | i don't think that is the problem |
| 16:43:55 | preglow | HELPME: yes, yes, but as i said, we have had another case resembling yours, and then the battery was a problem, so please try |
| 16:44:09 | HELPME | ok |
| 16:44:11 | preglow | it's worth a short anyway |
| 16:44:17 | preglow | shot, even |
| 16:44:33 | HELPME | right now I am backing up my data |
| 16:44:36 | preglow | just let the adapter charge for a quarter or something, then try again |
| 16:44:55 | HELPME | I will charge and try to launch iRiver firmware again later |
| 16:45:06 | preglow | good |
| 16:46:17 | preglow | rockbox messing up the disk really shouldn't happen, the fat driver should be the same as the one on archos, and that's gotten a lot of testing |
| 16:46:24 | preglow | plus, i've _really_ abused my player, and nothing has happened yet |
| 16:46:32 | preglow | but time will tell |
| 16:46:42 | preglow | i think i'll go for a walk in the snow |
| 16:46:53 | jpburton5150 | rar |
| 16:47:00 | preglow | qpeg |
| 16:47:08 | jpburton5150 | i _still_ cannot get rockbox to compile on cygwin |
| 16:47:19 | jpburton5150 | it say stuff about the unrecognized architecture |
| 16:47:30 | jpburton5150 | but ive got m68k-elf-gcc set up |
| 16:47:37 | preglow | jpburton5150: i tried as well, but gave up |
| 16:47:54 | jpburton5150 | haha... so you cant compile either then? |
| 16:48:34 | preglow | i've got a linux box |
| 16:48:35 | preglow | i use that |
| 16:48:44 | preglow | i'm not particularily fond of cygwin anyway |
| 16:48:53 | jpburton5150 | alright |
| 16:48:54 | jpburton5150 | yeah |
| 16:49:14 | jpburton5150 | in a bit i might reinstall a linux partition |
| 16:49:19 | jpburton5150 | any recommended ones? |
| 16:49:28 | rasher | ubuntu or debian |
| 16:49:32 | rasher | is my preferred choice |
| 16:49:36 | jpburton5150 | k yeah |
| 16:49:53 | preglow | but, yes, bbl |
| 16:50:08 | preglow | ubuntu is nice |
| 16:50:23 | | Join Tang [0] (~chatzilla@ARennes-204-1-44-154.w81-49.abo.wanadoo.fr) |
| 16:50:32 | Tang | Hi :) |
| 16:53:13 | | Quit jyp ("poof!") |
| 16:53:48 | *** | Saving seen data "./dancer.seen" |
| 16:55:59 | | Join Schnueff [0] (~mah@134.96.247.240) |
| 16:57:38 | | Join webguest33 [0] (~534e073f@labb.contactor.se) |
| 17:00 |
| 17:04:16 | | Quit webguest33 ("CGI:IRC (EOF)") |
| 17:06:35 | | Quit muesli- (Read error: 113 (No route to host)) |
| 17:08:45 | | Nick Lynx_ is now known as Lynx_awy (HydraIRC@134.95.189.59) |
| 17:12:01 | | Quit HELPME ("CGI:IRC") |
| 17:12:04 | | Join HELPME [0] (~54ee108a@labb.contactor.se) |
| 17:18:12 | rasher | HELPME: any luck? |
| 17:18:53 | | Join Luke1 [0] (~a@dpc691997050.direcpc.com) |
| 17:19:26 | Luke1 | would someone be able to take a look at this eBay auction for a 20 GB FM Recorder and give their opinion? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=15054&item=5750788165&rd=1 |
| 17:19:33 | Luke1 | It says: |
| 17:19:33 | Luke1 | 3 DAY SERVICE |
| 17:19:33 | Luke1 | MP3 PLAYER HANGS AT START UP. MAY BE FIXABLE OR GOOD FOR PARTS. MP 3PLAYER ONLY. |
| 17:19:44 | Luke1 | I wonder what that means is wrong if it hangs like that |
| 17:21:16 | * | rasher has no idea |
| 17:21:50 | HELPME | NO! :( |
| 17:21:58 | Luke1 | All right. I have an extra 20 GB hard drive, so if that needed replacing it seems like that wouldn't be too bad |
| 17:22:10 | Luke1 | but I have no clue what causes a unit to hang like that |
| 17:22:15 | HELPME | I just feel like I bricked my iRiver :( |
| 17:22:31 | HELPME | better not delete rockbox.iriver :) |
| 17:22:54 | rasher | HELPME: it boots and can write to disk, I doubt it's broken beyond repair |
| 17:23:08 | HELPME | hope not |
| 17:23:09 | linuxstb | HELPME: If I was you, I would just leave it charging and wait for LinusN to appear. |
| 17:23:11 | rasher | I'm guessing you'll have to wait for someone more in-the-know to come around |
| 17:24:01 | HELPME | how does your iRiver |
| 17:24:13 | HELPME | original firmware behave? |
| 17:24:19 | rasher | Mine works as usual |
| 17:24:24 | linuxstb | Never used it... |
| 17:24:27 | rasher | h120 though |
| 17:24:58 | linuxstb | I suppose I could test it for you now - I have a H140. |
| 17:25:08 | HELPME | mine turns off the backlight under "READ FILE SYSTEM" after the harddisk aktivity stops |
| 17:25:10 | rasher | HELPME: what did you say the error was? |
| 17:25:38 | rasher | oh, it stops in the "read file system" stage? |
| 17:26:11 | HELPME | it never pass "READ FILE SYSTEM" - harddisk stops reading (and red led) and the backlight is turned off |
| 17:26:23 | HELPME | I waited 20-25 min. |
| 17:26:35 | rasher | This shouldn't happen, but you could try running scandisk on it, or even formatting it I guess (after backing up data :) |
| 17:26:51 | rasher | did you do anything in rockbox before this happened? |
| 17:27:08 | HELPME | mount /mnt/iriver |
| 17:27:17 | HELPME | uploaded rockbox |
| 17:27:26 | HELPME | umount /mnt/iriver |
| 17:27:46 | HELPME | i tried scandisk in Windows |
| 17:27:59 | HELPME | does linus have a scandisk |
| 17:28:06 | rasher | not for vfat no |
| 17:28:07 | HELPME | linux :) |
| 17:28:15 | rasher | afaik |
| 17:28:18 | rasher | hrm |
| 17:28:20 | linuxstb | dosfsck |
| 17:28:25 | rasher | oh there is? |
| 17:28:26 | rasher | fun |
| 17:28:39 | HELPME | maybe I should try that |
| 17:28:45 | rasher | ISTR someone else having fat corruption problems |
| 17:28:50 | rasher | also using linux |
| 17:28:58 | rasher | and someone mentioning a vfat bug |
| 17:29:04 | rasher | but I'm not too sure about the details |
| 17:29:48 | HELPME | after USB connection, Rockbox release the connection in 1 sec. or less |
| 17:30:00 | HELPME | iRiver firmware takes up to a minute |
| 17:30:08 | rasher | yes, it's very snappy :) |
| 17:30:19 | rasher | that's because iRiver reads the entire disk contents |
| 17:30:24 | rasher | for some reason |
| 17:30:45 | HELPME | I don´t think so, the complete FAT maybe |
| 17:31:01 | sneakums | the fat is just a map of used and free clusters, it shoudlnt' ahev tor ead that at al |
| 17:31:07 | sneakums | it seems to read the entire directory tree |
| 17:31:18 | HELPME | on the FAT, right? |
| 17:31:38 | sneakums | no, the fat is just a map of used and free clusters. |
| 17:31:43 | sneakums | the directories are separate |
| 17:32:41 | HELPME | are you sure - that seems pretty stupid to me |
| 17:33:40 | sneakums | as far as i can tell, that is what the iriver firmware does |
| 17:34:13 | HELPME | how can you tell - are you an FAT32 expert? |
| 17:35:32 | sneakums | no, but i know the difference between a file allocation table and a directory tree, and can make a reasonable guess as to which one would need to be read when |
| 17:42:09 | HELPME | here is some FAT32 info: http://home.teleport.com/~brainy/fat32.htm |
| 17:42:30 | HELPME | notice the "Directory Table" |
| 17:42:44 | HELPME | which is part of FAT32 |
| 17:42:56 | sneakums | but it isn't the FAT |
| 17:43:20 | HELPME | ? |
| 17:43:36 | sneakums | FAT the file system was so named because it uses a file allocation table to track the used and free clusters |
| 17:43:51 | sneakums | which i think is the source of the confusion here |
| 17:52:27 | HELPME | damn, dosfsck - FAT32 not supported. http://rpmfind.net/linux/RPM/contrib/libc6/i386/dosfsck-0.1-4.i386.html |
| 17:52:49 | HELPME | newer versions must exists |
| 17:52:57 | sneakums | the one in Debian is version 2.10 |
| 17:53:03 | sneakums | at least |
| 17:53:14 | sneakums | there is a package called dosfstools that has a program called dosfsck |
| 17:53:24 | sneakums | and the version of the dosfstools package is 2.10 |
| 17:53:47 | sneakums | i've never actually tried it |
| 17:53:47 | HELPME | I have redhat 9, it's is not installed |
| 17:54:03 | HELPME | a link? |
| 17:54:04 | sneakums | worst case, you can download the source an dcompile it yourself |
| 17:54:48 | | Quit Luke1 () |
| 17:54:49 | sneakums | here's the source: http://ftp.debian.org/debian/pool/main/d/dosfstools/dosfstools_2.10.orig.tar.gz |
| 17:55:16 | HELPME | thanks, i'll try it |
| 17:56:42 | | Join jyp [0] (~jp@98.203-200-80.adsl.skynet.be) |
| 18:00 |
| 18:02:01 | preglow | HELPME: i'm guessing a format should fix it |
| 18:02:08 | preglow | HELPME: is rockbox able to access the disk? |
| 18:02:54 | HELPME | yes, can access it |
| 18:03:06 | HELPME | but I don´t think a format is a good idea |
| 18:03:35 | HELPME | then I might might launch Rockbox (and of course iRiver firmware) |
| 18:03:43 | HELPME | might=not |
| 18:04:05 | | Quit jyp ("poof!") |
| 18:04:09 | HELPME | I am running dosfsck 2.8 now |
| 18:04:11 | thegeek | ? |
| 18:04:13 | thegeek | dude |
| 18:04:16 | thegeek | if you format the drive |
| 18:04:30 | thegeek | hmm |
| 18:04:32 | preglow | HELPME: sure, it would be a last resort |
| 18:04:41 | HELPME | I will loser rockbox.iriver |
| 18:04:46 | preglow | yes, i know |
| 18:04:47 | thegeek | but hey |
| 18:04:49 | HELPME | I still have Rockbox |
| 18:04:52 | thegeek | are you running the latest kernel? |
| 18:04:53 | HELPME | :) |
| 18:05:02 | HELPME | yes, last kernel |
| 18:05:04 | thegeek | there was a kernel bug that fucked things with iriver |
| 18:05:08 | sneakums | after you format, just copy it over again |
| 18:05:13 | thegeek | mhm |
| 18:05:14 | preglow | thegeek: what kernel version? |
| 18:05:20 | thegeek | hmm |
| 18:05:21 | thegeek | let me see |
| 18:05:32 | thegeek | http://www.ussg.iu.edu/hypermail/linux/kernel/0406.1/0542.html |
| 18:05:35 | thegeek | 2.6.5 ? |
| 18:05:47 | thegeek | iriver+kernel+corruption">http://www.google.com/search?q=iriver+kernel+corruption |
| 18:05:48 | HELPME | dosfsck found something |
| 18:05:54 | | Join jyp [0] (~jp@129.23-136-217.adsl.skynet.be) |
| 18:06:34 | HELPME | dosfsck: Reclaimed 847 unused clusters |
| 18:06:38 | preglow | well |
| 18:08:21 | HELPME | dosfsck: Free cluster summary wrong (211974 vs. 212821) |
| 18:08:30 | HELPME | I corrected it |
| 18:08:35 | preglow | well, does it do any good? |
| 18:08:53 | HELPME | still testing |
| 18:10:03 | HELPME | I ran dosfsck again and got the same error :( |
| 18:10:18 | preglow | neat! |
| 18:10:28 | HELPME | u think so? |
| 18:10:38 | preglow | no, i was being sarcastic |
| 18:11:00 | HELPME | great!' |
| 18:11:11 | preglow | but i don't think the free cluster summary should be very decisive |
| 18:11:13 | thegeek | just format it |
| 18:11:17 | rasher | I'd just format |
| 18:11:28 | thegeek | and copy over rockbox if it does not work |
| 18:11:37 | rasher | wait |
| 18:11:41 | preglow | you can't copy over rockbox after having formatted it |
| 18:11:42 | preglow | heh |
| 18:11:43 | preglow | that is |
| 18:11:49 | preglow | format it, copy rockbox, then restart it |
| 18:11:54 | rasher | HELPME: can you bring up iRiver in usb-mode? |
| 18:12:03 | thegeek | obviously he can |
| 18:12:06 | HELPME | and hope my computer don't crash :( |
| 18:12:11 | rasher | thegeek: obviously? |
| 18:12:12 | thegeek | since he is running dosfsck |
| 18:12:14 | HELPME | rasher: yes |
| 18:12:17 | thegeek | ;) |
| 18:12:20 | rasher | he could be using rockbox usb mode |
| 18:12:26 | thegeek | hmm |
| 18:12:32 | thegeek | oh |
| 18:12:43 | rasher | so there's no way you can lose usb mode |
| 18:12:52 | preglow | ahh, i thought he was using usb mode in rockbox |
| 18:12:56 | thegeek | hmm |
| 18:12:56 | thegeek | but |
| 18:13:01 | thegeek | I thought usb-mode was hardware |
| 18:13:02 | thegeek | like |
| 18:13:11 | thegeek | but yeah |
| 18:13:14 | thegeek | ;) |
| 18:13:15 | preglow | well, it is, but i needs software to activate it |
| 18:13:16 | HELPME | rasher: no, I can't bring up iRiver firmware USB mode |
| 18:13:27 | thegeek | well that changes things a bit;) |
| 18:13:30 | rasher | it does |
| 18:13:32 | preglow | not really |
| 18:13:37 | preglow | you can format it, put in rockbox, and then restart it |
| 18:13:53 | | Quit jpburton5150 (Read error: 54 (Connection reset by peer)) |
| 18:14:13 | preglow | nothing says you have to restart the player after having formated it |
| 18:14:37 | HELPME | but what if Rockbox USB is messing up my drive |
| 18:14:38 | preglow | HELPME: this was a h140? |
| 18:14:45 | HELPME | preglow: yes |
| 18:14:48 | preglow | HELPME: it can't, usb mode is hardware |
| 18:15:08 | preglow | HELPME: the only thing rockbox does is stop accessing the hard drive so that the computer can do it itself |
| 18:15:59 | HELPME | a FORMAT through Rockbox might not be failure free |
| 18:16:06 | preglow | what makes you say that? |
| 18:16:28 | preglow | there is no 'through rockbox', all the accesses from the computer goes through hardware |
| 18:16:32 | preglow | rockbox doesn't enter into it |
| 18:16:39 | preglow | it just sits dumbly |
| 18:16:59 | preglow | the usb->ata is done by a bridge chip |
| 18:17:22 | HELPME | I like to hear Linus point on this before I do anything stupid |
| 18:17:31 | preglow | as would i ;) |
| 18:20:03 | | Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) |
| 18:20:15 | | Quit ripnetUK (Client Quit) |
| 18:23:52 | | Join coob [0] (pen0r@82-44-227-205.cable.ubr11.haye.blueyonder.co.uk) |
| 18:25:03 | | Quit pill (Read error: 104 (Connection reset by peer)) |
| 18:29:10 | | Join hubble [0] (hubble@h13n1fls302o1033.telia.com) |
| 18:29:35 | hubble | yes, finally got my first RXAK on the I2C interface! =) |
| 18:29:42 | | Join webguest87 [0] (~3e9ea7ba@labb.contactor.se) |
| 18:31:53 | rasher | hubble: What does this mean? |
| 18:32:39 | | Join pill [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
| 18:33:32 | hubble | rasher: not much, but it's a start getting the i2c driver to the audio chip working |
| 18:33:52 | rasher | Hurray |
| 18:34:17 | rasher | Any reason why I should not modify the pluginindex page to include iRiver info? |
| 18:34:46 | Quelsaruk | pluginidex page? |
| 18:34:48 | Quelsaruk | hmmm |
| 18:34:51 | rasher | http://www.rockbox.org/twiki/bin/view/Main/PluginIndex |
| 18:34:58 | rasher | and the subpages I guess |
| 18:35:14 | rasher | or should that only be done when the port is ready? |
| 18:35:33 | rasher | At any rate, that page would look so much nicer as a table |
| 18:36:19 | rasher | oh, it's magic |
| 18:36:38 | Quelsaruk | hmm |
| 18:36:40 | Quelsaruk | well |
| 18:36:48 | Quelsaruk | that page must be changed |
| 18:36:57 | Quelsaruk | as archos player can use Snow right now too |
| 18:37:01 | rasher | heh |
| 18:37:03 | Quelsaruk | and maybe more plugins |
| 18:37:04 | Quelsaruk | so... |
| 18:37:08 | rasher | well the page itself is dynamic |
| 18:37:49 | rasher | so you'd just have to edit the PluginSnow page |
| 18:37:50 | rasher | and so on |
| 18:38:24 | preglow | hubble: do you know how many components are connected by i2c? i know of the codec and the eeprom |
| 18:38:30 | rasher | But I'd like to try and change the page to be a table |
| 18:38:55 | rasher | guess I'll try and do it - and I'll reverse it if it turns out to be rubbish |
| 18:39:26 | hubble | preglow: atleast the codec and fm chip |
| 18:40:29 | preglow | the eeprom is i2c as well, but i don't think rockbox will use that |
| 18:40:56 | hubble | preglow: ok.. going to see if i get an ack from the fm chip soon now |
| 18:41:21 | preglow | hubble: that'd be really cool |
| 18:41:32 | preglow | stuff really did accelerate after having a bootloader |
| 18:42:20 | hubble | but audio support is pretty far away.. we need a i2s driver aswell.. maybe should update to todo wiki about that =) |
| 18:42:32 | HCl | that reminds me |
| 18:45:23 | HCl | how do i feed sound to rockbox? |
| 18:45:37 | hubble | HCl: via i2s |
| 18:45:58 | hubble | HCl: which can be driving using DMA transfers |
| 18:46:04 | hubble | diving = driven |
| 18:46:25 | linuxstb | HCl: The "audio API" is still to be decided. How would you like it to work? |
| 18:46:57 | HCl | uh. |
| 18:47:07 | HCl | linuxstb: well, hold on a sec.. |
| 18:48:05 | HCl | well, i haven't really looked at it yet |
| 18:48:11 | HCl | but pretty much, something that'll play pcm data |
| 18:48:20 | HCl | till it reaches the end of it |
| 18:49:09 | HCl | Whenever realtime sound output is operational, |
| 18:49:09 | HCl | pcm_submit is responsible for timing, and should not return until it |
| 18:49:09 | HCl | has successfully processed all the data in its input buffer (pcm.buf). |
| 18:49:15 | HCl | from the gnuboy hacking documentation |
| 18:49:44 | | Join webguest28 [0] (~54de59b4@labb.contactor.se) |
| 18:49:56 | linuxstb | HCl: Yes, I read that as well. I guess that the audio API needs both blocking and non-blocking audio functions then. |
| 18:50:04 | HCl | yea |
| 18:50:36 | linuxstb | The audio system will also need to know the sample-rate, number of channels etc of the PCM data. |
| 18:50:42 | HCl | yea |
| 18:50:55 | linuxstb | But it's all straightfoward stuff. |
| 18:51:49 | | Join iriver [0] (~54ee108a@labb.contactor.se) |
| 18:52:05 | preglow | yes |
| 18:52:05 | | Quit webguest28 (Client Quit) |
| 18:52:17 | iriver | I'm interested in the audio API too |
| 18:53:36 | iriver | Have you looked at the MCF5249 user manual chapter 17? |
| 18:53:46 | HCl | i can't say i have |
| 18:53:48 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) |
| 18:53:52 | *** | Saving seen data "./dancer.seen" |
| 18:53:56 | linuxstb | I think I browsed it a couple of months ago... |
| 18:55:20 | linuxstb | As the Wiki page says, there are probably going to be three separate subsystems - the "audio-playback subsystem", the "codec subsystem" and the low-level hardware drivers. |
| 18:55:30 | iriver | Figure 17-1 (Audio Interface Block Diagram) is quite nice |
| 18:55:51 | linuxstb | Personally, I'm concentrating on the codecs at the moment. I'll leave the hardware to Linus and the audio-playback to people who are more familiar with Rockbox. |
| 18:56:19 | iriver | We need some queue struture which can signal when they are almost empty |
| 18:56:32 | * | HCl agrees with linuxstb |
| 19:00 |
| 19:00:50 | | Quit pike (Read error: 60 (Operation timed out)) |
| 19:01:42 | iriver | who are the audio-playback people of Rockbox? |
| 19:01:48 | iriver | Linus :) |
| 19:03:14 | | Part webguest87 |
| 19:03:36 | Tang | lol you don't let him some time for real life? lol |
| 19:03:43 | HCl | :P |
| 19:04:09 | iriver | it is great that hubble worked on the i2c |
| 19:04:24 | iriver | is working on.. that is :) |
| 19:04:36 | | Quit hubble () |
| 19:04:49 | linuxstb | iriver: I think I'm the only person actively working anything to do with the software parts of audio playback at the moment. |
| 19:04:50 | HCl | whats rxak? |
| 19:05:19 | coob | are you guys still planning on using MAD for mp3 playback? |
| 19:05:24 | preglow | coob: yes |
| 19:05:34 | iriver | i am looking on the i2s and mcf5249 low-level audio driver API |
| 19:05:35 | preglow | coob: it's a great decoder, and i don't see any other libs as better alternatives |
| 19:05:40 | linuxstb | coob: yes - I'm working on getting a test decoder working at the moment. |
| 19:06:30 | preglow | HCl: i2c signal sent from transmitting part, i think |
| 19:06:41 | coob | ah right - I have no idea of the comparison between CPU power of the iPod's dual ARM's and the coldfire stuff, but I'm not sure how much optimisation of MAD you'll have to do |
| 19:07:12 | preglow | coob: i don't know how much we HAVE to do, but i'm having a look at the dsp parts of the coldfire as we speak |
| 19:07:31 | coob | there's dsp parts? lucky bastards :) |
| 19:07:43 | linuxstb | As HCl (I think) said earlier today, we want to optimise everything as much as possible - the more efficient the playback, the more we can do at the same time (e.g. games). |
| 19:07:46 | preglow | not much to speak of, there is a mac unit |
| 19:07:57 | preglow | with 48 bit wide registers |
| 19:07:59 | preglow | more would be nice |
| 19:08:00 | HCl | not only that, the more efficient, the less battery we use |
| 19:08:06 | HCl | and the more runtime we get |
| 19:08:13 | linuxstb | HCl: Absolutely. |
| 19:08:17 | Tang | and it will let more battery power too |
| 19:08:31 | * | rasher has an argument with TWiki |
| 19:08:34 | Tang | (oups i was too late) |
| 19:09:35 | Tang | ABout the audio codec |
| 19:09:55 | iriver | I was thinking about a general decoder function interface |
| 19:09:56 | iriver | we could use function pointers for replacing the codec functionality |
| 19:10:04 | Tang | an HA memeber was wondering |
| 19:10:22 | Tang | if the seamless playback was lnked with the decoder libbrary |
| 19:10:26 | Tang | or not |
| 19:10:47 | Tang | since mp123 (used by foobar) is seamless |
| 19:10:47 | iriver | linuxstb: what function interface would you suggest? |
| 19:10:54 | Tang | nut not MAD |
| 19:10:58 | Tang | :/ |
| 19:14:36 | preglow | it will be seamless |
| 19:15:16 | preglow | the decoder library itself doesn't matter, we'll have to write the code that ties different tracks together |
| 19:15:26 | preglow | and we'll make it gapless |
| 19:15:31 | linuxstb | Starting at the lowest level, I think there's going to be a PCM buffer - the low-level audio driver will run in it's own thread, constantly trying to empty that buffer, and the audio system will be doing it's best to make sure it's never empty. |
| 19:15:52 | linuxstb | If the audio system succeeds, then playback will be gapless. |
| 19:16:07 | HCl | sounds great. |
| 19:16:16 | sneakums | and the winning will be large |
| 19:16:20 | HCl | especially because i'd be able to link gnuboy directly to that buffer xD |
| 19:16:41 | linuxstb | Only possibly flaw in playback could be when the sample-rate changes (e.g. from 44.1KHz to 48KHz). |
| 19:16:59 | HCl | you need to be able to set the samplerate of the pcm buffer of rockbox |
| 19:17:07 | HCl | etc |
| 19:17:41 | linuxstb | I think we need more detail than that - i.e. the PCM buffer will contain blocks of data, and each block can be a different samplerate. |
| 19:18:01 | iriver | function pointer info: http://www.newty.de/fpt/intro.html |
| 19:18:37 | preglow | linuxstb: i really don't think a gap at sample rate change matters, stuff that is supposed to be gapless won't have different sample rates anyway |
| 19:18:54 | linuxstb | preglow: Agreed. |
| 19:19:29 | preglow | it's not worth the pain of having to keep track of the position in the buffer at which we'll have to change sample rate |
| 19:19:50 | HCl | mhm |
| 19:20:13 | iriver | There will will need to be small PCM buffer internally in the MCF5249 |
| 19:20:35 | linuxstb | preglow: Not sure if I agree. I think it depends how big the PCM buffer is going to be. We don't want to have to wait for it to empty before starting to decode the next track, just because it is using a different samplerate. |
| 19:20:38 | preglow | the area around the sample rate change probably wont be guaranteed to be up to par by the phillips codec either |
| 19:20:51 | iriver | It will be transfered directly via DMA to the I2S bus out to the UDA1380 |
| 19:21:02 | * | rasher updates PluginIndex ( http://www.rockbox.org/twiki/bin/view/Main/PluginIndex ) |
| 19:21:17 | rasher | It's slightly less dynamic now, but much easier to read |
| 19:21:37 | preglow | rasher: looks great |
| 19:21:53 | preglow | rasher: that mess really did need to be tableified |
| 19:21:54 | rasher | Should I add iRiver and Gmini to the table? |
| 19:22:00 | preglow | rasher: i don't see why not |
| 19:22:06 | rasher | Okay, I'll go ahead |
| 19:22:37 | preglow | the information is already there, might as well complete it |
| 19:22:47 | iriver | DMA is performed on the internal audio bus of the MCF5249 |
| 19:23:08 | preglow | linuxstb: i don't think we'll end up with a very large buffer |
| 19:23:20 | preglow | we might end up with several, as a matter of fact |
| 19:23:27 | preglow | sample rate can be a buffer tag, then |
| 19:23:51 | iriver | the large buffer will be for undecoded codec data (raw mp3, ogg, flac etc.) |
| 19:23:52 | preglow | if the buffers are small enough, it's more than adequate to only do that check when we change buffers |
| 19:23:57 | linuxstb | Yes, "current track" and "next track" PCM buffers would work well. |
| 19:24:31 | preglow | linuxstb: no, i was thinking a bit more granular than that, several buffers no matter what state you're in |
| 19:24:35 | preglow | this is the way most audio apis do it |
| 19:25:06 | linuxstb | So why would we need more than one PCM buffer? |
| 19:25:34 | sneakums | the difference between a single buffer with tagged blocks and multiple tagegd buffers is not so obvious to me |
| 19:25:36 | preglow | it's good to have another buffer to work on when you send it to the buffer you've just finished to the codec |
| 19:26:28 | preglow | this is the way it's done on most audio apis on computers, but there might of course be good reason to not do it this way on a portable |
| 19:26:46 | linuxstb | sneakums: The blocks can be of varying size, the PCM buffers will (I assume) be a constant size. |
| 19:27:04 | iriver | I think a small PCM transition buffer is needed to ensure gapless/crossfading |
| 19:27:17 | rasher | What's the name of a joystick-press on the iRiver? |
| 19:27:28 | iriver | SELECT |
| 19:27:37 | preglow | like you have one buffer, fill it, send it to the dac, and instead of waiting until the das is done with it, you can start on a new buffer straight away |
| 19:27:45 | preglow | the dac |
| 19:27:50 | preglow | i still type like a pig |
| 19:28:24 | linuxstb | preglow: are you talking about tiny PCM buffers inside the low-level audio driver? |
| 19:28:44 | preglow | i'm talking about what the audio codecs will pass to the low-level audio driver |
| 19:30:10 | linuxstb | I'm thinking that from the point of view of the high-level codecs and audio API, then will just have a PCM buffer to fill with data. They may themselves need additional PCM buffers, and the audio driver may need additional buffers, but there will be one main "transfer PCM buffer". |
| 19:31:15 | preglow | the audio driver should not need additional buffers |
| 19:31:33 | preglow | it should just dma the memory it gets straight to the codec chip if it can take more data |
| 19:31:42 | preglow | barring the need for conversion of the data, of course |
| 19:31:55 | preglow | but we should try avoiding that |
| 19:32:42 | linuxstb | So starting from the bottom, do we agree that there is a single PCM buffer the audio driver reads from, or do you multiple buffers? |
| 19:32:54 | linuxstb | ^do you want multiple buffers? |
| 19:33:34 | preglow | it's the same thing, really, it's just that with one buffer, a fast decoder will constantly have to watch that it doesn't write into an area of the buffer that hasn't yet been sent to the codec chip |
| 19:33:56 | preglow | but of course, it can all be wrapped in book keeping functions |
| 19:34:14 | preglow | i don't think i'm very seriously against having one buffer, this is just the way i'm used to doing it |
| 19:34:37 | preglow | if the guys who now the hardware better is biased against one of the methods, that's what we'll picj |
| 19:34:40 | preglow | pick |
| 19:35:23 | linuxstb | But it should be (mostly) independent of the hardware - we need to abstract the API higher than that. |
| 19:35:52 | rasher | The keys for the chessclock plugin on iRiver are crazy |
| 19:35:57 | preglow | yep, it will be hardware independent no matter how you do it |
| 19:36:13 | preglow | rasher: then port it to use better keys ;) |
| 19:36:19 | sneakums | the idea of threads passing buffers back and forth like a bucket brigade makes a pretty picture in my head, i will say that |
| 19:37:03 | iriver | codec independent is also important - we need a common interface |
| 19:37:06 | linuxstb | sneakums - yes, we need to try and keep it as simple as possible. |
| 19:37:11 | rasher | preglow: I'll have a look at that later, for now, I be wikihacking |
| 19:37:23 | preglow | sneakums: yes, i like it as well, and the decoder has to call a function to pass it a free buffer, that's where things will block if you've filled all the buffers you can and have to wait before you can decode more |
| 19:37:58 | linuxstb | iriver - yes, that's sort of what I'm looking at in detail at the moment. I'm implementing various decoders using different libraries and then I'll suggest a sensible common API. |
| 19:38:13 | iriver | great |
| 19:38:28 | preglow | i think we'll need to codec layers as well, one for streaming codecs, and one for non-streaming ones |
| 19:38:38 | preglow | two codec layers, damn, i have to start reading shit before i press enter |
| 19:38:57 | | Join mecraw [0] (~mecraw@c-24-9-220-243.client.comcast.net) |
| 19:39:11 | iriver | i don't quite follow |
| 19:39:31 | preglow | mp3, ogg = streaming. xm, sid, mod = non-streaming |
| 19:39:50 | preglow | once the latter is loaded, rockbox doesn't have to think about disk accesses until the track is done |
| 19:40:28 | preglow | with the former, rockbox has to constantly watch if the audio buffer is nearing its end, and load more data if it's needed |
| 19:41:34 | rasher | could anybody explain this to me: #define CUBE_Z_INC (BUTTON_ON | BUTTON_UP) |
| 19:43:14 | rasher | ah, got it |
| 19:43:53 | iriver | preglow: yeah, there is a lot of things to think about. Didn't think about sid, mod |
| 19:45:15 | iriver | to me sid and mod will also be streaming once they have been through the synth |
| 19:46:48 | linuxstb | No, I think the difference is that with a streaming codec, you read (and then discard) X bytes of the input stream, and then that generates Y bytes of PCM data. |
| 19:47:09 | linuxstb | With a SID/MOD/etc file, the input file isn't a stream. |
| 19:47:28 | rasher | Could we honestly claim that metronome is working on iRiver? |
| 19:48:18 | preglow | gotta go the shop, brb |
| 19:48:21 | rasher | I guess I'll put it down as supported |
| 19:54:30 | rasher | I don't get the tap mode.. |
| 19:55:14 | rasher | would perhaps make more sense if I had sound |
| 20:00 |
| 20:02:02 | preglow | what's tape mode? |
| 20:02:09 | preglow | i can't start it |
| 20:02:12 | preglow | tap mode.. |
| 20:02:41 | iriver | I guess it is able to tell the tempo you are tapping |
| 20:02:49 | rasher | or should be, at least :) |
| 20:02:52 | preglow | yes, sure, but i don't get how to start it |
| 20:02:53 | preglow | heh |
| 20:02:57 | iriver | i can't get it to work neither |
| 20:03:13 | rasher | I just went by the keyapping in the source |
| 20:04:22 | HCl | whats metronome again? |
| 20:04:37 | rasher | A thing that goes "tick, tick, tick" at a specified interval |
| 20:04:42 | preglow | the thing on a piano that goes tick tock |
| 20:04:44 | Tang | quote: |
| 20:04:48 | Tang | preglowit will be seamless |
| 20:05:05 | preglow | Tang: yes, what about it? |
| 20:05:19 | Tang | no i wanted to thak you for the answer |
| 20:05:22 | Tang | preglow |
| 20:05:23 | preglow | ahh |
| 20:05:23 | preglow | heh |
| 20:05:28 | preglow | no problem |
| 20:05:33 | Tang | i just failde my copy/cut |
| 20:05:35 | Tang | lol |
| 20:05:37 | preglow | there's no point in having gaps in the sound |
| 20:05:56 | Tang | Thanks i'll transmit this on HA |
| 20:05:57 | Tang | :) |
| 20:06:01 | rasher | HA? |
| 20:06:20 | preglow | hydrogenaudio |
| 20:07:38 | Tang | yes Hydrogenaudio |
| 20:07:41 | Tang | indeed |
| 20:07:43 | Tang | :) |
| 20:07:54 | Tang | with Linus agreement |
| 20:08:25 | preglow | linux himself has said that rockbox will use the extra lame header data, actually |
| 20:08:26 | Tang | i tried to relay the latestrockbox iRiverport progress |
| 20:08:34 | Tang | okay |
| 20:08:34 | preglow | linu_S_ |
| 20:08:42 | preglow | this is getting confusing |
| 20:08:42 | Tang | linusM |
| 20:08:44 | Tang | i see |
| 20:08:49 | preglow | linusN, actually :P |
| 20:08:49 | Tang | lol |
| 20:08:55 | Tang | ops sorry |
| 20:09:15 | Tang | as i said i was relaying the latest progress at HA |
| 20:09:30 | Tang | i hope this will motivate some skilled coders |
| 20:09:38 | Tang | to make tehir hands dirty |
| 20:09:42 | Tang | in the codec part |
| 20:09:58 | Tang | (especially for MPC playback) |
| 20:11:01 | preglow | more help is appreciated, of course |
| 20:11:32 | Tang | okay |
| 20:11:41 | Tang | i've jsut put the info |
| 20:11:55 | Tang | i'll see if there is some reaction |
| 20:12:07 | Tang | and if not I'll try to contact some guys directly |
| 20:13:08 | Tang | (especially Peter pawlowski foobar2k devlopper, who released the integer libmusepack library) |
| 20:13:12 | | Join xen` [0] (~xen@ADijon-151-1-59-186.w83-196.abo.wanadoo.fr) |
| 20:13:49 | preglow | yes, that's what we'll use |
| 20:15:01 | linuxstb | Tang: Something no-one has really considered is real-time encoders for Rockbox. Recording will come first as WAV-only, and we will then need to think about a lossy encoder that can work in real-time on the iRiver. Maybe the HA people have some suggestions for that. |
| 20:15:24 | preglow | that will most certainly require custom code |
| 20:15:43 | Tang | Okay linuxstb i'll ask at HA place |
| 20:15:44 | Tang | :) |
| 20:16:13 | Tang | but indeed i'm not aware of anything "builtin" for lossless real time encoding |
| 20:16:26 | Tang | (integer one) |
| 20:17:07 | linuxstb | I'm thinking about lossy, not lossless. For lossless, we have WAV. |
| 20:17:15 | preglow | and with a bit of luck, flac |
| 20:17:48 | linuxstb | A flac encoder would be nice, buit the space savings don't make it a high priority IMO. |
| 20:18:09 | linuxstb | I would prefer 100% stable and reliable WAV recordings. |
| 20:18:11 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 20:18:37 | preglow | nothing is a high priority right now, heh |
| 20:18:39 | preglow | we need audio |
| 20:19:04 | preglow | but yes, a realtime lossy codec would rock |
| 20:19:06 | linuxstb | Also, battery power is an issue with field-recording - so WAV would hopefully allow the CPU to slow right down to the minimum. |
| 20:19:11 | Tang | Ah sorry i read too quick |
| 20:19:15 | rasher | note to self: change keymappings for stopwatch (and see about making it use the entire screen) |
| 20:19:19 | Tang | i understood lossless |
| 20:19:25 | preglow | linuxstb: too bad the hard drive is what sucks most power :/ |
| 20:19:34 | Tang | indeed i believed there where some libs for encoding |
| 20:19:42 | Tang | 'ill ask for both if you want |
| 20:19:50 | preglow | Tang: there are, but they are floating point and too slow for us |
| 20:20:00 | Tang | okay i undertsand |
| 20:20:02 | preglow | Tang: mostly, at least, i don't know much about it |
| 20:20:06 | Tang | i'm goona ask |
| 20:20:11 | linuxstb | Most codecs are optimised for fast decoding and slow encoding. Not good for the iRiver. |
| 20:20:32 | Tang | hum for lossless you talk i guess |
| 20:20:34 | Tang | ? |
| 20:20:49 | linuxstb | Tang: No, both lossy and lossless codecs are like that. |
| 20:20:54 | Tang | ah okay |
| 20:20:58 | Tang | i'm gonna ask |
| 20:21:09 | Tang | no fear( (lol) |
| 20:21:29 | Tang | (just joking, HA people aren't cruel ;)) |
| 20:35:01 | | Quit Schnueff ("leaving") |
| 20:39:29 | rasher | http://www.rockbox.org/twiki/bin/view/Main/PluginIndex looking much better now |
| 20:41:03 | Quelsaruk | yes |
| 20:41:05 | Quelsaruk | looking better |
| 20:41:22 | rasher | And with up-to-date iRiver info |
| 20:41:29 | rasher | (I hope) |
| 20:41:43 | Quelsaruk | rasher: can you add player to the snow and cube plugins? |
| 20:41:43 | Quelsaruk | :D |
| 20:41:51 | rasher | oh right |
| 20:42:40 | Quelsaruk | thx |
| 20:44:11 | rasher | I don't know the keynames though :\ |
| 20:44:53 | Quelsaruk | hmmm |
| 20:44:57 | Quelsaruk | then, don't do it |
| 20:44:57 | Quelsaruk | :D |
| 20:45:12 | rasher | you do it then :) |
| 20:45:27 | Tang | Indeed great job for pluginindex rasher! |
| 20:45:27 | Quelsaruk | no way |
| 20:45:28 | Quelsaruk | ;) |
| 20:46:02 | Tang | i 've created the asking thread for lossless integer encoder under open source licensing |
| 20:46:26 | Tang | and asked the same for lossy in the HA thread dedicated to the Rbx iRiverport |
| 20:46:28 | Tang | :) |
| 20:46:39 | Tang | i'm gonna put the link if you want |
| 20:47:34 | HELPME | Too all linux users: which device /dev/ do you have associated to your iRiver USB mount in /etc/fstab? |
| 20:48:03 | linuxstb | HELPME: I think it depends on the other hardware in your PC - for me, it's /dev/sdb1 |
| 20:48:15 | Quelsaruk | HELPME: i have my archos in /dev/sda1 |
| 20:48:18 | Tang | The lossless thread: |
| 20:48:26 | Tang | http://www.hydrogenaudio.org/forums/index.php?act=ST&f=19&t=31471&st=0#entry272923 |
| 20:48:53 | Tang | The same question for lossy encoder in the rbx iRiverport at HA: |
| 20:48:56 | Tang | http://www.hydrogenaudio.org/forums/index.php?showtopic=27390&pid=272907&st=0&# |
| 20:49:12 | Tang | Feel free to tell me if you see something to be corrected |
| 20:49:15 | Tang | i'll edit |
| 20:49:16 | Tang | :) |
| 20:51:47 | linuxstb | Tang: They seem the right questions to me, thanks. |
| 20:52:01 | Tang | Okay linuxstb |
| 20:52:07 | Tang | don't thank me |
| 20:52:19 | Tang | it's me to thank all you ;) |
| 20:53:38 | | Join R3nTiL_ [0] (~zorroz@217.30.249.130) |
| 20:53:54 | *** | Saving seen data "./dancer.seen" |
| 20:54:14 | HELPME | linustb & Quesaruk: thanks, I use /dev/sda1 |
| 20:54:34 | HELPME | so that is not the reason why my H140 disk is seemed up |
| 20:57:48 | | Quit Sucka ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 20:58:50 | Quelsaruk | hmmm |
| 20:59:27 | Quelsaruk | HELPME: do you still have that problem with bad sectors? |
| 21:00 |
| 21:00:19 | HELPME | i will just test |
| 21:01:26 | preglow | what, doesn't c guarantee use of arithmetic shifts when you shift signed numbers? |
| 21:01:49 | Quelsaruk | HELPME: is your drive under warranty? did you make something that can void that warranty? if not, you could ask the company to repair it |
| 21:02:41 | HELPME | I install Rockbox bootloader :) |
| 21:02:55 | HELPME | i don't think iRiver will be happy about it! |
| 21:03:19 | sneakums | well, they already have your money. |
| 21:03:41 | Quelsaruk | hmmm |
| 21:03:53 | Quelsaruk | can't you take out the bootloader? |
| 21:03:59 | preglow | he can't flash it |
| 21:04:01 | linuxstb | HELPME: Have you reformatted yet, or are you waiting for Linus's advice? |
| 21:04:11 | HELPME | waiting for linus |
| 21:04:17 | preglow | i don't think he'll be on tonight |
| 21:04:24 | preglow | least, doesn't seem like it |
| 21:04:50 | HELPME | Quelraruk: read today's irc log |
| 21:04:56 | linuxstb | So there's still one option yet - as others have said, there shouldn't be a problem to reformat and then copy rockbox.iriver back. But there's no harm in waiting. |
| 21:05:58 | preglow | rockbox.iriver and .rockbox dir, yes |
| 21:06:18 | preglow | rockbox with no .rockbox dir just fails miserably |
| 21:06:18 | preglow | heh |
| 21:06:44 | preglow | does anyone know how long a 68k 'int' is? |
| 21:06:58 | sneakums | i'd be surprised if it weren't four bytes. |
| 21:07:02 | preglow | yes, so would i |
| 21:07:08 | preglow | but that would certainly explain this |
| 21:07:25 | HELPME | I fixed the clusters errors previously, but now I get them again "Free cluster summary wrong (221742 vs. really 221739)" |
| 21:08:44 | HELPME | I tried deleting a lot of my data from my H140, but when I tried to shutdown Rockbox it hung showing "Shutting Down" |
| 21:08:57 | HELPME | had to reset |
| 21:10:10 | HELPME | I have also experienced that Rockbox USB also crashes Windows when inserted |
| 21:10:21 | preglow | sizeof(int) = 4, yes |
| 21:10:32 | linuxstb | preglow: I've just done a check, and "int" is 4 bytes, "short" is 2 bytes and "long long" is 8 bytes. |
| 21:10:42 | linuxstb | Beat me to it... |
| 21:10:43 | preglow | yes, i did so as well |
| 21:10:44 | preglow | heh |
| 21:11:06 | preglow | HELPME: again... rockbox has nothing to do with the usb |
| 21:11:23 | linuxstb | But I've noticed that the Rockbox snprintf doesn't support floats or "long long". |
| 21:11:32 | preglow | it just passes control to the usb gateway chip |
| 21:11:40 | Tang | hi HELPME, sorry for your iHP |
| 21:11:44 | preglow | linuxstb: floats i understand, long longs you should never use |
| 21:11:56 | rasher | Is there any reason the stopwatch shouldn't be keeping more than 10 laptimes? |
| 21:11:59 | Tang | don't knew the whole story |
| 21:12:03 | preglow | i've noticed it doesn't understand %i |
| 21:12:11 | Tang | is it linked with Rbx or something else? |
| 21:12:39 | linuxstb | preglow: I was just using them for debugging output. |
| 21:12:48 | linuxstb | Well, trying to use them... |
| 21:13:03 | preglow | linuxstb: yes, but if you debug something by printing long longs, you're obviously using them :PP |
| 21:13:37 | linuxstb | I was trying to use a long long to calculate the % decoding speed - to prevent overflows. |
| 21:13:51 | linuxstb | But I changed the formula instead. |
| 21:13:53 | preglow | ahh |
| 21:14:01 | preglow | that's more qualified use |
| 21:14:48 | linuxstb | But as I said, libFLAC is full of 64-bit integers, so that's an area to investiage. |
| 21:15:41 | preglow | yup |
| 21:16:48 | linuxstb | I'm eagerly waiting for Linus to work his magic. |
| 21:17:00 | linuxstb | ... and get the iRiver running at full speed. |
| 21:17:58 | | Quit R3nTiL_ () |
| 21:18:39 | * | rasher has a look at solitaire.c |
| 21:19:08 | rasher | that sure is a lot of keybindings |
| 21:21:21 | izzy | linuxstb: have you measured if flac requires more cpu time than mp3 to decode? with average compression on both |
| 21:21:52 | linuxstb | izzy: I'm in the process of getting libmad running on the iRiver as we speak. When I finish that, I can do some speed tests. |
| 21:22:27 | izzy | ok, that's good :) |
| 21:22:31 | izzy | how about on x86? |
| 21:22:37 | linuxstb | What would you consider "average compression" for MP3? 128kbps? |
| 21:22:59 | linuxstb | izzy: No, I don't think that will be that useful. |
| 21:23:29 | izzy | maybe more, 168kbps perhaps |
| 21:23:49 | izzy | I was just wondering because I haven't tried flac even on pc :) |
| 21:24:16 | izzy | I use ogg for my own encodings |
| 21:24:54 | izzy | coldfire manual says "MP3 decode requires less than 20MHz CPU bandwidth" |
| 21:26:05 | linuxstb | Well, on my 2.8GHz Xeon, a 4 minute FLAC file takes about 2 seconds to decode. |
| 21:26:34 | rasher | Using linux? Time it |
| 21:27:09 | linuxstb | rasher: I did. "user 0m1.950s" |
| 21:27:14 | rasher | ah |
| 21:27:20 | rasher | You sounded so vague :) |
| 21:27:21 | linuxstb | Just trying OGG now... |
| 21:28:02 | linuxstb | 2.594s for a 192kbps OGG |
| 21:28:29 | izzy | hmm |
| 21:29:08 | sneakums | 3.3 secs on a 1.5GHz G4 for a 4.5 min ~85kbps vorbis |
| 21:29:19 | sneakums | with ogg123 |
| 21:29:24 | sneakums | now there's a useless datapoint for you |
| 21:29:37 | Tang | ogg require more processing than mp3 |
| 21:29:42 | Tang | it's well known |
| 21:30:16 | linuxstb | Just trying MP3 now - lame "−−alt-preset extreme" gave me 193.4kbps (similar bitrate to the ogg file) |
| 21:30:28 | linuxstb | ^sorry, −−alt-preset standard |
| 21:31:29 | rasher | hey, putting "cube" in high-speed mode and limiting the rotation to one axis looks sortof cook |
| 21:31:33 | rasher | cool |
| 21:31:57 | linuxstb | "madplay -o wav:" gave me 2.834s. So that compares with 2.594 for OGG and 1.950 for FLAC in my very non scientific tests. |
| 21:33:38 | Tang | lol |
| 21:34:47 | linuxstb | And a 192kbps MP2 file was 2.275s - so unsurprisingly MP2 is simpler than MP3 and OGG. |
| 21:35:08 | linuxstb | Let's see how they compare on the iRiver. |
| 21:35:11 | izzy | I would also guess that encoding of flac is easier task than lossy formats |
| 21:35:31 | linuxstb | izzy: Don't make me do all that again :-) |
| 21:35:35 | izzy | :D |
| 21:35:44 | izzy | I didn't mean that ;) |
| 21:36:31 | linuxstb | But yes, I think the flac encoder is the quickest of all of them. |
| 21:36:38 | Tang | hum not sure encoding in flac 'll be easier than in lossy format |
| 21:36:57 | rasher | Couldn't the 64bit ints be messing things up? |
| 21:37:15 | rasher | or was that in the encoding? |
| 21:37:25 | rasher | nevermind me, I'm babbling |
| 21:37:34 | linuxstb | OK :-) |
| 21:37:56 | linuxstb | What did you mean by "messing things up"? Do you mean slowing it down, or causing other problems? |
| 21:38:11 | rasher | slowing it down |
| 21:39:06 | linuxstb | Yes, I'm sure it is. |
| 21:39:18 | izzy | flac is still in integers only? |
| 21:39:44 | sneakums | computers should all be 64-bit by now anyway |
| 21:39:51 | linuxstb | The decoding is, but the encoding isn't. |
| 21:39:51 | sneakums | it's the future, dagnabbit! |
| 21:40:09 | izzy | linuxstb: ok |
| 21:41:02 | izzy | has anyone tried to compile ogg/tremor yet? |
| 21:41:23 | linuxstb | No, but it's next on my list after libmad. |
| 21:42:12 | sneakums | first you're flac'y, then go mad, and finally you just sit there and tremor. |
| 21:42:18 | linuxstb | lol. |
| 21:42:23 | izzy | :) |
| 21:42:29 | linuxstb | I'll be waving at the end of it. |
| 21:51:23 | preglow | sneakums: hahah |
| 21:54:37 | | Quit Ka (Read error: 110 (Connection timed out)) |
| 21:54:54 | | Join Ka [0] (~tkirk@pcp0010733332pcs.howard01.md.comcast.net) |
| 22:00 |
| 22:12:14 | HCl | :P |
| 22:12:39 | rasher | mmm solitaire |
| 22:13:28 | thegeek | hehe |
| 22:20:03 | HELPME | PROBLEM FIXED - My H140 finally started with the iRiver firmware... I don't know what was wrong |
| 22:20:22 | rasher | :) |
| 22:20:35 | HELPME | I ran dosfsck several times |
| 22:21:00 | HELPME | tried starting the iriver firmware 20-30 times with no luck |
| 22:21:12 | HELPME | strange :) |
| 22:21:35 | HELPME | gotta go |
| 22:21:43 | | Quit HELPME ("CGI:IRC") |
| 22:36:28 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 22:51:36 | | Quit DMJC-L ("Leaving") |
| 22:53:57 | *** | Saving seen data "./dancer.seen" |
| 22:54:07 | | Join muesli- [0] (muesli_tv@1Cust36.tnt4.hnr2.deu.da.uu.net) |
| 22:54:35 | muesli- | g'mornin ladiez :D |
| 22:54:39 | Tang | Hi Muesli! |
| 22:54:46 | Tang | you're the same from MR? |
| 22:54:49 | muesli- | hi Tang! |
| 22:54:52 | Tang | :) |
| 22:54:55 | muesli- | yepp, i am ;) |
| 22:55:04 | muesli- | bonjour mon amour ;) |
| 22:55:05 | Tang | Okay and so do I for tang ;) |
| 22:55:08 | Tang | lol |
| 22:55:28 | muesli- | dont blame me for my lousy french ;) |
| 22:55:29 | Tang | we are on a very serious IRC channel mr Museli :o |
| 22:55:40 | Tang | (you're not English?) |
| 22:55:59 | muesli- | no, i am not...i am german |
| 22:56:29 | Tang | AH okay |
| 22:56:36 | Tang | my english too won't be perfect |
| 22:56:43 | Tang | (cause I'm french) |
| 22:57:13 | muesli- | see query ;) |
| 22:57:21 | Tang | (gutten tag and ich li bedich is all i know in Deutch, don't care the spelling) |
| 22:57:43 | muesli- | see query ;) |
| 22:58:25 | Tang | "see query"? |
| 22:58:49 | muesli- | which irc-client or you using? |
| 22:59:20 | Tang | hum i'm using chatzillia |
| 22:59:22 | muesli- | it will probably be mirc if you're using windows |
| 22:59:30 | Tang | in fact |
| 22:59:39 | Tang | (a plugin for firefox) |
| 22:59:50 | muesli- | a query is a seperate windows for private chats |
| 22:59:57 | Tang | ah oaky |
| 23:00 |
| 23:00:04 | Tang | i see it |
| 23:01:11 | | Quit DMJC ("Leaving") |
| 23:03:02 | | Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 23:04:43 | | Join Diway [0] (~diway@dasylau.adsl.nerim.net) |
| 23:04:45 | | Quit DMJC (Client Quit) |
| 23:04:48 | Diway | hi ! |
| 23:05:41 | Tang | This isI've got some answer from amorim on HA board! |
| 23:05:57 | Tang | he advice wavpack for lossless but also lossy encoding |
| 23:06:15 | Tang | (wavpack is the only one lossy encoder with integer mat) |
| 23:08:02 | preglow | lossless and lossy? |
| 23:09:09 | preglow | i see |
| 23:10:27 | Tang | i send the links: |
| 23:10:41 | Tang | lossless: |
| 23:10:45 | Tang | http://www.hydrogenaudio.org/forums/index.php?showtopic=31471&pid=272945&st=0&# |
| 23:10:57 | Tang | lossy: |
| 23:11:00 | Tang | http://www.hydrogenaudio.org/forums/index.php?showtopic=27390&st=0&p=272949&# |
| 23:11:11 | Tang | yes indeed wavpack is an hybrid codec: |
| 23:11:19 | Tang | there is lossy and lossless mode |
| 23:11:20 | Tang | ;) |
| 23:11:32 | | Quit iriver ("CGI:IRC (Ping timeout)") |
| 23:13:06 | linuxstb | Tang: Thanks for that - wavpack looks promising, for both lossy and lossless real-time compression. It's definitely one worth testing on the iRiver itself. |
| 23:13:17 | muesli- | brb in 45mins |
| 23:13:37 | linuxstb | Do you know if wavpack is generally considered a good codec? |
| 23:14:39 | Tang | okay i'm very happy to help :) |
| 23:19:05 | Tang | Hum i've seen a mistake (a lack in fact) |
| 23:19:16 | Tang | in the "firmware feature comparison" |
| 23:19:21 | Tang | for iHP |
| 23:19:36 | Tang | " Mid-playlist resume ? for iHP" |
| 23:20:03 | Tang | In fct there is mid playlist resume with original firmware since v1.60 (or 1.40 maybe) |
| 23:20:10 | Tang | http://www.rockbox.org/docs/features.html |
| 23:20:19 | Tang | :) |
| 23:20:36 | rasher | Where do I put patches? The SF patch tracker or do I wait for someone here to get it? |
| 23:21:01 | Tang | also for: |
| 23:21:18 | Tang | " Supports bad path prefixes in playlists Yes Yes ?" |
| 23:21:24 | Tang | the answer is "YES" ;) |
| 23:21:48 | Tang | " File Delete & Rename −− No" |
| 23:21:53 | Tang | the good answer is: |
| 23:22:02 | Tang | "file delete yes" |
| 23:22:06 | Tang | rename NO |
| 23:23:41 | Tang | Backlight-on when charging option −−> the answer is YES in fact: you can select light always on from external power source (AC or external battery pack) |
| 23:24:28 | Tang | hum there is quite many mistake i'll correct it and sen an email |
| 23:24:35 | Tang | seems a better ssolution |
| 23:25:28 | jyp | I got the 220 lcd emulated ... |
| 23:25:28 | | Join amiconn [0] (~jens@pD95D199F.dip.t-dialin.net) |
| 23:25:30 | jyp | jyp/Gmemu/220-menu.png">http://users.skynet.be/jyp/Gmemu/220-menu.png |
| 23:26:07 | preglow | weet |
| 23:26:15 | rasher | :) |
| 23:26:34 | jyp | on to writing a rockbox driver for it :) |
| 23:27:43 | amiconn | hi |
| 23:28:08 | amiconn | rasher: I added the player to the snow, mosaique and cube plugin description in the wiki |
| 23:28:47 | HCl | what about putting sokoban on player? |
| 23:29:08 | amiconn | That'd be really hard... |
| 23:29:14 | rasher | amiconn: Good, good |
| 23:29:39 | * | amiconn has to investigate a strange problem on Ondio |
| 23:31:09 | amiconn | Either the manufacturer's formatting of the internal flash is messed up, or the rockbox fat16 support has a bug .. :-/ |
| 23:31:23 | rasher | sniff, fat16 :( |
| 23:31:54 | amiconn | fat32 wouldn't really make sense on a 128 MB flash chip, imho |
| 23:32:02 | rasher | Heh |
| 23:32:27 | sneakums | maybe if you want lots of small files |
| 23:32:33 | sneakums | lots and lots |
| 23:32:34 | rasher | I don't. |
| 23:32:37 | amiconn | After all, we have to support it (we support fat32 as well), since the archos firmware can only boot off a fat16 partition |
| 23:35:54 | amiconn | sneakums: Why would you want lots of small files on a music player? |
| 23:36:04 | rasher | amiconn: sid support! :) |
| 23:36:09 | sneakums | i assume you wouldn't |
| 23:36:16 | rasher | (yes I know, not on that device) |
| 23:36:40 | sneakums | but fat16 has that 2^16 cluster limit |
| 23:36:45 | rasher | Where do I put patches for a) solitaire keybindings for iriver, b) logo plugin ? |
| 23:37:21 | amiconn | rasher: Umm, the standard place is the sf patch tracker |
| 23:37:29 | rasher | alright |
| 23:37:39 | rasher | not sure where it was appreciated |
| 23:37:41 | | Quit muesli- (Read error: 113 (No route to host)) |
| 23:40:33 | | Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 23:50:19 | rasher | patches added |
| 23:56:17 | | Join amiconn_ [0] (~jens@pD9E7F6F4.dip.t-dialin.net) |
| 23:56:30 | | Quit amiconn (Nick collision from services.) |
| 23:56:30 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7F6F4.dip.t-dialin.net) |
| 23:57:14 | amiconn | Grmpf. Seems my sector count calculation for MMC was not quite correct :( |
| 23:57:31 | amiconn | I should read the datasheets more thoroughly |
icon identifies that the person is a core developer (has commit access).