| 00:01:09 | | Quit Rower85 (Quit: Hmmm...) |
| 00:02:10 | jhMikeS | saratoga: it must handle any arbitrary amount though it can output none if it doesn't yet have enough data |
| 00:02:21 | saratoga | thanks |
| 00:10:35 | jhMikeS | resample_data.frequency isn't used by asm (mistakenly implied that it is), it's ok to just increase last_sample if a longer history is required |
| 00:14:56 | preglow | whatcha working on=? |
| 00:17:33 | jhMikeS | saratoga's cubic splinging the resampler |
| 00:17:53 | jhMikeS | derp splinging, splining |
| 00:18:34 | preglow | what kind of cubic spline? hermite? |
| 00:18:39 | jhMikeS | yes |
| 00:18:48 | preglow | yeah, should be ok |
| 00:20:48 | CIA-79 | Commit 6fd4780 in rockbox by Michael Sevakis: Correct comments in lin_resample re: what is actually used by asm. |
| 00:22:15 | *** | Saving seen data "./dancer.seen" |
| 00:23:57 | saratoga | preglow: http://src.gnu-darwin.org/ports/multimedia/helixplayer/work/hxplay-1.0.7/audio/resampler/hermite.c |
| 00:26:31 | CIA-79 | 6fd4780 build result: All green |
| 00:26:41 | preglow | http://musicdsp.org/showone.php?id=93 |
| 00:26:55 | preglow | some of those forms are also worth checking out, especially for fixed point |
| 00:26:58 | | Part domonoky |
| 00:27:10 | preglow | the last one especially |
| 00:27:36 | saratoga | i think thats the form i'm using |
| 00:27:38 | preglow | actually think i've got code for that lying some place |
| 00:27:53 | saratoga | 3 muls and some shifts in place of divides |
| 00:28:05 | preglow | yeah, http://www.pvv.org/~thomj/rockbox/flanger.c |
| 00:28:29 | saratoga | huh maybe it isn't |
| 00:34:54 | saratoga | heh, this hermite code counts samples by rounding the phase, while the rockbox code truncates it |
| 00:34:54 | | Quit maffe (Quit: IRC ist obsolet!) |
| 00:35:14 | saratoga | probably going to be a hilarious off by 1 error in there somewhere |
| 00:35:26 | preglow | you tend to hear those really easily |
| 00:36:35 | saratoga | yeah |
| 00:36:43 | saratoga | just trying to get it to run without a segfault now |
| 00:36:50 | jhMikeS | sine + pitchscreen works nicely |
| 00:36:50 | saratoga | been too long since i looked at c |
| 00:36:50 | JdGordon | funman: pong :) |
| 00:36:57 | JdGordon | wait till tuesday night... tommorrow night |
| 00:37:03 | preglow | but yeah, rounding doesn't sound right in that case |
| 00:37:03 | saratoga | i keep trying to do matlab assignments :) |
| 00:37:17 | preglow | *shiver* |
| 00:37:53 | jhMikeS | u no lik matlab? |
| 00:37:54 | saratoga | lists without commas gets addictive |
| 00:37:55 | | Quit c3sso (Ping timeout: 250 seconds) |
| 00:38:05 | saratoga | matlab is an abomination |
| 00:38:21 | preglow | i should like matlab |
| 00:38:25 | preglow | but i just can't |
| 00:42:04 | saratoga | /* Wrap phase accumulator back to start of next frame. */ data->phase = phase - (pos << 16); |
| 00:42:13 | saratoga | what is this for? |
| 00:45:18 | | Join kevku [0] (x@Gizka-1-pt.tunnel.tserv24.sto1.ipv6.he.net) |
| 00:50:39 | preglow | sec |
| 00:52:25 | preglow | it just preserves the fractional part of the phase accumulator |
| 00:52:31 | jhMikeS | not quite |
| 00:52:52 | jhMikeS | depends |
| 00:53:08 | preglow | depends on the delta |
| 00:53:12 | preglow | it could be more than a fraction |
| 00:53:17 | preglow | but not by much :> |
| 00:54:08 | jhMikeS | if you're past the end of a frame, it positions where it thinks it will be within the next buffer, and it keeps doing that until it's within some buffer, which could in theory be several skips |
| 00:54:52 | preglow | yeah, that's more accurate |
| 00:55:23 | preglow | if you processed a linear block of samples, that line wouldn't be necessary, it's basically just compensating for the block based processing |
| 00:55:43 | saratoga | ugh |
| 00:55:45 | preglow | sweet god, i can't believe we're still using this piece of shit resampler :> |
| 00:55:59 | jhMikeS | it's fast? |
| 00:56:02 | jhMikeS | sort of? |
| 00:56:21 | saratoga | so what i have no is a resampler that has an unsigned int fractional part that wraps around as it accumulates |
| 00:56:22 | preglow | well, as fast as you can get and still call it resampling with a close semblance of a straight face |
| 00:56:34 | jhMikeS | lol |
| 00:56:35 | saratoga | and a signed int integer part that is incremented when the fractional part wraps around |
| 00:56:53 | * | jhMikeS admits his face was a bit crooked, maybe not quite enough :) |
| 00:57:05 | saratoga | should i just subtract the number of output samples from the interger part and hope for the best? |
| 00:57:28 | preglow | hope and pray |
| 00:57:41 | | Quit ender` (Quit: The sardines were packed as tight as the coach section of a 747.) |
| 00:57:52 | jhMikeS | no way to just combine int+frac ? |
| 00:58:22 | saratoga | i could, but i'm not sure that makes sense |
| 00:58:31 | saratoga | it'd be less accurate, and i need the fractional part anyway |
| 00:58:34 | saratoga | so it saves shifts |
| 00:59:08 | jhMikeS | the asm stuff decomposes it once per call and recombines it |
| 00:59:27 | saratoga | you think its worth the accuracy hit? |
| 00:59:30 | saratoga | i agree its an easier solution |
| 00:59:54 | jhMikeS | is it subject to amplify the inaccuracy in some way? |
| 01:00 |
| 01:00:36 | preglow | do we have any guarantees on block size? |
| 01:00:38 | saratoga | the target sampling rate will be off by 1 sample every second or so |
| 01:00:54 | jhMikeS | preglow: nope, I made it all so it's completely arbitrary |
| 01:00:56 | saratoga | i guess thats a pretty minor pitch error |
| 01:01:09 | jhMikeS | I don't think that hardware is that accurate |
| 01:01:21 | saratoga | yeah i suppose not |
| 01:01:27 | saratoga | alright, time to rewrite this mess again |
| 01:01:30 | preglow | the pitch error doesn't matter, what matters is if the resampler produces more/less samples than it should |
| 01:01:36 | preglow | or goes through its input slower/faster |
| 01:01:48 | preglow | but i guess that doesn't matter if the input isn't live |
| 01:02:13 | jhMikeS | I've tested the same sincewav file player against play and it beats every few seconds, varying with device |
| 01:02:22 | jhMikeS | s/since/sine |
| 01:02:31 | preglow | the real sample rate is usually pretty far off in most dap hardware anyway |
| 01:03:26 | | Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 01:04:09 | jhMikeS | I think the AMS players were the worst ones |
| 01:04:12 | saratoga | yeah people have done measurements of some of our players |
| 01:04:16 | saratoga | no the AMS ones are fixed now |
| 01:04:54 | jhMikeS | by a few HZ at most? |
| 01:05:10 | saratoga | ROCKBOX PITCH FIX: The good folks who maintain Rockbox apparently knew about the above error, and interestingly, fixed it in their firmware. Here's the same Clip+ playing the same file but running Rockbox and the error is now near zero (0.04%): |
| 01:05:47 | saratoga | still 17 samples per second, so i guess whatever |
| 01:05:49 | preglow | i've seen things be off by hundreds of hz |
| 01:05:58 | preglow | imperceptible even then |
| 01:05:59 | jhMikeS | 18Hz is pretty nasty. the gigabeats and coldfires are better |
| 01:07:26 | saratoga | the sandisk firmware is off by a lot more |
| 01:07:31 | jhMikeS | of course I think they're optimized for 48 |
| 01:07:37 | jhMikeS | +K |
| 01:07:40 | | Quit factor (Read error: Connection reset by peer) |
| 01:07:46 | preglow | most things are optimized for either of 48 or 44.1 |
| 01:08:14 | jhMikeS | the beast has a nice pll on the codec so it's always pretty damn good :) |
| 01:08:14 | saratoga | i think the problem was that they used one PLL for the pclk and the DAC, which meant that they couldn't hit all sampling rates exactly |
| 01:08:27 | saratoga | which was dumb since the ams chips have two plls |
| 01:08:55 | jhMikeS | some of the enabled samplerates in the AMS are so far off you can hear it with direct comparison |
| 01:09:10 | | Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 01:10:10 | saratoga | frac = f >> 1; |
| 01:10:16 | saratoga | so if f is 0.32 unsigned |
| 01:10:49 | saratoga | and our phase is s15.16 |
| 01:11:22 | jhMikeS | or, optimistically, the frac is 0.16 unsigned :) |
| 01:11:32 | saratoga | i guess I want to do (0x0000FFFF&phase) << 15? |
| 01:13:00 | jhMikeS | I guess, but in assembly I'll try to pull funny tricks like is already done |
| 01:13:17 | jhMikeS | *if I do that bit |
| 01:14:12 | | Quit kadoban_ (Ping timeout: 272 seconds) |
| 01:18:22 | jhMikeS | I guess asm isn't required to keep its data the same precise format as the C code |
| 01:30:43 | saratoga | heh, so right now i just get static |
| 01:32:30 | saratoga | ah now it works |
| 01:32:37 | saratoga | apparently the original code assumed 16 bit input |
| 01:32:50 | | Join Thra11_ [0] (~thrall@31.185.180.140) |
| 01:32:53 | jhMikeS | all great things start with static, even the universe :) |
| 01:33:45 | saratoga | ha |
| 01:33:52 | saratoga | actually theres some static sound still, so something is wrong |
| 01:34:17 | saratoga | i wonder if i'm just clipping |
| 01:36:16 | saratoga | jhMikeS: how are the input samples to the resampler scaled? |
| 01:36:20 | | Quit Thra11 (Ping timeout: 276 seconds) |
| 01:37:00 | jhMikeS | saratoga: they won't be if the codec outputs > 16 bits |
| 01:37:37 | saratoga | i have a volume dependent crackle which i'm assuming is overflow, but i'm not srue why |
| 01:40:17 | jhMikeS | maybe it's just not audible until the signal is loud enough? |
| 01:41:09 | | Join Keripo [0] (~Keripo@165.123.49.209) |
| 01:41:54 | saratoga | i assume i've made a mistake somewhere in the scaling |
| 01:45:18 | saratoga | its not clipping, its the way the history samples are being computed |
| 01:45:29 | saratoga | its volume dependent since you only notice when they're wrong if they're also loud :) |
| 01:45:52 | saratoga | jhMikeS: did you write the logic for the linear resampler, or at least understand it? |
| 02:00 |
| 02:00:00 | jhMikeS | how it is now in many ways, yes, so that it would transition up/down cleanly and handle 0 consumed/produced properly. I didn't do the original, which was rather buggy. |
| 02:01:10 | saratoga | i need to work on something, else so i'm going to push it to gerrit for now |
| 02:01:17 | saratoga | feel like skimming it to see if i've made some dumb mistake? |
| 02:01:26 | jhMikeS | sure |
| 02:01:47 | jhMikeS | is this planned to replace the linear one? |
| 02:02:22 | saratoga | for now it replaces it, i don't know that we have to do that though |
| 02:02:32 | saratoga | and crap pushed to gerrit with the meier patch applied |
| 02:02:45 | saratoga | that is something the commit -v could have mentioned ... |
| 02:02:51 | jhMikeS | of course, codecs that really need speed could just handle it themselves |
| 02:03:08 | saratoga | http://gerrit.rockbox.org/r/#/c/231/ |
| 02:11:26 | | Quit prof_wolfff (Ping timeout: 276 seconds) |
| 02:13:55 | | Quit bitcraft (Remote host closed the connection) |
| 02:16:05 | | Join bitcraft_ [0] (~bitcraft@173-20-20-92.client.mchsi.com) |
| 02:22:19 | *** | Saving seen data "./dancer.seen" |
| 02:23:07 | jhMikeS | I can see that if count < 3 then it'll be looking ahead into nowhere |
| 02:23:39 | jhMikeS | or did I misread, hmm |
| 02:24:40 | | Quit pamaury (Read error: Connection reset by peer) |
| 02:31:56 | jhMikeS | hmmm... last_samples aren't being read at the begginning using channel info |
| 02:40:58 | | Quit bitcraft_ (Remote host closed the connection) |
| 03:00 |
| 03:03:22 | | Quit KiwiCam (Quit: Leaving) |
| 03:08:31 | saratoga | jhMikeS: thanks, that seems to fix it |
| 03:10:15 | saratoga | pushed the fixed version to gerrit |
| 03:10:19 | saratoga | will play around with this more in the morning |
| 03:20:34 | saratoga | well just quickly trying a 96k sampling rate file with two strong ultrasound tones, both Hermite and linear are horrible, but hermite sounds a lot less bad |
| 03:23:51 | | Quit saratoga (Quit: Page closed) |
| 03:51:56 | | Join bitcraft [0] (~bitcraft@50.44.14.169) |
| 04:00 |
| 04:13:33 | | Quit perrikwp (Read error: Connection reset by peer) |
| 04:17:51 | | Quit bitcraft (Remote host closed the connection) |
| 04:22:20 | *** | Saving seen data "./dancer.seen" |
| 04:32:31 | | Join FrenchVerbs [0] (~chatzilla@c-71-193-88-22.hsd1.mn.comcast.net) |
| 04:33:08 | FrenchVerbs | Hey guys, I am on a somewhat old build of rockbox and when I plug in my ipod classic, it refuses to show up as a disk drive. How can I go about fixing this? |
| 04:34:24 | FrenchVerbs | Also congrats on a decade! |
| 04:35:07 | | Quit TheSphinX_ (Ping timeout: 244 seconds) |
| 04:37:08 | FrenchVerbs | It does show up in device manager though. |
| 04:37:35 | FrenchVerbs | Anyone there? |
| 04:39:01 | kisak | yes, just noone has seen what you said who has an answer for you |
| 04:39:19 | kisak | (yet) |
| 04:40:05 | | Join TheSphinX^ [0] (~briehl@p5B323F30.dip.t-dialin.net) |
| 04:41:47 | FrenchVerbs | Wait, it just showed up. I'm going to take this oppurtunity to update my version of rockbox. |
| 04:43:08 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 04:43:15 | | Quit [7] (Disconnected by services) |
| 04:44:08 | CIA-79 | Commit 675f171 in rockbox by Rafaël Carré: skin_parser: simplify skin_buffer_alloc |
| 04:46:57 | FrenchVerbs | Where can I see a changelog for the nightly builds btw? |
| 04:49:16 | funman | www.rockbox.org |
| 04:49:40 | funman | there are no nightly builds though, builds are made each time the source is changed |
| 04:52:32 | FrenchVerbs | http://download.rockbox.org/daily/ipodclassic/ |
| 04:52:47 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 04:52:48 | FrenchVerbs | isn't that a nightly (daily) build, funman? |
| 04:53:05 | funman | hmm yes |
| 04:53:15 | funman | i thought we only copied some current builds |
| 04:53:30 | FrenchVerbs | What do you mean? |
| 04:53:45 | funman | see "code changes" on the web site |
| 04:54:04 | FrenchVerbs | Okay, thanks |
| 04:55:28 | | Quit pixelma (Disconnected by services) |
| 04:55:28 | | Quit amiconn (Disconnected by services) |
| 04:55:30 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:55:30 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:55:32 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:55:35 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:59:45 | | Quit FrenchVerbs (Quit: ChatZilla 0.9.88.2 [Firefox 15.0a1/20120506030520]) |
| 05:00 |
| 05:01:09 | CIA-79 | Commit aaf9a1b in rockbox by Rafaël Carré: get_image_filename() return value is never used |
| 05:14:13 | CIA-79 | Commit 65bb8e4 in rockbox by Rafaël Carré: Remove extraneous parens |
| 05:17:07 | | Quit [Saint] (Read error: Connection reset by peer) |
| 05:19:07 | | Quit factor (Read error: Connection reset by peer) |
| 05:26:33 | | Quit enthdegree (Ping timeout: 260 seconds) |
| 05:29:25 | | Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) |
| 05:29:49 | | Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 05:32:28 | | Join enthdegree [0] (~enthdegre@wikimedia/enthdegree) |
| 05:35:03 | | Join bitcraft [0] (~bitcraft@50.44.14.169) |
| 05:35:46 | | Quit bitcraft (Remote host closed the connection) |
| 05:38:59 | | Join bitcraft [0] (~bitcraft@50.44.14.169) |
| 05:43:24 | CIA-79 | Commit 06c8ab8 in rockbox by Rafaël Carré: Don't use function in a function |
| 05:43:24 | CIA-79 | Commit 5aadf87 in rockbox by Rafaël Carré: asap codec: remove invalid memset |
| 05:43:25 | CIA-79 | Commit dfeab52 in rockbox by Rafaël Carré: remove extraneous parens |
| 05:43:26 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 05:45:11 | | Quit bitcraft (Remote host closed the connection) |
| 05:48:43 | CIA-79 | Commit 2eccc02 in rockbox by Rafaël Carré: sansa AMS: i2s_reset() is never used |
| 05:51:08 | | Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) |
| 05:53:58 | * | [Saint] wonders if funman has any insight into the recent(-ish) skin engine weirdness. |
| 05:57:08 | | Quit [Saint] (Quit: Quit) |
| 05:57:29 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 05:57:44 | funman | http://people.videolan.org/~funman/rockbox/ (clip zip) |
| 05:57:56 | funman | [Saint]: no i am still waiting for jd help |
| 05:58:16 | funman | i dont really understand hwo buflib/skin buffer work |
| 05:58:55 | [Saint] | funman: right, I was just curious. The skin engine was a minefield even before burflib ;) |
| 05:59:23 | [Saint] | I have a feeling, and have had for a while, that bufflib is rather broken. |
| 06:00 |
| 06:00:11 | funman | the bug i pointed out is clearly specific to skin and not caused by buflib |
| 06:02:48 | CIA-79 | Commit cf09020 in rockbox by Rafaël Carré: Sansa AMS: more compat irq names |
| 06:09:34 | funman | AlexP: ping |
| 06:09:40 | funman | AlexP: http://build.rockbox.org/shownewlog.cgi?rev=cf09020;type=sansac200v2boot |
| 06:09:43 | | Quit enthdegree (Quit: HydraIRC -> http://www.hydrairc.com <- Organize your IRC) |
| 06:12:15 | funman | AlexP: seems to be python3 |
| 06:14:10 | * | [Saint] recalls that coming up some time ago. |
| 06:16:17 | [Saint] | Its barring for distros that aren't symlinking so python "just works" when python2 is expected, iirc. |
| 06:16:26 | [Saint] | *barfing |
| 06:19:35 | CIA-79 | Commit bed634d in rockbox by Rafaël Carré: thumb-cc.py: fix for python 3.2 |
| 06:20:24 | funman | the problem is that it is symlinked |
| 06:21:42 | | Quit Topy44 (Ping timeout: 276 seconds) |
| 06:22:21 | *** | Saving seen data "./dancer.seen" |
| 06:23:15 | [Saint] | Anyone know who owns/runs/manages/whatever the Rockbox commit log Twitter account? |
| 06:23:55 | [Saint] | It occurs to me that it would be a whole lot more useful if it actually gave a link to the commit. |
| 06:24:26 | [Saint] | As it is, it simply states "this happened" which is useful, but could be more so. |
| 06:31:03 | funman | that would be zagor |
| 06:33:22 | funman | it would be http://git.rockbox.org/?p=rockbox.git;a=commit;h=XXXX (XXX = short id) |
| 06:36:37 | | Quit Thra11_ (Ping timeout: 240 seconds) |
| 06:36:50 | | Quit anewuser () |
| 06:51:24 | CIA-79 | Commit ed38c5d in rockbox by Rafaël Carré: remove unused prototypes |
| 06:56:14 | CIA-79 | Commit 7ca2081 in rockbox by Rafaël Carré: remove debug-target.h |
| 07:00 |
| 07:02:50 | | Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 07:06:11 | | Quit [Saint] (Ping timeout: 250 seconds) |
| 07:10:28 | | Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 07:14:40 | | Join stoffel [0] (~quassel@pD9E42742.dip.t-dialin.net) |
| 07:19:57 | CIA-79 | Commit 803408f in rockbox by Rafaël Carré: simplify copy_padded |
| 07:29:24 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 07:30:56 | CIA-79 | Commit dd57c01 in rockbox by Rafaël Carré: simplify yearday_to_daymonth() |
| 07:32:20 | | Quit [Saint_] (Ping timeout: 244 seconds) |
| 07:33:52 | | Join HaloNachos117 [0] (~181eb2a3@www.haxx.se) |
| 07:36:06 | CIA-79 | Commit c4a51d2 in rockbox by Rafaël Carré: missing const |
| 07:37:29 | HaloNachos117 | Hi, I just wanted to celebrate the return/resurrection of a great old player. My old Sansa Fuze v2 has a cracked screen, so I've not been able to use it for a long time. However, with Rockbox, I'm now able to use the voice feature. Thanks a lot to the dev's out there for making something so awesome! |
| 07:37:55 | | Quit HaloNachos117 (Client Quit) |
| 07:39:54 | | Join HaloNachos117 [0] (~181eb2a3@www.haxx.se) |
| 07:40:22 | HaloNachos117 | Hi, I just wanted to celebrate the return/resurrection of a great old player. My old Sansa Fuze v2 has a cracked screen, so I've not been able to use it for a long time. However, with Rockbox, I'm now able to use the voice feature. Thanks a lot to the dev's out there for making something so awesome! Why didn't I think of doing this sooner? |
| 07:40:28 | | Quit HaloNachos117 (Client Quit) |
| 07:45:57 | [Saint] | Gotta love those... |
| 07:46:20 | funman | % git grep ifdef|wc -l |
| 07:46:20 | funman | 8781 |
| 07:46:41 | [Saint] | "Hi, just wanted to say you're awesome and I appreciate it, no complaints...bye!" |
| 07:46:51 | [Saint] | that's my type of user... |
| 07:47:44 | [Saint] | funman: Ô_o |
| 07:49:08 | kugel | funman: perhaps related to FS #12657, some stkov corrupting skin memory? |
| 07:49:08 | fs-bluebot | http://www.rockbox.org/tracker/task/12657 ThinBasic causes panic on Nano 1g (bugs, unconfirmed) |
| 07:49:46 | funman | kugel: cant tell without jd opinion |
| 07:50:26 | kugel | the skin engine seems to have a stack heavy function somewhere, or perhaps it recurses too deep |
| 07:50:36 | funman | it is not a stkov in this case |
| 07:51:35 | funman | something allocates from skin_buffer, then modifies skin_buffer pointer then reads from allocated memory |
| 07:51:43 | funman | and it is dead wrong |
| 07:53:10 | funman | kugel: core_alloc.c has no license ? |
| 07:54:00 | kugel | it should |
| 07:54:16 | kugel | i probably have forgotten to add the header |
| 08:00 |
| 08:03:51 | | Quit bluebrother (Ping timeout: 244 seconds) |
| 08:04:24 | | Quit fs-bluebot (Ping timeout: 276 seconds) |
| 08:04:40 | | Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) |
| 08:05:49 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 08:06:07 | | Quit remlap (Ping timeout: 240 seconds) |
| 08:06:44 | | Join fs-bluebot [0] (~fs-bluebo@f053153074.adsl.alicedsl.de) |
| 08:18:47 | | Nick JdGordon is now known as MrsJD (~jonno@rockbox/developer/JdGordon) |
| 08:19:42 | | Join jdgord [0] (~jdgord@rockbox/developer/JdGordon) |
| 08:21:12 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:21:29 | | Nick MrsJD is now known as JdGordon (~jonno@rockbox/developer/JdGordon) |
| 08:22:23 | *** | Saving seen data "./dancer.seen" |
| 08:25:38 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 08:31:33 | JdGordon | funman: what have you done!!!! :) |
| 08:31:37 | | Join c3sso [0] (~tux@89.106.213.194) |
| 08:43:42 | | Quit jdgord (Read error: Connection reset by peer) |
| 08:45:47 | [Saint] | JdGordon: did your work with skin code formatting (line breaks/indentation) actually go in, and is it explained anywhere what's accepted if so? |
| 08:46:29 | kugel | i think so |
| 08:46:32 | [Saint] | I hate it...but for the general public to jot go insane immediately, I'm going to have to work on the readability of these conditions of mine. |
| 08:46:43 | [Saint] | *to not |
| 08:49:17 | [Saint] | When even I find it hard (actually close to impossible) to parse what I'm writing, I /probably/ shouldn't expect anyone else's experience to be any different, I guess. |
| 08:49:55 | [Saint] | And I would like for people to he able to learn from the code, not be baffled by it. If at all possible. |
| 08:53:29 | [Saint] | I remember the old "happy accident" way of splitting long lines with a #, but I don't know what the rules are now indentation and line breaking is actually a thing. |
| 08:58:02 | funman | JdGordon: ? |
| 09:00 |
| 09:39:14 | | Join n1s [0] (~n1s@nl118-175-223.student.uu.se) |
| 09:39:14 | | Quit n1s (Changing host) |
| 09:39:14 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 09:49:02 | preglow | 03:20 < saratoga> well just quickly trying a 96k sampling rate file with two strong ultrasound tones, both Hermite and linear are horrible, but hermite sounds a lot less bad |
| 09:49:21 | preglow | saratoga: that sounds about as i'd expect it to be, so seems you've succeeded |
| 09:49:51 | preglow | you won't get much better than that with a pure interpolative approach |
| 09:52:02 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 09:52:02 | | Quit bertrik (Changing host) |
| 09:52:02 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 09:56:26 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 10:00 |
| 10:04:22 | | Quit tchan (Ping timeout: 246 seconds) |
| 10:15:07 | | Join bitcraft [0] (~bitcraft@50-103-46-79.dklb.il.frontiernet.net) |
| 10:18:05 | CIA-79 | Commit 51a73d8 in rockbox by Michael Sevakis: Stop clickiness on manual track changes as best as possible. |
| 10:18:56 | | Quit bitcraft (Remote host closed the connection) |
| 10:21:44 | CIA-79 | 51a73d8 build result: All green |
| 10:22:27 | *** | Saving seen data "./dancer.seen" |
| 10:22:51 | n1s | funman: isn't the if condition in commit 803408f inverted, should be if (src[i] == 0) or if (!src[i]) afaict |
| 10:24:40 | kugel | why not even make it a memcpy();memset(); combo? |
| 10:25:20 | kugel | ah, nevermind |
| 10:25:37 | kugel | strcpy();memset(); would work |
| 10:26:12 | kugel | strlcpy* |
| 10:26:44 | n1s | yeah |
| 10:29:09 | CIA-79 | Commit 3f61caa in rockbox by Nils Wallménius: rbcodec: abstract tdspeed buffer allocation |
| 10:29:26 | | Join Syconaut^ [0] (viper@c-4dfd72d5.162-1-64736c10.cust.bredbandsbolaget.se) |
| 10:35:58 | | Quit c3sso (Ping timeout: 245 seconds) |
| 10:36:37 | kugel | hm, how can I make sure a semaphore isn't released before the semaphore_wait() call? |
| 10:37:34 | | Quit mc2739 (Ping timeout: 260 seconds) |
| 10:39:13 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 10:39:53 | jhMikeS | kugel: ?? |
| 10:40:50 | kugel | hm, iiuc our semaphores can be signalled before the wait() call in which case wait() returns immediately no? |
| 10:42:53 | jhMikeS | yes |
| 10:43:17 | jhMikeS | that's what's supposed to happen |
| 10:43:27 | kugel | then the deadlock is somewhere else. however it works with a few printf()s in the code |
| 10:44:19 | jhMikeS | deadlock? |
| 10:45:27 | kugel | http://pastie.org/3872330 |
| 10:47:45 | * | jhMikeS tried an I/O thread some time ago |
| 10:48:57 | jhMikeS | are you actually disabling "interrupts"? |
| 10:50:28 | jhMikeS | kugel: I remember you left that bit out. You'll probably corrupt stuff if signaling from amother thread and not going through the right bits |
| 10:51:07 | kugel | where should I disable interrupts? |
| 10:51:36 | kugel | stupid sdl thread create/exit debug |
| 10:51:50 | kugel | makes it slow |
| 10:51:55 | jhMikeS | I suppose semaphore_release will if the functions are implemented |
| 10:52:41 | jhMikeS | for the whole gimmick to work it needed sim_enter_int_handler (or whatever that was called) |
| 10:53:25 | kugel | seems to work with that indeed |
| 10:56:49 | kugel | it should work without too IIUC though |
| 10:58:02 | | Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) |
| 10:58:13 | jhMikeS | no, it won't, I think it'll deadlock :) |
| 10:58:17 | | Quit pamaury (Changing host) |
| 10:58:17 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 10:58:24 | | Join jdgord [0] (~jdgord@rockbox/developer/JdGordon) |
| 10:58:42 | kugel | if the sem can be signalled before wait()? |
| 11:00 |
| 11:00:58 | jhMikeS | the internal mutex in there will left unlocked, not protecting the scheduler lists |
| 11:05:28 | | Quit jdgord (Read error: Connection reset by peer) |
| 11:06:01 | kugel | how? |
| 11:06:58 | | Join LinusN [0] (~linus@giant.haxx.se) |
| 11:06:59 | jhMikeS | set_irq_level just locks then unlocks the internal mutex |
| 11:07:45 | jhMikeS | the calls in the kernel then leave the lists unprotected from preemtive manipulation |
| 11:07:51 | kugel | if I don't call the sim_(enter|exit)_irq_handler pair it's not locked in the first place |
| 11:08:16 | jhMikeS | because? |
| 11:08:36 | | Join jdgord [0] (~jdgord@rockbox/developer/JdGordon) |
| 11:09:18 | kugel | which mutex exactly? the irq sim_irq_mtx is locked in sim_enter |
| 11:09:32 | jhMikeS | yes |
| 11:09:48 | jhMikeS | set_irq_level does it too but doesn't keep it locked |
| 11:10:12 | kugel | which set_irq_level call? |
| 11:10:22 | jhMikeS | in kernel-sdl.c |
| 11:10:47 | kugel | who calls it? |
| 11:11:28 | jhMikeS | the sem functions, the queue functions, the scheduler, |
| 11:12:50 | jhMikeS | things that act like interrupts must call sim_enter/exit_irq_handler before interacting with the kernel |
| 11:13:05 | kugel | okay |
| 11:13:30 | * | kugel stops trying to understand why the kernel goes insane without |
| 11:13:45 | jhMikeS | linked lists and other data structs |
| 11:14:23 | jhMikeS | using it for disk IO would increase the chances of breakdown |
| 11:15:01 | kugel | stderr redirect in gdb doesnt appear to work |
| 11:15:04 | jhMikeS | you might even miss waking up the thread approaching the block |
| 11:15:54 | jhMikeS | it would be blocking but not yet visible to whoever is waking it because not everything is updated |
| 11:18:07 | | Quit jdgord (Read error: Connection reset by peer) |
| 11:21:48 | n1s | jhMikeS: there's one place left in rbcodec accessing global_settings, the dsp_callback function (dsp_misc.c). wtachi's patch moves it out to the rb specific helper file, i think it makes sense since it's rather specific to our acritecture. but i see you have added a FIXME comment to it to move the sw volume stuff, comments? |
| 11:23:11 | n1s | the patch is in g#145 but requires some syncing |
| 11:23:13 | fs-bluebot | Gerrit review #145 at http://gerrit.rockbox.org/r/#change,145 : rbcodec refactoring: dsp_callback by Sean Bartell (changes/45/145/2) |
| 11:24:36 | jhMikeS | n1s: yeah, it should be in the pcm driver so it adjusts everything! :) |
| 11:25:39 | jhMikeS | otherwise it has to be painstakenly written into everything using pcm directly and to every pcm channel |
| 11:26:19 | n1s | so it shouldn't actually be in dsp at all |
| 11:27:38 | jhMikeS | I think not. Besides it would have alot of latency there. |
| 11:28:43 | n1s | it sounds rather easy to do, what's the catch? ;) |
| 11:30:00 | jhMikeS | double buffer in the affected drivers (which is what, just a MIPS target or two?) |
| 11:30:16 | n1s | yeah seems only the onda targets use this |
| 11:30:34 | jhMikeS | HAVE_SW_VOLUME_CONTROL would be a pointless define too |
| 11:30:44 | jhMikeS | nothing should have to know |
| 11:31:29 | n1s | so faking volume control in the target driver |
| 11:31:51 | jhMikeS | yeah |
| 11:32:14 | n1s | i can try to whip something up but i don't have one of the affected targets |
| 11:32:45 | jhMikeS | I wouldn't mind one, if nothing else than to just learn MIPS assembly effectively |
| 11:33:51 | jhMikeS | has anyone done anything with them in recent history? |
| 11:34:12 | jhMikeS | seems like it just got dumped |
| 11:34:21 | n1s | not anything i remember |
| 11:34:24 | AlexP | funman: Right, forgot about that |
| 11:34:37 | AlexP | I've killed that client for the minute |
| 11:34:54 | jhMikeS | the only more neglected target I can think of is the i.FP |
| 11:35:42 | jhMikeS | actually, not really. seems most of them just age :) |
| 11:35:55 | jhMikeS | like milk, not wine :p |
| 11:37:50 | n1s | these ports build at least :) |
| 11:38:16 | | Quit kevku (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/) |
| 11:38:25 | AlexP | funman: Oh, I see you fixed it :) |
| 11:39:21 | n1s | i'm not sure if a blind patch would help either especially since i'm confused by thsi dma stuff... |
| 11:42:01 | n1s | seems pretty much only mcuelenaere was active on that port |
| 11:42:41 | jhMikeS | keeping those ports running is like changing the oil on an engine with a missing cylinder head |
| 11:42:48 | jhMikeS | s/running/building |
| 11:44:21 | | Quit funman (Read error: Operation timed out) |
| 11:45:49 | n1s | jhMikeS: yeah, last commit by him touching that port was in jan last year :/ |
| 11:46:55 | jhMikeS | I wonder if anyone but me noticed the recording screen going haywire on gigabeat S :\ |
| 11:47:32 | * | jhMikeS awaits it to be magically fixed |
| 11:48:19 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 11:50:59 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
| 11:58:57 | kugel | jhMikeS: the pcm-alsa backend needs it too (not on ypr0 though because we can access the codec there) |
| 12:00 |
| 12:00:18 | | Quit remlap1 (Quit: Leaving.) |
| 12:01:14 | kugel | can I turn the sdl debug messages off? it makes my work unbearably slow |
| 12:02:44 | | Quit funman (Ping timeout: 260 seconds) |
| 12:03:29 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 12:03:38 | jhMikeS | which ones? |
| 12:04:13 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 12:05:28 | kugel | huh. they're gone now |
| 12:05:43 | jhMikeS | viola! |
| 12:05:49 | kugel | wth |
| 12:06:28 | | Quit factor (Ping timeout: 252 seconds) |
| 12:06:35 | kugel | ahh |
| 12:06:39 | kugel | they only appear within gdb |
| 12:06:57 | kugel | so it's not about sdl actually |
| 12:07:09 | n1s | so assumin it's not ok to kill sw volume and not acceptable to push untested patches to the onda port and pretend they take care of it, how should the sw volume stuff be handled? |
| 12:07:39 | jhMikeS | the listener can imagine it's quieter? |
| 12:07:56 | kugel | can't the pcm mixer apply the volume? |
| 12:07:58 | jhMikeS | For sim it's in the pcm driver |
| 12:08:00 | n1s | ah yes, or hold the headphone further away |
| 12:08:01 | jhMikeS | it can |
| 12:08:22 | jhMikeS | no positive gain though, just 0 or less |
| 12:08:35 | kugel | that should be fine |
| 12:08:38 | jhMikeS | decibally speaking |
| 12:14:23 | kugel | go for it then :) |
| 12:17:24 | jhMikeS | that's mixer abuse |
| 12:17:50 | | Quit funman (Ping timeout: 252 seconds) |
| 12:18:13 | kugel | really? |
| 12:19:07 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 12:19:12 | kugel | it's common that the mixer module handles global volume as well isnt it? |
| 12:21:22 | jhMikeS | it may be, so long as the mixer is used. several things don't use it though |
| 12:22:29 | *** | Saving seen data "./dancer.seen" |
| 12:23:16 | kugel | right. but i don't see how it's mixer abuse |
| 12:23:29 | jhMikeS | maybe it could be implemented in pcm.c instead to catch it all, but the sim does it in its pcm driver |
| 12:23:42 | kugel | more stuff goes through the mixer than through dsp so it's an improvement :) |
| 12:27:36 | kugel | spawning mass threads doesnt work well in gdb |
| 12:28:17 | kugel | man, i don't really want a single i/o thread which is a waste of resources 99% of the time (even if it idles) |
| 12:28:33 | | Quit funman (Ping timeout: 250 seconds) |
| 12:30:10 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 12:31:56 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 12:32:16 | jhMikeS | use an existing thread like the input one? |
| 12:39:09 | kugel | trying that right now |
| 12:43:12 | | Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 12:47:59 | kugel | horribly slow via SDL_PushEvent |
| 12:58:00 | kugel | event queue processing is slow |
| 12:58:47 | kugel | SDL_PushEvent + 1-thread-per-transfer is almost as slow as SDL_PushEvent only (while 1-thread-per-transfer was blazing fast outside gdb) |
| 13:00 |
| 13:08:41 | | Quit Elfish (Ping timeout: 252 seconds) |
| 13:08:48 | | Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc) |
| 13:09:54 | | Quit Cthulhux (Ping timeout: 252 seconds) |
| 13:10:10 | | Join Cthulhux [0] (cthulhux@rosaelefanten.org) |
| 13:10:47 | | Quit Cthulhux (Changing host) |
| 13:10:47 | | Join Cthulhux [0] (cthulhux@piratenpartei/ni/tux) |
| 13:23:07 | kugel | ha! |
| 13:23:26 | kugel | according to http://gameprogrammer.com/fastevents/fastevents1.html SDL_WaitEvent sucks. and it's true |
| 13:36:13 | kugel | http://pastie.org/3872960 (jhMikeS ^) |
| 13:49:08 | kugel | jhMikeS: "Well, he's no Jan Brady"? |
| 13:51:13 | | Quit Keripo (Quit: Leaving.) |
| 13:59:16 | | Join TheLemonMan [0] (~LemonBoy@adsl-ull-43-248.45-151.net24.it) |
| 14:00 |
| 14:03:26 | n1s | hmm, i'm not sure how to hook this in to pcm.c i guess just throwing in loops for applying gain in pcm_play_data_start and pcm_play_dma_complete_callback would not be ideal |
| 14:10:06 | | Join anewuser [0] (~anewuser@190.207.222.122) |
| 14:10:06 | | Quit anewuser (Changing host) |
| 14:10:06 | | Join anewuser [0] (~anewuser@unaffiliated/anewuser) |
| 14:22:31 | *** | Saving seen data "./dancer.seen" |
| 14:25:48 | | Join FrenchVerbs [0] (~chatzilla@c-71-193-88-22.hsd1.mn.comcast.net) |
| 14:26:45 | FrenchVerbs | Hey guys I'm on the latest version of rockbox with an ipod classic. Everytime I boot up I get a *Panic* audio_buffer_noalloc(): EOM (65536 > 0) What does this mean? |
| 14:28:41 | FrenchVerbs | Would clearing rockbox database in the boot menu help? |
| 14:29:46 | FrenchVerbs | I've gotta go to school, but I'll hang out in case someone can help me out. |
| 14:34:51 | n1s | quick hack in pcm.c to set volume there http://pastie.org/3873163 works in the sim at least |
| 14:35:29 | | Quit bertrik (Remote host closed the connection) |
| 14:35:36 | n1s | would somethign like this but cleande up of course be the way to do it or do we need to buffer pcm while applying the gain? |
| 14:35:57 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 14:35:57 | | Quit bertrik (Changing host) |
| 14:35:57 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 14:43:47 | | Quit kadoban_ (Ping timeout: 265 seconds) |
| 14:45:30 | | Join Thra11 [0] (~thrall@31.185.180.140) |
| 14:46:42 | | Quit bertrik (Read error: No route to host) |
| 14:49:56 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 15:00 |
| 15:00:43 | | Join eyfour [0] (~a4@85.252.220.105) |
| 15:11:28 | | Join enthdegree [0] (~enthdegre@wikimedia/enthdegree) |
| 15:18:07 | | Quit Cthulhux (Ping timeout: 252 seconds) |
| 15:23:20 | | Quit eyfour (Quit: WeeChat 0.3.5) |
| 15:23:52 | | Join Cthulhux [0] (cthulhux@piratenpartei/ni/tux) |
| 15:24:23 | | Join eyfour [0] (~a4@85.252.220.105) |
| 15:27:03 | n1s | a bunch of the newer metadata parser files lack header |
| 15:30:20 | | Quit TheLemonMan (Quit: WeeChat 0.3.7) |
| 15:32:23 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 15:36:42 | | Quit stoffel (Ping timeout: 260 seconds) |
| 15:37:05 | | Join funman_ [0] (~fun@rockbox/developer/funman) |
| 15:37:26 | | Quit funman (Ping timeout: 265 seconds) |
| 15:42:07 | | Quit funman_ (Ping timeout: 240 seconds) |
| 15:43:17 | | Join funman [0] (~fun@altair.via.ecp.fr) |
| 15:43:19 | | Quit funman (Changing host) |
| 15:43:19 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 15:50:15 | | Join Topy44 [0] (~Topy44@f048224156.adsl.alicedsl.de) |
| 16:00 |
| 16:07:34 | | Join c3sso [0] (~tux@89.106.213.194) |
| 16:10:46 | | Quit enthdegree (Ping timeout: 255 seconds) |
| 16:12:55 | | Join stoffel [0] (~quassel@pD9E42742.dip.t-dialin.net) |
| 16:22:34 | *** | Saving seen data "./dancer.seen" |
| 16:39:59 | | Join megal0maniac [0] (~megal0man@196.213.53.210) |
| 16:40:39 | megal0maniac | Quick question. My Fuze+ has died completely, or so I thought. Can still access recovery mode. Is it possible to fix it? |
| 16:42:51 | megal0maniac | I guess that isn't really a quick question... :) |
| 16:50:52 | | Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) |
| 16:52:29 | megal0maniac | Have to go. Will re-join IRC when I get home and review the logs. If anyone knows how to dump a firmware image (or simply recover,) please let me know |
| 16:52:32 | megal0maniac | Thanks |
| 16:54:11 | | Quit megal0maniac (Quit: Konversation terminated!) |
| 16:55:07 | pamaury | megal0manic: it is possible to reinstall a firmware image, but it would interesting to know why it failed in the first place |
| 16:58:31 | | Part Zagor |
| 17:00 |
| 17:07:35 | | Join mortalis [0] (~mortalis@77.108.98.177) |
| 17:10:41 | | Join megal0maniac [0] (~vwmazfa@197.171.142.46) |
| 17:11:38 | | Join TheLemonMan [0] (~LemonBoy@adsl-ull-43-248.45-151.net24.it) |
| 17:12:57 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 17:13:49 | | Quit megal0maniac (Client Quit) |
| 17:28:46 | | Quit factor (Read error: Connection reset by peer) |
| 17:32:20 | | Join megal0maniac [0] (~megal0man@41.52.11.242) |
| 17:33:16 | megal0maniac | Hello. Can't check the logs at the moment, but does anyone know how to restore a Fuze plus from within recovery mode? |
| 17:35:07 | pamaury | megal0maniac: yes, it's written on the wiki |
| 17:35:29 | pamaury | http://www.rockbox.org/wiki/SansaFuzePlusPort#Linux_AN1 |
| 17:35:40 | megal0maniac | I only saw how to get it into Recovery mode, not how to flash it... |
| 17:37:00 | pamaury | the link I gave you explains everything, I wrote it so that anyone can restore its device (if it's still working) |
| 17:37:03 | megal0maniac | Alright, thanks. Will have a closer look when I get to a computer |
| 17:38:23 | megal0maniac | It's odd. It just freaked out completely and switched off. Only recently did I manage to get it into recovery mode... |
| 17:39:09 | | Part LinusN |
| 17:41:40 | pamaury | indeed |
| 17:43:07 | megal0maniac | Thanks again for your hard work :) |
| 17:43:08 | megal0maniac | I'll brb |
| 17:43:15 | | Quit megal0maniac (Quit: used jmIrc) |
| 17:44:00 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:46:43 | | Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 17:47:25 | | Quit TheLemonMan (Quit: WeeChat 0.3.7) |
| 17:51:06 | | Quit kugel (Remote host closed the connection) |
| 17:55:01 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 17:56:33 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 17:57:33 | kugel | jhMikeS: re-using the input thread is suboptimal too. it loses input events when being spammed and/or blocked by I/O |
| 17:59:40 | kugel | the result is that it's not much more responsible than without this (with sigaltstack threads existing solution is not functional) |
| 18:00 |
| 18:05:34 | | Quit anewuser (Ping timeout: 255 seconds) |
| 18:11:23 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 18:22:38 | *** | Saving seen data "./dancer.seen" |
| 18:22:43 | n1s | grr, this header mess is infuriating |
| 18:25:29 | | Quit mystica555 (Ping timeout: 252 seconds) |
| 18:27:13 | | Quit [Saint] (Read error: Connection reset by peer) |
| 18:35:31 | | Join megal0maniac [0] (~megal0man@dsl-244-87-212.telkomadsl.co.za) |
| 18:38:28 | megal0maniac | @pamaury I was looking at the wrong wiki page :$ Busy installing Ubuntu (only distro I have on hand) and hopefully get it sorted soon |
| 18:39:38 | | Join saratoga [0] (98032941@gateway/web/freenode/ip.152.3.41.65) |
| 18:40:16 | saratoga | preglow: so if I want to try an oversampling hermite interpolator, what is the correct type of filter to use for upsampling? |
| 18:42:48 | | Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) |
| 18:43:20 | CIA-79 | Commit 7803f31 in rockbox by Nils Wallménius: Don't reinvent ctype.h functions |
| 18:44:51 | funman | n1s: good catch |
| 18:45:10 | funman | kugel: for 803408f strlcpy is not usable because it nulkl terminates the copy |
| 18:46:04 | kugel | just overwrite that byte? |
| 18:48:40 | | Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 18:48:57 | kugel | ah but it could write 1 byte too much |
| 18:58:05 | | Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) |
| 18:59:18 | * | n1s pokes CIA-79 |
| 19:00 |
| 19:01:17 | | Join prof_wolfff [0] (~prof_wolf@213.37.48.196.static.user.ono.com) |
| 19:01:39 | CIA-79 | Commit dae7a29 in rockbox by Rafaël Carré: fix a mistake of 803408f18 spotted by n1s |
| 19:05:27 | | Join lebellium [0] (~chatzilla@e179077231.adsl.alicedsl.de) |
| 19:12:42 | | Quit krnlyng (Read error: Connection timed out) |
| 19:14:53 | | Join ej0rge [0] (~alhaz@207.135.137.71) |
| 19:15:12 | ej0rge | So i just noticed something weird about the behavior of the equalizer on my gigabeat S |
| 19:15:34 | ej0rge | It strikes me as odd that i should be able to clearly hear a tonal difference between EQ enabled and EQ disabled when the EQ is zeroed out |
| 19:15:45 | ej0rge | Any thoughts? |
| 19:23:19 | megal0maniac | Not sure about Rockbox, but in the world of pro / studio audio, this is normal. |
| 19:24:05 | gevaerts | ej0rge: given a non-0 precut there will be a volume difference at least |
| 19:24:16 | megal0maniac | The sound is still passing through some or other circuitry, and while it isn't intentionally changing the sound, it does have an effect. I'd imagine that it's a similar scenario in rockbox |
| 19:24:39 | gevaerts | megal0maniac: it's not. the EQ is pure software |
| 19:25:17 | ej0rge | gevaerts: Stranger still, when i loaded the "Default" EQ preset, the difference seemed to go away |
| 19:25:32 | | Join megal0maniac__ [0] (~michael@dsl-244-87-212.telkomadsl.co.za) |
| 19:26:12 | ej0rge | iirc there are some rockbox targets with hardware eq features that are supported, but those are always in a sub-menu separate from "Equalizer", right? |
| 19:26:55 | ej0rge | gevaerts: loading the default preset does not seem to have changed any values, but I am unsure of my conclusions. I'll come back and/or log a bug if i duplicate the behavior on another device. |
| 19:27:02 | ej0rge | or find some way to make this one do it again |
| 19:27:22 | megal0maniac | Yes, but then it's passing through algorithms instead of circuitry. Same priciple, I'd imagine |
| 19:27:43 | ej0rge | megal0maniac: unless the setting is "Do nothing" - in which case, mathematically, it should do, nothing. |
| 19:27:50 | | Quit megal0maniac (Quit: Konversation terminated!) |
| 19:28:07 | ej0rge | he didn't seem all that megalomaniacal to me . . . |
| 19:28:20 | megal0maniac__ | I'm still here :P |
| 19:28:26 | ej0rge | oh! |
| 19:29:02 | | Join anewuser [0] (~anewuser@190.207.222.122) |
| 19:29:03 | | Quit anewuser (Changing host) |
| 19:29:03 | | Join anewuser [0] (~anewuser@unaffiliated/anewuser) |
| 19:29:28 | ej0rge | megal0maniac__: On an analog EQ, there are intrinsic qualities of the circuitry - such as phase distortion from passing through banks of capacitors - that are unavoidable |
| 19:30:00 | ej0rge | megal0maniac__: software eq *shouldn't have as many intrinsic artifacts. But I am not an expert. |
| 19:30:22 | megal0maniac__ | Different machine. If it's set to 0, but on, then wouldn't it be passing through some sort of algorithm? I haven't seen the source, and wouldn't understand it anyway, but it's the only explanation I can think of. Same is true for Waves plug-ins, but this is done deliberately... So I don't actually know, but that's my 2 cents :) |
| 19:30:54 | ej0rge | megal0maniac__: Sure, but just as your spreadsheet is the same going into a zip file as it is coming out, heavy math doesn't mean that the output changes |
| 19:31:34 | ej0rge | it is, at least, not intrinsic to the method |
| 19:31:41 | megal0maniac__ | Fair point.. What is the audible difference? |
| 19:31:55 | ej0rge | When i turned on the eq, it sounded muffled |
| 19:31:59 | ej0rge | slightly |
| 19:32:09 | ej0rge | treble rolloff was notable |
| 19:33:04 | n1s | ej0rge: the fixed point math isn't perfect so you can't really compare the eq to the zip algo |
| 19:33:06 | ej0rge | It's possible that I've just had so many versions of rockbox on the thing, and played with the eq settings so little, that i had something stuck somewhere that didn't go away until i loaded a preset |
| 19:33:15 | ej0rge | n1s: fair enough |
| 19:33:21 | n1s | it should however not apply any gain for a band if it's set to 0 |
| 19:33:59 | n1s | also note that the beast has both hardware and software eq, i'm not sure how the hw one behaves |
| 19:34:53 | ej0rge | n1s: yeah, me either, but my assumption is that those are implemented in the 'tone controls' menu, like the tone controls on my old H120 |
| 19:35:02 | n1s | nope |
| 19:35:07 | ej0rge | ah |
| 19:35:09 | ej0rge | ok |
| 19:36:35 | ej0rge | well, I have more beasts. I'll see if i can find or force the condition, if the mood strikes me |
| 19:37:11 | n1s | well, you're partially right it's under tone controls but controlled differntly to the usuall bass/treble ones |
| 19:37:47 | n1s | ej0rge: so you're sure all bands have 0 gain and just enabling the eq makes the audio change? |
| 19:40:38 | n1s | and as gevaerts pointed out precut also at 0? |
| 19:41:47 | megal0maniac__ | ATA Error: -2 |
| 19:42:03 | megal0maniac__ | I take it this is not good... |
| 19:44:52 | ej0rge | n1s: That is what i observed |
| 19:45:12 | ej0rge | n1s: but it doesn't seem to do that ever since i loaded the "default" preset |
| 19:45:40 | ej0rge | megal0maniac__: when has an ATA Error been good? |
| 19:49:50 | | Join [Saint] [0] (~Saint]@101.98.158.103) |
| 19:49:51 | | Quit [Saint] (Changing host) |
| 19:49:51 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 20:00 |
| 20:04:38 | | Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) |
| 20:05:15 | * | megal0maniac__ rages |
| 20:05:39 | megal0maniac__ | Seems as though yet another Fuze+'s internal memory has failed |
| 20:06:06 | | Quit remlap (Ping timeout: 240 seconds) |
| 20:16:37 | | Join TheLemonMan [0] (~LemonBoy@adsl-ull-43-248.45-151.net24.it) |
| 20:22:42 | *** | Saving seen data "./dancer.seen" |
| 20:24:22 | preglow | saratoga: i just wouldn't go there |
| 20:24:43 | preglow | saratoga: that kind of upsampling resamplers only work if you can make the upsampling implicit |
| 20:24:47 | preglow | like with polyphase filters |
| 20:25:02 | preglow | with "work" i mean being fast enough |
| 20:26:12 | kugel | is that comparable to SSAA (super sampling anti aliasing)? |
| 20:26:24 | kugel | i mean upscaling then downscaling again? |
| 20:26:47 | preglow | yeah |
| 20:27:01 | preglow | though ssaa synthesizes the scene in its upsampled domain directly |
| 20:27:19 | preglow | instead of starting in one sample rate, then upsampling, then downsampling to yet another rate |
| 20:27:48 | | Quit remlap1 (Quit: Leaving.) |
| 20:27:54 | kugel | right |
| 20:29:25 | preglow | saratoga: using either fir or iir filters for upsampling combined with spline downsampling pretty much requires you to actually calculate all the upsampled samples explicitely before downsampling with a spline again, the performance hit would be huge |
| 20:30:16 | saratoga | preglow: with FIR, you can just compute the output samples your polynomial actually needs right? |
| 20:30:28 | funman | JdGordon: ping |
| 20:30:35 | preglow | saratoga: yeah, but the spline resampler would always need like every other sample, for example |
| 20:30:45 | preglow | saratoga: so you wouldn't be able to craft an optimization around it |
| 20:30:49 | saratoga | yeah, but for 2x thats not too bad |
| 20:30:53 | preglow | wouldn't <- |
| 20:31:23 | saratoga | looking at that paper, it seems like the actual computational expense of oversampling is relatively small compared to the improvement in snr |
| 20:31:30 | saratoga | for low ratios anyway |
| 20:31:33 | saratoga | like 2x or 4x |
| 20:31:50 | preglow | i'm pretty sure you'd be better off just implementing a polyphase sinc resampler, like libsrc or the speex one |
| 20:32:16 | saratoga | the problem with that though is that you need fairly high order to get good results |
| 20:32:25 | preglow | high order for excellent results |
| 20:32:32 | saratoga | if i understand you correctly |
| 20:32:35 | preglow | but good results don't need much |
| 20:32:43 | saratoga | actually, what do you mean by sinc resampler? |
| 20:33:02 | saratoga | upsamplign to the LCM, sinc filtering, and then downsampling? or something else |
| 20:33:12 | preglow | that's the explicit form of it |
| 20:33:26 | preglow | but there's a polyphaseish form of it that's very popular |
| 20:33:35 | preglow | https://ccrma.stanford.edu/~jos/resample/ |
| 20:33:47 | preglow | where the upsampling is implicit |
| 20:33:57 | preglow | well, seems implicit when you calculate it |
| 20:34:13 | saratoga | yes, we have code for doing that on the tracker |
| 20:34:29 | saratoga | its not as efficient as I would like |
| 20:35:31 | saratoga | fs#12223 |
| 20:35:32 | fs-bluebot | http://www.rockbox.org/tracker/task/12223 sinc resampling for rockbox (patches, unconfirmed) |
| 20:35:55 | saratoga | ~25MHz for 48k to 44.1k resampling |
| 20:36:56 | saratoga | the idea of the polynomial filters is that they're quite fast, and with a low degree of oversampling the overhead is much less then upsampling to ~1MHz needed for the sinc method |
| 20:39:12 | saratoga | actually the ASM version of that is much faster |
| 20:40:26 | | Join dhrasmus [0] (~dhrasmus@75-175-2-105.ptld.qwest.net) |
| 20:44:44 | | Quit dhrasmus (Client Quit) |
| 20:45:25 | | Quit saratoga (Ping timeout: 245 seconds) |
| 20:47:19 | preglow | well, the trick with this method of sinc resampling is that you don't need to do that upsampling explicitely |
| 20:48:25 | | Quit TheLemonMan (Quit: WeeChat 0.3.7) |
| 20:48:28 | preglow | but anywho, experimenting is good |
| 20:48:37 | preglow | but you should consider doing said experimentation in matlab :> |
| 20:52:18 | | Join jfc [0] (~Fung@inet-hqmc05-o.oracle.com) |
| 20:54:18 | funman | by the way ffmpeg and libav got 2 competing resampling libraries |
| 20:59:58 | | Quit c3sso (Ping timeout: 260 seconds) |
| 21:00 |
| 21:07:34 | | Join T44 [0] (Topy44@f048224156.adsl.alicedsl.de) |
| 21:09:32 | | Quit Topy44 (Read error: Connection reset by peer) |
| 21:10:48 | | Part eyfour ("WeeChat 0.3.5") |
| 21:11:21 | | Join c3sso [0] (~tux@89.106.213.194) |
| 21:11:46 | | Quit megal0maniac__ (Quit: Ex-Chat) |
| 21:18:40 | | Quit c3sso (Ping timeout: 265 seconds) |
| 21:19:49 | | Join TheLemonMan [0] (~LemonBoy@adsl-ull-43-248.45-151.net24.it) |
| 21:25:19 | | Join dhrasmus [0] (~dhrasmus@75-175-2-105.ptld.qwest.net) |
| 21:30:24 | | Quit benedikt93 (Quit: Bye ;)) |
| 21:45:48 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 21:51:53 | | Join domonoky1 [0] (~Domonoky@agsb-5d871b1d.pool.mediaWays.net) |
| 21:53:14 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
| 21:54:13 | | Quit domonoky (Ping timeout: 260 seconds) |
| 22:00 |
| 22:06:22 | | Join enthdegree [0] (~enthdegre@wikimedia/enthdegree) |
| 22:15:47 | | Quit stripwax (Quit: http://miranda-im.org) |
| 22:18:23 | | Quit preglow (Changing host) |
| 22:18:23 | | Join preglow [0] (thomj@rockbox/developer/preglow) |
| 22:20:38 | | Quit mortalis (Quit: Leaving) |
| 22:22:01 | | Quit enthdegree (Read error: Operation timed out) |
| 22:22:44 | *** | Saving seen data "./dancer.seen" |
| 22:34:18 | | Quit dhrasmus (Quit: Leaving) |
| 22:43:30 | | Quit nosa-j (Read error: Connection reset by peer) |
| 22:44:29 | | Join nosa-j [0] (~m00k@adsl-74-235-42-27.clt.bellsouth.net) |
| 22:48:59 | | Quit stoffel (Remote host closed the connection) |
| 23:00 |
| 23:01:50 | | Quit Rower85 (Quit: Hmmm...) |
| 23:14:15 | | Join Pro7__ [0] (~Pro7@87.254.70.6) |
| 23:19:42 | | Quit nosa-j (Ping timeout: 245 seconds) |
| 23:20:29 | | Join nosa-j [0] (~m00k@adsl-74-235-42-239.clt.bellsouth.net) |
| 23:27:26 | | Quit y4n (Quit: We're fucking 3LN!) |
| 23:30:39 | | Quit FrenchVerbs (Quit: ChatZilla 0.9.88.2 [Firefox 15.0a1/20120506030520]) |
| 23:42:01 | | Join kevku [0] (x@Gizka-1-pt.tunnel.tserv24.sto1.ipv6.he.net) |
| 23:58:24 | | Join Sorrento [0] (~sorrento@c-68-61-186-14.hsd1.mi.comcast.net) |
icon identifies that the person is a core developer (has commit access).