| 00:00:01 | saratoga | generally just because two SD cards are packaged the same doesn't mean they're the same internally |
| 00:00:32 | tuxifier | sorrowly :) |
| 00:01:03 | tuxifier | I already even tried to dd the image of the working card to the unrecognized |
| 00:01:08 | tuxifier | no success |
| 00:02:41 | saratoga | probably just a bug in our controller driver that only occurs with some cards |
| 00:02:58 | wah_wah_69 | Hi everyone! I have just made a post about the vibe 300 in the forum, take a look if you're interested in a new port. |
| 00:05:38 | saratoga | i really doubt anyone here is interested |
| 00:05:57 | wah_wah_69 | Hi everyone! |
| 00:05:57 | wah_wah_69 | I've owned a Packard Bell Vibe 300 for aroud 4 years (It was a christmas gift), the first thing I made when it was given to me was to take a look around here for a port, but there was none :'( |
| 00:06:27 | wah_wah_69 | crap, this irc client, I pasted all that without wanting |
| 00:06:47 | wah_wah_69 | So who might have info to help me develop a new port? |
| 00:08:22 | saratoga | have you seen this: http://www.rockbox.org/twiki/bin/view/Main/NewPort |
| 00:09:15 | wah_wah_69 | I'm reading it right now, its quite light on technical details |
| 00:09:35 | saratoga | yeah, you pretty much have to figure those our yourself |
| 00:10:30 | soap | thomasjfox, I appear to have forgotten the root password of my N810! |
| 00:10:36 | wah_wah_69 | The thing is, having the same portalplayer chip as some supported players it might be more or less easy |
| 00:10:46 | thomasjfox | soap: trustno1? |
| 00:10:52 | saratoga | i guess a good first step would be to figure out how to recover from a bad flash |
| 00:11:17 | saratoga | then dig through the firmware file and see if you can figure out which GPIO pins go where |
| 00:11:32 | gevaerts | wah_wah_69: it's going to be easier than some ports, yes |
| 00:11:39 | wah_wah_69 | I don't know this even is flashable, it has an mi4 file in the sytem directory |
| 00:11:47 | saratoga | then try to blink the lights on or something |
| 00:12:10 | thomasjfox | soap: On the n900 it usually works by "sudo gainroot" or "root" in the terminal |
| 00:13:09 | saratoga | yes thats the "normal" PP method, the H10 and i think Phillips players use that |
| 00:13:37 | soap | oh, thomasjfox, I set a root password years ago. But my "default" root password isn't working. |
| 00:13:56 | saratoga | comparing to this page for the H10 might be interesting: http://www.rockbox.org/wiki/IriverH10PortDevInfo |
| 00:13:59 | thomasjfox | soap: Can you open a normal user terminal? |
| 00:14:00 | gevaerts | Also the mr100, the samsungs, and I think the vibe500 |
| 00:14:15 | soap | thomasjfox, yes |
| 00:14:33 | thomasjfox | Try if you have the "root" or "sudo gainroot" stuff installed. Then you don't need the password |
| 00:14:37 | gevaerts | Well, some of them use a different filename, but that's not very important |
| 00:15:20 | wah_wah_69 | thanks saratoga! I should have found thank link myself. |
| 00:15:29 | soap | thomasjfox, "Enable RD mode to gain root privileges" |
| 00:15:49 | Torne | install the rootsh package from maemo.org |
| 00:15:53 | Torne | then sudo gainroot |
| 00:16:14 | Torne | you can't become root without installing something or turning on R&D mode with flasher, but that has other sideeffects |
| 00:16:47 | saratoga | wah_wah_69: also this page: http://www.rockbox.org/wiki/SamsungYH92xPort |
| 00:18:19 | saratoga | does it also have a .ROM file in the system folder? if so that may contain the recovery code if you flash a bad .mi4 file |
| 00:18:24 | soap | Torne, yea that's what google is telling me. I would have sworn I went through all this ages ago. |
| 00:18:45 | | Quit TheSeven (Disconnected by services) |
| 00:18:46 | | Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) |
| 00:20:13 | wah_wah_69 | saratoga, yes it has a file called pp5020.mi4 in the system directory |
| 00:20:38 | thomasjfox | gevaerts: I found something out about the pulseaudio CPU usage |
| 00:20:48 | Tim_Elliott | I wish someone would make a port for the Insignia Pilot |
| 00:21:03 | thomasjfox | The protection for the speakers just kicks in at a certain global volume level |
| 00:21:13 | gevaerts | Tim_Elliott: New Year's wishes should be made in December |
| 00:21:19 | thomasjfox | So CPU is about 7% lower if I keep the volume below that |
| 00:21:22 | AlexP | Not on demand.. blah.. interested owners.. blah.. etc. etc. |
| 00:21:31 | gevaerts | thomasjfox: interestin |
| 00:21:31 | | Quit feisar- (Ping timeout: 276 seconds) |
| 00:21:33 | gevaerts | g |
| 00:21:37 | wah_wah_69 | it boots as USB mass storage just by plugging an usb cable, so it might be easy to recover |
| 00:21:43 | | Quit bertrik (Quit: CGI:IRC) |
| 00:22:43 | thomasjfox | gevaerts: Maybe we should set an initial volume on application startup just a bit below that level |
| 00:23:41 | | Quit kugel (Remote host closed the connection) |
| 00:23:44 | *** | Saving seen data "./dancer.seen" |
| 00:23:47 | AlexP | thomasjfox: can you detect speakers vs headphones, and then set a limit in rockbox a fraction below that when on speakers? |
| 00:24:03 | AlexP | As it'd make no difference to the max, but save a load of power by the sounds of it |
| 00:24:13 | thomasjfox | Alexp: Should be possible |
| 00:24:26 | soap | thomasjfox, big issue is that rockbox doesn't show up as a running application, |
| 00:24:47 | gevaerts | thomasjfox: do we want to touch the global volume at all? |
| 00:25:02 | thomasjfox | gevaerts: Maybe just once? |
| 00:25:18 | thomasjfox | soap: But you are able to run it? |
| 00:25:23 | | Quit tuxifier (Remote host closed the connection) |
| 00:25:23 | gevaerts | I know I'd be annoyed if apps all think they should set the volume for me |
| 00:25:24 | wah_wah_69 | saratoga, it has some other files but none are called *.rom, there's a sysinfo.ini file which contains some info, is seems to have been generated by the firmware updater, this line is the one that references the bootloader: Bootloader=BL_pp6005_5020_color.rom |
| 00:25:53 | thomasjfox | gevaerts: We could make it a platform based option |
| 00:26:14 | soap | thomasjfox, I have no music on my N810, but elsewise it runs fine. I'll load some music when I find a micro cable |
| 00:26:35 | gevaerts | thomasjfox: the way I see it, rockbox is an *application* on maemo. It shouldn't try to take over the system in any way |
| 00:26:41 | thomasjfox | soap: hehe, you really haven't used it in a long time |
| 00:27:06 | thomasjfox | gevaerts: Hmm. On the other hand is saves quite some CPU |
| 00:27:12 | soap | I use it every day, but it is an appliance to me. |
| 00:27:18 | gevaerts | Yes, but it's not CPU *we* are wasting |
| 00:27:45 | soap | everything I need is installed (fbreader, claws mail, ssh) and that's all I do. |
| 00:28:19 | thomasjfox | gevaerts: What if we make this a platform option and only set the volume if 1. it's on speakers and 2. it's above the limit (=don't touch lower volumes) |
| 00:28:24 | | Quit BlakeJohnson86 (Quit: Leaving.) |
| 00:28:55 | gevaerts | thomasjfox: well, to put it simply, if I installed an audio player that did that, I'd report it as a bug |
| 00:29:08 | thomasjfox | gevaerts: It should be configurable of course |
| 00:30:15 | thomasjfox | I don't like the idea much either - but it's a cheap way to save CPU :) |
| 00:31:44 | | Quit Keripo (Quit: Leaving.) |
| 00:31:45 | | Quit ender` (Quit: Information travels more surely to those with a lesser need to know.) |
| 00:32:51 | | Quit Buschel (Ping timeout: 265 seconds) |
| 00:37:41 | | Join factor [0] (~factor@75.108.68.114) |
| 00:39:12 | | Quit chattr (Ping timeout: 240 seconds) |
| 00:41:43 | | Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) |
| 00:42:56 | thomasjfox | soap: Can you just download a mp3 of the net for testing? Here's a free track: http://simonv.com/music/mp3/SIMON_V-Stand_by_V.mp3 |
| 00:43:42 | thomasjfox | soap: Would be nice to get some CPU load info when the display is on/off |
| 00:45:52 | | Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) |
| 00:49:49 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 00:50:51 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 00:51:39 | | Quit GuySoft (Ping timeout: 246 seconds) |
| 00:53:30 | | Quit thomasjfox (Remote host closed the connection) |
| 00:53:38 | | Join Strife89 [0] (~Strife89@adsl-80-182-157.mcn.bellsouth.net) |
| 00:54:58 | | Quit Tim_Elliott (Ping timeout: 272 seconds) |
| 00:58:31 | | Join GuySoft [0] (~guysoft@bzq-109-64-46-137.red.bezeqint.net) |
| 01:00 |
| 01:00:33 | | Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) |
| 01:04:16 | | Quit GuySoft (Ping timeout: 276 seconds) |
| 01:05:01 | | Join eRivas [0] (~je@190.150.0.99) |
| 01:05:50 | eRivas | is it possible to have a volume icon that will display volume level only when it is changed? |
| 01:07:05 | | Join mikroflops_ [0] (~yogurt@h-34-71.A238.priv.bahnhof.se) |
| 01:07:06 | n1s | yes |
| 01:08:02 | n1s | at least i'm pretty sure it is, take a look ath the CustomWPS page for the details |
| 01:08:37 | eRivas | in the manual? |
| 01:09:09 | n1s | the wiki is probably better but the manual has the wps tags too |
| 01:10:00 | eRivas | ok, I've already taken a look at the tags, what I don't understand is how to handle the events, since the numeric display won't be always visible |
| 01:10:12 | | Quit mikroflops (Ping timeout: 246 seconds) |
| 01:10:37 | JdGordon| | umm, you should be able to do it |
| 01:10:41 | JdGordon| | let me have a quick look |
| 01:11:15 | | Part domonoky |
| 01:12:18 | JdGordon| | eRivas: you can do %?if(%bl, >, 90)<charged> |
| 01:12:40 | JdGordon| | 90 is the % level which you want to define as "close enough to fully charged" |
| 01:12:58 | JdGordon| | oh woops... changed not charged |
| 01:13:03 | JdGordon| | no, you cant do that |
| 01:13:16 | eRivas | I saw something like that in the failsafe theme |
| 01:13:31 | JdGordon| | you can do it for volume, not battery |
| 01:13:43 | eRivas | yeah, volume I said |
| 01:13:57 | JdGordon| | wtf? i'm still asleep here :p |
| 01:14:20 | eRivas | hahaha, so an if is the way to go? |
| 01:14:39 | | Quit kadoban (Ping timeout: 240 seconds) |
| 01:14:53 | JdGordon| | no, there is a actual tag for volume changing |
| 01:15:22 | JdGordon| | %?mv<%pv> is what you want |
| 01:15:45 | eRivas | ok, the wiki has more of this? |
| 01:15:48 | | Join GuySoft [0] (guy@bzq-79-179-5-239.red.bezeqint.net) |
| 01:16:29 | JdGordon| | http://www.rockbox.org/wiki/Main/CustomWPS#Increasing_47Decreasing_Volume |
| 01:16:58 | eRivas | excellent, thanks a lot |
| 01:17:13 | | Join feisar- [0] (jljhook@irkki.fi) |
| 01:18:09 | eRivas | so, if %mv is true, show numbers, else, show icon? |
| 01:19:29 | JdGordon| | that gets more complicated |
| 01:19:30 | | Quit antil33t (Read error: Connection reset by peer) |
| 01:19:58 | JdGordon| | %?mv<%pv|%pv(stuff to make it a bar)> or you can do a icon strip also |
| 01:21:30 | eRivas | yes, I already have the strip |
| 01:22:49 | eRivas | current code: |
| 01:22:50 | eRivas | %?pv<%xd(da)|%xd(db)|%xd(db)|%xd(dc)|%xd(dc)|%xd(dd)|%xd(dd)> |
| 01:22:52 | | Join Rob2222 [0] (~Miranda@p4FFF03A1.dip.t-dialin.net) |
| 01:23:01 | eRivas | with volume icon declared as d |
| 01:25:08 | | Join webguest91 [0] (~48802c70@giant.haxx.se) |
| 01:27:25 | | Quit webguest91 (Client Quit) |
| 01:27:49 | | Join webguest94 [0] (~48802c70@giant.haxx.se) |
| 01:27:54 | | Quit webguest94 (Client Quit) |
| 01:35:23 | | Quit n1s (Quit: Lämnar) |
| 01:37:52 | | Join markun [0] (~markun@5ED33C2C.cm-7-4a.dynamic.ziggo.nl) |
| 01:37:52 | | Quit markun (Changing host) |
| 01:37:52 | | Join markun [0] (~markun@rockbox/developer/markun) |
| 01:46:20 | eRivas | when I declare and image to be preloaded, I can specify coordinates, are these coordinates relative to the viewport containing the image or are they absolute? |
| 01:46:30 | | Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) |
| 01:48:26 | | Quit Keripo (Ping timeout: 250 seconds) |
| 01:50:46 | | Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) |
| 02:00 |
| 02:01:22 | JdGordon| | eRivas: viewport |
| 02:02:43 | eRivas | and can I use math operations, I'm thinking of displaying vol as positive integers, as opposed to the true -dB approach |
| 02:02:53 | | Quit feisar- (Read error: Operation timed out) |
| 02:03:18 | eRivas | so if min vol is -81 dB, I would like to do %pv+81 |
| 02:04:23 | JdGordon| | no |
| 02:05:03 | | Quit mortalscan (Ping timeout: 240 seconds) |
| 02:06:13 | | Quit froggyman (Ping timeout: 260 seconds) |
| 02:08:40 | | Join AndyI [0] (~pasha_int@212.14.211.84) |
| 02:10:20 | | Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) |
| 02:11:16 | | Quit antil33t (Client Quit) |
| 02:11:38 | | Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) |
| 02:15:32 | | Join JesusFreak316_ [0] (~JesusFrea@pool-173-65-105-252.tampfl.fios.verizon.net) |
| 02:23:47 | *** | Saving seen data "./dancer.seen" |
| 02:26:17 | [7] | oh my. |
| 02:26:41 | [7] | do i understand correctly that the ATA layer doesn't handle splitting too-large transfers for non-lba48 drives? |
| 02:28:06 | | Quit JesusFreak316_ (Remote host closed the connection) |
| 02:42:28 | * | [7] spots a rockbox main menu on his ipod classic's LCD :) |
| 02:42:48 | gevaerts | \☺/ |
| 02:42:56 | gevaerts | Congratulations! |
| 02:43:05 | * | [7] needs to figure out why the clickwheel doesn't work :/ |
| 02:43:30 | [7] | might be as trivial as me forgetting to unmask an IRQ |
| 02:45:11 | * | [7] was right :) |
| 02:45:31 | * | [7] browses folders on the disk |
| 02:46:51 | [7] | four more things that need to be looked into rather soon: |
| 02:47:00 | [7] | - enable caches |
| 02:47:10 | [7] | - make codecs/plugins compile |
| 02:47:20 | [7] | - implement ata dma |
| 02:47:37 | [7] | - figure out why Buschel's LCD code doesn't work |
| 02:59:20 | | Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 03:00 |
| 03:00:57 | | Join feisar- [0] (jljhook@irkki.fi) |
| 03:02:35 | | Join einarin [0] (~johnny@207-224-41-189.hlrn.qwest.net) |
| 03:05:22 | | Quit feisar- (Ping timeout: 246 seconds) |
| 03:05:37 | einarin | is there someone around who could help me with the Sansa AMS recovery mode? |
| 03:11:28 | saratoga | einarin: maybe, but i've never tried it myself |
| 03:14:49 | | Quit timccc (Ping timeout: 246 seconds) |
| 03:16:06 | eRivas | I would like to suggest new strings available for translation: in, of |
| 03:16:18 | | Join jduley [0] (~ca24b342@giant.haxx.se) |
| 03:17:26 | | Quit DerPapst (Quit: Leaving.) |
| 03:19:01 | * | [7] spots a nice cabbiev2 backdrop :) |
| 03:19:36 | [7] | plugins fail with "incompatible model", whatever that means |
| 03:20:06 | | Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) |
| 03:20:46 | saratoga | they check to make sure they're compiled for the right target ID IIRC |
| 03:21:00 | [7] | yeah, but why doesn't it recognize it's own id? |
| 03:21:07 | | Join timccc [0] (~timccc@112.166.15.141) |
| 03:21:11 | [7] | i.e. where did i forget to change it? |
| 03:21:32 | saratoga | i think you have to set it in configure and maybe the target.h file |
| 03:21:35 | saratoga | not sure though |
| 03:23:23 | jduley | saratoga: Hi, has anyone looked at fixing pause/unpause squeak on the clip+ FS #11812? |
| 03:23:32 | saratoga | no i don't think so |
| 03:23:38 | saratoga | i just noticed it recently actually |
| 03:23:55 | saratoga | it doesn't happen with my usual headphones so i'm not too concerned ;) |
| 03:24:39 | | Quit mortalscan (Ping timeout: 240 seconds) |
| 03:25:11 | jduley | I just heard from another person who experiences it so was wondering if it was something worth fixing |
| 03:26:30 | saratoga | its worth fixing |
| 03:26:44 | saratoga | if someone posts a patch i'll confirm and then commit it |
| 03:30:53 | jduley | ok I wouldn't have a clue where to start with a patch so it won't be me. Do you think it happens on all AMSv2 devices as that other guy had it on his Fuze v2? |
| 03:31:13 | soap | Thomasjfox, I promise to be less apathetic towards Rockbox on the N810 tomorrow if you highlight me. |
| 03:32:56 | [7] | hm, the target id in the plugins seems to be correct |
| 03:33:03 | [7] | where's the target id that the loader checks? |
| 03:36:13 | saratoga | you should probably ask kugel or someone in the morning |
| 03:36:19 | saratoga | plugins aren't the most important thing anyway |
| 03:36:34 | [7] | but codecs are :) |
| 03:36:43 | saratoga | hmm yes good point |
| 03:37:10 | * | [7] wonders if it will reach 10% realtime in its current state |
| 03:38:10 | saratoga | [7]: codecs.c |
| 03:38:12 | saratoga | around line 200 |
| 03:38:49 | [7] | i spotted it in the plugin code in the meantime, and both values are 0x47, so it must be something else |
| 03:39:01 | saratoga | oh you said model, not version |
| 03:39:04 | saratoga | heh i have no idea |
| 03:39:10 | saratoga | i'm actually a little surprised we check for that |
| 03:41:03 | saratoga | [7]: it compares TARGET_ID as defined in teh codec to TARGET_ID as defined in the main binary |
| 03:41:47 | [7] | it's probably the load address that's making it fail |
| 03:41:58 | saratoga | yeah i don't see anyway they could be different |
| 03:49:18 | CIA-7 | New commit by saratoga (r28942): Commit part of FS #11748 by Michael Hohmuth. Adds support for automatically resuming any song that is not played to completion at any point later in ... |
| 03:50:02 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 03:50:07 | [7] | yeah, was indeed a linker script problem |
| 03:50:29 | einarin | saratoga: on the sansaAMSunbrick page, it says to dd orig_image.bin to the device, but they don't say what orig_image is or how to make one |
| 03:51:56 | saratoga | einarin: its just a copy of the front of the NAND chip from a working player |
| 03:51:56 | CIA-7 | r28942 build result: 46 errors, 0 warnings (saratoga committed) |
| 03:51:59 | saratoga | bah |
| 03:52:21 | [7] | hm, i'd really like to get that port into SVN, but it requires those ATA changes that haven't been tested on other targets |
| 03:52:34 | saratoga | damn archos! |
| 03:54:39 | | Quit froggyman (Ping timeout: 240 seconds) |
| 03:57:05 | saratoga | huh i don't understand why archos is different here |
| 03:57:24 | eRivas | how do I use the %Re tag, just insert it or specify alternatives? |
| 03:58:13 | | Quit GuySoft (Ping timeout: 260 seconds) |
| 03:59:12 | | Join GuySoft [0] (guy@bzq-79-179-5-239.red.bezeqint.net) |
| 04:00 |
| 04:00:26 | | Quit xavieran (Ping timeout: 255 seconds) |
| 04:01:04 | | Quit [7] (Disconnected by services) |
| 04:01:05 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 04:01:51 | | Join feisar- [0] (jljhook@irkki.fi) |
| 04:05:57 | TheSeven | woah! |
| 04:06:05 | TheSeven | we're getting closer |
| 04:06:14 | * | TheSeven needs to fix audio tomorrow |
| 04:06:38 | TheSeven | it plays back the first second correctly, and then it goes nuts |
| 04:06:44 | saratoga | ok i have no idea whats going on, how can an extern variable in tagcache.c to playback.c work on SWCODEC but not on HWCODEC? |
| 04:06:54 | | Quit feisar- (Ping timeout: 265 seconds) |
| 04:07:05 | TheSeven | USB seems to work apart from it exposing a wrong sector size |
| 04:08:46 | saratoga | wait |
| 04:09:01 | saratoga | HWCODEC uses playback.c right? |
| 04:10:00 | * | TheSeven falls asleep... it's 4AM again |
| 04:13:25 | | Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) |
| 04:13:30 | saratoga | ugh this is going to be hard to fix without talking to a HWCODEC person |
| 04:15:17 | JdGordon| | saratoga: wassup? |
| 04:15:39 | saratoga | i didn't realize HWCODEC works completely different then SWCODEC for handling track changes |
| 04:16:08 | saratoga | i can make it compile, but i have no idea if this automatic resume feature will even work as implemented on HWCODEC |
| 04:16:15 | saratoga | and i have no device to try it on |
| 04:16:40 | JdGordon| | ahem... we should fork hwcodec out and drop it |
| 04:16:44 | saratoga | yes |
| 04:16:48 | saratoga | but anyway |
| 04:17:10 | saratoga | how limited is HWCODEC? i thought it just used a DSP but was otherwise pretty similar in terms of buffering and playback, but it looks like that is not the case |
| 04:17:25 | saratoga | does it make sense to support resume on it? |
| 04:18:25 | JdGordon| | I assume so |
| 04:19:11 | saratoga | anyone got a HWCODEC player handy to test something? |
| 04:19:21 | JdGordon| | Massive assumption, but I dont tihnk the hwcodecs would sell very well if they couldnt resume mid track :p |
| 04:19:46 | saratoga | or can I do this in the sim (does the sim even work work for HWCODEC)? |
| 04:19:51 | | Quit jduley (Quit: CGI:IRC) |
| 04:19:57 | JdGordon| | sim is not simulated for hwcodec at all |
| 04:20:05 | JdGordon| | s/sim/playback/ |
| 04:20:06 | saratoga | amazing |
| 04:20:13 | | Join Barahir_ [0] (~jonathan@frnk-590f4df5.pool.mediaWays.net) |
| 04:20:25 | saratoga | who actually has one of these devices |
| 04:20:51 | JdGordon| | RockboxTesting ... |
| 04:21:15 | JdGordon| | I have an ajbr but not with me, and most of the hwcodec owners are *difficult* to get to test things |
| 04:21:29 | saratoga | yes the wiki suggests you |
| 04:21:41 | | Quit Barahir (Read error: Operation timed out) |
| 04:21:58 | eRivas | can I use playlist name - %pn - as a condition for an if? |
| 04:22:06 | saratoga | Llorean LambdaCalculus379 |
| 04:22:09 | saratoga | one of you be online |
| 04:22:14 | JdGordon| | eRivas: yes |
| 04:22:19 | eRivas | ok |
| 04:22:30 | JdGordon| | saratoga: #ifdef if out.. doesnt it require the db anyway which isnt on the lowmem targets? |
| 04:22:34 | JdGordon| | or am i confusing things? |
| 04:23:04 | saratoga | the player has the database |
| 04:23:42 | JdGordon| | eRivas: what sort of check do you want to do with it? I *think* %?pn is true when you play from a m3u (and maybe directory) and false when its a dynamic playlist |
| 04:23:48 | *** | Saving seen data "./dancer.seen" |
| 04:24:24 | eRivas | JdGordon|: %?pn<%pn> |
| 04:24:33 | JdGordon| | yeah that would prob work |
| 04:24:39 | eRivas | thanks |
| 04:26:38 | JdGordon| | saratoga: two options, 1) #ifdef it out and leave it untill someone can test, 2) make it compile and wait for complaints/verification that it works |
| 04:26:51 | eRivas | JdGordon|: how do I use the %Re tag, just insert it or specify alternatives? |
| 04:27:00 | saratoga | if i understand mpeg.c correctly, its not going to work as currently implemented |
| 04:27:05 | JdGordon| | the danger with 2) is what happened to me, 6+months before finding out it is broken |
| 04:28:33 | saratoga | what the hell does hwcodec actually include then |
| 04:28:44 | JdGordon| | eRivas: like all tags, it depends what you want... %Re will show some text, %?Re<option|option|option> gives you more control |
| 04:28:45 | saratoga | i just realized i don't know if i've ever looked at a rockbox source file it uses before now |
| 04:29:23 | eRivas | JdGordon|: it's just that I insterted it alone and will only show aiff, other encoders will not be shown |
| 04:29:35 | eRivas | JdGordon|: so I guess I must specify my text |
| 04:31:51 | | Quit kadoban (Quit: bye) |
| 04:32:07 | | Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 04:39:36 | | Join fyrestorm [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) |
| 04:39:46 | | Quit kadoban (Ping timeout: 265 seconds) |
| 04:43:16 | | Quit GuySoft (Ping timeout: 264 seconds) |
| 04:44:13 | | Quit JdGordon| (Ping timeout: 260 seconds) |
| 04:49:23 | | Quit pixelma (Disconnected by services) |
| 04:49:24 | CIA-7 | New commit by saratoga (r28943): Blind commit a 'fix' for automatic resume on HWCODEC since I don't understand HWCODEC and have no way to test builds for it. For now just disable it. ... |
| 04:49:26 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:49:28 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:50:50 | | Quit amiconn (Disconnected by services) |
| 04:50:51 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:50:54 | CIA-7 | r28943 build result: All green |
| 04:51:08 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:51:10 | saratoga | fuck still wastes 100 bytes on HWCODEC |
| 04:51:38 | saratoga | amiconn: (for the logs) can you comment on how this should be fixed in FS #11748? |
| 05:00 |
| 05:01:31 | | Quit factor (Ping timeout: 265 seconds) |
| 05:03:05 | | Join feisar- [0] (jljhook@irkki.fi) |
| 05:03:10 | | Quit TheSeven (Ping timeout: 240 seconds) |
| 05:07:43 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 05:14:37 | eRivas | is there a radio token to indicate radio muted? |
| 05:14:59 | | Join factor [0] (~factor@75.108.68.114) |
| 05:16:41 | einarin | saratoga: thanks |
| 05:17:06 | | Quit Rob2222 (Ping timeout: 272 seconds) |
| 05:17:42 | | Quit wah_wah_69 (Ping timeout: 276 seconds) |
| 05:49:42 | | Quit einarin (Ping timeout: 276 seconds) |
| 05:51:00 | | Join wah_wah_69 [0] (~io@212.225.156.123) |
| 05:51:18 | | Join einarin [0] (~johnny@207-224-41-189.hlrn.qwest.net) |
| 05:57:33 | | Quit MethoS- (Remote host closed the connection) |
| 06:00 |
| 06:01:06 | | Join fyre^OS [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) |
| 06:03:34 | | Quit eRivas (Quit: Saliendo) |
| 06:04:52 | | Quit fyrestorm (Ping timeout: 264 seconds) |
| 06:07:50 | | Join JdGordon| [0] (~jonno@124-149-188-197.dyn.iinet.net.au) |
| 06:07:50 | | Quit JdGordon| (Changing host) |
| 06:07:50 | | Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) |
| 06:09:13 | | Quit einarin (Quit: leaving) |
| 06:11:42 | | Quit wah_wah_69 (Read error: Connection reset by peer) |
| 06:14:08 | | Quit parafin (Ping timeout: 276 seconds) |
| 06:20:15 | * | JdGordon| wonders if hwcodec can be simulated on swcodec by setting up a virtual MAS |
| 06:23:36 | | Join binaryhermit [0] (~binaryher@adsl-70-131-127-225.dsl.emhril.sbcglobal.net) |
| 06:23:52 | *** | Saving seen data "./dancer.seen" |
| 06:24:34 | | Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 06:26:00 | | Join binaryhermit_ [0] (~binaryher@adsl-99-135-145-17.dsl.emhril.sbcglobal.net) |
| 06:26:13 | | Quit binaryhermit_ (Read error: Connection reset by peer) |
| 06:28:35 | | Quit factor (Ping timeout: 240 seconds) |
| 06:30:04 | | Quit binaryhermit (Ping timeout: 264 seconds) |
| 06:48:38 | | Quit JdGordon| (Quit: Lost terminal) |
| 06:49:29 | | Join JdGordon| [0] (~jonno@124-149-188-197.dyn.iinet.net.au) |
| 06:49:29 | | Quit JdGordon| (Changing host) |
| 06:49:29 | | Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) |
| 07:00 |
| 07:09:28 | | Join GuySoft [0] (guy@bzq-109-67-22-249.red.bezeqint.net) |
| 07:16:12 | | Quit Keripo1 (Quit: Leaving.) |
| 07:45:33 | | Join leavittx__ [0] (~lev@MS-159-112.dyn-ip.SPb.SkyLink.RU) |
| 07:46:39 | | Join Thopter [0] (~AbuMaia@208.123.144.34) |
| 07:49:10 | | Quit leavittx_ (Ping timeout: 276 seconds) |
| 07:50:42 | Thopter | I'm new to Rockbox, having installed it via the Rockbox Utility on my Clip+ 8GB earlier today. I found a language quiz patch that I would like to install, but I'm not sure how to go about doing that. All the info I've read about adding patches talks about using diff files, but this patch is provided as a .c file. Can someone point me to some instructions somewhere that could get me through? |
| 07:52:48 | | Join Horschti [0] (~Horschti@xbmc/user/horscht) |
| 07:57:07 | | Quit Horscht (Ping timeout: 276 seconds) |
| 08:00 |
| 08:01:01 | | Quit xavieran (Ping timeout: 276 seconds) |
| 08:05:00 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 08:11:49 | | Join parafin [0] (parafin@paraf.in) |
| 08:13:03 | | Quit JdGordon| (Quit: Lost terminal) |
| 08:13:49 | | Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) |
| 08:23:54 | *** | Saving seen data "./dancer.seen" |
| 08:26:14 | | Join saratoga_ [0] (9803c22e@gateway/web/freenode/ip.152.3.194.46) |
| 08:31:53 | | Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) |
| 08:39:09 | | Quit user890104 (Ping timeout: 272 seconds) |
| 08:40:04 | | Join user890104 [0] (~Venci@6bez10.info) |
| 08:48:41 | | Quit antil33t () |
| 08:53:00 | | Join JdGordon [0] (7c95bcc5@gateway/web/freenode/ip.124.149.188.197) |
| 09:00 |
| 09:08:30 | | Quit fyre^OS (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) |
| 09:11:29 | | Join [Saint] [0] (S_a_i_n_t@203.184.3.36) |
| 09:36:29 | | Quit JdGordon (Ping timeout: 265 seconds) |
| 09:46:23 | | Join bmbl [0] (~bmbl@unaffiliated/bmbl) |
| 10:00 |
| 10:00:25 | | Quit xavieran (Ping timeout: 246 seconds) |
| 10:14:36 | | Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) |
| 10:16:44 | amiconn | TheSeven: DMA for LCD updates still has advantages even if the main thread needs to be blocked until completion: Other threads can run meanwhile (e.g. codec) |
| 10:17:47 | | Quit mortalscan (Ping timeout: 240 seconds) |
| 10:23:15 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 10:23:57 | *** | Saving seen data "./dancer.seen" |
| 10:33:31 | amiconn | saratoga: Hwcodec does not use playback.c at all. It has its own (considerably less complex) playback engine, in mpeg.c |
| 10:34:12 | | Join icarusfactor [0] (~factor@75.108.68.114) |
| 10:35:14 | | Quit icarusfactor (Remote host closed the connection) |
| 10:35:37 | | Join icarusfactor [0] (~factor@75.108.68.114) |
| 10:38:12 | | Join factor_ [0] (~factor@75.108.68.114) |
| 10:38:17 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 10:38:57 | * | pixelma doesn't think she is "difficult to test things" |
| 10:39:04 | pixelma | +get to |
| 10:39:16 | | Nick icarusfactor is now known as factor (~factor@75.108.68.114) |
| 10:39:40 | pixelma | the only thing about testing on the Ondio is that putting on test builds takes ages (if I need everything) |
| 10:39:53 | | Quit factor_ (Read error: Connection reset by peer) |
| 10:42:45 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:53:30 | [Saint] | It's amazing enough you even *have* the Ondio |
| 10:53:38 | [Saint] | let alone more than one. |
| 10:54:38 | pixelma | huh, I only have one Ondio. And it's a nice player with better sound quality than the other players I have |
| 10:55:17 | [Saint] | Oh...sorry. I thought you had two. And yeah, they're not a bad player at all. I've only ever seen one "in the wild" though. |
| 11:00 |
| 11:00:05 | saratoga_ | amiconn: so basically if we want to have this work, I'd have to figure out how mpeg.c works then tie it into that playback engine at the right spots? |
| 11:03:21 | pixelma | saratoga_: does this feature need the database in RAM or only the database? |
| 11:04:06 | saratoga_ | its about the automatic resume feature |
| 11:04:30 | pixelma | yes, but your commit message mentions that it is tied to the database |
| 11:04:43 | saratoga_ | it requires some changes to playback.c (basically to actually set the resume positions) |
| 11:05:35 | | Join stoffel [0] (~quassel@p57B4B791.dip.t-dialin.net) |
| 11:05:36 | saratoga_ | it stores stuff in the database yeah, but the problem is actually getting track changes to use that information on HWCODEC |
| 11:06:47 | pixelma | it's just that if it needs the database in RAM then it's not worth looking into integrating it into hwcodec since those targets are lowmem so don't have the option to load the database into RAM (just that part isn't available there), that's al |
| 11:06:49 | pixelma | l |
| 11:07:10 | saratoga_ | i don't think it needs to be in RAM |
| 11:09:39 | pixelma | I remember that gather runtime data needed a few fixes to get to work properly on hwcodec but made to work in the end |
| 11:16:22 | | Join fml [0] (~5df3c93d@giant.haxx.se) |
| 11:16:50 | | Join pamaury [0] (~quassel@dhcp-129-228.residence.ens-lyon.fr) |
| 11:16:50 | | Quit pamaury (Changing host) |
| 11:16:50 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:16:56 | fml | Hello. There is a typo in the last commit. In settings.h, the comment for the new settingis wrong (copy-paste?). |
| 11:17:26 | fml | ...but I can't fix it now. |
| 11:17:31 | | Quit fml (Client Quit) |
| 11:17:44 | amiconn | Imo multi-resume is a rather esoteric feature. I fail to see a use case... |
| 11:18:40 | pixelma | something with podcasts and/or audiobooks |
| 11:18:55 | amiconn | For automatic multi-resume, that is. Doing it manually has been possible for years already, using bookmarks |
| 11:21:00 | amiconn | Bookmarks have the further advantage that they don't require the database, while the new multi-resume seems to |
| 11:24:13 | [Saint] | unfortunate;y, this conversation has been had before...I would have preferred to see functionality of bookmarking increased if it actually needed it. |
| 11:24:21 | [Saint] | *unfortunately |
| 11:25:36 | | Join kevku [0] (~kevku@2001:7d0:0:f000::135d) |
| 11:27:40 | pixelma | indeed, and I didn't really see a consensus or at least something close in the thread |
| 11:27:58 | pixelma | I was even a bit surprised to see the commit now |
| 11:29:01 | [Saint] | As was I, I thought it was still very much "up in the air". |
| 11:29:38 | Llorean | amiconn: The problem is the current bookmarking feature doesn't work with the database. |
| 11:30:06 | Llorean | To me, the reasonable solution would've been to fix bookmarking to work with the database, and then add a "if a bookmark is present when file is played, automatically resume the most recent bookmark" option. |
| 11:31:16 | [Saint] | the impression I got was "yeah, but...that's too hard, and I already did this". |
| 11:31:36 | pixelma | I don't complain too loud becaus I didn't take part of the discussion on the ml but I felt that all I wanted to say has been said (I mostly agree/d with Llorean) and the thread had already become so long :\ |
| 11:31:47 | pixelma | *part in |
| 11:32:37 | Llorean | [Saint]: I don't like the idea that a less ideal solution should be used because a good one hasn't completed yet - they're hard to remove later, and it just leads to a pile of half-features interacting in weird ways. |
| 11:32:39 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 11:32:57 | Llorean | But I think I'm in the minority of preferring to have things wait until a "good" solution to a problem comes along. |
| 11:33:13 | * | Llorean still feels Rockbox has gotten progressively buggy for a while now. |
| 11:33:18 | pixelma | I think the same way |
| 11:34:21 | [Saint] | I've sat back, because the last time I got truly empassioned about something I thought was totally the wrong direction to head in...it fel on deaf ears. |
| 11:34:31 | [Saint] | As lons as it has an off button, fine with me. |
| 11:34:46 | [Saint] | *long |
| 11:35:48 | | Join Topy44 [0] (~Topy44@f048144099.adsl.alicedsl.de) |
| 11:36:29 | | Quit Topy (Read error: Connection reset by peer) |
| 11:37:42 | | Join JdGordon| [0] (~jonno@124-149-188-197.dyn.iinet.net.au) |
| 11:37:42 | | Quit JdGordon| (Changing host) |
| 11:37:42 | | Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) |
| 11:38:11 | saratoga_ | imo the really buggy stuff is in playback.c, and this doesn't seriously impact that one way |
| 11:38:39 | saratoga_ | since the changes are pretty trivial and don't impact how playback.c works unless you enable automatic resume |
| 11:39:08 | pixelma | but the point of "implemented half-baked feature" still stands, IMO |
| 11:39:08 | saratoga_ | otherwise you just 'else' into the old case |
| 11:39:17 | saratoga_ | i don't think so |
| 11:39:24 | saratoga_ | its not obvious to me how you could implement this better |
| 11:44:12 | Llorean | Fix bookmarking instead of adding a new feature? It serves basically the same purpose. |
| 11:47:06 | saratoga_ | from my point of view bookmarking is essentially an even worse implementation of a less useful feature |
| 11:47:36 | saratoga_ | while having a manual way to set resume points could be useful, its a pretty silly way to do things when you can quite easily do it automatically |
| 11:48:08 | saratoga_ | in the long term i just assumed we'd get rid of book marking and allow a way to manually set resume points in the database if people thought it was useful enough |
| 11:48:33 | pixelma | why is it less useful? And from a user's point of view, I prefer the bookmarking implementation since it doesn't need the database |
| 11:48:53 | Llorean | You'd be losing a lot of functionality if you took away having multiple bookmarks in a single file. |
| 11:49:05 | pixelma | I don't know what you mean with automatic and manual there |
| 11:50:10 | [Saint] | is there not already automatic bookmarking? |
| 11:50:16 | saratoga_ | you prefer it because it doesn't do things the correct way? |
| 11:50:18 | [Saint] | didn't Torne work on that? |
| 11:50:33 | Llorean | [Saint]: Yes. But there's not automatic resume of bookmarks (unless I missed that being added) and bookmarks don't work with the database. |
| 11:50:39 | saratoga_ | from a users point of view how is that a preference? |
| 11:51:07 | pixelma | saratoga_: what is the "correct" way? Not relying on another feature I need to explicitely enable if I don't use it? |
| 11:51:32 | saratoga_ | the database is the correct way to store metadata about tracks |
| 11:52:00 | saratoga_ | its literally what a database does |
| 11:52:35 | pixelma | resume points aren't metadata in my eyes, it's a playback/playlist thing |
| 11:53:13 | saratoga_ | playback data about a specific file thats unrelated to the current state of the playback engine is metadata |
| 11:54:16 | Llorean | Playback state isn't really metadata in my eyes either. |
| 11:55:09 | Llorean | Also the database is for storing it for search purposes. It's not like we're going to say "we're removing ID3 tags, files should store all their info in the database" or "we're removing support for external album art, it needs to be scanned and entered into the database" |
| 11:55:17 | Llorean | The only functionality that should require the database is searching/using the database. |
| 11:55:28 | saratoga_ | no |
| 11:55:35 | saratoga_ | thats stupid |
| 11:55:51 | saratoga_ | anything that involves storing data persistantly should use the database |
| 11:55:59 | Llorean | Why? |
| 11:56:04 | saratoga_ | because thats what its for |
| 11:56:11 | Llorean | Not really. |
| 11:56:27 | Llorean | It was originally "tagcache" and I think the name gives a pretty clear reason for its being in existence. |
| 11:56:27 | | Quit stripwax (Quit: http://miranda-im.org) |
| 11:56:31 | | Quit bluebrother (Disconnected by services) |
| 11:56:32 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
| 11:56:49 | saratoga_ | so what? |
| 11:57:11 | Llorean | So, my reason's just as good as yours. You've decided its intent is "all persistent data" but that wasn't, at least, its original intent. |
| 11:57:24 | Llorean | And I don't think there's been a discussion that its intent has changed, has there? |
| 11:57:37 | pixelma | why is a resume point persistent? And I also think about bookmarking as related to the playlist and not to a certain file that happens to be affected |
| 11:57:44 | saratoga_ | first of all, the database already stores more then just tags |
| 11:58:16 | Llorean | saratoga_: What, file ratings? |
| 11:58:27 | saratoga_ | run time stats as well |
| 11:58:30 | AlexP | I would fight tooth and nail against removing bookmarking and forcing the database |
| 11:58:42 | Llorean | Ratings are something that traditionally goes into tags, only we don't support writing to tags. |
| 11:58:48 | AlexP | I don't object to this feature, but do not force the database on us |
| 11:59:05 | Llorean | Run time stats are necessary for database searches since that's something you can query it for. |
| 11:59:17 | saratoga_ | like, say resume information? |
| 11:59:46 | Llorean | You can query for resume information? What, are you going to search for "files I've got resume points in at longer than 4 minutes in"? |
| 11:59:54 | AlexP | bookmarks can e.g. be easily copied between players |
| 12:00 |
| 12:00:00 | saratoga_ | "i've got a file, does it have a resume point?" |
| 12:00:19 | Llorean | "I've got a file, does it have album art" |
| 12:00:26 | Llorean | Clearly album art needs to be using the database only too, now |
| 12:00:44 | saratoga_ | no because we have to buffer album art |
| 12:01:26 | saratoga_ | look i'm not doubting that you can duplicate everything that a sane data storage system does with a mess of files on the hard disk, i'm just saying doing that for no reason is ridiculous |
| 12:01:49 | Llorean | Resume points without database isn't "no reason" |
| 12:01:55 | AlexP | no reason? |
| 12:02:02 | saratoga_ | there are obviously a few targets where memory is so tight we can't do things sensibly, but they're fewer and fewer every day |
| 12:02:08 | Llorean | Resume point are something people have been using, as bookmarks, without the database for *years* in Rockbox. |
| 12:02:18 | Llorean | There's no reason to add it to the database other than a desire to force users to lose existing functionality |
| 12:02:24 | saratoga_ | "without the database" is not a reason |
| 12:02:31 | saratoga_ | literally |
| 12:02:43 | saratoga_ | it doesn't explain anything |
| 12:02:44 | Llorean | What's the reason *for* adding it other than "I think it belongs there"? |
| 12:02:55 | AlexP | I don't really see the point in this discussion, it looks like it is going to get committed anyway |
| 12:03:02 | saratoga_ | its already committed |
| 12:03:06 | AlexP | exactly |
| 12:03:14 | AlexP | So why discuss if it is ignored |
| 12:03:18 | Llorean | AlexP: Yes, but now he's advocating removing bookmarks. |
| 12:03:19 | | Quit factor (Ping timeout: 255 seconds) |
| 12:03:27 | Llorean | That hasn't happened yet. |
| 12:03:34 | AlexP | Llorean: I'm not worried about that, I'd just revert it |
| 12:03:36 | saratoga_ | i'm not removing bookmarks because i don't care |
| 12:03:50 | saratoga_ | i'm just pointing how ridiculous people are about the database |
| 12:03:58 | AlexP | In your opinion |
| 12:03:59 | saratoga_ | avoiding it is an end in and of itself |
| 12:04:10 | saratoga_ | not one person has so far mentioned why they don't want to use it |
| 12:04:16 | Llorean | saratoga_: Bookmarking a single file shouldn't depend on having enough disk space for the whole database. |
| 12:04:18 | saratoga_ | isn't that a little funny to you guys? |
| 12:04:22 | AlexP | Loss of lots of RAM |
| 12:04:23 | Llorean | A bookmark is tiny, the database isn't necessarily |
| 12:04:31 | saratoga_ | how much RAM? |
| 12:04:36 | AlexP | 2 MB |
| 12:04:40 | Llorean | If there were a way to store it in the database without initializing it with tag data, sure, that's different. |
| 12:04:46 | saratoga_ | 2MB for how many tracks? |
| 12:04:52 | AlexP | Loads of small ones |
| 12:05:12 | saratoga_ | how many? |
| 12:05:43 | Llorean | saratoga_: forcing people to use the database because you think it's sane seems to be another end in and of its self. |
| 12:05:45 | AlexP | I can't remember exactly, my player isn't to hand. 15k ish IIRC although that is a guess |
| 12:05:50 | Llorean | Why make them use it for a feature that doesn't *require* it? |
| 12:06:00 | Llorean | Database searches require it, obviously, by their nature. Bookmarks don't. |
| 12:06:18 | saratoga_ | forcing people to use rockbox features that are implemented well is a goal of mine yes |
| 12:06:26 | AlexP | I can move bookmarks between players |
| 12:06:29 | saratoga_ | you're complaining that i want to improve things |
| 12:06:32 | AlexP | How to do that with the db |
| 12:06:32 | saratoga_ | well played |
| 12:06:37 | Llorean | saratoga_: That's not an improvement. |
| 12:06:47 | saratoga_ | your technical opinion? |
| 12:06:49 | Llorean | "We'd like to force you to use an unnecessary amount of disk space for information that's a few bytes. " |
| 12:07:07 | Llorean | Why should a user be force to cache all of their files' metadata just to store a resume point? |
| 12:07:22 | Llorean | That's inefficiency at its fines. |
| 12:07:24 | Llorean | t |
| 12:07:24 | saratoga_ | i'm not saying they should |
| 12:07:26 | AlexP | anyway, as I say I don't object to this particular feature too much, it is bookmarking I care about |
| 12:07:34 | Llorean | saratoga_: You said they should be forced to use the database for resume points. |
| 12:07:37 | saratoga_ | yes |
| 12:07:38 | Llorean | That's what the database *is* |
| 12:07:43 | saratoga_ | it doesn't have to be |
| 12:07:58 | Llorean | Well you didn't say you were talking about a hypothetical future database that follows rules known only to you. |
| 12:08:06 | AlexP | Being able to have only those files with resume points added to the database would be very nice |
| 12:08:08 | Llorean | We all assumed you were talking about the real database that exists right now. |
| 12:08:21 | AlexP | add them one by one as resume points get added |
| 12:08:23 | Llorean | As I said, I wouldn't object if the database could be restricted to only holding the resume data. |
| 12:08:29 | saratoga_ | obviously i'm not since the database i'm talking about includes bookmarks . . . |
| 12:08:44 | Llorean | saratoga_: Sorry, "the database we have plus the feature you explicitly mentioned adding to it" |
| 12:08:58 | Llorean | We can't read your mind, so we obviously can't know about features you *haven't* spoken of. |
| 12:09:08 | saratoga_ | well if we're talking about how we want things to be i don't see why we should assume limitations we have now |
| 12:09:21 | saratoga_ | you could ask me |
| 12:09:28 | AlexP | ! |
| 12:09:48 | Llorean | That makes no sense. I shouldn't have to ask you about every possible permutation. If you're discussing one possibility you should describe it, not assume people can read your mind and know what you intend. |
| 12:10:09 | saratoga_ | err, what? |
| 12:10:10 | Llorean | If you say "I think the database should be the only place to keep resume points" it's pretty reasonable that someone will think you mean the *current* database, not some other one you've got in your head. |
| 12:10:33 | | Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) |
| 12:10:39 | saratoga_ | no thats not reasonable since i'm talking about improving the database! |
| 12:10:46 | Llorean | Especially when someone has already mentioned they'd be okay with it if it didn't have to include all the metadata, and you ignore that for five minutes without saying "yes, like that" |
| 12:11:51 | saratoga_ | honestly no one even mentioned memory use until the very end of this argument, so i don't know why i should assume thats what you're concerned about |
| 12:12:01 | Llorean | saratoga_: It's perfectly reasonable to think, when someone refers to the database, that they're referring to it as it exists, plus anything they've explicitly mentioned, because someone with the intent of having a constructive conversation would mention other changes they have. ESPECIALLY when they might mitigate some of the objections people brought up. |
| 12:12:06 | | Join factor [0] (~factor@75.108.68.114) |
| 12:12:58 | Llorean | saratoga_: (5:04:39 AM) Llorean: If there were a way to store it in the database without initializing it with tag data, sure, that's different. <−− Seems that even without the mention of "memory" this should've at least prompted a "they might be interested in this idea" |
| 12:13:11 | saratoga_ | i think its perfectly reason for people who have a problem with a specific aspect of something (e.g. having a database in memory) to actually mention that instead of complaining about nothing in particular |
| 12:13:32 | Llorean | saratoga_: You can't discuss a feature without being at the same place about it, so are there any other changes you're holding in your mind that might affect this image of the database you have? |
| 12:14:20 | saratoga_ | yeah but i haven't hashed them out yet |
| 12:14:54 | saratoga_ | i was thinking of a system where you either just index all the files but don't cache the tags, or better yet don't index anything until its actually played |
| 12:15:13 | saratoga_ | so it behaves sort of like a cache on low memory targets |
| 12:15:16 | Llorean | How about never index anything, if the user doesn't want to have it indexed? |
| 12:15:43 | Llorean | As I said, I wouldn't mind if all my bookmarks or runtime stats were stored, but I don't want to waste disk space creating a searchable database I'll never use. |
| 12:24:00 | *** | Saving seen data "./dancer.seen" |
| 12:28:32 | | Join Buschel [0] (~chatzilla@p54A3B908.dip.t-dialin.net) |
| 12:30:19 | Buschel | [Saint]: ping |
| 12:30:43 | [Saint] | yo. |
| 12:31:06 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 12:31:14 | * | TheSeven wonders if the iPod Classic port should go into SVN or FlySpray |
| 12:31:34 | TheSeven | the problem is that it might break other targets that I don't have and thus can't test on |
| 12:31:34 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 12:31:41 | TheSeven | (due to the ATA changes) |
| 12:31:44 | Buschel | still need verification for some patches on the iPod color. do you have access to it? |
| 12:31:45 | [Saint] | which ones? |
| 12:32:08 | [Saint] | Bushmills: Ah, yes. Which patches. |
| 12:32:09 | Buschel | TheSeven: if it possibly brakes other targets I would not submit to svn |
| 12:32:48 | TheSeven | Buschel: on the other hand, nobody seems to be willing to test that part right now |
| 12:32:57 | TheSeven | so this thing might be stuck in flyspray forever |
| 12:33:31 | TheSeven | if it breaks, it breaks completely (no disk access possible at all), so it will be apparent |
| 12:33:36 | AlexP | TheSeven: Send a mail to the dev list saying here it is on fs, please test as it might break x, y, z - if nobody tests it'll go in in a week |
| 12:33:36 | TheSeven | and probably trivial to fix |
| 12:34:18 | AlexP | I'm happy to test later on today |
| 12:34:32 | * | TheSeven needs to figure out which targets might be affected |
| 12:34:54 | Buschel | [Saint]: FS #11843 v16, and FS #11820 (will provide a test patch later) |
| 12:34:54 | TheSeven | basically everything that's doing ATA byte swapping, and we should also test the bigendian targets |
| 12:36:03 | Buschel | TheSeven: why not submit the Classic port except this breaking change in one step and the ATA stuff in a second submit to be able to roll it back easily? |
| 12:36:26 | TheSeven | because the classic port can't work without the changes |
| 12:36:31 | Buschel | [Saint]: also, can you check which lcd_type your color has? this is available in the debug menu |
| 12:37:15 | TheSeven | and i don't think it will need a rollback. if anything, it will need a few more #ifdefs swapping bytes |
| 12:37:28 | [Saint] | Buschel: The OFs or RBs? |
| 12:37:33 | Buschel | RB's |
| 12:37:33 | [Saint] | (debug menu) |
| 12:38:17 | [Saint] | LCD type: 1 |
| 12:38:31 | [Saint] | (for both, incedentally) |
| 12:38:55 | Buschel | hmm, interesting. both reach ~52 fps RGB full screen, right? |
| 12:39:16 | [Saint] | it was something like that. |
| 12:39:33 | Buschel | the nano 1G also uses lcd_type 1 |
| 12:40:15 | [Saint] | quite a difference in screen size though ;) |
| 12:40:59 | Buschel | [Saint]: yes, but the throughput in MB/s is still 2.5x faster nano1g vs. color |
| 12:41:19 | Buschel | [Saint]: short test regarding FS #11820 -> http://pastie.org/1423126 |
| 12:43:33 | Buschel | amiconn: do you still have access to the iPod photo which you used to measure LCD speed (see LcdFrateRate wiki) |
| 12:44:34 | Buschel | [Saint]: if FS #11843 v16 works for you, I am interested in RGB/YUV speed boosted/unboosted. I would like to submit if it works fine |
| 12:45:21 | [Saint] | Ok, I'm patching now. Then building, <slight delay>, testing. :) |
| 12:45:46 | Buschel | so, you are able to build again :) |
| 12:46:14 | [Saint] | Yes, I figured out my CygWin gremlin. |
| 12:51:15 | [Saint] | rockboxdev.sh was trying to delete the build dir while it was still in it...the code for it was fine, I added a pause and prompt for manual resume and it worked fine. |
| 12:52:01 | [Saint] | without it, it was ignoring a "cd" for some reason, seems to work on other systems though. |
| 12:52:11 | [Saint] | *cd .. |
| 12:58:21 | | Quit saratoga_ (Quit: Page closed) |
| 13:00 |
| 13:01:13 | | Quit JdGordon| (Quit: Lost terminal) |
| 13:04:07 | amiconn | saratoga: One main point about the database in rockbox is that it's optional. Atm I don't need bookmarks or automatic resume points, because I neither listen to audio books nor podcasts |
| 13:05:36 | amiconn | But if I ever start doing that, I much prefer a way that doesn't require me to use the database, which I don't use regularly either |
| 13:06:55 | amiconn | I have it enabled for pictureflow to work, but that's only for occasional, show-off. In >99.9% of all cases I start playback from the file browser |
| 13:08:02 | * | [Saint] only has the DB enables so he can occasionally show someone pictureflow/wps integration. |
| 13:08:23 | [Saint] | *enabled |
| 13:08:39 | * | amiconn never even tried pf/ wps integration |
| 13:09:29 | [Saint] | kinda cool. But just for "eye candy". |
| 13:09:52 | amiconn | Rockbox has a lot of feature I have no use for... |
| 13:10:20 | amiconn | At least most of them aren't duplicating functionality.. this latest one does though :( |
| 13:10:52 | [Saint] | <y general theory is "as long as I can turn it off, then sweet"...this is a bit of a grey area. |
| 13:11:34 | [Saint] | It's only by the coincidence I use the DB for pictureflow that it doesn't really affect me. I understand there are many that don't use the DB. |
| 13:13:41 | Buschel | [Saint]: still building? |
| 13:19:16 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 13:19:32 | | Quit leavittx__ (Ping timeout: 276 seconds) |
| 13:19:36 | n1s | speaking of testing, could anyone with a coldfire target that's not h300 or hd300 test the testbuilds i linked in my mail to the ml last week? And it would be cool if someone could test building the new toolchain on cygwin too |
| 13:19:58 | | Quit Judas_PhD (Client Quit) |
| 13:21:56 | pixelma | hmm, what do I need for the toolchain? |
| 13:22:17 | pixelma | do, I need to build it myself? |
| 13:22:20 | pixelma | -, |
| 13:23:23 | pixelma | n1s: could you provide an M5 build with FM enabled (in advanced options)? |
| 13:23:37 | n1s | pixelma: sure |
| 13:24:56 | n1s | pixelma: it would be good if someone tested building the toolchain on cygwin |
| 13:26:12 | pixelma | I'm not sure I know everything that's involved for doing so (except taking time... ;) ) |
| 13:28:16 | n1s | i have a patch so anyone who wants to test building just needs to apply it and run rockboxdev.sh |
| 13:29:11 | n1s | (the tools patch in FS #7832) |
| 13:30:10 | n1s | pixelma: http://dl.dropbox.com/u/17484767/rockbox-m5-fm.zip |
| 13:32:40 | n1s | I'm mostly worried about target specific drivers breaking as everything seems to work fine on my h300 |
| 13:34:58 | pixelma | ok, I'll have a look at sound etc. and recording and have an eye on the RTC. The radio is basically the same as the H300's AFAIK but you'll get half an X5 test with this too ;) |
| 13:35:36 | n1s | great |
| 13:36:16 | | Join bluebrother [0] (~dom@g226069187.adsl.alicedsl.de) |
| 13:36:16 | | Quit bluebrother (Changing host) |
| 13:36:16 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 13:38:02 | Dreamxtreme | TheSeven i have a 3rd gen on the way if you need help to test anything |
| 13:39:22 | | Quit bluebroth3r (Ping timeout: 272 seconds) |
| 13:45:52 | | Join T44 [0] (~Topy44@f048048039.adsl.alicedsl.de) |
| 13:48:44 | amiconn | n1s: There's something in your 'rockboxdev.sh' patch that doesn't belong there |
| 13:48:54 | amiconn | 'make' -> 'make -j4' |
| 13:49:00 | | Quit Topy44 (Ping timeout: 240 seconds) |
| 13:49:47 | | Join Ogham [0] (~Ogham@unaffiliated/ogham) |
| 13:50:48 | Ogham | Can anyone throw any light on bug FS #11812 ? Does this have the potential to damage low impedance IEM's? |
| 13:51:31 | * | amiconn isn't sure which of the diff files in fs #7832 are needed to get the whole thing |
| 13:53:34 | pixelma | n1s: playback works (flac and wav tested), sound settings seems to work (bass, treble tested which are in software with this DAC), voice works, FM seems to be working correctly, recording works (tested with the built-in mic), the RTC doesn't show any problems. Anything else to test? |
| 13:54:40 | * | amiconn could test h100 if he knew what's needed |
| 13:55:25 | pixelma | n1s: oh - buttons work, mpegplayer works |
| 13:57:27 | amiconn | Buschel: Sure, since it's mine. But I don't have it with me atm |
| 14:00 |
| 14:15:29 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 14:18:25 | n1s | amiconn: only the last 2, the codec tuning one isn't actually necessary though |
| 14:18:46 | n1s | so just the patch for configure and rockboxdev.sh |
| 14:19:19 | Buschel | amiconn: fine, could you just test (function, speed) FS #11843 v16 and check what lcd_type you have? you could place this info in flyspray |
| 14:19:56 | n1s | pixelma: sounds good, if you have a remote, testing that might be interesting |
| 14:20:13 | * | Buschel wonders where [Saint] is, he seems to have vanished... |
| 14:20:48 | pixelma | n1s: don't have one yet, though B4gder wanted to send me one sometime |
| 14:20:51 | n1s | amiconn: since it seems to work well for all tested players so far, things specific for the h100 would be most interesting, and the remote if you have one, since i don't |
| 14:21:07 | amiconn | I do have a remote |
| 14:21:40 | amiconn | The H100 and the M3 have some drivers which the later coldfire targets don't have |
| 14:21:58 | n1s | and, yes i forgot to remove that make -j4 change as well as the commented out code since i wasn't sure if we wanted to keep support for the old toolchain in the script so that patch isn't quite finished |
| 14:22:32 | amiconn | These targets do not have the PCF5060x, but separate ADCs instead. Especially the M3 one is rather picky about timings (and slow...) |
| 14:23:05 | n1s | it would be great if you could test that |
| 14:23:20 | n1s | pixelma: ok, thanks for testing :) |
| 14:23:45 | pixelma | you're welcome :) |
| 14:24:03 | *** | Saving seen data "./dancer.seen" |
| 14:25:28 | pixelma | Could it be that mp3 decoding got a bit faster or somesuch? I have the impression that mpegplayer works better (my videos I wanted to encode again because of choppy playback due to a bit higher bitrate look better and I wondered why) |
| 14:30:59 | n1s | mp3 decoding got about 3% faster but i don't think that would be noticable in mpegplayer |
| 14:31:52 | * | amiconn is trying to build the new toolchain on cygwin |
| 14:32:29 | n1s | amiconn: cool :) |
| 14:33:03 | amiconn | Will take a while, even though I've disable the on-access AV for this |
| 14:33:07 | amiconn | *disabled |
| 14:33:51 | pixelma | maybe for other reasons then, anyway - it looks like I don't have to encode these videos again :) |
| 14:34:02 | n1s | pixelma: nice |
| 14:34:33 | n1s | amiconn: do you remember why the old toolchain needs a patch to disable some multilib? |
| 14:34:39 | amiconn | yes |
| 14:35:10 | amiconn | The disabled multilib fails to build on various systems. Those need the patch |
| 14:36:09 | n1s | do you know if it is needed for the new toolchain? (i guess your build will fail if that's the case) |
| 14:37:05 | amiconn | How should I know? There's just one way to find out... |
| 14:37:50 | n1s | yeah |
| 14:38:20 | pixelma | guess we also need some testers for the toolchain on Mac too, IIRC they also show weird behaviour sometimes |
| 14:38:50 | n1s | is any active dev using macOS ? |
| 14:39:01 | amiconn | n1s: Do you use linux x86_64? |
| 14:39:06 | n1s | yes |
| 14:39:18 | amiconn | So it's probably not needed anymore. |
| 14:39:27 | pixelma | Lambda has one I think (and JdGordon had access to one but I don't know if this is the case anymore) |
| 14:39:37 | n1s | no, the 64 bit patch isn't needed anymore |
| 14:40:13 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 14:40:50 | amiconn | Ah, that was another patch |
| 14:41:09 | n1s | yes |
| 14:44:08 | n1s | oh, i just remembered that the patched rockboxdev.sh only builds coldfire multilibs |
| 14:45:00 | n1s | so that particualr problem will probably not show up |
| 14:45:08 | [Saint] | did something with the speex encoder change recently...ish? |
| 14:45:22 | [Saint] | I can't seem to build voice files on CygWin |
| 14:46:08 | amiconn | n1s: Maybe it would be a good idea anyway to disable all multilibs we don't use. It would speed up tollchain building, and the resulting toolchain would need less disk space. |
| 14:46:48 | n1s | yes, that is true |
| 14:47:22 | amiconn | It would mean additional work if we add a target that needs them though |
| 14:47:25 | [Saint] | http://pastebin.com/8bkEEdPS is what bash has to say about the whole voice building fiasco, fwiw. |
| 14:47:57 | amiconn | Same applies to the SH multilibs btw - we only use sh1 |
| 14:48:40 | n1s | amiconn: the −−with-arch=cf config option makes it build only the coldfire multilibs, not the other m68k ones so maybe that's good enough? |
| 14:49:03 | amiconn | aha |
| 14:49:08 | amiconn | Let's see |
| 14:51:38 | n1s | only 8 different multilibs are built and they take about a half megabyte of space each |
| 14:53:58 | n1s | the old toolchain built 10 |
| 14:55:28 | Buschel | [Saint]: does FS #11843 work for you? |
| 14:55:56 | | Join stsquad` [0] (~user@nat18.sesnet.co.uk) |
| 14:56:21 | amiconn | n1s: |
| 14:56:22 | amiconn | configure: error: in `/tmp/rbdev-build/build-binutils/ld': |
| 14:56:22 | amiconn | configure: error: C compiler cannot create executables |
| 14:59:48 | n1s | hmm |
| 15:00 |
| 15:00:14 | n1s | i have to go for a while but will look at that later |
| 15:00:38 | amiconn | Happened after running for 25 minutes |
| 15:03:19 | | Quit [Saint] (Ping timeout: 255 seconds) |
| 15:09:24 | | Quit sasquatch (Ping timeout: 240 seconds) |
| 15:11:44 | | Join [Saint] [0] (S_a_i_n_t@203.184.0.102) |
| 15:13:41 | [Saint] | Buschel: very, very weird behaviour. |
| 15:14:31 | [Saint] | the top of the screen is being drawn again oer the bottom of the screen. |
| 15:14:52 | [Saint] | which dissappears momentarily whilst scrolling. |
| 15:16:19 | Buschel | YUV is working fine? |
| 15:16:42 | [Saint] | how am I to establish that? |
| 15:16:59 | Buschel | play a movie or use test_fps |
| 15:17:35 | [Saint] | yes. |
| 15:19:20 | [Saint] | the boot splash and the menus are garbled in the same way, a split about two thirds down the screen where the top of the screen is drawn overtop. |
| 15:19:44 | Buschel | I am checking right now |
| 15:22:05 | Buschel | can you backtrace which patch-version introduced this? you'll just need to re-build rockbox.ipod |
| 15:22:50 | Buschel | seems like the RGB screen update is broken |
| 15:24:00 | | Quit MethoS- (Remote host closed the connection) |
| 15:24:08 | Buschel | (which is funny as it did not change as much as YUV) |
| 15:25:56 | | Join sasquatch [0] (~username@46.114.82.65) |
| 15:37:22 | | Part stsquad` ("ERC Version 5.3 (IRC client for Emacs)") |
| 15:39:58 | | Quit GodEater (Read error: Operation timed out) |
| 15:42:43 | * | Buschel cannot recognize the fault in the code... :/ |
| 15:46:48 | n1s | amiconn: that error seems vague, is there anything interesting in the config.log ? |
| 15:49:55 | n1s | that the binutils build fails is interesting since it's the same version that we use for arm-elf now |
| 15:50:05 | n1s | eh, arm-eabi-elf |
| 15:54:24 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 15:55:06 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:55:52 | | Quit kadoban (Read error: Operation timed out) |
| 15:56:36 | Buschel | [Saint]: are you still there? |
| 15:58:23 | | Join mystica555_ [0] (~mike@c-75-70-179-25.hsd1.co.comcast.net) |
| 16:00 |
| 16:00:07 | Buschel | [Saint]: yeah, I think I have it :) |
| 16:03:49 | Buschel | [Saint]: as the full screen lcd update needs to loop twice to update your screen, I need to correct the address within the framebuffer after the first run. this is not needed for the nano1g. |
| 16:08:51 | TheSeven | damn, that DMA buffering logic is driving me nuts |
| 16:09:43 | | Join GodEater [0] (~bibble@rockbox/staff/GodEater) |
| 16:10:28 | Buschel | [Saint]: updated FS #11843 v17 |
| 16:12:31 | Buschel | [Saint], soap: if I am not wrong the swapping in the LCD driver is not really needed. I will provide a patch for testing as soon as v17 (or any neccessery bugfix for this) has been submitted |
| 16:15:34 | n1s | hmm, i have no idea what could cause that cygwin failure, maybe i should set up a cygwin environment to test in myself :/ |
| 16:17:12 | n1s | apparently a new binutils release has been made but i can't find any info on what they have fixed in it, only added features |
| 16:24:06 | *** | Saving seen data "./dancer.seen" |
| 16:28:19 | | Quit mystica555_ (Ping timeout: 264 seconds) |
| 16:34:14 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 16:34:24 | | Quit Buschel (Ping timeout: 276 seconds) |
| 16:35:06 | TheSeven | urgh |
| 16:35:14 | TheSeven | that bugger doesn't even manage MP3 realtime |
| 16:36:05 | TheSeven | IIUC it's an ARM9e running at 216MHz |
| 16:36:18 | TheSeven | caches should be enabled |
| 16:36:34 | TheSeven | from the skipping behavior i'd say 80% realtime |
| 16:37:02 | n1s | that sounds too slow for that core/freq even with caches disabled |
| 16:37:41 | TheSeven | with caches disabled the UI was lagging |
| 16:38:26 | TheSeven | what's the best way to figure out the real clock? |
| 16:38:49 | TheSeven | let it iterate a thousand times through a loop of a thousand nops and measure the time? |
| 16:39:39 | n1s | i can't think of another way of doing it without knowing how it's configured |
| 16:40:30 | TheSeven | the rest of the UI is responding quite fast, and games like chopper run fluently |
| 16:44:07 | TheSeven | n1s: 10.000 iterations of 1.000 nops took 52.319µs |
| 16:44:45 | TheSeven | so if there would be zero overhead, that would be ~191MHz |
| 16:45:10 | TheSeven | it must be something different... |
| 16:45:32 | n1s | if caches are disabled and memory is slow enough to cause mp3 to not be realtime i'd guess the overhead would be significant |
| 16:46:11 | n1s | can you run test_codec ? |
| 16:46:47 | n1s | an do less demanding codecs play fine, like flac or just a wav for example? |
| 16:47:37 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 16:53:32 | kugel | TheSeven: 10M instructions in 52µs? |
| 16:54:55 | kugel | that's a lot more than 191MHz |
| 16:55:13 | TheSeven | huh? |
| 16:55:32 | TheSeven | 52ms (i used . as a thousands separator) |
| 16:55:43 | kugel | oh |
| 16:56:14 | TheSeven | well, this is assuming that the usec timer counts usecs of course :) |
| 16:56:31 | kugel | you don't use . as thousands seperator in english :) |
| 16:58:01 | TheSeven | well, but then it would have been 10 instructions in 52µs |
| 16:58:36 | kugel | true |
| 16:59:06 | TheSeven | and the usec timer seems to be sane |
| 17:00 |
| 17:00:01 | TheSeven | 5'229'780µs for 1'000'000'000 instructions took like 5 seconds, so that's fine |
| 17:00:07 | | Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) |
| 17:00:11 | | Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) |
| 17:00:29 | TheSeven | (191.212632MHz) |
| 17:01:23 | TheSeven | does rockbox do cpu time accounting for the individual threads? |
| 17:01:44 | TheSeven | maybe there's just some CPU hog? |
| 17:03:18 | * | TheSeven compiles a build with test plugins |
| 17:03:50 | n1s | the Os stacks (IIRC) debug screen shows someinfo about the threads but not the cpu time i think |
| 17:04:35 | TheSeven | gevaerts: any idea why rockbox usb exposes 512 byte sectors on a drive with 4096 bytes per physical sector, formatted as a superfloppy fat32 file system with 4096 bytes per sector? |
| 17:05:07 | TheSeven | the file system works fine in rockbox, so that ipod video hack layer must be functioning |
| 17:19:09 | TheSeven | n1s: flac plays fine |
| 17:19:27 | TheSeven | but the playback progress bar is jumping like crazy |
| 17:19:48 | TheSeven | probably due to a problem with pcm_get_bytes_waiting |
| 17:19:48 | n1s | weird |
| 17:29:36 | pamaury | TheSeven: does usb msc supports something else than 512 bytes per sectors ? |
| 17:29:51 | pamaury | I don't remember but I'm not sure |
| 17:30:18 | TheSeven | the whole flac file (27MB) would fit easily into RAM, and there's also 27MB allocated in the buffering debug screen |
| 17:30:26 | TheSeven | the pcm buffer is always around half full |
| 17:30:47 | TheSeven | pamaury: certainly |
| 17:31:45 | TheSeven | real is always in the 50000-70000 range, usefl is 20000-40000 |
| 17:31:56 | TheSeven | so we're indeed facing a problem on the disk side of things? |
| 17:32:12 | TheSeven | the ATA driver is still PIO only for now |
| 17:32:46 | n1s | if the disk is the bottleneck wouldn't mp3 work better than flac? |
| 17:33:30 | | Join liar [0] (~liar@188-22-211-66.adsl.highway.telekom.at) |
| 17:33:56 | TheSeven | if disk accesses are eating lots of CPU, the MP3 codec might push the bandwidth further down |
| 17:34:34 | TheSeven | and the scheduler efficiency might also suffer at a more balanced codec/disk load |
| 17:34:41 | TheSeven | from* |
| 17:34:49 | n1s | yeah, but the mp3 file will be much smaller than flac, anyway, what numbers do you get from test_disk? |
| 17:35:14 | TheSeven | let me check |
| 17:35:43 | TheSeven | create: 6 files per second |
| 17:36:07 | TheSeven | open: 10568 files, dirscan: 487371, delete: 5 |
| 17:36:31 | TheSeven | create/write/read 512,a: 16/16/783 kB/s |
| 17:36:46 | TheSeven | create/write/read 512,u: 16/16/715 kB/s |
| 17:37:06 | TheSeven | create/write/read 4096,a: 924/936/789 kB/s |
| 17:37:20 | TheSeven | create/write/read 4096,: 935/947/781 kB/s |
| 17:37:30 | TheSeven | that was 4096,u |
| 17:37:45 | TheSeven | create/write/read 1048576,a: 961/979/812 kB/s |
| 17:37:58 | TheSeven | create/write/read 1048576,u: 943/956/807 kB/s |
| 17:38:05 | n1s | that looks like a definite bottleneck |
| 17:38:22 | TheSeven | however read performance seems to be ok, even for sub-sector accesses |
| 17:39:32 | n1s | right, shouldnt' be bad enough to cause stuttering for mp3 |
| 17:39:40 | | Quit liar (Read error: Operation timed out) |
| 17:40:09 | TheSeven | hm, maybe disk accesses are over-yielding? |
| 17:40:44 | n1s | see http://www.rockbox.org/wiki/DiskSpeed for a speed comparison |
| 17:41:15 | n1s | TheSeven: iirc a thread should yield about once each tick or so if not sleeping |
| 17:42:22 | TheSeven | hm, disk accesses are certainly yielding way more |
| 17:42:35 | TheSeven | there will be several calls to yield() after each access |
| 17:45:13 | | Quit sasquatch (Ping timeout: 240 seconds) |
| 17:45:41 | | Join sasquatch [0] (~username@2.210.213.240) |
| 17:46:28 | * | TheSeven needs to reformat the disk |
| 17:53:02 | TheSeven | hm, after i replaced some yields that aren't present on other devices with busy waiting the buffering screen results for flac are a tiny bit better, but still way off normal |
| 17:53:24 | TheSeven | mp3 is still stuttering |
| 17:55:37 | kugel | is it only stuttering during buffering or the whole time? |
| 17:56:08 | TheSeven | it never manages to buffer more than ~40KB |
| 17:57:21 | TheSeven | flac manages to read ~300KB ahead once and then also starts rebuffering like every second |
| 17:58:19 | * | TheSeven wonders if there are some tunables he could play with |
| 18:00 |
| 18:02:16 | | Join Buschel [0] (~chatzilla@p54A3B3F6.dip.t-dialin.net) |
| 18:02:27 | TheSeven | hm, the disk can barely keep up with flac apparently |
| 18:03:02 | TheSeven | if i remove all yields from the ata driver, it manages to read up to ~2MB ahead |
| 18:03:13 | n1s | what was it you needed someone to test to be able to commit your work? |
| 18:03:26 | TheSeven | in complex areas of the song the usefl value drops badly |
| 18:03:46 | TheSeven | it has barely ~1MB of usable data after a total of ~20MB played |
| 18:04:10 | TheSeven | n1s: disk access on all big-endian or ata-swapped-words targets |
| 18:04:39 | n1s | i can test on my h300, i'ts big endian, i have no idea if it swaps words though |
| 18:04:39 | TheSeven | first rebuffering at ~25 of ~27MB played this time |
| 18:05:24 | TheSeven | and MP3 is worse than before, even though it manages to buffer a bit more data now (this time the codec seems to be starving, not the disk) |
| 18:05:57 | TheSeven | no rebuffering so far, ~500KB readahead accumulated during the first ~3MB |
| 18:06:00 | n1s | where can i find the patch? |
| 18:08:05 | TheSeven | n1s: http://pastie.org/1423647 |
| 18:08:28 | n1s | anything special or just any reading/writing? |
| 18:08:36 | TheSeven | if it fails, nothing will work at all |
| 18:08:57 | n1s | ok |
| 18:09:10 | TheSeven | hm, mp3 even fails after it has finished buffering (at ~90% of the track) |
| 18:12:42 | TheSeven | how does the ATA driver tell the low level driver which PIO mode it should use? |
| 18:16:19 | n1s | TheSeven: something is definitely broken, menu and filebrowser text is scrambled |
| 18:16:30 | TheSeven | damn |
| 18:16:58 | TheSeven | but it managed to mount the volume? |
| 18:17:11 | n1s | looks like it |
| 18:17:19 | TheSeven | that's interesting |
| 18:18:07 | TheSeven | Torne: do i understand correctly that rockbox always uses PIO0? |
| 18:24:08 | TheSeven | apparently now |
| 18:24:09 | *** | Saving seen data "./dancer.seen" |
| 18:24:11 | TheSeven | not* |
| 18:30:00 | n1s | TheSeven: think i found one bug in your patch |
| 18:31:19 | n1s | IIUC it handles all coldfires the same even though some do the swap words thing |
| 18:31:50 | | Join Kitar|st [0] (~Kitarist@BSN-182-77-193.dial-up.dsl.siol.net) |
| 18:32:42 | TheSeven | so one would need more #ifdef'ing in firmware/target/coldfire/ata-target.h? |
| 18:32:54 | n1s | yes, i think so |
| 18:33:00 | TheSeven | MPIO is handled by a different file |
| 18:33:20 | n1s | oh, i missed that then |
| 18:37:25 | | Quit feisar- (Ping timeout: 240 seconds) |
| 18:41:47 | | Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) |
| 18:42:06 | n1s | TheSeven: removing the swap16 from ata.c:1141 fixes it |
| 18:42:26 | | Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) |
| 18:43:53 | TheSeven | hm, but that seems to be needed on other targets |
| 18:44:28 | TheSeven | which raises the question which targets need it and which don't |
| 18:46:15 | n1s | that seems odd since before the patch only big endian targets that don't swap words had this swap (and now that ATA_IN16 already swaps for those targets that extra swap was just swapping back) |
| 18:48:14 | n1s | IIUC an extra swap there would cause wildly different settings to be used by the ata driver |
| 18:51:35 | | Quit Llorean (Quit: Leaving.) |
| 18:55:24 | TheSeven | it works fine on my ipod classic - but maybe that's specific to that platform |
| 18:56:57 | * | pixelma curses mpegplayer debug output in a sim for a file which only plays without audio in Rockbox but works fine in VLC |
| 18:57:21 | pixelma | there's so much info that I can't even see what actually happens :\ |
| 18:57:39 | Buschel | can you see which audio codec is used? |
| 18:58:53 | pixelma | maybe that's a hint: audio: mad_header_decode failed:forbidden bitrate value ? |
| 18:59:42 | Buschel | what does vlc tell you? |
| 18:59:51 | n1s | hmm, a dump of the ata identify info with svn is different from one with the patch and my change |
| 19:00 |
| 19:01:02 | TheSeven | how different? |
| 19:01:29 | pixelma | the video is a music video where I had to transcode the video part but it has mpg audio, so I thought I could do without transcoding - it's 22.05 kHz though and 48 kb/s. Is mpegplayer not able to resample? |
| 19:02:23 | n1s | TheSeven: i just md5sumed them, checking it out now |
| 19:04:50 | | Join y4n [0] (y4n@unaffiliated/y4ndexx) |
| 19:05:10 | Buschel | pixelma: I don't know... but good question |
| 19:05:35 | n1s | TheSeven: 2 bytes differ |
| 19:05:40 | Buschel | pixelma: which layer is it? |
| 19:06:17 | amiconn | n1s: Nothing interesting in there. config.log has been touched the last time at 14:32 (build started at 14:30), the build error happened 14:55 |
| 19:06:20 | y4n | Hello. It is weird how with a certain loud album I can hear volume fluctuating during listening, on a rockbox'd clip+. Compressor is off... no such issues when listening in foobar2000 for example. |
| 19:06:35 | y4n | envy - Recitation (2010) |
| 19:07:16 | n1s | amiconn: ah, ok, i set up cygwin on my netbook to try and figure it out |
| 19:07:58 | amiconn | Umm, on a netbook it will probably take *very* long (assuming netbook == atom) |
| 19:08:33 | n1s | yes |
| 19:08:34 | pixelma | Buschel: VLC stats tell me that there are also "lost buffers" (? losely translated back from its German UI) right at the start. I don't know what that means though |
| 19:08:47 | pixelma | I'll try something else |
| 19:09:17 | n1s | TheSeven: in fact 4 bytes differ |
| 19:09:17 | pixelma | in the audio part |
| 19:09:54 | n1s | but that means the swap is wrong for h300 at least |
| 19:09:56 | linuxstb | pixelma: Can you upload this somewhere? |
| 19:10:40 | TheSeven | is it normal that the pcm buffer never gets filled more than ~60%? |
| 19:11:12 | | Join feisar- [0] (jljhook@irkki.fi) |
| 19:11:28 | amiconn | TheSeven: There's an easy way to find out whether buffering is causing the slowdown: Start playback, then press pause immediately, and wait until the disk stops. Only unpause after that |
| 19:11:36 | Buschel | pixelma: what happens if you simply comment line 167 in libmad/frame.c ? |
| 19:12:24 | pixelma | linuxstb: I first wanted to try if my transcoding program does something weird - I also cut the file because it has parts I'm not intersted in at the beginning and the end. I'll try without the cutting |
| 19:12:45 | TheSeven | even when it's finished buffering CPU usage is way too high |
| 19:12:54 | TheSeven | it's fine in test_codec though |
| 19:13:52 | TheSeven | I have ATA DMA up and running now - it manages to read about twice as fast as it plays for FLAC now |
| 19:14:27 | pixelma | Buschel: layer 3 |
| 19:15:19 | TheSeven | MP3 still isn't realtime |
| 19:15:53 | Buschel | TheSeven: what is the DRAM / SRAM speed like? |
| 19:16:15 | | Quit feisar- (Ping timeout: 276 seconds) |
| 19:16:23 | TheSeven | no idea |
| 19:16:34 | | Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 19:16:42 | TheSeven | but the test_codec results seem to be sane |
| 19:16:44 | Buschel | can you check with test_mem? |
| 19:16:49 | TheSeven | http://pastie.org/1423556 |
| 19:17:19 | TheSeven | all >100MB/s |
| 19:17:23 | Buschel | looks good. are the decoding times correct? |
| 19:17:27 | | Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) |
| 19:17:41 | TheSeven | they should be, at least roughly |
| 19:17:43 | Buschel | "all >100 MB/s" is too high imho |
| 19:17:50 | n1s | amiconn: my build failed with some libiconv error |
| 19:17:58 | | Join WonTu [0] (~WonTu@p57B572F3.dip.t-dialin.net) |
| 19:18:04 | TheSeven | the tick might be off by a few percent, but not terribly much |
| 19:18:12 | | Part WonTu |
| 19:18:30 | Buschel | if so, the memory bandwidth would be surprisingly high |
| 19:18:38 | amiconn | n1s: Btw, the binutils build errored while building gprof |
| 19:19:22 | amiconn | gprof has a separate config.log, but I can't find anything interesting in there either |
| 19:19:27 | TheSeven | DRAM cnt: 2048 size: 64MB, read: 104.9MB/s (610ms), write: 220.6MB/s (290ms), memset: 220.6MB/s (290ms), memcpy: 133.3MB/s (480ms) |
| 19:20:17 | TheSeven | IRAM cnt: 2048 size: 64MB, read: 128.0MB/s (500ms), write: 182.8MB/s (350ms), memset: 182.8MB/s (350ms), memcpy: 152.3MB/s (420ms) |
| 19:20:59 | TheSeven | 108 iterations so far |
| 19:21:17 | pixelma | linuxstb: a file produced without the cuts works |
| 19:22:10 | TheSeven | ~2.2 seconds per iteration, so the msec values seem to be sane |
| 19:22:15 | Buschel | these numbers are quite high. I like to see the IRAM speed reaching the speed of the PP5022. |
| 19:22:47 | * | TheSeven wonders how to leave this plugin |
| 19:22:56 | Buschel | skip left |
| 19:23:08 | TheSeven | doesn't do anything |
| 19:23:18 | Buschel | wait a while |
| 19:23:38 | Buschel | otherwise press Menu + Select for while ;) |
| 19:23:40 | TheSeven | no reaction even after several iterations |
| 19:23:44 | | Join feisar- [0] (jljhook@irkki.fi) |
| 19:23:45 | TheSeven | hm, that's what i'm about to do |
| 19:24:46 | * | amiconn retries the build, in order to exclude random failure |
| 19:25:11 | n1s | amiconn: i'm rerunning my build too |
| 19:25:52 | TheSeven | any other ideas what might be causing playback to eat cpu like shit? |
| 19:26:08 | Buschel | dsp stuff |
| 19:26:21 | * | TheSeven doesn't think there is dsp stuff enabled |
| 19:26:26 | Buschel | did you try to run test_codec including dsp |
| 19:26:28 | Buschel | ? |
| 19:26:31 | TheSeven | the PCM driver should only cause one IRQ per ~9000 samples, if the chunks passed by the pcm buffer are that big |
| 19:26:42 | n1s | TheSeven: does the port define CPU_ARM and ARM_ARCH? |
| 19:26:48 | Buschel | it is copying all pcm data from a to b |
| 19:27:22 | TheSeven | n1s: i'd think so, as the test_codec results seem to be reasonable |
| 19:27:50 | n1s | right |
| 19:28:11 | TheSeven | test_codec with DSP is also several hundred percents realtime, even for MP3 |
| 19:28:17 | Buschel | ok |
| 19:28:19 | | Quit feisar- (Ping timeout: 264 seconds) |
| 19:28:26 | TheSeven | 430.70% to be exact |
| 19:28:33 | TheSeven | 44.5MHz |
| 19:29:18 | TheSeven | (320kbit/s) |
| 19:29:32 | | Join feisar- [0] (jljhook@irkki.fi) |
| 19:29:43 | TheSeven | flac: 1032.30%, 18.56MHz |
| 19:30:16 | * | TheSeven tries test_disk again |
| 19:30:57 | TheSeven | still only 16KB/s for 512 byte writes |
| 19:31:12 | TheSeven | 512 byte reads are at ~1.5MB/s |
| 19:32:09 | TheSeven | writes are about twice as fast as reads for bigger chunk sizes, weird... hm, write caching... |
| 19:32:30 | TheSeven | anyway, this shouldn't be the bottleneck any more |
| 19:32:47 | TheSeven | reads are ~1.6MB/s independent of the size |
| 19:33:17 | TheSeven | that's way slower than i'd expect, but should still be sufficient for playback |
| 19:33:33 | | Quit feisar- (Ping timeout: 240 seconds) |
| 19:33:41 | TheSeven | so this could be: |
| 19:33:55 | TheSeven | - some kind of fight between threads |
| 19:34:02 | TheSeven | - some buffering/playback issue |
| 19:34:05 | TheSeven | - the pcm driver |
| 19:34:17 | TheSeven | any other ideas what could be the culprit that doesn't influence test_codec? |
| 19:34:58 | linuxstb | pixelma: My guess is that the mp3 frames are cut, meaning the audio stream doesn't start on a frame boundary. That may or may not be legal, but I would expect vlc to be a lot more tolerant of such things than mpegplayer. |
| 19:35:04 | TheSeven | is PCM-WAV significantly faster than FLAC? |
| 19:35:09 | TheSeven | if yes I might try that |
| 19:35:32 | n1s | TheSeven: it should be |
| 19:36:03 | n1s | straight 16 bit 44.1kHz pcm needs basically no processing at all |
| 19:36:25 | TheSeven | *if* it does no processing at all |
| 19:36:36 | pixelma | linuxstb: sounds likely. I wonder if mpegplayer should also tolerate this or not. Of course you can't take care of every corner case, I just pity that it looks like I'll have to transcode the audio |
| 19:37:07 | pixelma | maybe there are better transcoders though which can handle this correctly |
| 19:37:46 | pixelma | and cut on frame borders |
| 19:38:14 | TheSeven | 2.38MHz, 8039.57% realtime |
| 19:40:03 | TheSeven | and guess what? it's stuttering! |
| 19:40:39 | TheSeven | so the two "extremes" wav and mp3 are stuttering, while flac works. what the hell? |
| 19:41:07 | TheSeven | the UI is barely responsive while playing the WAV file |
| 19:41:19 | | Join feisar- [0] (jljhook@irkki.fi) |
| 19:42:59 | linuxstb | pixelma: Do you have access to mplayer? You can use that to dump the audio stream (mplayer -dumpaudio -dumpfile audio.mp3 file.mpg) |
| 19:45:00 | TheSeven | wav even stutters after buffering completed |
| 19:45:07 | TheSeven | apparently every time the wps updates |
| 19:45:42 | Buschel | the screen update? |
| 19:45:48 | TheSeven | maybe |
| 19:46:01 | TheSeven | and if buffering hasn't completed, it just reads one little chunk from the disk once a second, judging from the disk's noise |
| 19:46:05 | Buschel | how much fps do you get via test_fps? |
| 19:46:06 | n1s | TheSeven: does the lcd update disable interrupts for too long or something |
| 19:46:13 | TheSeven | it shouldn't |
| 19:46:57 | Buschel | what happens if you play a file while being in the main menu? |
| 19:47:10 | n1s | amiconn: my binutils build now completed... the error i got before went away when i installed libiconv but it looked different from your error |
| 19:47:29 | TheSeven | test_fps data aborts at yuv |
| 19:47:42 | TheSeven | rgb is 25 full / 100 quarter |
| 19:49:02 | amiconn | 25fps is awfully slow |
| 19:49:33 | Buschel | afaik wps did 5 fps (full screen). so, this would equal 20% of the cpu time during playback. if the 5-fps-full-screen assumption is still valid |
| 19:49:36 | TheSeven | this is still non-optimized C code, and the LCD is rather big (320x240x16bits) |
| 19:50:26 | | Quit kugel (Remote host closed the connection) |
| 19:50:56 | TheSeven | judging from the stuttering and lcd contents it's just doing a single frame per second (cabbiev2) |
| 19:51:25 | TheSeven | and the stuttering doesn't change if i go to the main menu |
| 19:52:14 | Buschel | then the screen update are not the problem. main menu is not drawn cyclic |
| 19:54:53 | n1s | hmm, the gmp/mpfr kluge in rockboxdev.sh needs to be updated for 4.5 as it needs mpc too |
| 19:54:56 | TheSeven | and if flac plays fine, i can't see any reason why wav shoudln't, if it's not buffering |
| 19:55:23 | amiconn | n1s: binutils build worked here too. weird. |
| 19:56:18 | * | TheSeven is running out of ideas |
| 19:58:10 | | Join GeekShad0w [0] (~Antoine@93.21.168.55) |
| 20:00 |
| 20:00:15 | Buschel | [Saint]: you there? |
| 20:00:39 | | Quit GeekShadow (Ping timeout: 272 seconds) |
| 20:02:28 | | Join GeekSh4dow [0] (~Antoine@93.21.167.104) |
| 20:03:49 | | Quit GeekShad0w (Ping timeout: 240 seconds) |
| 20:06:00 | TheSeven | hm, our bigendian targets are all the archos, iriver, iaudio, mpio and meizu players, and additionally the yp-s3? |
| 20:06:05 | TheSeven | which of those have ata? |
| 20:06:20 | TheSeven | ata_swap_words targets seem to be only archos and mpio |
| 20:07:36 | TheSeven | n1s: does that mean that that your iriver is one of those identify-swap-needed targets (bigendian but not ata_swap_words) |
| 20:09:36 | n1s | i think so, yes |
| 20:10:09 | TheSeven | that's a bit confusing... |
| 20:11:56 | TheSeven | so on iriver, the read is already swapping, and that's sufficient |
| 20:13:08 | TheSeven | on mpio the read normally isn't swapped, but ata_swap_words is defined |
| 20:13:23 | TheSeven | so the identify info won't be swapped at all |
| 20:13:35 | TheSeven | so removing the additional swap would handle that as well |
| 20:14:16 | TheSeven | the same holds true for archos |
| 20:14:35 | TheSeven | meizu doesn't have ata-based players afaik, and the yp-s3 is flash-based as well |
| 20:15:04 | TheSeven | iaudio seems to work like iriver |
| 20:16:20 | TheSeven | none of the littleendian targets have ata_swap_words, so they never swap anything |
| 20:16:34 | TheSeven | sounds like that swap16 should be removed, as the ipod classic is the only one needing it |
| 20:17:00 | TheSeven | so the ipod classic is actually a littleendian ata_swap_words target? |
| 20:17:11 | | Quit jfc^2 (Read error: No route to host) |
| 20:17:35 | | Join jfc^2 [0] (~john@dpc6682208002.direcpc.com) |
| 20:18:50 | TheSeven | ata_swap_words doesn't seem to affect data transfers on bigendian platforms |
| 20:20:00 | TheSeven | so the data endian swap actually happens for all bigendian targets |
| 20:20:32 | TheSeven | which means my patch is broken on mpio and archos |
| 20:21:51 | amiconn | little endian targets should never need ata swap because ata is also little endian |
| 20:22:12 | amiconn | Big endian targets do need it, unless there's some hardware swap mechanism |
| 20:22:42 | TheSeven | it seems like there is a little endian target with a hardware swap mechanism :/ |
| 20:23:09 | amiconn | That's weird |
| 20:23:15 | TheSeven | the identify words i'm getting on the ipod classic are big endian |
| 20:24:05 | pixelma | linuxstb: I made something which I think is the audio dump with the transcoder I use but I'm not sure if it really leaves the stream "in peace" |
| 20:24:11 | *** | Saving seen data "./dancer.seen" |
| 20:26:58 | | Quit GuySoft (Ping timeout: 248 seconds) |
| 20:27:16 | | Quit bmbl (Quit: Verlassend) |
| 20:29:31 | TheSeven | amiconn: any idea why the data endianness is swapped on all bigendian targets, but the identify endianness only on iriver and iaudio? |
| 20:29:36 | TheSeven | or am i misunderstanding something? |
| 20:30:07 | TheSeven | are some OFs writing data with wrong endianness, and we want to be compatible with that? |
| 20:30:41 | TheSeven | not that it would make any sense... |
| 20:32:57 | | Quit stoffel (Ping timeout: 276 seconds) |
| 20:38:35 | linuxstb | pixelma: I don't know if it's your transcoder, but that audio stream has an ID3 tag at the start. That would confuse mpegplayer... |
| 20:39:03 | pixelma | I wondered why there even is one in the file |
| 20:39:29 | pixelma | found it too when playing the dumped mp3 in foobar |
| 20:40:44 | pixelma | are you sure it's a tag? I wonder why an uncut file would play if the transcoder would add it always |
| 20:40:51 | | Quit Buschel (Ping timeout: 240 seconds) |
| 20:42:51 | linuxstb | pixelma: Yes, looking at it in a hex editor shows it begins with the string "ID3" |
| 20:44:00 | TheSeven | amiconn: if your statement above is correct, this comment would be very confusing: |
| 20:44:01 | TheSeven | this info differently that normal sector data */ |
| 20:44:09 | TheSeven | /* the IDENTIFY words are already swapped, so we need to treat |
| 20:44:09 | TheSeven | this info differently that normal sector data */ |
| 20:44:23 | | Quit GeekSh4dow (Quit: The cake is a lie !) |
| 20:44:43 | n1s | hmm, the mpc lib isn't available from the same mirrors we get gmp and mpfr |
| 20:44:51 | pixelma | TheSeven: its grammar is confusing anyway ;) |
| 20:45:29 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 20:46:55 | TheSeven | oh, this is getting even more confusing: |
| 20:47:09 | TheSeven | what about the strings in the identify info? which byte order do those have? |
| 20:47:45 | TheSeven | if i swap the byte order, the strings look right in the hexedit |
| 20:48:09 | TheSeven | what does this mean for the endianness of the rest? |
| 20:54:57 | TheSeven | also, if I undestand page 114 of ATA8-ACS right, ata isn't hardwired to 512 bytes per sector |
| 20:56:50 | TheSeven | or rather pages 23, 113 and 114 |
| 20:57:26 | GodEater | hahaha |
| 20:57:30 | GodEater | this sounds like where I came into Rockbox |
| 21:00 |
| 21:01:07 | | Join Buschel [0] (~chatzilla@p54A3B3F6.dip.t-dialin.net) |
| 21:09:25 | | Part y4n |
| 21:10:20 | | Quit balintx (Remote host closed the connection) |
| 21:13:24 | | Quit factor (Quit: Leaving) |
| 21:14:18 | | Join factor [0] (~factor@75.108.68.114) |
| 21:14:22 | | Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) |
| 21:17:23 | | Quit factor (Read error: Connection reset by peer) |
| 21:17:38 | | Join factor [0] (~factor@75.108.68.114) |
| 21:22:10 | Thopter | I'm new to Rockbox, having installed it via the Rockbox Utility on my Clip+ 8GB earlier today. I found a language quiz patch that I would like to install, but I'm not sure how to go about doing that. All the info I've read about adding patches talks about using diff files, but this patch is provided as a .c file. Can someone point me to some instructions somewhere that could get me through? |
| 21:28:54 | Buschel | Thopter: can you compile rockbox? |
| 21:29:31 | Thopter | Buschel: with a decent set of instructions to get me started, sure |
| 21:30:14 | Buschel | Thopter: then you should first walk through this http://www.rockbox.org/wiki/HowToCompile |
| 21:32:54 | Thopter | Buschel: Ok, that looks straightforward enough. What do I do with this .c patch file? |
| 21:33:24 | Buschel | is this a patch or a new plugin? |
| 21:33:32 | Thopter | it's a plugin |
| 21:34:35 | | Join simonrvn_ [0] (simon@197.159-ppp.3menatwork.com) |
| 21:34:37 | Buschel | is it in the tracker somewhere (I am talking of flyspray)? |
| 21:35:07 | Thopter | flyspray 2896 |
| 21:35:47 | [Saint] | anyone tried building convttf lately? I have a binary already compiled...so I can still use aliased fonts, but trying to build convttf fails quite dramatically. |
| 21:36:48 | Buschel | Thopter: it's a diff file. this patch does not apply anymore? |
| 21:37:08 | Thopter | I downloaded the .zip file, inside was a .c |
| 21:37:21 | Buschel | Thopter: check the diff file below |
| 21:37:32 | | Quit simonrvn (Ping timeout: 240 seconds) |
| 21:37:32 | | Nick simonrvn_ is now known as simonrvn (simon@197.159-ppp.3menatwork.com) |
| 21:38:16 | [Saint] | Buschel: Sorry about last night, I had a really bad headache and went to bed. Building with latest LCD patch now. |
| 21:38:46 | Buschel | [Saint]: no prob, I hope your feeling ok now :) |
| 21:38:56 | Buschel | you're |
| 21:39:06 | Thopter | Buschel: ah, I see. The fellow's instructions aren't very clear to me though. |
| 21:40:14 | Buschel | Thopter: what is not clear? |
| 21:41:08 | Thopter | given that reaction, something that should be clear. guess I'll go read some more |
| 21:42:40 | Buschel | Thopter: you should set up and development environment and downlad the source. then compile without any patch and see whether this is working. if so, you may apply the patch (as described in flyspray) and rebuild. |
| 21:43:25 | Thopter | ... yeah, I need to read up some more on this. Thanks for the assistance |
| 21:43:27 | Ogham | Can anyone throw any light on bug FS #11812 ? Does this have the potential to damage low impedance IEM's? |
| 21:43:48 | Buschel | Thopter: you're welcome |
| 21:44:44 | TheSeven | Ogham: i doubt that it will destroy them thermally |
| 21:44:55 | Thopter | any chance this plugin (2896) might make it into the program someday? |
| 21:45:14 | TheSeven | loud noise should be worse for them |
| 21:45:21 | * | TheSeven killed a pair that way recently |
| 21:46:20 | [Saint] | it could, potentially tear the speaker cone if the sample it paused on was incredibly loud, and the volume was very high. |
| 21:46:51 | Buschel | Thopter: I don't think so. It is in flyspray since ages without being included to official builds. |
| 21:46:52 | * | TheSeven doubts it will tear it more than playing back that sample without pausing |
| 21:47:33 | TheSeven | btw. i'm sure other targets have the same problem |
| 21:47:34 | Thopter | so I'll have to do this for every update. Oh well, first time is always the hardest |
| 21:47:57 | [Saint] | Thopter: I'd be quite surprised if it applies cleanly. |
| 21:48:01 | [Saint] | Or, at all. |
| 21:48:13 | Thopter | because it's old? |
| 21:48:14 | [Saint] | it is ~4 years old. |
| 21:48:25 | Ogham | Owch, apparently the clip+ has been measured putting out 240mV whilst paused, do you think that would be enough to damage 16 Ohm Impedance IEM's? |
| 21:48:56 | Buschel | [Saint], Thopter: one step after the other. imho the patch itself is quite simple. so, it should be easily adaptable to the current code |
| 21:49:33 | [Saint] | Oh yes, it's certainly able to be applied. |
| 21:49:37 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 21:49:55 | [Saint] | It just depends on the level of effort one is prepared to go to to get it to do so. |
| 21:50:03 | [Saint] | And the knowledge of the person doing so. |
| 21:50:11 | TheSeven | Ogham: that would be ~4 milliwatts of power |
| 21:51:48 | n1s | Thopter, [Saint]: a plugin that old will not build due to the plugin header changes |
| 21:52:17 | n1s | easily fixed though, just delete the old header macro in the plugin .c file |
| 21:53:09 | Ogham | TheSeven: I'm not too hot on my basic physics! But that doesn't seem like much power.. do you think it would cause issues if it was constant for a long duration? |
| 21:53:45 | [Saint] | check the specs of your IEMs |
| 21:53:52 | TheSeven | i think the only impact a long duration can have is heat. and 4 milliwatts of heat shouldn't be an issue. |
| 21:54:51 | TheSeven | it might be possible that that voltage is sufficient to bend the membrane excessively, but it won't make a difference if that's applied for a second or an hour in that case |
| 21:58:29 | | Quit feisar- (Ping timeout: 240 seconds) |
| 21:59:36 | Ogham | TheSeven: Ah, ok.. and if 240mV applied during playback does not cause an issue, then I am I correct in assuming that it shouldn't cause an issue if applied constantly whilst the device is paused? |
| 21:59:57 | TheSeven | i didn't say that |
| 22:00 |
| 22:00:27 | soap | Buschel, what do you want tested? [Saint] you testing too? |
| 22:00:28 | TheSeven | if alternating voltages follow each other in rapid succession, the membrane won't be bent as far as when a constant voltage is applied |
| 22:00:54 | [Saint] | soap: Yessir, building now. |
| 22:01:13 | TheSeven | so 1/50th second vs. 1 second makes a difference, while 1 second vs. 1 hour probably won't |
| 22:01:29 | TheSeven | personally i'd expect them to survive that though |
| 22:01:42 | Ogham | Ah, that makes sense.. |
| 22:02:18 | Ogham | If they were to be damaged in the manner what is the likely outcome? An instantly recognisable difference in sound quality, or a slow degredation? |
| 22:02:21 | Buschel | [Saint], soap: if the latest patch works for you both I will submit. afterwards I have some further changes to verify ;) |
| 22:03:20 | * | [Saint] isn't sure if this discussion is still on topic or not. |
| 22:05:06 | soap | define "latest". That's really the question I was getting at. Are you going to commit the last one I tested, and want to verify the changes in the most recent FS patch, or is the most recent FS patch the one you want to commit and thus needs my testing? |
| 22:05:33 | gevaerts | TheSeven: I'm assuming you use SECTOR_SIZE=512? |
| 22:05:40 | TheSeven | yes |
| 22:05:45 | gevaerts | And you have MAX_LOG_SECTOR_SIZE defined to something |
| 22:06:24 | Buschel | soap: v17 (=latest) needs to be tested by Saint. as this (hopefully) fixes some issues he had on his iPod color |
| 22:06:24 | TheSeven | #define MAX_LOG_SECTOR_SIZE 4096 |
| 22:06:24 | TheSeven | #define MAX_PHYS_SECTOR_SIZE 4096 |
| 22:06:35 | gevaerts | ok |
| 22:07:25 | Buschel | soap: afterwards I will make further changes I would like to have tested by you both |
| 22:07:52 | gevaerts | The problem is that usb_storage use disk_sector_multiplier, which is detected by disk.c based on which "actual" sector sizes it manages to mount partitions with |
| 22:08:15 | gevaerts | For superfloppy mode it never sets it |
| 22:08:30 | TheSeven | aha, sounds like that should be fixed :) |
| 22:08:49 | soap | so, not to beat a dead horse Buschel, to be perfectly clear v17 does not need testing by soap. |
| 22:08:57 | gevaerts | Presumably disk_mount() could set disk_sector_multiplier for superfloppy mode based on the fat bpb_bytspersec field |
| 22:09:11 | Ogham | Yup sorry to be off-topic! I'll shut-up now, I'm just really worried about damaging my hardware due to this bug! |
| 22:09:11 | | Quit Thopter (Quit: Sayonara) |
| 22:09:48 | Buschel | soap: yes, v17 does not to be tested by you. |
| 22:10:17 | Ogham | So last question.. if this bug was going to cause damage to my IEM's would it be instantly recognisable or a slow degredation? |
| 22:10:30 | * | Ogham promises not to ask any more questions! :) |
| 22:10:41 | [Saint] | Well, at the end of the day the no warranty/guarantee is pretty specific. |
| 22:10:54 | [Saint] | And, that question is almost impossible to answer. |
| 22:10:56 | * | TheSeven thinks nobody knows a definitive answer to that, besides the manufacturer maybe |
| 22:11:26 | soap | Ogham, IF IF it were to cause damage it would likely be through voicecoil overheating and eventual fuzing. |
| 22:11:40 | soap | IF IF IF IF |
| 22:11:44 | TheSeven | gevaerts: so the fat code relies on bpb_bytspersec anyway? |
| 22:12:03 | Buschel | [Saint]: still compiling? |
| 22:12:06 | gevaerts | I guess so |
| 22:12:19 | TheSeven | soap: voicecoil overheating won't happen at that wattage, i would be more concerned about mechanical membrane damage |
| 22:12:37 | [Saint] | Yes, sorry. I needed to clean my build dir so it's taking longer than normal. |
| 22:12:42 | [Saint] | Buschel: ^ |
| 22:12:55 | soap | that voltage is too low as a percentage of "expected" to see much distention, no? |
| 22:13:00 | | Quit factor (Ping timeout: 246 seconds) |
| 22:13:55 | soap | I mean, if a 10v rail to rail headphone amp won't bend the membrane too much why would 1/4v? |
| 22:16:15 | TheSeven | a 10v rail to rail headphone amp? i doubt one will use such a thing at 16 ohms impedance |
| 22:16:48 | | Quit saratoga (Quit: Page closed) |
| 22:17:05 | TheSeven | i'm pretty sure that one *can* damage 16ohms inears at 1V |
| 22:17:59 | TheSeven | 10V at 16 ohms would be 6 watts. that will certainly kill the voice coil. |
| 22:18:24 | | Join AlexP_mob [0] (~ap@rockbox/staff/AlexP) |
| 22:19:54 | gevaerts | TheSeven: http://pastebin.com/SKp6KYVb (compiles, but untested apart from that) |
| 22:20:25 | * | TheSeven will throw that into his tree :) |
| 22:23:44 | gevaerts | TheSeven: actually, it might be interesting to see what the OF does with a plain standard 512 byte sector drive |
| 22:24:08 | gevaerts | If it also treats that as 4K, it might be better to use a fixed value |
| 22:24:12 | *** | Saving seen data "./dancer.seen" |
| 22:24:20 | Ogham | Thanks very much for your time all, one last thing then.. taking the no guarantee/warranty as a given - would you all be happy to continue usingexpensive IEM''s with rockbox in this situation? |
| 22:24:54 | [Saint] | I use a pair of Sennheiser IE8s |
| 22:25:00 | * | gevaerts considers using expensive IEMs to be proof of insanity, so he wouldn't use them, including in this situation |
| 22:25:09 | [Saint] | ;) |
| 22:25:34 | Ogham | True.. I wish I had bought cheaper ones I would not be so concerned about now! |
| 22:25:35 | TheSeven | gevaerts: i seriously doubt we can set sector_size to 4k without major ata rework |
| 22:25:53 | gevaerts | TheSeven: not sector_size, no, but hardcode disk_sector_multiplier |
| 22:26:04 | Ogham | [Saint]: Do you use them on a Clip+ with this firmware bug? |
| 22:26:19 | TheSeven | hardcoding that won't buy us much |
| 22:26:38 | TheSeven | (except from rejecting partitioning that the OF wouldn't like) |
| 22:26:44 | gevaerts | The way things work now is that we actually have to trust data on the disk (partition table, FAT bootsector,...) to tell us how to interpret that same data |
| 22:27:07 | [Saint] | No, but at the end of the day I think you're being a little bit over cautious. A meteorite could plummet to earth and smash your IEMs, things break. |
| 22:27:23 | AlexP_mob | That is a bit silly |
| 22:27:47 | [Saint] | That was kind of the point. |
| 22:27:48 | AlexP_mob | You can't avoid that, you can this |
| 22:27:55 | gevaerts | Ogham: have you considered contacting the manufacturer of your IEMs? They're much more likely to know |
| 22:28:07 | gevaerts | We can really only guess |
| 22:28:28 | AlexP_mob | Saint no, I meant your point was silly |
| 22:28:49 | [Saint] | I realise that. |
| 22:28:53 | gevaerts | If the things are really expensive, I'd assume they do have a support service that can be reached :) |
| 22:29:33 | Ogham | gevaerts: I think I better had.. that or switch back to OF and hope that I have not already caused considerable damage! |
| 22:29:40 | TheSeven | Ogham: you could just put a decoupling capacitor in between) |
| 22:29:45 | gevaerts | Are you sure the OF doesn't do this? |
| 22:30:01 | Ogham | gevaerts: definately, its a rockbox issue |
| 22:30:16 | gevaerts | Sure, but that's not what I asked |
| 22:30:25 | Ogham | TheSeven: I guess I could try that.. again I am a little restricted by my lack of technical knowhow! |
| 22:30:48 | gevaerts | The fact that rockbox has a bug does not prove anything about the OF |
| 22:31:05 | [Saint] | The forum suggests it's rather hit and miss, and dependant on the IEMs. |
| 22:31:16 | [Saint] | As I understand it, not all are experiencing this. |
| 22:31:31 | Ogham | gevaerts: Well, the mV was measured as 0 when the player was paused and using OF |
| 22:31:37 | gevaerts | ok |
| 22:31:45 | gevaerts | Tested multiple times, I presume |
| 22:32:24 | gevaerts | I mean, with this sort of bug, the value you get is more or less unpredictable and will be zero every now and then |
| 22:32:30 | Ogham | gevaerts: Yes, people suggested possible problems with the tests such as no load, and the tests were repeated |
| 22:33:41 | [Saint] | Buschel: success...stand by for FPS results. |
| 22:33:50 | Buschel | \o/ |
| 22:35:00 | Ogham | [Saint]: well, the voltage is always there on a meter, but different IEM's vary in if they hear a squeak when the player is paused/resumed |
| 22:37:10 | [Saint] | LCD 1/1: 19.4, 1/4: 77.1 LCD YUV 1/1: 17.4, 1/4: 70.0 @30MHz ; LCD 1/1: 51.7, 1/4: 206.0 LCD YUV 1/1: 46.7, 1/4: 187.0 @80MHz |
| 22:37:14 | [Saint] | Buschel: ^ |
| 22:38:54 | amiconn | TheSeven: A, that's a detail I forgot. For some reason identify data is big endian, unlike normal ata data |
| 22:39:00 | Ogham | Well, I think I better switch back to the OF for the time being.. I'm not convinced that my IEM's are safe, I just hope they are not already damaged too much! |
| 22:39:11 | Ogham | Thanks again all, sorry to get off-topic here! |
| 22:39:25 | TheSeven | amiconn: ah? i had the opposite impression when looking at the code |
| 22:40:16 | amiconn | So if you want the 16 bit ints to be little endian, you need to byte-swap - but then strings are in the wrong order |
| 22:40:50 | amiconn | Actually, that's probably the reason why it's big endian |
| 22:41:21 | * | TheSeven is completely confused now |
| 22:42:18 | [Saint] | Buschel: Where is the patch for the LCD shotdown artefacts I'm getting on iPod Colour? It's not on the tracker. |
| 22:43:05 | TheSeven | amiconn: apparently, on little-endian targets, identify and data is handled the same way, while on big endian targets they're handled differently |
| 22:43:19 | CIA-7 | New commit by Buschel (r28944): Submit FS #11843 v17. Integrate YUV-blitting of nano 2G to nano1G/color LCD driver. Additionally refactor RGB and YUV screen updates to use same code ... |
| 22:43:38 | [Saint] | oh...found it. |
| 22:43:52 | [Saint] | Oh, wait...nope :/ |
| 22:43:55 | | Join GuySoft [0] (guy@bzq-79-179-40-185.red.bezeqint.net) |
| 22:44:25 | [Saint] | Buschel: Do you have the wait you added to LCD in a patch form? |
| 22:45:57 | [Saint] | aha, found it in the logs...sorry Buschel. |
| 22:46:02 | [Saint] | I'll test that now. |
| 22:47:50 | | Quit Judas_PhD (Ping timeout: 240 seconds) |
| 22:55:20 | | Join feisar- [0] (jljhook@irkki.fi) |
| 22:58:42 | Buschel | soap, [Saint]: can you now check this patch? -> http://pastie.org/1424222 |
| 22:58:48 | Buschel | (I call it v18) |
| 22:59:28 | [Saint] | what does this one do? |
| 23:00 |
| 23:00:10 | Buschel | it removes some (from my understanding unneeded) special handling |
| 23:00:14 | Buschel | in the LCD driver |
| 23:00:30 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 23:01:01 | soap | patch against current svn? |
| 23:01:12 | soap | duh, yes |
| 23:02:48 | | Quit feisar- (Ping timeout: 265 seconds) |
| 23:03:02 | | Join feisar- [0] (jljhook@irkki.fi) |
| 23:03:42 | | Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) |
| 23:04:20 | | Quit Keripo (Ping timeout: 264 seconds) |
| 23:09:25 | [Saint] | Buschel: The screen artefact patch doesn't work. |
| 23:09:47 | [Saint] | It just displays a full white screen before the horrible vertical lines now :/ |
| 23:09:48 | Buschel | ok, was a quick shot.. |
| 23:09:50 | [Saint] | Sorry. |
| 23:10:14 | [Saint] | It disturbs me how long the artefacts last for. |
| 23:10:20 | | Quit bertrik (Ping timeout: 255 seconds) |
| 23:10:36 | [Saint] | I would swear that it wasn't being powered down properly, as sometimes they can last on screen for over 5 minutes. |
| 23:13:54 | * | [Saint] has nice boot-splash and USB icons for his iPod Colours now. |
| 23:15:44 | * | TheSeven thinks he's caught all the corner cases of that ATA patch now |
| 23:16:05 | TheSeven | does anyone want to (re-)test it before i commit it? |
| 23:16:32 | n1s | sure |
| 23:19:51 | TheSeven | n1s: http://pastie.org/1424257 |
| 23:20:47 | soap | Buschel, no speed changes no regression in quality on Nano 1G. |
| 23:21:18 | Buschel | soap: good. let's hope Saint will report the same. |
| 23:22:12 | [Saint] | It will be a while before I can test this latest increment, but...fingers crossed, yes. |
| 23:22:16 | Buschel | soap: btw, could you update the LcdFrameRate wiki or give me the detailed numbers for all measurements (YUV/RGB/boosted/unboosted)? |
| 23:22:26 | soap | on it |
| 23:22:40 | Buschel | [Saint]: shall I upload a binary for you? |
| 23:22:51 | [Saint] | Buschel: I will do the same for the Colour when I've finished the test. |
| 23:23:29 | [Saint] | Buschel: It's building now, it's just a timing thing. I have to run out the door for about an hour shortly. |
| 23:23:40 | Buschel | ok |
| 23:24:26 | | Quit TheSeven () |
| 23:24:32 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 23:24:37 | amiconn | TheSeven: This isn't easy to understand. Afaiu the different handling of identify and plain data on big endia is because we want plain data in original order, but identify data in target endianess |
| 23:26:05 | amiconn | So on little endian no swap is required for both, while on big endian targets with hardware swap support we need to swap identify but not data, and on big endian without hardware swap support we need to swap data but not identify |
| 23:26:37 | TheSeven | yeah, i think i got it |
| 23:27:20 | TheSeven | and the ipod classic is different again: the data register is swapped, but not the control registers |
| 23:27:24 | TheSeven | don't ask me why |
| 23:27:26 | amiconn | Actually hardware swap support just means ata buffer lines 0..7 are connected to lines 8..15 of the data bus and vice versa |
| 23:28:35 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 23:28:38 | CIA-7 | New commit by theseven (r28945): Fix an ugly-looking comment |
| 23:28:38 | CIA-7 | r28945 build result: All green |
| 23:28:54 | TheSeven | now that was a fast build :) |
| 23:29:45 | CIA-7 | New commit by theseven (r28946): Autodetect sector size on superfloppy volumes based on the FAT32 BPB (kudos to Frank Gevaerts) |
| 23:29:51 | amiconn | That's the reason why the check_registers patterns are defined differently for the coldfire irivers |
| 23:30:06 | TheSeven | hm, no, on coldfire everything is swapped |
| 23:30:09 | TheSeven | not just the data register |
| 23:30:11 | Buschel | soap: the RGB fps was not affected at all? |
| 23:30:31 | amiconn | Maybe the classic runs in big endian arm mode (is that possible on the SoC?)? |
| 23:30:43 | soap | Buschel, hasn't been affected for quite a while. |
| 23:30:49 | soap | I'll double check. |
| 23:30:53 | soap | sheesh! ;) |
| 23:31:02 | TheSeven | nope, it's the ata core that's crazy |
| 23:31:18 | TheSeven | everything else doesn't do that kind of bullshit |
| 23:31:21 | Buschel | soap: Saint reported slight speedup for 1/4 screen RGB |
| 23:31:39 | TheSeven | apple seems to have worked around it by swapping things in software as well |
| 23:31:57 | | Join Rob2222 [0] (~Miranda@p4FFF3774.dip.t-dialin.net) |
| 23:32:01 | CIA-7 | r28946 build result: All green |
| 23:32:25 | soap | Buschel, yea, but all the numbers make more sense if we discount [Saint]'s findings! ;) |
| 23:32:29 | TheSeven | n1s: did you try the patch? |
| 23:32:59 | n1s | TheSeven: sorry, got stuck in a test disk run, didn't think it took this long |
| 23:33:13 | TheSeven | with or without the patch? |
| 23:33:21 | n1s | without |
| 23:33:25 | TheSeven | damn :/ |
| 23:33:35 | n1s | paperclipped it now |
| 23:33:46 | Buschel | soap: yes, true ;) |
| 23:33:49 | | Quit benedikt93 (Quit: Bye ;)) |
| 23:33:54 | [Saint] | Buschel: And what's wrong with my findings? ;) |
| 23:34:05 | n1s | TheSeven: no problem, it's just that the write and veryfy takes forever |
| 23:34:57 | Buschel | [Saint]: nothing, I better have findings before a submit than after :) |
| 23:35:23 | | Join advcomp2019_ [0] (~advcomp20@97-114-234-88.sxcy.qwest.net) |
| 23:35:23 | | Quit advcomp2019_ (Changing host) |
| 23:35:23 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 23:35:54 | | Quit pamaury (Remote host closed the connection) |
| 23:36:16 | | Join DerPapst1 [0] (~Alexander@91-66-226-46-dynip.superkabel.de) |
| 23:39:01 | | Quit DerPapst (Ping timeout: 276 seconds) |
| 23:39:01 | | Quit advcomp2019 (Ping timeout: 276 seconds) |
| 23:39:30 | * | TheSeven wants to get that port pushed into SVN as he won't have much time next week |
| 23:39:40 | | Quit Bushmills (Ping timeout: 276 seconds) |
| 23:41:54 | CIA-7 | New commit by alle (r28947): Fix typo in the comment |
| 23:44:04 | CIA-7 | r28947 build result: All green |
| 23:44:04 | CIA-7 | New commit by alle (r28948): Don't load the keyboard layout '-.kbd' (partial fix for FS #11847) |
| 23:44:52 | | Quit Llorean (*.net *.split) |
| 23:44:53 | | Quit kadoban (*.net *.split) |
| 23:44:53 | | Quit mortalscan (*.net *.split) |
| 23:44:53 | | Quit efyx (*.net *.split) |
| 23:44:53 | | Quit domonoky (*.net *.split) |
| 23:44:53 | | Quit chattr (*.net *.split) |
| 23:44:53 | | Quit Xerion (*.net *.split) |
| 23:44:53 | | Quit B4gder (*.net *.split) |
| 23:44:53 | | Quit Farthen (*.net *.split) |
| 23:44:53 | | Quit niekie (*.net *.split) |
| 23:44:53 | | Quit tempname (*.net *.split) |
| 23:44:54 | | Quit Stummi (*.net *.split) |
| 23:44:54 | | Quit mc2739 (*.net *.split) |
| 23:44:54 | | Quit jordan` (*.net *.split) |
| 23:44:54 | | Quit linuxstb (*.net *.split) |
| 23:44:54 | | Quit n17ikh (*.net *.split) |
| 23:44:54 | | Quit dionoea (*.net *.split) |
| 23:44:58 | | Quit AlexP_mob (*.net *.split) |
| 23:44:58 | | Quit n1s (*.net *.split) |
| 23:44:58 | | Quit mikroflops_ (*.net *.split) |
| 23:44:59 | | Quit elcan (*.net *.split) |
| 23:44:59 | | Quit simabeis (*.net *.split) |
| 23:44:59 | | Quit soap (*.net *.split) |
| 23:44:59 | | Quit parafin (*.net *.split) |
| 23:44:59 | | Quit bug2000 (*.net *.split) |
| 23:46:02 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 23:46:03 | | Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 23:46:03 | | Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) |
| 23:46:03 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 23:46:03 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 23:46:03 | | Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) |
| 23:46:03 | | Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 23:46:03 | | Join B4gder [0] (~daniel@rockbox/developer/bagder) |
| 23:46:03 | | Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) |
| 23:46:03 | | Join niekie [0] (quasselcor@CAcert/Assurer/niekie) |
| 23:46:03 | | Join tempname [0] (generic@server1.unitedservers.de) |
| 23:46:03 | | Join Stummi [0] (Stummi@rockbox/developer/Stummi) |
| 23:46:03 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 23:46:03 | | Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) |
| 23:46:03 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 23:46:03 | | Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) |
| 23:46:03 | | Join dionoea [0] (~dionoea@videolan/developer/dionoea) |
| 23:46:16 | CIA-7 | r28948 build result: All green |
| 23:46:40 | | Join parafin [0] (parafin@paraf.in) |
| 23:46:40 | | Join bug2000 [0] (~bug@unaffiliated/bug2000) |
| 23:46:57 | | Join AlexP_mob [0] (~ap@rockbox/staff/AlexP) |
| 23:46:57 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 23:46:57 | | Join mikroflops_ [0] (~yogurt@h-34-71.A238.priv.bahnhof.se) |
| 23:46:57 | | Join elcan [0] (user36@pr0.us) |
| 23:46:57 | | Join simabeis [0] (~simabeis@lobmenschen.de) |
| 23:46:57 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 23:48:44 | CIA-7 | New commit by alle (r28949): Don't load the colours file if it's set to '' (partial fix for FS #11847) |
| 23:50:11 | CIA-7 | r28949 build result: All green |
| 23:50:38 | | Quit kadoban (Ping timeout: 240 seconds) |
| 23:51:07 | * | TheSeven eagerly awaits testing results |
| 23:51:34 | n1s | TheSeven: seems to work fine on my h300 |
| 23:51:36 | | Join Bushmills [0] (~Bushmills@scarydevilmonastery.net) |
| 23:51:42 | | Quit elcan (Ping timeout: 246 seconds) |
| 23:52:01 | CIA-7 | New commit by theseven (r28950): Rework ATA driver to get rid of lots of target-specific constants and allow for non-memory-mapped task file registers. |
| 23:53:14 | | Quit thegeek (Read error: Connection reset by peer) |
| 23:53:29 | | Join thegeek [0] (~nnscript@132.108.34.95.customer.cdi.no) |
| 23:54:00 | CIA-7 | r28950 build result: 20 errors, 8 warnings (theseven committed) |
| 23:54:06 | TheSeven | arrrrrrrrrrrrrrr |
| 23:54:34 | | Quit scorche (Disconnected by services) |
| 23:54:43 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 23:54:44 | | Join scorche` [0] (~scorche@rockbox/administrator/scorche) |
| 23:54:46 | | Quit timccc (*.net *.split) |
| 23:54:46 | | Quit Sajber^ (*.net *.split) |
| 23:54:46 | | Quit Q__ (*.net *.split) |
| 23:54:46 | | Quit rvvs89 (*.net *.split) |
| 23:54:46 | | Quit pikytcus (*.net *.split) |
| 23:54:46 | | Quit scorche|1h (*.net *.split) |
| 23:54:46 | | Quit fred_2 (*.net *.split) |
| 23:54:46 | | Quit knittl (*.net *.split) |
| 23:54:46 | | Quit Hadaka (*.net *.split) |
| 23:54:46 | | Quit zu_ (*.net *.split) |
| 23:54:46 | | Quit Utchy (*.net *.split) |
| 23:54:46 | | Quit AlexP_mob (*.net *.split) |
| 23:54:47 | | Quit n1s (*.net *.split) |
| 23:54:47 | | Quit mikroflops_ (*.net *.split) |
| 23:54:47 | | Quit simabeis (*.net *.split) |
| 23:54:47 | | Quit soap (*.net *.split) |
| 23:57:33 | | Join evilnick [0] (~evilnick@ool-18bcf602.dyn.optonline.net) |
| 23:57:39 | | Quit tempname (Quit: Serverwechsel) |
| 23:57:46 | | Quit evilnick (Changing host) |
| 23:57:46 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
| 23:57:59 | | Join factor [0] (~factor@75.108.68.114) |
| 23:58:11 | | Join scorche|sh [0] (~scorche@squisch.net) |
| 23:58:14 | | Join Naked [0] (~naked@naked.iki.fi) |
| 23:58:17 | | Join pikytcus [0] (~bigd@failbox.co.cc) |
| 23:58:22 | | Nick Naked is now known as Hadaka (~naked@naked.iki.fi) |
| 23:58:32 | kugel | TheSeven: the ata_init() change looks suspicious |
| 23:58:45 | Buschel | good night |
| 23:58:46 | | Join rvvs89 [0] (rvvs89@mussel.ucc.gu.uwa.edu.au) |
| 23:58:49 | | Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) |
icon identifies that the person is a core developer (has commit access).