| 00:00:48 | | Join Scall- [0] (~chat@host10-17-static.5-79-b.business.telecomitalia.it) |
| 00:02:01 | mudlord | hi, does the newest git version of rockbox require a bootloader update, when upgrading from 3.13? |
| 00:02:37 | gevaerts | Which player? |
| 00:02:41 | | Quit pamaury (Ping timeout: 240 seconds) |
| 00:03:01 | mudlord | sansa clip zip |
| 00:03:07 | gevaerts | Then no |
| 00:03:15 | | Quit Scall- (Read error: Operation timed out) |
| 00:11:52 | | Quit bertrik (Remote host closed the connection) |
| 00:12:05 | | Quit ender` (Quit: The early bird may get the worm, but the second mouse gets the cheese.) |
| 00:16:18 | | Join Scall| [0] (~chat@host10-17-static.5-79-b.business.telecomitalia.it) |
| 00:17:56 | [Saint] | Generally speaking, if you have to update the bootloader, we'll tell you about it. |
| 00:18:20 | [Saint] | Otherwise, there's pretty much no point in updating the bootloader. |
| 00:20:21 | JdGordon | [Saint]: pong! |
| 00:22:45 | [Saint] | JdGordon: what is supposed to happen with the skin engine (wrt: updating) when the LCD turns off? |
| 00:23:25 | [Saint] | I got some fairly different results with battery benching the WPS with hold on vs the main menu with hold on, making me suspect something was still updating in the background. |
| 00:24:00 | [Saint] | (fallback WPS with peak meters {during playback} vs. fallback sbs in main menu) |
| 00:25:31 | JdGordon | umm, really straining my memory here |
| 00:28:00 | [Saint] | I had a brief look, but I got lost very quickly, and I didn;t want to assume that whatever the code said should happen was actually happening. |
| 00:40:56 | * | [Saint] seriously wonders if cooltwou is just having a giant laugh at our expense |
| 00:58:14 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131118212339]) |
| 01:00 |
| 01:05:25 | | Join treaki_ [0] (b69e7d54b3@p4FF4AE2D.dip0.t-ipconnect.de) |
| 01:07:46 | | Quit treaki (Ping timeout: 252 seconds) |
| 01:08:03 | | Join DuperMan [0] (woland@93-172-221-152.bb.netvision.net.il) |
| 01:08:19 | DuperMan | w00t where' malauy |
| 01:12:49 | [Saint] | Lets try to A - use real, English words and B - stay on topic, please. |
| 01:13:24 | JdGordon | [Saint]: umm, i think depending on the target, some will/should update in the background and most should not |
| 01:13:50 | JdGordon | what results are you seeing? |
| 01:14:09 | [Saint] | JdGordon: I thought as much based solely on runtimes, it made a measurable difference. |
| 01:14:18 | [Saint] | (around 2 hours less) |
| 01:14:30 | JdGordon | in the wps? |
| 01:14:41 | JdGordon | which target? |
| 01:14:58 | [Saint] | Yeah, wps vs. lists. |
| 01:15:01 | [Saint] | iPod Video. |
| 01:15:28 | JdGordon | peak meters enabled anywhere? |
| 01:15:41 | [Saint] | Yes. fallback wps. |
| 01:16:07 | [Saint] | But I was thinking with hold on and the LCD disabled, that shouldn;t matter. Guess I was wrong. |
| 01:16:32 | [Saint] | (hold isn;t necessarily relevant here, I just have my targets set to sleep the LCD immediately on hold) |
| 01:17:56 | [Saint] | I guess updating in the background is to avoid showing stale information (however briefly) when the targets wakes the LCD? |
| 01:19:12 | JdGordon | yeah, peakmeters are drawn (and refresh rate == 25HZ) any time the peak meter is neabled |
| 01:19:17 | JdGordon | regardless of lcd state |
| 01:19:20 | JdGordon | so thats a bug |
| 01:19:42 | [Saint] | Aha. Good to know. |
| 01:19:47 | JdGordon | im not sure the wps is updated even in this case |
| 01:20:32 | [Saint] | Well, that gives me more of a reason to remove the peak meters from the fallbac wps then I guess. |
| 01:20:51 | [Saint] | But, it would be nicer if it just stopped updating when the LCD was powered down. |
| 01:21:15 | [Saint] | Not /quite/ sure how to achieve that, I'll have a look this evening. |
| 01:21:59 | [Saint] | The runtime gave me the impression that something was pegging the CPU, nice to know I was on the right track. |
| 01:22:02 | JdGordon | should be really easy |
| 01:22:23 | JdGordon | skin_wait_for_action(), in there check the lcd is awake |
| 01:22:51 | JdGordon | it *may* need to be forced to do a full update when the lcd is reactivated (though i have a feeling this is done automatically anyway) |
| 01:23:01 | [Saint] | Does that also need special handling for remotes, or should that "Just Work"? |
| 01:23:25 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 01:23:55 | [Saint] | And, yes. I believe you're correct, I seem to recall a fullscreen update being forced when waking the LCD. |
| 01:26:32 | | Nick SuperBrainAk is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) |
| 01:27:32 | | Quit Scall| (Ping timeout: 272 seconds) |
| 01:27:49 | | Join Scall [0] (~chat@unaffiliated/scall) |
| 01:29:33 | JdGordon | you'd need to do some benchmarking |
| 01:29:57 | JdGordon | I'm guessing the sleep(0) is what is actually killing the battery more than the skin drawing |
| 01:30:26 | JdGordon | that function draws both displays, so you'd need to have it check if either are visible to keep the PM active |
| 01:30:57 | [Saint] | Hmmm. Possibly. But realistically, it makes absolutely zero sense to continue updating when the LCD is powered down. |
| 01:31:09 | [Saint] | And, yes. |
| 01:31:11 | JdGordon | I did a benchmark before the customsbs code and found there was no measurable difference between the skin engine and the regular lcd functions so drawing the menu screen |
| 01:37:36 | *** | Saving seen data "./dancer.seen" |
| 01:43:51 | DuperMan | I BUILD ZEN STUFSS |
| 01:43:54 | DuperMan | HOO RAY |
| 01:43:56 | DuperMan | ) |
| 01:43:58 | DuperMan | :) |
| 01:44:14 | DuperMan | all from other's code o'course |
| 01:50:31 | Mode | "#rockbox +o JdGordon" by ChanServ (ChanServ@services.) |
| 01:50:53 | Kick | (#rockbox DuperMan :#rockbox bye!) by JdGordon!cb1380e2@rockbox/developer/JdGordon |
| 01:50:54 | | Join DuperMan [0] (woland@93-172-221-152.bb.netvision.net.il) |
| 01:50:54 | | Quit fs-bluebot (Read error: Connection reset by peer) |
| 01:51:17 | | Part JdGordon ("DuperMan bye!") |
| 01:51:22 | | Join JdGordon [0] (cb1380e2@rockbox/developer/JdGordon) |
| 02:00 |
| 02:04:15 | | Join Strife89 [0] (~Strife89@adsl-98-80-224-53.mcn.bellsouth.net) |
| 02:10:05 | | Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) |
| 02:14:18 | | Quit pixelma (Remote host closed the connection) |
| 02:14:18 | | Quit amiconn (Remote host closed the connection) |
| 02:15:38 | | Join pixelma [0] (pixelma@rockbox/staff/pixelma) |
| 02:15:38 | | Join amiconn [0] (amiconn@rockbox/developer/amiconn) |
| 02:38:54 | mudlord | forgive me for this: https://github.com/Rockbox/rockbox/blob/c4f2a46e0dfee336ce7016cd62608097f15367b8/lib/rbcodec/codecs/libwmavoice/wmavoice.c but I thought floats were illegal |
| 02:39:05 | mudlord | I was wondering as I was wanting to do some graphics stuff using Pi |
| 02:39:21 | mudlord | for example: a C64 style twister demo |
| 02:44:02 | | Quit foolsh (Remote host closed the connection) |
| 02:46:10 | | Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) |
| 02:56:52 | | Quit cmhobbs (Ping timeout: 248 seconds) |
| 03:00 |
| 03:08:48 | | Join amayer [0] (~amayer@h222.56.21.98.dynamic.ip.windstream.net) |
| 03:10:10 | | Part mudlord |
| 03:11:02 | | Quit funman (Ping timeout: 272 seconds) |
| 03:12:07 | | Join funman [0] (~fun@chui-pas.net) |
| 03:28:39 | saratoga | mudlord: libwmavoice is disabled |
| 03:29:07 | saratoga | mt ported the decoder when he did wma pro, but didn't finish porting it to fixed point |
| 03:29:46 | | Quit Scall (Ping timeout: 272 seconds) |
| 03:30:52 | [Saint] | He be gooooooone, yo. |
| 03:37:40 | *** | Saving seen data "./dancer.seen" |
| 03:39:00 | | Quit SrRaven (Ping timeout: 248 seconds) |
| 03:42:10 | | Join SrRaven [0] (srraven@fatfecker.shagged.org) |
| 03:44:48 | | Join Scall [0] (~chat@unaffiliated/scall) |
| 03:51:14 | | Quit Scall (Ping timeout: 245 seconds) |
| 03:53:46 | | Quit amayer (Quit: Leaving) |
| 04:00 |
| 04:33:41 | | Quit pixelma (Disconnected by services) |
| 04:33:42 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:33:44 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:33:44 | | Quit amiconn (Disconnected by services) |
| 04:33:44 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:33:49 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:39:52 | | Join Scall- [0] (~chat@host10-17-static.5-79-b.business.telecomitalia.it) |
| 04:44:07 | | Quit Scall- (Ping timeout: 252 seconds) |
| 04:52:49 | | Nick DormantBrain is now known as SuperBrainAk (~andy@2001:470:8:a61::5f92:59a1) |
| 05:00 |
| 05:08:13 | | Quit [7] (Disconnected by services) |
| 05:08:26 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 05:37:44 | *** | Saving seen data "./dancer.seen" |
| 05:49:22 | | Join Scall [0] (~chat@unaffiliated/scall) |
| 05:53:48 | | Quit Scall (Ping timeout: 246 seconds) |
| 06:00 |
| 06:11:55 | | Join kugel [0] (~kugel@91-66-52-103-dynip.superkabel.de) |
| 06:11:55 | | Quit kugel (Changing host) |
| 06:11:55 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 06:13:20 | | Quit kiwicam (Remote host closed the connection) |
| 06:17:13 | | Quit kugel (Ping timeout: 245 seconds) |
| 06:22:45 | | Join kiwicam [0] (~quassel@121.99.176.30) |
| 06:27:58 | | Nick x56 is now known as everybody (~0x56@sillytitties.com) |
| 06:28:06 | | Nick everybody is now known as x56 (~0x56@sillytitties.com) |
| 06:39:52 | | Join Scall [0] (~chat@unaffiliated/scall) |
| 06:44:43 | | Quit Scall (Ping timeout: 245 seconds) |
| 07:00 |
| 07:00:10 | | Quit Strife89 (Ping timeout: 246 seconds) |
| 07:16:37 | | Quit akaWolf (Ping timeout: 248 seconds) |
| 07:17:55 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 07:37:47 | *** | Saving seen data "./dancer.seen" |
| 07:52:46 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
| 07:55:14 | | Join mortalis [0] (~kvirc@213.33.220.118) |
| 08:00 |
| 08:22:50 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 08:32:55 | | Join wodz_ [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 08:32:55 | | Quit wodz (Read error: Connection reset by peer) |
| 08:34:16 | | Quit funman (Changing host) |
| 08:34:16 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 08:35:32 | | Join LinusN [0] (linus@giant.haxx.se) |
| 08:44:33 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:49:54 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 09:00 |
| 09:07:40 | | Quit kevku (Ping timeout: 245 seconds) |
| 09:21:06 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 09:21:16 | | Quit bertrik (Remote host closed the connection) |
| 09:23:56 | | Join petur [0] (5bb7304d@rockbox/developer/petur) |
| 09:23:59 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 09:37:50 | *** | Saving seen data "./dancer.seen" |
| 09:39:11 | | Nick pookie_ is now known as olspookishmagus (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 09:53:52 | | Quit amiconn (Remote host closed the connection) |
| 09:53:52 | | Quit pixelma (Read error: Connection reset by peer) |
| 09:55:07 | | Join pixelma [0] (pixelma@rockbox/staff/pixelma) |
| 09:55:07 | | Join amiconn [0] (amiconn@rockbox/developer/amiconn) |
| 10:00 |
| 10:02:45 | | Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) |
| 10:14:55 | | Join maruk [0] (~papier@titanium.v6.sdv.fr) |
| 10:22:28 | | Nick SuperBrainAk is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) |
| 11:00 |
| 11:31:23 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:32:15 | copper | pamaury: did you get my battery benchmark? |
| 11:35:36 | pamaury | can you post the link again ? I didn't download the file |
| 11:36:23 | copper | 17:36:53 UTC <copper> pamaury: fuze+ battery benchmark, LAME V0, -20 dB, earbuds attached: https://outpost.fr/tmp/laE.txt |
| 11:37:53 | *** | Saving seen data "./dancer.seen" |
| 11:37:57 | pamaury | thanks |
| 11:37:58 | copper | weren't you guys talking about 40h battery life for the Fuze+, a while ago? |
| 11:38:10 | pamaury | I reached 35h some while ago |
| 11:38:25 | wodz_ | pamaury: The device doesn't respond to the repeated HWSTUB_INFO_TARGET request. |
| 11:38:26 | pamaury | someone reported 43h but that was without headphones so I'm not sure it counts |
| 11:38:45 | pamaury | I'm going to battery bench a few older revisions to see if there was a regression |
| 11:39:01 | wodz_ | pamaury: I mean rk27xx hwstub |
| 11:39:22 | pamaury | wodz_: but it answers to different requests ? (target, version, ...) |
| 11:39:48 | copper | I'm current benching my Classic with a year old build, and at 46% right now, it's been running for 16 hours, versus 12 hours for yesterday's benchmark (with the latest build) |
| 11:40:18 | copper | either the calibration is different, or there is indeed a battery life regression. We'll see when the benchmark completes. |
| 11:41:56 | wodz_ | pamaury: I tried only this one so don't know |
| 11:42:18 | copper | currently* |
| 11:42:52 | wodz_ | pamaury: When hwstub_shell starts it sends HWSTUB_INFO_TARGET and get correct response. |
| 11:43:15 | wodz_ | but sending it again after initialization doesn't work |
| 11:43:31 | wodz_ | so the device part is locked for some reason |
| 11:44:57 | pamaury | that's puzzling because the shell sends 4 requests on init: version, target, layout and features |
| 11:45:11 | wodz_ | and all this requests are handled correctly |
| 11:45:56 | pamaury | did you check with wireshark ? Maybe an invalid requests which get STALLED for whatever reason and the core is locked ? |
| 11:46:21 | wodz_ | pamaury: the repeated request looks exactly the same |
| 11:48:49 | wodz_ | pamaury: I vaguely remember the core being odd in handling some parts of the usb protocol. You made some changes to the usb core in rockbox to accomodate. Maybe this is related. |
| 11:48:50 | wodz_ | ? |
| 11:49:34 | pamaury | I need to read your code and the code of the whole driver to remember |
| 11:50:45 | pamaury | hum, why is there no code in your usb_drv_init() ? |
| 11:52:42 | wodz_ | in rb driver it configures only semaphores |
| 11:53:29 | pamaury | yeah but rockbox you control the whole state, here you should at leat soft disconnect and reconnect no ? |
| 11:53:38 | pamaury | depends on how you run it of course |
| 11:53:43 | pamaury | but in doubt |
| 11:55:23 | | Join lorenzo92 [0] (~chatzilla@95.237.104.88) |
| 11:56:25 | wodz_ | pamaury: Hmm you might be right. The core hard reset and soft reconnect is handled in usb connect interrupt BUT now I recall it didn't fire properly. |
| 11:57:20 | pamaury | wodz_: do you recall why we need "while (TX0BUF & TXFULL) /* TX0FULL flag */;" in ctr_write() ? |
| 11:58:10 | lorenzo92 | pamaury: found the audio issue, it was the gate pin is not active high but active low ;) |
| 11:58:29 | wodz_ | pamaury: not really |
| 11:58:31 | pamaury | lorenzo92: good :) easy fix |
| 11:58:36 | lorenzo92 | yep |
| 11:59:12 | lorenzo92 | pamaury: WTF I hear a horrible noise when touching the touch pad xD I think there are still some electrical issues haha |
| 11:59:39 | lorenzo92 | only when FM radio is enable, so I think the mux is either not correct or somthing similar |
| 11:59:43 | wodz_ | TX0FULL: Transmit Buffer status Indicate one packet has been written and available to be transmitted in the data registers, will be cleared by the UDC 2.0 for a successful IN transaction when receive ACK from UDC 2.0. |
| 11:59:50 | wodz_ | quoting doc |
| 12:00 |
| 12:03:42 | lorenzo92 | pamaury: and I actually don't hear any FM, chip is initialized and I see registers, but I'm unsure it is working hum |
| 12:04:09 | pamaury | lorenzo92: then how can you say sound working ?! |
| 12:04:35 | lorenzo92 | pamaury: the trick is the keyclick :D |
| 12:04:46 | lorenzo92 | awful but great while debugging |
| 12:05:23 | lorenzo92 | pamaury: now I have a look at the schematics and see if tuner needs the internal clock or has an external one.. |
| 12:08:15 | pamaury | wodz_: I'm puzzled by ctr_read() |
| 12:08:30 | pamaury | shouldn't the buf address by incremented *after* being written to the register ? |
| 12:09:01 | wodz_ | let me see |
| 12:09:21 | pamaury | and no, you don't use ctr_read() for the first read |
| 12:09:24 | | Join Scall- [0] (~chat@host10-17-static.5-79-b.business.telecomitalia.it) |
| 12:09:24 | pamaury | *ah no |
| 12:09:43 | pamaury | any reason for this ? |
| 12:09:53 | lorenzo92 | pamaury: now I understand, I missed the XTAL configuration, let me try again |
| 12:11:11 | pamaury | wodz_: I seem to recall in hwstub the usb_drv_recv() function is supposed to be blocking |
| 12:11:50 | wodz_ | pamaury: ctr_read() is called in irq. It is just helper function. |
| 12:11:59 | wodz_ | pamaury: oh, that might be the case then |
| 12:12:11 | pamaury | wodz_: why don't you use it in usb_drv_recv() too ? |
| 12:13:06 | pamaury | anyway that doesn't example the bug, these transfers only send things, not receive |
| 12:13:12 | wodz_ | Because of the sequence of buffer increment. in usb_drv_recv() you need to prime transfer in isr you need to point to the next block |
| 12:13:36 | pamaury | you could increment buffer pointer after the write to the register ?! |
| 12:13:52 | pamaury | ah no, you cannot control the receive size |
| 12:13:59 | pamaury | I forgot this core is dumb |
| 12:14:24 | wodz_ | I can't remember the details but I was unable to find sane solution other then this |
| 12:15:02 | lorenzo92 | dammit /* save binsize by only detecting presence for targets where it may be absent */ |
| 12:15:13 | lorenzo92 | I was sure that the chip was on in this way ^^ |
| 12:19:03 | pamaury | wodz_: I don't see anything else wrong |
| 12:19:04 | lorenzo92 | pamaury: got the problem. I confused the power pin vs the pin that tells me if radio is present or not ^^ |
| 12:19:39 | pamaury | I'll try with the usb analyser tonight |
| 13:00 |
| 13:02:30 | lorenzo92 | pamaury: fm radio works !! :) |
| 13:03:02 | lorenzo92 | there is a bug in the tea chip driver, because it does not turn on radio before probing it, anyone here to explain why? |
| 13:03:17 | wodz_ | lorenzo92: which target? Z5? |
| 13:03:38 | lorenzo92 | wodz_: not only, all target using the chip |
| 13:03:40 | lorenzo92 | i.e. |
| 13:03:51 | lorenzo92 | ondavx |
| 13:03:56 | pamaury | lorenzo92: are you using HEAD ? |
| 13:03:59 | lorenzo92 | indeed |
| 13:04:04 | pamaury | because I fixed such a bug recently |
| 13:04:14 | pamaury | And I'm pretty sure it was in a tea driver |
| 13:04:24 | lorenzo92 | hum |
| 13:04:30 | lorenzo92 | I synced yesterday |
| 13:04:42 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
| 13:05:11 | lorenzo92 | pamaury: HUGE bug in audio volume, at some point lowering it I got full output, you can imagine xD |
| 13:05:23 | pamaury | see commit 0463bf4cb252a7719feec4d7fede0e960ed876ed |
| 13:05:29 | pamaury | it was tea5760uk driver |
| 13:05:40 | lorenzo92 | I'm using the other variant |
| 13:06:06 | pamaury | it's a bug then |
| 13:06:19 | lorenzo92 | exactly the same, I'll do a gerrit for it now |
| 13:06:27 | lorenzo92 | or you do it? |
| 13:07:17 | pamaury | push something to gerrit, I'll review it |
| 13:07:33 | lorenzo92 | okay |
| 13:16:22 | lorenzo92 | g#670 |
| 13:17:09 | lorenzo92 | pamaury: I don't remember the command to yell a gerrit haha, anyways here you are |
| 13:17:12 | ikeboy | dealfisher has a 4GB clip and 8GB microsd card for 26.99 if anyones interested here: http://www.dealfisher.com/product/SanDisk-Sansa-Clip-4-GB-MP3-Player-and-8GB-microSD-Card.html |
| 13:17:32 | ikeboy | in dollars |
| 13:17:50 | lebellium | #g670 |
| 13:17:55 | copper | Does anyone here NOT own a Clip+ already? ;-) |
| 13:18:56 | ikeboy | I don't |
| 13:22:21 | | Quit ikeboy (Quit: ikeboy) |
| 13:36:12 | | Join pretty_function [0] (~sigBART@123.252.214.106) |
| 13:37:54 | *** | Saving seen data "./dancer.seen" |
| 13:39:54 | | Join OrIWillChecklogs [0] (~random-na@87.254.78.201) |
| 13:40:12 | | Quit OrIWillChecklogs (Client Quit) |
| 13:41:05 | | Join OrIWillChecklogs [0] (~random-na@87.254.78.201) |
| 13:41:41 | | Quit OrIWillChecklogs (Read error: Connection reset by peer) |
| 13:58:36 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
| 14:00 |
| 14:24:25 | pamaury | lebellium: " g#670" should print the details but the bot is dead apparently |
| 14:25:05 | lebellium | yeah that's what we concluded with lorenzo92 :) |
| 14:26:20 | pamaury | oops I reviewed but did not publish |
| 14:27:09 | | Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) |
| 14:31:20 | | Quit wodz_ (Quit: Leaving) |
| 14:32:39 | lorenzo92 | pamaury: thanks :) |
| 14:37:09 | | Quit krabador (Quit: Sto andando via) |
| 14:42:29 | | Quit mortalis (Ping timeout: 245 seconds) |
| 14:42:36 | | Join dfkt [0] (OxO29A@unaffiliated/dfkt) |
| 14:52:34 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 15:00 |
| 15:00:37 | | Quit cmhobbs (Ping timeout: 248 seconds) |
| 15:08:30 | | Join Strife89 [0] (~Strife89@adsl-98-80-224-53.mcn.bellsouth.net) |
| 15:18:43 | | Quit kevku (Ping timeout: 260 seconds) |
| 15:31:40 | | Join treaki__ [0] (~treaki@p4FF4B07C.dip0.t-ipconnect.de) |
| 15:33:27 | | Quit treaki_ (Ping timeout: 264 seconds) |
| 15:37:58 | *** | Saving seen data "./dancer.seen" |
| 15:39:36 | | Quit Scall- (Quit: Bye bye) |
| 15:41:46 | | Join hashbang [0] (~isajb@cse-ajb.cse.bris.ac.uk) |
| 15:41:51 | hashbang | hiya there |
| 15:45:24 | | Join Scall [0] (~chat@unaffiliated/scall) |
| 15:45:47 | pamaury | hashbang: if you have a question, please ask and if someone know he/she will answer |
| 15:46:38 | hashbang | I've just upgraded from an old version of RB to 3.12. Will 3.13 work on the h3xx, or does the 10 band advanced EQ require a faster CPU? |
| 15:48:03 | gevaerts | 3.13 will work just fine |
| 15:48:26 | gevaerts | I don't know if the h300 can handle ten bands, but then you don't have to use them all |
| 15:48:51 | gevaerts | In fact, usually if you need more than four or five, you're probably misunderstanding how a parametric EQ works |
| 15:49:24 | hashbang | gevaerts: I'd probably only use the presets - but they seem to use all the EQ bands |
| 15:49:41 | hashbang | gevaerts: or am I mis-reading the preset files? |
| 15:50:10 | copper | gevaerts: can you expand on that? |
| 15:56:02 | gevaerts | hashbang: you aren't. Those presets (i.e. the ones in 3.13) were a mistake, and current builds don't include them any more. |
| 15:56:29 | gevaerts | So if I were you, I'd save the old (3.12) ones somewhere and put them back after installing 3.13 |
| 15:57:08 | gevaerts | copper: see e.g. http://git.rockbox.org/?p=rockbox.git;a=commit;h=d475dd36a3702231fc76ef4dfdf771acbc730423 |
| 15:57:20 | hashbang | gevaerts: aha, that makes sense. I understand the extra bands only use CPU if they're actually enabled, so 3.13 with 3.12 presets will use same CPU as 3.12 by itself. |
| 15:58:19 | copper | gevaerts: I don't understand what's wrong with using 10 bands with different values? |
| 15:58:43 | gevaerts | copper: nothing's *wrong* with doing that, it's just probably a waste of CPU |
| 15:59:08 | gevaerts | With a parametric EQ you can adjust the width of a band |
| 15:59:41 | copper | I don't see the relation between the width of 5 bands, and using 10 bands with refined tuning |
| 16:00 |
| 16:00:50 | gevaerts | copper: most people who claimed they wanted more than five bands really meant they wanted to be able to copy the config from some non-parametric system with fixed bands |
| 16:01:04 | copper | that would be my case, yes |
| 16:01:19 | gevaerts | And while you *can* do that now, you |
| 16:01:33 | copper | I guess I don't understand what "parametric" and "band width" means |
| 16:02:03 | gevaerts | 're really better off studying a bit and making a simpler config, if you care about battery life (and therefotre CPU usage) |
| 16:02:36 | * | gevaerts isn't a specialist either |
| 16:03:19 | copper | gah, this needs a converter |
| 16:04:07 | gevaerts | copper: look at e.g. http://en.wikipedia.org/wiki/File:Graphic_equalizer.jpg (only one side for now, let's ignore the stereo bit). That's a non-parametric EQ, so you need lots and lots of sliders. For the adjustment shown on that photo, a parametric EQ probably only needs one band |
| 16:04:31 | gevaerts | And yes, we could really use a graphical representation of what the eq is set to |
| 16:04:35 | copper | yes because that's single curve |
| 16:06:03 | copper | with few data points |
| 16:06:08 | hashbang | http://gerrit.rockbox.org/r/#/c/401/ # the EQ presets on gerrit that need some work? |
| 16:06:21 | copper | parameters, whatever it's called |
| 16:07:26 | gevaerts | hashbang: I believe that that's the one that went into 3.13 and was removed again later |
| 16:07:59 | gevaerts | Or at least, a related one |
| 16:08:01 | * | gevaerts isn't sure |
| 16:08:21 | gevaerts | Ah, yes. A related one |
| 16:09:50 | * | gevaerts won't go into the issue of whether the entire concept of "genre"-specific EQ presets makes any sense at all :) |
| 16:10:18 | copper | https://outpost.fr/tmp/gSw.png |
| 16:10:22 | hashbang | gevaerts: probably ought to be based on output device (e.g. headphone model) + bass/treble |
| 16:10:29 | copper | that would be like 2 parametric bands, right? |
| 16:10:39 | hashbang | gevaerts: so use EQ to get flat response, then use bass and treble to taste |
| 16:10:59 | gevaerts | hashbang: that's what I'd say, yes. Not everyone agrees though |
| 16:11:27 | gevaerts | copper: I think so, yes |
| 16:11:35 | pamaury | copper: what is the audio player on this capture ? |
| 16:11:35 | copper | kay, I'll try to figure it out |
| 16:11:50 | copper | pamaury: https://code.google.com/p/quodlibet/ |
| 16:12:25 | pamaury | ah yeah, heard about it some time ago, some people told me that it is very good, is it the case ? |
| 16:12:40 | copper | love it |
| 16:13:20 | copper | https://outpost.fr/tmp/kWF.png |
| 16:14:01 | copper | pamaury: I particularly like internal and conditional tags |
| 16:14:14 | copper | and regex search capabilities |
| 16:14:24 | copper | https://quodlibet.readthedocs.org/en/latest/guide/tags/index.html |
| 16:14:37 | | Quit pretty_function (Remote host closed the connection) |
| 16:15:04 | | Join pretty_function [0] (~sigBART@123.252.214.106) |
| 16:17:15 | | Quit Strife89 (Ping timeout: 264 seconds) |
| 16:17:28 | | Quit Zagor (Quit: Clint excited) |
| 16:19:39 | | Quit pretty_function (Ping timeout: 264 seconds) |
| 16:28:14 | hashbang | gevaerts: thanks for the clarification and the tip to restore the 3.12 eq presets. :-) |
| 16:28:59 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
| 17:00 |
| 17:00:17 | | Quit Zarggg (Quit: Zarggg) |
| 17:00:54 | pamaury | copper: is your Fuze+ available for another benchmark ? |
| 17:01:05 | copper | yup |
| 17:02:21 | pamaury | can you do a benchmark for a particular revision ? |
| 17:02:52 | copper | yarp |
| 17:04:37 | pamaury | ok, let me have a look, currently I'm benchmarking a commit as of january |
| 17:07:26 | pamaury | copper: this one c4f2a46e0dfee336ce7016cd62608097f15367b8 |
| 17:07:56 | copper | that commit sounds rather familiar :P |
| 17:08:18 | copper | same codec and volume? |
| 17:08:30 | copper | LAME V0, -20 dB? |
| 17:09:56 | pamaury | yeah |
| 17:10:02 | copper | ok, will let you know |
| 17:10:14 | pamaury | yeah I thought I would spare you the 0.1dB volume bug ^^ |
| 17:15:37 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
| 17:16:39 | | Join Strife89 [0] (~Strife89@2602:306:250e:659:d559:5f8e:7e2:3b71) |
| 17:18:23 | | Quit mc2739 (Ping timeout: 246 seconds) |
| 17:18:39 | | Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) |
| 17:20:31 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 17:25:52 | copper | I hope you'll find something: those battery benchmarks are slow |
| 17:26:25 | copper | (and possibly taxing for the battery?) |
| 17:26:43 | | Join Narod [0] (Narod@p5DDDBB69.dip0.t-ipconnect.de) |
| 17:27:34 | saratoga | hashbang: the problem with the old presets is that they don't make a lot of sense for how our EQ works, and they are very inefficient |
| 17:28:47 | | Quit Narod (Client Quit) |
| 17:29:14 | | Join Narod [0] (Narod@p5DDDBB69.dip0.t-ipconnect.de) |
| 17:30:15 | pamaury | copper: I don't think a benchmark or two will damage your battery |
| 17:30:23 | pamaury | just don't leave it in a very discharged state |
| 17:30:30 | copper | ok |
| 17:30:46 | saratoga | yeah we should be cutting off the battery before it really gets that low |
| 17:32:04 | pamaury | it shut down at 3.3V |
| 17:35:54 | | Quit petur (Quit: Page closed) |
| 17:37:59 | *** | Saving seen data "./dancer.seen" |
| 17:57:48 | | Quit hashbang (Quit: Leaving.) |
| 18:00 |
| 18:03:41 | | Join pretty_function [0] (~sigBART@123.252.214.106) |
| 18:07:46 | | Join fs-bluebot [0] (~fs-bluebo@g225254054.adsl.alicedsl.de) |
| 18:07:46 | fs-bluebot | Build Server message: New build round started. Revision adc5033, 243 builds, 36 clients. |
| 18:08:40 | bluebrother | only that that round has been finished long ago ... |
| 18:08:46 | * | bluebrother needs to fix the bot |
| 18:10:52 | lorenzo92 | ...otherwise everyone feels like don't remembering how to ^^ |
| 18:10:53 | lorenzo92 | :D |
| 18:11:17 | bluebrother | never thought that bot would live that long :) |
| 18:12:15 | | Quit krabador (Quit: Sto andando via) |
| 18:17:00 | lorenzo92 | pamaury: refactor done! i'm going to gerritize it soon |
| 18:21:39 | | Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:21:40 | | Quit bertrik (Changing host) |
| 18:21:40 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 18:31:39 | | Part maruk |
| 18:37:09 | lorenzo92 | pamaury: gerritized ;) |
| 18:37:44 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 18:38:07 | | Part LinusN |
| 18:39:26 | pamaury | lorenzo92: why does your patch reports a diff to powermgmt-imx233.c with empty diff ? |
| 18:40:13 | pamaury | lorenzo92: you declare your target as having HOLD but you didn't put any value in the table for hold |
| 18:40:55 | pamaury | and the {0, IMX233_BUTTON_LRADC_END} is incorrect, it should be the default value of lradc when there is no button (probably 3300 or something) |
| 18:41:16 | pamaury | and hold is probably 0 so add {0, IMX233_BUTTON_LRADC_HOLD} at the beginning of the table |
| 18:42:18 | pamaury | also why do you declare fmradio i2c as harware but set sw defines ? is it software or hardware ?! |
| 18:45:41 | | Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) |
| 18:47:06 | lorenzo92 | pamaury: for the diff, no idea, I'll look into it |
| 18:47:18 | lorenzo92 | for the hold button hum, my hold button is gpio based |
| 18:47:24 | lorenzo92 | not lradc based |
| 18:47:40 | pamaury | ah sorry, I misread |
| 18:47:50 | pamaury | my comment still apply to the last line of the table though |
| 18:48:29 | lorenzo92 | pamaury: for radio, indeed, I placed the pins only for testing :) |
| 18:53:55 | | Quit linuxguy3 (Ping timeout: 245 seconds) |
| 19:00 |
| 19:27:41 | copper | note to self: it's easier to set positive gain in the EQ and compensate with adequate precut |
| 19:38:02 | *** | Saving seen data "./dancer.seen" |
| 19:45:21 | copper | gevaerts: alright, I think I managed to convert my desktop EQ with just the low and high shelf filters :) |
| 19:45:56 | copper | it's a rather simple V shaped EQ anyway |
| 19:46:01 | | Quit Narod () |
| 19:49:29 | | Quit pretty_function (Remote host closed the connection) |
| 19:49:56 | | Join pretty_function [0] (~sigBART@123.252.214.106) |
| 19:54:29 | | Quit pretty_function (Ping timeout: 246 seconds) |
| 20:00 |
| 20:04:10 | copper | yup, sounds like my desktop \o/ |
| 20:29:08 | | Quit pamaury (Ping timeout: 248 seconds) |
| 20:37:05 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 20:49:58 | | Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) |
| 20:50:03 | | Quit einhirn (Client Quit) |
| 21:00 |
| 21:03:01 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 21:09:14 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
| 21:16:13 | | Join Strife89 [0] (~Strife89@2602:306:250e:659:f9bb:d536:26f4:b5ca) |
| 21:21:51 | | Quit krnlyng (Ping timeout: 246 seconds) |
| 21:23:59 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 21:24:27 | | Quit shai (Read error: Connection reset by peer) |
| 21:33:23 | | Quit rela (Read error: Connection reset by peer) |
| 21:38:06 | *** | Saving seen data "./dancer.seen" |
| 21:40:34 | | Quit gelraen (Read error: Connection reset by peer) |
| 21:40:42 | | Join gelraen [0] (~imax@lab.biomed.kiev.ua) |
| 22:00 |
| 22:04:36 | | Quit fs-bluebot (Ping timeout: 248 seconds) |
| 22:05:15 | | Quit bluebrother (Ping timeout: 246 seconds) |
| 22:06:25 | | Quit ikeboy (Quit: ikeboy) |
| 22:07:13 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 22:10:09 | | Quit lorenzo92 (Remote host closed the connection) |
| 22:11:15 | | Nick DormantBrain is now known as SuperBrainAk (~andy@2001:470:8:a61::5f92:59a1) |
| 22:11:37 | | Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) |
| 22:29:27 | wodz | pamaury: ping |
| 22:30:29 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 22:33:42 | | Join krnlyng [0] (~liar@83.175.90.24) |
| 22:39:33 | Ctcp | Ping from gevaerts!~fg@rockbox/developer/gevaerts |
| 22:43:25 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 22:49:34 | | Quit mc2739 (Quit: leaving) |
| 22:52:44 | pamaury | wodz: pong |
| 22:54:03 | wodz | pamaury: What I found interesting is that according to wireshark the last request send to device before things go wrong is SET_FEATURE |
| 22:54:52 | wodz | this set feature seems to ask to enter test_mode |
| 22:57:17 | pamaury | hum, very strange |
| 22:57:27 | pamaury | are you sure it is sent the device ? |
| 22:57:43 | pamaury | *to the |
| 22:58:22 | pamaury | have you tried to run the code with valgrind ? maybe there is a memory corruption happening |
| 22:59:39 | wodz | pamaury: what is the meaning of 'Protocol' field in wireshark? |
| 22:59:49 | wodz | I mean USB vs USBHUB |
| 23:00 |
| 23:01:12 | pamaury | usbhub means the requests was sent to a hub |
| 23:01:46 | pamaury | usually set_features is used on hub to reset devices for example |
| 23:02:02 | wodz | ok so this is SET_FEATURE is irrelevant |
| 23:02:17 | pamaury | probably except if it sent to this device specifically |
| 23:02:18 | wodz | anyway the device simply stops responding |
| 23:03:08 | pamaury | what is the lates requests sent ? get_version ? |
| 23:03:28 | pamaury | sorry get target ? |
| 23:04:16 | wodz | sucessfull or failing? |
| 23:04:24 | pamaury | successful |
| 23:05:16 | wodz | HWSTUB_INFO_TARGET |
| 23:05:47 | pamaury | I'm asking this because the HWSTUB_INFO_TARGET is special: its buffer stage is 64-bytes exactly, that's one packet |
| 23:05:57 | pamaury | so maybe the driver is getting confused in some way |
| 23:06:21 | pamaury | maybe the core doesn't notify the completion of the ZLP packet for example |
| 23:06:35 | pamaury | and the code gets stuck |
| 23:06:59 | | Quit bertrik (Remote host closed the connection) |
| 23:07:31 | wodz | how to change request size so it will be 63 for example? |
| 23:08:08 | pamaury | in hwstub_protocol.h, edit the usb_resp_info_target_t structure |
| 23:08:14 | pamaury | be sure to recompile both the stub and the tool |
| 23:08:20 | pamaury | using make clean |
| 23:08:29 | pamaury | (my makefile doesn't track dependencies correctly) |
| 23:12:41 | wodz | yeah that is the problem |
| 23:13:00 | wodz | I reduced name[] to 40 and now it doesn't hang |
| 23:13:11 | wodz | pamaury: ^ |
| 23:14:05 | pamaury | ok, now we know what is the problem |
| 23:14:42 | pamaury | does the core notify completion for ZLP ? |
| 23:14:48 | wodz | how to print value of some mem cell? print(%x, DEV.read32(address)) ? |
| 23:14:59 | [Saint] | copper: I see you, like myself, got rapidly educated wrt: parametric equalizers :) |
| 23:15:02 | pamaury | print(DEV.read32(address)) |
| 23:15:18 | pamaury | for formatting, print(string.format("%x",DEV.read32(addr))) |
| 23:16:45 | wodz | ok reading mem works as well |
| 23:17:05 | pamaury | we need to fix this bug |
| 23:17:09 | wodz | now I need to understand what is the problem |
| 23:17:18 | [Saint] | Ms [Saint] and her workmates insist on using g#401 - but it really is for people with more CPU than sense whom can't be bothered or don't care to learn about the merits of a parametric EQ. |
| 23:17:21 | | Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) |
| 23:18:13 | [Saint] | ...and that's not necessarily a bad thing, I just didn't particularly care to push for those EQ presets because it allows people to do very stupid things on targets that almost certainly can't handle it. |
| 23:18:18 | pamaury | wodz: my theory is that you don't get an interrupt when the ZLP completes, but that's just a theory |
| 23:18:26 | [Saint] | ANd then they'll complain and say its my/our fault. |
| 23:18:29 | | Nick SuperBrainAk is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) |
| 23:18:32 | pamaury | perhaps because of dma |
| 23:19:09 | [Saint] | Did fs-bluebot die? |
| 23:19:09 | wodz | pamaury: With 64bytes payload we should issue ZLP, righ? |
| 23:19:22 | pamaury | yes |
| 23:21:21 | copper | [Saint]: it's just what usually happens with me: I went from not caring and using dumb means of doing something, to caring and actually thinking of a smarter way of doing the same thing :) |
| 23:21:42 | [Saint] | Pretty much the same with me. |
| 23:21:45 | copper | sometimes I simply forget to use my brain |
| 23:22:05 | copper | (oftentimes*) |
| 23:22:27 | wodz | pamaury: But we send ZLP in other occasions sucessfully, don't we? |
| 23:23:01 | | Quit saratoga (Quit: Page closed) |
| 23:23:27 | [Saint] | I really should have a look at converting those presets to using as little bands as possible, you could assist if you'd like (nudge nudge... http://gerrit.rockbox.org/r/#/c/401/ :))? |
| 23:23:42 | pamaury | wodz: maybe not, it's quite rare to send a multiple of the packet size on a control endpoint |
| 23:23:58 | copper | [Saint]: you know, I thought about that a couple hours ago |
| 23:24:23 | pamaury | the Rockchip USB code you sent me suggest there is no difference for the ZLP, so it should trigger the IN0 interrupt normally |
| 23:24:29 | copper | it's a somewhat lengthy process to RMAA settings though |
| 23:24:57 | [Saint] | copper: if you put you mind to it, it should be fairly obvious where those were stole...errr, borrowed from. :) |
| 23:25:06 | copper | I know, I remember :) |
| 23:25:43 | [Saint] | Perhaps you could brief me on the process you used? I have had some difficulty with this myself. |
| 23:26:02 | wodz | pamaury: no I mean do we force ZLP in code somewhere so we are sure the driver is able to produce such thing |
| 23:26:38 | [Saint] | copper: if you have the time, I would very much appreciate a rough outline of how you achieved this. |
| 23:26:41 | pamaury | wodz: may I suggest you try to ack in rockbox ? modify our usbstack so that for example a string descriptor is exactly 64-bytes and see what happens |
| 23:26:47 | pamaury | *hack |
| 23:27:46 | pamaury | wodz: yes, in receive controls but your driver has not receive any such control yet |
| 23:27:53 | copper | [Saint]: identify peaks, their center frequency and their amplitude; tinker with either the Q setting or the center frequency until you get the curve that you want, as verified by running RMAA with the EQ on. |
| 23:28:06 | wodz | as this driver is cop/paste and stripped from anything but EP0 I don't see the point |
| 23:28:25 | copper | I noticed that in order to get the curve that I wanted, I had to change the center frequency by as much as 2 kHz in the mids |
| 23:28:31 | pamaury | wodz: the point is to check if that work in rockbox ! |
| 23:28:41 | pamaury | and in rockbox you have logf... |
| 23:29:00 | gevaerts | copper: probably in part because of the non-linear frequency scale used on your other eq |
| 23:29:24 | copper | gevaerts: my desktop player EQ is actually faulty |
| 23:29:44 | copper | I get 8 dB variations with 6 dB settings |
| 23:29:47 | | Quit amayer (Quit: Leaving) |
| 23:30:08 | copper | with super weird looking curves |
| 23:30:30 | copper | whereas the Rockbox EQ performs as expected |
| 23:30:39 | copper | (again, as verified with RMAA) |
| 23:32:10 | copper | creating Rockbox EQ presets to copy existing (iTunes or whatever) presets would be a lengthy process |
| 23:32:31 | [Saint] | Ah, another thing I wanted to ask the various sound-understanding-type-guys here - is there supposed to be a recipe for calculating the amount of replaygain pre-amplification to use? |
| 23:32:34 | copper | and one would wonder, whether those existing presets have merit to begin with |
| 23:33:05 | [Saint] | I averaged the total gain applied and divided by two, which seems ok, but I basically pulled it out of my ass. |
| 23:33:09 | copper | [Saint]: negative pre-amp should match your highest positive replaygain value |
| 23:33:28 | copper | in order to avoid clipping |
| 23:33:56 | copper | i.e. if you have an album with +3 dB replaygain, you should set the pre-amp to -3 dB |
| 23:34:12 | copper | that way, your music collection will never clip |
| 23:34:15 | [Saint] | ~90% of my replaygain values are negative. |
| 23:34:21 | copper | yup, that's normal |
| 23:34:40 | copper | but positive gain values exist |
| 23:34:48 | copper | like, with classical music, or albums from the 80s |
| 23:35:14 | copper | you can also set the preamp value to match different reference levels |
| 23:35:17 | copper | RG is 89dB |
| 23:35:25 | copper | the new ITU stuff is 84dB |
| 23:35:35 | copper | that's what Opus uses, for instance |
| 23:35:56 | copper | i.e. you have to add 5dB to Opus gain in order to match the Replaygain reference level |
| 23:36:35 | [Saint] | The problem I had was it just being ridiculously quiet. I averaged the gain applied accross all tracks and divided by two (which came out at 6dB after a tiny amount of rounding) and applied that as positive pre-amp and it seems ok I guess. |
| 23:36:53 | [Saint] | But I'm never really comfortable with just pulling things out of the sky like that. |
| 23:37:19 | copper | er, your average Replaygain was -12 dB? |
| 23:37:41 | [Saint] | yep. |
| 23:37:49 | copper | lots of contemporary releases |
| 23:38:03 | [Saint] | Lots of...lots of everything. :) |
| 23:38:08 | copper | well, you went for the "will work in most cases" way |
| 23:38:10 | *** | Saving seen data "./dancer.seen" |
| 23:38:37 | copper | which is different from the "will work with absolutely anything" way ;-) |
| 23:39:00 | [Saint] | ...which would be? |
| 23:39:05 | copper | I don't need to add gain because all my headphones and IEMs are sensitive enough |
| 23:39:32 | copper | [Saint]: which would be, take the highest Replaygain value you've got in your music collection, and apply preamp gain that matches it |
| 23:39:45 | [Saint] | My IEMs are plenty sensitive - I just like my music _loud_. |
| 23:39:51 | copper | like I said: if your max gain is +3dB, set preamp to -3dB |
| 23:40:04 | copper | I like it loud too :) |
| 23:40:24 | [Saint] | Your definition of loud and mine might differ greatly, though. |
| 23:40:49 | [Saint] | My volume with IEMs in usually sits around -6dB. |
| 23:40:54 | copper | well, I've been accused of being completely deaf a lot of times ;) |
| 23:41:12 | copper | anyway, you got the idea |
| 23:41:19 | copper | get |
| 23:41:23 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 23:41:30 | wodz | pamaury: Yeah, it seems ZLP does not generate ACK interrupt |
| 23:41:43 | [Saint] | No, no. Past tense is fine. I understand now. Thank you. |
| 23:41:52 | [Saint] | :) |
| 23:42:18 | copper | basically, the objective is to avoid applying positive gain to a file that might already have peaks that reach 0 dBFS |
| 23:42:34 | copper | which can very well happen with Replaygain |
| 23:42:44 | pamaury | wodz: I'm surprised, but hey, might be just another quirk |
| 23:42:46 | copper | with high dynamic range content |
| 23:43:24 | copper | Replaygain will try to make it sound as loud as the usual, modern, compressed recordings, but when the material has super high dynamic range, the peaks will then exceed 0 dBFS |
| 23:43:33 | copper | e.g. with classical music |
| 23:44:06 | copper | and then, if you don't apply negative preamp gain, the material will clip |
| 23:44:30 | copper | but given today's music collections for most people, that's a fringe case |
| 23:44:59 | [Saint] | unless you're gevaerts |
| 23:45:20 | copper | I guess that's why the newer loudness standards use a lower reference level (84 dB vs. 89 dB): it leaves more headroom |
| 23:46:05 | copper | but then, you'd need DAPs with more max voltage / power to compensate |
| 23:46:10 | | Nick rocketni1e is now known as rocketnine (~tee@198.199.104.66) |
| 23:46:59 | copper | attenuating by 6 dB for replaygain and an additional 6 dB for EQing is already pushing it |
| 23:47:25 | copper | add 6dB more for modern recordings, and you're already attenuating your source by a full 18 dB |
| 23:48:53 | copper | add 5 dB to match the newer ITU reference level, and that makes a grand total of 23 dB |
| 23:49:14 | copper | (which is quite ridiculous) |
| 23:50:07 | copper | add to that the French / EU volume cap, and your iPod becomes unusable ;P |
| 23:50:43 | copper | (a volume cap that is completely arbitrary and does not take into account the various impedance and sensitivity values of various ear buds / IEMs / headphones) |
| 23:51:14 | [Saint] | None of my material clips. Primarily, I just wanted to know if I was "Doing It Right ™", and I guess its pleasing to know that I wasn't totally "Doing It Wrong ™" but given this new information I will make some changes. |
| 23:51:58 | copper | your material could clip, but for such a small amount of contiguous samples, that it might well be inaudible |
| 23:52:22 | | Join GLC- [0] (clg@56k.modeemi.net) |
| 23:52:25 | GLC- | hello |
| 23:52:29 | GLC- | good day |
| 23:53:37 | GLC- | i recently got my iPod 5G back after a few years.. Apple has probably released firmware updates to it |
| 23:54:03 | [Saint] | I sincerely doubt it. |
| 23:54:12 | GLC- | but I really dislike iTunes, so I was thinking of Rockboxing it |
| 23:54:38 | GLC- | it was like 2006 when i last time upped the firm |
| 23:55:05 | GLC- | and the person who had it hasn't even synced music to it, she listened mine |
| 23:55:09 | GLC- | anyhow |
| 23:55:43 | wodz | pamaury: seems like the workaround works |
| 23:55:44 | GLC- | does RockBox work with WMP12? I have Win 7 pro x64 |
| 23:55:52 | copper | [Saint]: the thing with peak values is, you can very well have very marginal peaks that are a full 3 dB (or more) above 99% of the rest of the content |
| 23:55:56 | pamaury | wodz: this usb core is really fucked up ^^ |
| 23:56:18 | wodz | pamaury: OF handles ZLP case specially too |
| 23:56:19 | GLC- | could I sync Rockboxed Ipod 5G with WMP12? |
| 23:56:21 | copper | in that case, clipping on those peaks might not matter |
| 23:56:33 | [Saint] | GLC-: It should. For all intents and purposes the device should simply appear as a removable mass storage device. |
| 23:57:09 | [Saint] | Most people prefer to simply drag and drop their audio with Rock box though. |
| 23:57:31 | GLC- | [Saint], ok, that's good to hear |
| 23:57:54 | [Saint] | The choices you make for getting audio to the device really depend on whether or not you are you going to be continuing to use the original firmware or not. |
| 23:58:27 | GLC- | drag and drop? so there's no folder structure in the Ipod then? or does Rockbox auto-create it? but how does then WMP12 could sync the music to the rockbox system? |
| 23:58:44 | copper | the file structure is what you make it |
| 23:58:56 | copper | the iPod is just like a normal USB flash drive |
icon identifies that the person is a core developer (has commit access).