00:41:52 | *** | Saving seen data "./dancer.seen" |
01:00 |
01:59:26 | efqw | update regarding battery bench: |
02:00 |
02:00:09 | efqw | if I shut down rb and actually put the microsd into my computer, I do get the logs |
02:00:24 | efqw | but I don't see anything if I `cat` the file in the console |
02:00:39 | efqw | so I assume everything was written when rb quits? |
02:00:44 | efqw | this is odd |
02:04:53 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
02:06:07 | Stanley00 | I also tried battery_bench on my M5, with in-ear phone, it reported about 9h playing to go from 100% to 5% |
02:06:21 | Stanley00 | *in-ear headphone |
02:07:20 | efqw | yeah, I have some low-impedance stuff plugged in as well to simulate regular usage |
02:29:28 | _bilgus__ | are you guys using the test audio files for this? |
02:30:59 | | Quit _3dsv (Ping timeout: 240 seconds) |
02:32:44 | efqw | I was not aware of the existence of a test audio file. |
02:33:05 | efqw | I just picked a random flac album I had |
02:33:22 | _bilgus__ | https://www.rockbox.org/wiki/CodecPerformanceComparison#Requirements |
02:34:31 | Stanley00 | I also used my own flac album |
02:34:36 | _bilgus__ | they are under codec tests but it gives a good base line for testing BB and doing codec bench too |
02:35:00 | _bilgus__ | assuming your player handles them all without crashing |
02:35:40 | efqw | I'll do the codec bench after the bettery bench is done. |
02:36:15 | _bilgus__ | its probably jaw dropping fast on that processor |
02:36:52 | efqw | yeah, that's what I'd expect tbh :P |
02:38:35 | efqw | something like 5000%+ perhaps |
02:41:56 | *** | Saving seen data "./dancer.seen" |
02:42:05 | | Join _3dsv [0] (~3dsv@068-184-255-059.res.spectrum.com) |
03:00 |
03:18:03 | | Join petur [0] (~petur@77.77.179.66) |
03:18:03 | | Quit petur (Changing host) |
03:18:03 | | Join petur [0] (~petur@rockbox/developer/petur) |
03:48:37 | | Quit Rower (Read error: Connection reset by peer) |
03:49:01 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
04:00 |
04:41:59 | *** | Saving seen data "./dancer.seen" |
04:57:40 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
05:00 |
05:19:01 | Stanley00 | I'm working on the poweroff issue on m5 |
05:19:28 | Stanley00 | https://github.com/jerome-pouiller/ioctl <= not sure if we can use this and call to it to shutdown axp after issue the poweroff command |
05:24:54 | | Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) |
05:28:58 | Stanley00 | yup, it works on m5... if you all agree on this, we can just have something like `system("poweroff; sleep 10; ioctl /dev/axp173 magic_number");` |
05:52:50 | | Quit prof_wolfff (Ping timeout: 256 seconds) |
06:00 |
06:25:37 | | Join Rower- [0] (~Rower@185.246.208.202) |
06:27:58 | | Quit Rower (Ping timeout: 256 seconds) |
06:31:15 | wodz | speachy: do you by any chance know how asound.conf values corelate with alsa device string? I mean I am looking way to avoid dynamicaly crafting entry in asound.conf file for bt devices |
06:42:00 | *** | Saving seen data "./dancer.seen" |
07:00 |
07:01:25 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
07:05:08 | | Quit Rower- (Ping timeout: 272 seconds) |
07:09:09 | speachy | wodz: type:deviceid[,subdevice] |
07:09:41 | Stanley00 | efqw: https://pastebin.com/raw/0WN8HyUV <= my current work-around for poweroff issue |
07:10:22 | wodz | speachy: how to pass device specific params? |
07:11:10 | speachy | 'hw:0' is usually all that's needed for native hw but you're locked into hw capabilities only, 'plughw:0' is the wrapper that will do conversions/etc for you if the hw doesn't do what you want |
07:12:09 | speachy | what sort of params? (I don't think you specify that in the devicestring, that's either in asound.conf or you specify the options when doing your hw/swparams setup api calls...) |
07:12:26 | Stanley00 | speachy: I'm having weird issue with M5 volume button. it won't take effect until I press pause and the play the current song. Do you have any idea what may causing this? |
07:12:52 | speachy | (it's been well over a decade since I've done anything substantial with alsa..) |
07:13:20 | wodz | speachy: For each bt device hiby creates entry in asound.conf like this pcm.80_C7_55_63_59_D6{ |
07:13:20 | wodz | type bluetooth |
07:13:20 | wodz | bdaddr 80:C7:55:63:59:D6 |
07:13:20 | DBUG | Enqueued KICK wodz |
07:13:20 | wodz | profile a2dp |
07:13:20 | wodz | } |
07:13:52 | wodz | then you can reference this as alsa device '80_C7_55_63_59_D6' |
07:14:15 | speachy | if you do 'aplay -l' it will show you the perspective from alsa's api |
07:14:22 | wodz | I would prefer to avoid writing entries in aplay.conf |
07:14:47 | wodz | **** List of PLAYBACK Hardware Devices **** |
07:14:47 | wodz | card 0: k1 [k1], device 0: k1-cs42l51 cs42l51-hifi-0 [] |
07:14:48 | wodz | Subdevices: 1/1 |
07:14:48 | *** | Alert Mode level 1 |
07:14:48 | wodz | Subdevice #0: subdevice #0 |
07:14:53 | wodz | not really helpful |
07:14:53 | speachy | I don't know if that's possiblem. :/ |
07:17:56 | wodz | bluealsa can do that |
07:18:08 | wodz | the string is like this bluealsa:DEV=00:0B:D5:F5:F8:B9,PROFILE=a2dp |
07:18:50 | speachy | you beat me to it. :) |
07:18:52 | wodz | since bluealsa is based on pcm plugin from bluez4 I thought it would be possible here as well |
07:19:59 | speachy | I'd bet bluealsa's using a /etc/asound.conf that's been parameterized. |
07:20:07 | speachy | see https://volkerschatz.com/noise/alsa.html |
07:20:41 | speachy | search for '@args' |
07:23:43 | wodz | ok, now that starts to make sense |
07:24:03 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
07:24:20 | wodz | when parametrization was introduced? Maybe we can do the same |
07:24:49 | *** | Alert Mode OFF |
07:24:56 | speachy | I'd be shocked if it wasn't supported on those hiby targets. |
07:25:15 | speachy | I _think_ they have alsa 1.0.26? circa 2013-ish. |
07:25:27 | speachy | parameters are probably at least a decade older |
07:26:45 | wodz | good so it is a matter of crafting parametrized config |
07:26:46 | speachy | so we can add a generic parameerized bluetooth entry at the end of /etc/asound.conf when we patch in the bootloadr, or of hiby_player mucks with it (ie strips it out) we can do it the startup script that launches the loader |
07:27:03 | wodz | exactly |
07:27:43 | | Quit Stanley00 () |
07:27:44 | speachy | btw, tools/hiby_patcher.pl is what's used to mangle the update.upt images these days. |
07:28:26 | wodz | https://github.com/Arkq/bluez-alsa/blob/master/src/asound/20-bluealsa.conf |
07:29:45 | wodz | looks like changing type from bluealsa to bluetooth should do the trick |
07:30:42 | wodz | I mean pcm part |
07:30:51 | speachy | yepper |
07:33:16 | | Join MrZeus_ [0] (~MrZeus@185.195.232.139) |
07:34:18 | speachy | Stanley00, does the volume display change when you hit the buttons? |
07:35:40 | speachy | Also, you need to run battery_bench until the device shuts down. the last time I did a bench run on an uncalibrated device, it was under 10% for over five hours. |
07:49:28 | wodz | speachy: Sometimes I can get aplay to work with bt, but mostly I get this |
07:49:30 | wodz | Playing WAVE 'test_file.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo |
07:49:30 | wodz | ALSA lib audio/pcm_bluetooth.c:2056:(audioservice_recv) Too short (0 bytes) IPC packet from bluetoothd |
07:49:30 | wodz | aplay: set_params:1166: Unable to install hw params: |
07:49:30 | wodz | ACCESS: RW_INTERLEAVED |
07:49:30 | wodz | FORMAT: S16_LE |
07:49:33 | wodz | SUBFORMAT: STD |
07:49:35 | wodz | SAMPLE_BITS: 16 |
07:49:37 | wodz | FRAME_BITS: 32 |
07:49:39 | wodz | CHANNELS: 2 |
07:49:41 | wodz | RATE: 44100 |
07:49:43 | wodz | PERIOD_TIME: (46439 46440) |
07:49:45 | wodz | PERIOD_SIZE: 2048 |
07:49:47 | wodz | PERIOD_BYTES: 8192 |
07:49:49 | wodz | PERIODS: 3 |
07:49:51 | wodz | BUFFER_TIME: (139319 139320) |
07:49:53 | wodz | BUFFER_SIZE: 6144 |
07:49:55 | wodz | BUFFER_BYTES: 24576 |
07:49:57 | wodz | TICK_TIME: [0 0] |
07:49:59 | wodz | and bluetoothd dies |
07:50:03 | wodz | any idea? |
08:00 |
08:36:29 | speachy | not particularly. nothing of use in the bluetoothd logs? |
08:42:04 | *** | Saving seen data "./dancer.seen" |
08:43:21 | speachy | maybe it wasn't actively paired at the itme? |
08:44:10 | wodz | bt-device -i reported paired and connected |
08:46:22 | wodz | Battery is dying in my device. This complicates everything further |
08:47:45 | | Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) |
09:00 |
09:10:18 | | Join t0mato2 [0] (~t0mato@193.32.127.162) |
09:10:50 | | Quit t0mato (Ping timeout: 256 seconds) |
09:10:50 | | Nick t0mato2 is now known as t0mato (~t0mato@193.32.127.162) |
09:19:51 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
09:30:16 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
09:30:41 | Stanley00 | speachy: yes, the volume icon changed as I pressed the volume buttons |
09:31:10 | Stanley00 | I also tried change volume from sound setting but it's still won't effect until I paused the current playing |
09:34:56 | | Quit Stanley00 (Read error: Connection reset by peer) |
09:36:34 | efqw | it's been more than 7 hours and the m3k's battery is still at 3.863v |
09:36:59 | efqw | I think it's pretty safe to assume this thing can do more than 14hrs |
09:39:41 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
09:41:55 | Stanley00 | since the poweroff is working on my m5 now, I guess I can do the battery_benchmark this weekend |
09:42:49 | Stanley00 | also, where can I find the bluetooth code for hosted targets? I grep through the rockbox master but I can't find any |
09:43:18 | Stanley00 | and what can I expected from current bluetooth support for hosted targets? |
09:46:02 | | Quit Stanley00 (Remote host closed the connection) |
09:48:22 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
09:55:30 | | Quit pamaury (Ping timeout: 272 seconds) |
09:57:35 | | Quit Stanley00 (Remote host closed the connection) |
09:59:58 | efqw | there is no BT code *at all* yet |
10:00 |
10:07:22 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
10:08:05 | Stanley00 | efqw: oops, I thought I heard we have somewhat bluetooth for hosted here :( |
10:08:25 | Stanley00 | anyway, did you check my work-around for m3k poweroff issue? |
10:08:41 | efqw | it's still doing the battery bench :P |
10:09:35 | Stanley00 | I see |
10:10:08 | Stanley00 | FiiO stated that m5 can last for 10 hours, so I could be happy with around 9 hours for rockbox |
10:10:40 | Stanley00 | consider I didn't tune and turn off unneeded chipset/peripherals yet |
10:11:29 | Stanley00 | funny thing is my laptop sometimes can see my M5 via bluetooth while I boot rockbox |
10:24:39 | efqw | for me a dedicated DAP needs a fairly good battery life that lasts through multiple listening sessions without needing to recharge |
10:28:53 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
10:29:12 | | Quit massiveH (Quit: Leaving) |
10:30:54 | | Quit Stanley00 (Ping timeout: 245 seconds) |
10:42:07 | *** | Saving seen data "./dancer.seen" |
10:57:48 | | Quit Oksana (Ping timeout: 260 seconds) |
11:00 |
11:07:20 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
11:16:20 | speachy | Stanley00: the m5 is a modification of the existing m3k/fiio drivers, correct? |
11:24:24 | | Quit petur (Quit: Connection reset by beer) |
11:25:05 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
11:25:25 | Stanley00 | sorry, I got very unstable network here |
11:27:56 | | Quit Stanley00 (Remote host closed the connection) |
11:29:08 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
11:29:47 | Stanley00 | if you're asking about the volume buttons issue. All I changed that can related to sound is replace '/dev/ak4376' to /dev/ak4377 on m5 |
11:30:53 | Stanley00 | one side note is it used to worked before when I edit m3k code directly, but then I pull the master branch, and create separated files for m5, the issue appears |
11:47:09 | | Quit Stanley00 (Ping timeout: 245 seconds) |
11:49:37 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
11:50:05 | Stanley00 | speachy: I think I found it, https://github.com/Rockbox/rockbox/blame/master/firmware/drivers/audio/fiiolinux_codec.c#L94 <= this muted supposed to be initialized by 0 instead? |
11:50:52 | speachy | mute state wouldn't affect the inability to adjust the volume when playing (assuming you could hear anything to start with) |
11:52:04 | Stanley00 | but later, at line 129, it won't enter the code to apply volume, |
11:54:01 | speachy | add audiohw_mute(false); to the end of audiohw_preinit() |
11:54:50 | Stanley00 | it make sense. So, we use value of -1 for another special meaning of muted state then? |
11:55:21 | speachy | thats to make sure we explicitly call audiohw_mute() |
11:55:35 | speachy | instead of relying on something happening implicitly. |
11:56:20 | speachy | not entirely clear it'll do any good on this platform |
11:56:42 | speachy | since there's no dedicated mute control on the audio path |
11:57:09 | speachy | oh! everyone, gerrit's going offline in a few minutes. |
11:57:21 | speachy | anongit and gitweb will continue fine |
11:59:14 | | Quit Stanley00 (Ping timeout: 245 seconds) |
12:00 |
12:01:23 | speachy | and it's now offline. |
12:02:45 | | Quit MrZeus_ (Ping timeout: 240 seconds) |
12:03:31 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
12:09:17 | efqw | `up 10:07, 0 users, load average: 2.08, 2.04, 2.05` |
12:09:34 | efqw | battery still at 3.825v |
12:09:48 | efqw | don't tell me this is gonna last 20h, lol |
12:14:24 | fs-bluebot_ | Build Server message: New build round started. Revision 97b8692, 293 builds, 9 clients. |
12:15:25 | speachy | ok, gerrit is back up. |
12:16:19 | | Join MrZeus_ [0] (~MrZeus@185.195.232.139) |
12:18:24 | | Quit Stanley00 (Ping timeout: 245 seconds) |
12:24:35 | speachy | Stanley00: I committed that change I suggested. tbh I'm not sure how you got _any_ sound out at all without it. |
12:26:13 | speachy | never say never! :D |
12:26:26 | speachy | aro you playing that flac file, or something else? |
12:29:40 | fs-bluebot_ | Build Server message: Build round completed after 915 seconds. |
12:29:49 | fs-bluebot_ | Build Server message: Revision 97b8692 result: All green |
12:30:31 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
12:32:33 | Stanley00 | my collections is mostly flac, with a few mp3 and ogg |
12:32:58 | Stanley00 | there's maybe some code path relate to play/pause logic that effect the volume, I guess |
12:36:42 | | Quit Stanley00 (Quit: Ping timeout (120 seconds)) |
12:42:08 | *** | Saving seen data "./dancer.seen" |
12:43:18 | speachy | do you have current code otherwise? |
13:00 |
13:13:47 | | Join Stanley00 [0] (0135c695@unaffiliated/stanley00) |
13:14:39 | Stanley00 | I was trying latest code from master before bed, but it looks like you forgot to update muted variable in audiohw_mute =]] |
13:15:45 | speachy | ...oh, lovely. |
13:16:11 | speachy | that's what happens when I can't test the code I'm changing |
13:16:43 | fs-bluebot_ | Build Server message: New build round started. Revision 02c5dd3, 293 builds, 9 clients. |
13:20:07 | _bilgus__ | and what happens when I _CAN_ test the code I'm changing :p |
13:20:31 | Stanley00 | it's time for bed, good night everyone |
13:26:47 | _bilgus__ | night |
13:27:35 | Stanley00 | okay, now's bed time storry: I'm testing the test_files earlier, and it seems that ape_c5000 is killing my m5... cpu top at 97% and the sound is lagging... =]] |
13:28:07 | _bilgus__ | __builtin you mentioned xworld does it use xlcd or are the unrelated? |
13:28:20 | | Part Stanley00 |
13:30:55 | speachy | Stanley000, APE @c5K is ... quite intensive. |
13:30:59 | fs-bluebot_ | Build Server message: Build round completed after 856 seconds. |
13:31:01 | fs-bluebot_ | Build Server message: Revision 02c5dd3 result: All green |
13:31:02 | fs-bluebot_ | Build Server message: New build round started. Revision 1e12990, 293 builds, 9 clients. |
13:32:34 | _bilgus__ | thats why I mentioned 'if the player can play them' |
13:33:28 | _bilgus__ | I tell you what though I'm still tired of that song that most of the test files use |
13:35:59 | speachy | most (all?) of our targets can't handle ape @c4K either. |
13:44:18 | fs-bluebot_ | Build Server message: Build round completed after 798 seconds. |
13:44:20 | fs-bluebot_ | Build Server message: Revision 1e12990 result: All green |
14:00 |
14:02:25 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
14:21:09 | | Quit pamaury (Ping timeout: 265 seconds) |
14:41:42 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
14:42:12 | *** | Saving seen data "./dancer.seen" |
15:00 |
15:00:46 | _bilgus__ | well I tried and failed to make xlcd stride agnostic, oh well I left the pieces in there for anyone who wants to expand it |
15:01:22 | _bilgus__ | getting tired of this patch, get it working then expand from there |
15:06:22 | _bilgus__ | OK g#2811 SHOULD be ready! |
15:06:24 | fs-bluebot_ | Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct by William Wilgus |
15:06:38 | speachy | 25th time's the charm, eh? |
15:06:55 | _bilgus__ | look at the advanced keylock patch I think I had 50 |
15:07:55 | _bilgus__ | I do try to tend to push my days work up there so I can read through it on breaks |
15:09:18 | _bilgus__ | there is still 2bit corruption on non-native strides but I want to get all these other targets right that can be a different patch since nothings using it ATM |
15:10:41 | speachy | it works! |
15:10:51 | speachy | okay, this is... funny |
15:11:07 | speachy | I hit play on the UIsim on my workstation, and music started playing out of my laptop. |
15:11:46 | _bilgus__ | I didn't do that! |
15:12:21 | _bilgus__ | g#1417 I guess it was only 40 patch sets |
15:12:23 | fs-bluebot_ | Gerrit review #1417 at http://gerrit.rockbox.org/r/1417 : Selective Backlight/Advanced Softlock - Selective actions based on context by William Wilgus |
15:12:36 | speachy | I must have paired them via bluetooth at some point because nothing else makes any sense |
15:13:18 | _bilgus__ | adv keylock was actually much more difficult but this one is far more annoying and sprawled out |
15:14:45 | _bilgus__ | I'll commit this by the weekend assuming no more flaws pop up |
15:15:51 | speachy | can't say I've run into anything new, but it does fix two bugs I've personally tripped over. |
15:16:17 | _bilgus__ | I think the other thing I want to do is to wire the dirty vp stuff a little deeper in the core to the point that it will not refresh a vieport that is already clean |
15:16:59 | _bilgus__ | bugs you found prior to this rewrite? NO way :p |
15:17:55 | speachy | of course not, rockbox's code is pristine and perfect, as was handed down by the Swedish Demigods |
15:18:27 | _bilgus__ | If I had to guess one of the bugs was the wps thing and a stride issue in plugins? |
15:19:03 | speachy | display&|viewport corruption in multiple plugins and that wps thing. |
15:19:27 | speachy | possible this likely fixes some of the crash-on-exit plugin issues seen on the hosted targets |
15:20:22 | _bilgus__ | well it does force vp init now on plugin start and cleans it up on exit |
15:21:03 | _bilgus__ | before it was just kinda luck of the draw |
15:21:19 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
15:21:19 | * | speachy nods. |
15:51:27 | | Quit MrZeus_ (Ping timeout: 260 seconds) |
15:58:47 | speachy | grr, gitlab oauth integration into our gerrit instance is still shot |
16:00 |
16:04:42 | | Join MrZeus_ [0] (~MrZeus@185.195.232.139) |
16:06:27 | _bilgus__ | reviewing the framebuffer patch I see a lot of code for clipping that could probably be moved to a clip func ptr within the viewport |
16:07:47 | | Quit fs-bluebot_ (Ping timeout: 260 seconds) |
16:07:48 | _bilgus__ | same ida as the fb address function pointer, I mean it could be moved there as well but I wouldn't want the overhead on every pixel |
16:07:54 | | Join fs-bluebot [0] (~fs-bluebo@55d45674.access.ecotel.net) |
16:10:28 | speachy | I like the sound of that. |
16:10:56 | _bilgus__ | hmm I really didn't consider the implications on the bootloaders I wonder how much of this code they pull in |
16:12:23 | speachy | most of 'em don't display anything at all. |
16:13:17 | speachy | so I expect minimal effect on bl code size. |
16:14:11 | _bilgus__ | heeh I already got a error :p |
16:14:42 | _bilgus__ | time to upgrade my toolchain |
16:14:43 | speachy | might have IRAM size problems. |
16:14:49 | _bilgus__ | lol |
16:15:09 | _bilgus__ | do I just rebuild off the new rbdev.sh? |
16:16:30 | | Quit pamaury (Ping timeout: 258 seconds) |
16:16:43 | speachy | I'd recommend moving the old ones out of the way rather than installing over them, but otherwise it's just run and wait a while. |
16:20:45 | | Quit Rower (Ping timeout: 240 seconds) |
16:21:22 | _bilgus__ | ok when I get back I shall continue this adventure |
16:21:42 | speachy | only (native) arm and m68k changed |
16:28:30 | _bilgus__ | was about to ask |
16:38:20 | braewoods | _bilgus__: well i know the h120 bootloader does display stuff to remote LCD |
16:38:24 | braewoods | and the native one |
16:38:53 | braewoods | but just text |
16:40:24 | _bilgus__ | as longas it doesn't do scrolling should be ok and I believe I pulled scrolling from all bootloaders at some point |
16:42:14 | | Quit Oksana (Ping timeout: 256 seconds) |
16:42:16 | *** | Saving seen data "./dancer.seen" |
16:55:15 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
17:00 |
17:28:32 | | Quit lebellium (Quit: Leaving) |
18:00 |
18:42:18 | *** | Saving seen data "./dancer.seen" |
19:00 |
19:19:57 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
19:19:57 | | Join fs-bluebot_ [0] (~fs-bluebo@55d44bc9.access.ecotel.net) |
19:22:23 | | Quit fs-bluebot (Ping timeout: 260 seconds) |
19:23:14 | | Quit bluebrother^ (Ping timeout: 265 seconds) |
19:35:07 | | Join Alexander [0] (53d58627@39.83-213-134.dynamic.clientes.euskaltel.es) |
19:35:32 | | Nick Alexander is now known as Guest40192 (53d58627@39.83-213-134.dynamic.clientes.euskaltel.es) |
19:36:13 | Guest40192 | Hey there! So i encountered an "error/bug" of some sort. Should i expose it here, or where should i head to? |
19:36:59 | | Nick Guest40192 is now known as zazuradia (53d58627@39.83-213-134.dynamic.clientes.euskaltel.es) |
19:38:26 | zazuradia | I mean, my player model is iPod 6G 160GB and i installed Rockbox less than a month ago. |
19:43:04 | | Quit MrZeus_ (Ping timeout: 256 seconds) |
19:51:00 | speachy | first, are you using the 3.15 release or a dev/nightly build? |
19:52:41 | zazuradia | it says 3.15 in the Info section. and i don't use to install nightly nor dev builds. |
19:55:01 | speachy | please see if the issue is stull present in a recent nightly or dev build, and if it still is, then it's worth talking about |
19:55:58 | speachy | FWIW I'm not aware of any reason to not be using a dev/nightly build |
19:57:05 | zazuradia | i avoid them in general because of potential stability problems. |
19:57:57 | braewoods | i think that's more true for recent ports |
19:57:58 | zazuradia | the "bug" is just that the player refuses to play any file beyond 14 hours. (ie: audiobooks, which is the main reason i use this ipod) |
19:59:12 | speachy | yeah, please make sure it's still present first |
19:59:23 | speachy | I cant' say I've personally tried anything over about 9h. |
19:59:26 | zazuradia | i just say it plain and simple because it may have to do with some kind of filesystem or hardware limitation already known. i've googled like an hour and didn't find anything related to rockbox that could be of use. |
20:00 |
20:00:33 | braewoods | zazuradia: is this a single file that's 14 hours+ or a bunch of files adding up to 14 hours+? |
20:01:58 | zazuradia | single files only. i've aded many days worth of music to the database and it plays as expected. but when it comes to a file longer than 14h it just skips it and starts playing the next one. |
20:03:41 | braewoods | encoded as mp3? |
20:04:16 | braewoods | this may be an area that isn't well tested since i can't say i know many people that encode single files that long |
20:04:57 | zazuradia | mpeg-4, 134kbps vbr, |
20:05:03 | braewoods | so AAC? |
20:05:58 | braewoods | either way first thing to try is a development build |
20:05:59 | zazuradia | the file properties say mpeg-4, but i encoded them with the "send itunes as audio track" tool on mac. |
20:06:13 | braewoods | i see. |
20:07:27 | zazuradia | i just installed the lates dev build i found, rebooted, tried to play and it skips every track over 14h |
20:07:48 | braewoods | i wonder if it's something to do with RAM or so... |
20:07:55 | braewoods | hm |
20:08:16 | braewoods | zazuradia: one idea, see if encoding one of those files temporarily as something else like Opus would change anything |
20:08:57 | braewoods | it may help narrow it down to codec specific issue vs general decoding issue |
20:09:15 | braewoods | though it may simply be running into some kind of limiter on length |
20:12:22 | | Join Stanley00 [0] (~Stanley00@unaffiliated/stanley00) |
20:12:54 | braewoods | zazuradia: i assume you haven't modified yours with a higher capacity drive or so? |
20:13:06 | braewoods | RB has known issues if used with iflash |
20:13:46 | zazuradia | nope. only a sticker for the screen. everything else is out of the box. not even the hard drive or the battery |
20:14:34 | Stanley00 | FYI: bbout ape file last night, m5 can handle c4000 with 60% cpu usage |
20:14:45 | Stanley00 | about* |
20:16:02 | zazuradia | braewoods: i could try to reencode the file i have, but i can't output any other format in the mac's built-in tool |
20:16:29 | braewoods | wasn't saying you should... i've never used ipods myself. |
20:16:35 | braewoods | i mean |
20:16:38 | braewoods | with their tool |
20:16:55 | braewoods | you'd probably have to install third party tools to do it |
20:18:07 | zazuradia | also worth noting, i started using rockbox on this "newer" ipod because the (stock firm) 5G gave me problems keeping track on files over 14h too. |
20:19:22 | zazuradia | i mean, the files played well, but when i tried to ff or rw when reached that limit, if i tried to do it it would freeze, start over or skip the track. |
20:19:39 | braewoods | just how long are your audio books? |
20:19:51 | braewoods | most things i know of would split them across multiple files |
20:21:40 | zazuradia | for example, the longest one is IT (S. King) with almost 23 hours. |
20:22:29 | zazuradia | i "make" them myself and leave them single filed for as long as they would go. i have no way of knowing how long will it end up being. |
20:23:22 | braewoods | well, transcoding them as a more compact format like Opus may help narrow it down |
20:23:24 | Stanley00 | Hmm... 14h is like 50.000 seconds. Maybe there's limit at 65536 or something like that? |
20:24:10 | braewoods | it would be closer to 18h if that was the case |
20:25:20 | Stanley00 | zazuradia: how did you come up with 14h limit, do you have other file that last around 10h? |
20:25:51 | Stanley00 | May be it's 32768 limit for signed type |
20:27:51 | braewoods | 32767 actually |
20:27:57 | braewoods | :) |
20:28:27 | zazuradia | well, not seconds, but since this is a device intended to play music, maybe it calculates the time in minutes, and it doesn't have the capacity to track minute quantities over 4 digits, but 999 minutes is like 16h, and that doesn't match either. |
20:31:16 | zazuradia | (i'm trying to reencode the file to ogg, btw. but it's a huge file and it's taking some time) |
20:31:48 | | Quit Acou_Bass (Ping timeout: 256 seconds) |
20:42:20 | *** | Saving seen data "./dancer.seen" |
20:44:55 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
20:48:32 | | Quit Stanley00 () |
20:52:41 | speachy | zazuradia: oh, it's mp4? yeah, that's definitely a problem for larger files. |
20:53:38 | braewoods | speachy: why? |
20:53:44 | braewoods | ram requirements? |
20:54:05 | zazuradia | i have a file that is 14h exactly and another one 13 and a half or so. one of them doesn't play and the other does perfectly |
20:54:19 | speachy | the container is more oriented towards streaming. |
20:54:54 | braewoods | is the same true for opus then? it was originally conceived for realtime audio streams |
20:55:14 | speachy | fs#13159 |
20:55:17 | fs-bluebot_ | http://www.rockbox.org/tracker/task/13159 rockbox hangs on certain m4a files (bugs, unconfirmed) |
20:55:25 | speachy | I reported this bug over two years ago. :D |
20:56:44 | speachy | basically parsing the stream is memory intensive. |
20:57:04 | braewoods | my first hunch was some kind of RAM limiter |
20:57:19 | speachy | IIRC on less-ram-blessed targets the failure point happens a lot earlier (~6-7h, I think) |
20:59:31 | zazuradia | i could give you the gdrive link for the 14h file, if you want to try anything. |
20:59:52 | braewoods | i'll give it a try |
21:00 |
21:00:01 | zazuradia | https://drive.google.com/file/d/1s1mtKRdYavGnE-5CUrfNylWynZustNDn/view?usp=sharing |
21:00:17 | zazuradia | (it's in spanish, and pretty fast, btw) |
21:01:26 | braewoods | most of my rockboxs have 32MB |
21:03:04 | braewoods | zazuradia: for reference the upper limit is 2TB for storage media for RB, if that's even possible to achieve |
21:03:12 | braewoods | depends on the port as well |
21:03:34 | braewoods | but 2TB is the limiter inherited from the disk label most use |
21:03:53 | braewoods | though i have seen a few targets that use no partition table |
21:05:08 | zazuradia | my ipod are windows formated. do you think this would change if i mac partitioned them? |
21:05:29 | braewoods | yes |
21:05:35 | braewoods | and RB would no longer work |
21:05:46 | zazuradia | oops. XDD |
21:06:23 | _bilgus__ | braewoods has it try opus or flac |
21:06:31 | speachy | (or even mp3) |
21:06:57 | _bilgus__ | 14 hours is excessive |
21:06:59 | braewoods | not yet. i'm about to myself but it takes time |
21:07:25 | speachy | It's not clear yet if SDUC (ie >2TB cards) required changes to the SD command protocol. |
21:08:45 | braewoods | i'll see what happens once this is done |
21:10:53 | zazuradia | omg. i changed the format (from whatever itunes uses, mp4, aac...) to ogg and it seems to work. :) |
21:11:15 | _bilgus__ | :((( [ERR] Packed data (135305 bytes) doesn't fit in the firmware (134008 bytes) |
21:11:20 | zazuradia | i mean, i recoded the complete file. it took a little while. ^_^U |
21:11:24 | _bilgus__ | I KNEW IT! |
21:11:44 | _bilgus__ | !k is a lot of code |
21:11:53 | _bilgus__ | 1k* |
21:11:55 | speachy | _bilgus__: what target? |
21:12:10 | _bilgus__ | clip+ its the one thast closest to the line |
21:12:21 | _bilgus__ | multiboot was within 30 bytes |
21:12:36 | _bilgus__ | 30 BYTES! lol |
21:15:04 | braewoods | opus is encoding at 48x |
21:15:06 | braewoods | raltime |
21:15:08 | braewoods | lol |
21:15:21 | braewoods | first hour is nearly done |
21:15:47 | zazuradia | do you know of any offline converter? |
21:15:51 | braewoods | zazuradia: realistically your best option is opus. it's fairly CPU friendly and is very compact in terms of audio. |
21:16:03 | braewoods | zazuradia: uh... |
21:16:12 | braewoods | zazuradia: i'm just using a command line approach |
21:16:26 | braewoods | faad Memorias\ de\ idhun\ 2\ Triada.m4a -o /dev/stdout | opusenc - Memorias\ de\ idhun\ 2\ Triada.opus |
21:16:29 | braewoods | for my test |
21:16:51 | braewoods | it will probably lose metadata |
21:16:53 | braewoods | but |
21:17:01 | braewoods | a more professional tool can probably help there |
21:17:21 | braewoods | i'll see if this works |
21:17:24 | braewoods | let me finish encoding first |
21:17:31 | braewoods | at 3 hour mark |
21:17:53 | braewoods | this is with my quad core ivy bridge laptop |
21:18:10 | braewoods | 49.6x |
21:18:56 | braewoods | 17% faad, 100% opusenc lol |
21:19:09 | _bilgus__ | personally flac is better optimized and faster encoding too |
21:19:26 | speachy | but a real waste of disk space for a 14h audio book. |
21:19:27 | braewoods | but it's lossless so more space consumption |
21:19:31 | zazuradia | hmm. command line isn't friendly enough. i would need some kind of front-end so i could batch reencode files. |
21:19:41 | braewoods | indeed. |
21:19:51 | _bilgus__ | zazuradia, linux? |
21:19:52 | braewoods | right now i'm just trying to re-encode this one file to see how it compares. |
21:19:56 | zazuradia | win10 |
21:19:57 | braewoods | he's using Mac |
21:19:59 | braewoods | or |
21:20:00 | braewoods | that |
21:20:06 | braewoods | i just assumed lol |
21:20:20 | braewoods | at 5 hour mark |
21:20:51 | braewoods | this'll take around 20 minutes |
21:20:55 | braewoods | at 48x |
21:21:01 | zazuradia | nah, i use mac only for that tool, but i bootcamped my laptop quite long ago. i don't like mac, but it's the only thing i know of that has this handy tool. |
21:21:17 | _bilgus__ | windows how about audacity it has a batch convert mode |
21:21:29 | braewoods | does that include metadata translation? |
21:21:43 | braewoods | to the extent that is possible |
21:21:45 | braewoods | anyway |
21:21:52 | _bilgus__ | doubtful if you want that the music brainz might help after the fact |
21:22:27 | braewoods | hm AAC is fairing better than I expected |
21:22:39 | braewoods | i guess opus isn't able to dip the bitrate as much |
21:22:49 | _bilgus__ | pretty sure it includes scripting support so not too hard to get a transfer method going |
21:23:28 | braewoods | interestingly i think opus will end up around 20% smaller |
21:23:39 | braewoods | 8 hour mark |
21:24:22 | zazuradia | 50% smaller in my case |
21:24:31 | braewoods | for ogg? |
21:24:36 | braewoods | it probably dropped the bitrate |
21:24:40 | braewoods | heavily |
21:24:45 | zazuradia | around 800mb to around 400 |
21:24:48 | braewoods | opus is around the same bitrate |
21:25:01 | zazuradia | nah, from 134 vbr to 128. i don't need more than that. |
21:25:06 | braewoods | i see. |
21:25:12 | braewoods | maybe ogg is better sometimes. |
21:25:22 | braewoods | i thought opus was always the king lol |
21:25:51 | zazuradia | well, since it's not music i'm working with, i'm okay with pretty low quality, if this means i'm gonna save on disk space. |
21:26:27 | braewoods | i've mainly used opus to avoid having tradeoffs in ripped CD tracks |
21:26:32 | braewoods | they're much smaller than mp3s |
21:26:58 | braewoods | 3.3 hours to go :x |
21:27:45 | zazuradia | many years ago i would care about codec compatibility, but it's nothing to worry about today. rockbox and vlc got me covered. |
21:29:29 | speachy | ok...32-bit to 38-bit addressing. But the old address field was only 32-bit. |
21:31:47 | speachy | which implies new CMDs were defined. |
21:32:34 | __builtin | _bilgus__: xworld and xlcd are unrelated |
21:32:53 | braewoods | zazuradia: 13% smaller |
21:33:02 | __builtin | xworld's name was inspired by xrick, which was sitting in gerrit around the same time |
21:33:10 | zazuradia | same settings, i guess? |
21:33:24 | _bilgus__ | ok I was just making sure, I had started converting xlcd to arbitrary strides but it kept causing issues |
21:33:41 | speachy | unless someone happens to have a copy of the SD 7.0/7.1 specs lying around.... |
21:33:55 | braewoods | zazuradia: -shrug- But it works. |
21:34:02 | braewoods | so whatever works i guess lol |
21:34:05 | braewoods | anything but AAC |
21:34:07 | _bilgus__ | also the patch is up on gerrit if you want to check out the changes that apply to your babies I'd highly appreciate it |
21:34:14 | _bilgus__ | @__builtin |
21:34:21 | _bilgus__ | 2811 |
21:34:33 | __builtin | alright, I'll take a look |
21:34:42 | __builtin | "my babies" :) |
21:35:52 | _bilgus__ | for the most part I only gave them their own FB I didn't do anything to optimize beyond using rb->screens[MS].currentvp for stuff that needs performance it a lot |
21:36:06 | zazuradia | oh yeah. when i started using this tool i used to end up with files above 9GB, for some reason. the tool saves a huge file to the desktop, THEN it recodes it through itunes and saves it in it's directory system. i learned this second file sounds about the same and it's like 1/10 the size. |
21:36:48 | _bilgus__ | 'it a lot' yeah no clue either.. |
21:37:22 | __builtin | doesn't look like a huge change to my plugins at least |
21:37:33 | __builtin | if it compiles I've got no issue with it |
21:40:31 | speachy | So the question is.. did they bump up the block size from 512B to 32K, or did they define a new cmd to allow specifying the extra 6 bits? |
21:47:26 | | Quit cockroach (Quit: leaving) |
21:51:44 | zazuradia | okay guys, it's pretty late here and i kind of need a little bit of sleep. |
21:52:16 | zazuradia | THANKS A LOT for the help solving my problem. i can't thank you enough. |
21:52:19 | zazuradia | see ya! |
21:53:27 | zazuradia | oh btw, i started a thread on the forums before anyone here responded, so i marked it as [SOLVED] and replied with the answer and the steps for the workaround. :) |
21:54:14 | _bilgus__ | __builtin, thanks |
22:00 |
22:05:23 | | Quit zazuradia (Remote host closed the connection) |
22:16:38 | | Quit prof_wolfff (Ping timeout: 256 seconds) |
22:42:21 | *** | Saving seen data "./dancer.seen" |
22:53:19 | _bilgus__ | speachy WELL it turns out that the bootloader doesn't fit @ head either [ERR] Packed data (135305 bytes) doesn't fit in the firmware (134008 bytes) |
22:53:45 | _bilgus__ | let me double check that I'm not doing something stupid |
22:57:05 | _bilgus__ | so yeah my patch doesn't increase the size at all but now gonna have to find 1K somewhere |
22:57:59 | _bilgus__ | speachy does the buildfarm create bootloader builds anymore? |
22:59:03 | _bilgus__ | AHH I bet the build but don't go through the mkamsboot stuff |
22:59:09 | _bilgus__ | they* |
23:00 |
23:20:04 | speachy | yeah, they just genetate the binaries. |
23:20:14 | speachy | as in whatever 'make' generates |
23:21:46 | speachy | wonder where teh size bump came from. (git-bisect?) |
23:21:54 | speachy | (new toolchain?) |
23:23:03 | _bilgus__ | maybe and that might be why I was sticking to the old one originally but can't say for sure |
23:24:13 | _bilgus__ | I do know buffers in bss are inconsequential (~20 bytes each) because of the compression |
23:24:55 | _bilgus__ | so this is going to be a stictly code game I already did this once to get MB inthere so the easy stuff is gone |
23:25:19 | _bilgus__ | rtl language support can probably go |
23:25:54 | _bilgus__ | diacritics can probably get condensed to a single codepage or so |
23:27:32 | _bilgus__ | if we make the boot logo the size of the screen (if its not already) we can get rid of the lcd buffer probably not too much there on the clip+ though |
23:28:24 | _bilgus__ | oh yeah 20 bytes! |
23:35:32 | _bilgus__ | wonder what buflib is used for in the bootloader |
23:44:52 | | Quit [7] (Disconnected by services) |
23:44:58 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
23:45:31 | _bilgus__ | well printf is using 2k wonder if unneeded things are being exposed again |
23:48:59 | _bilgus__ | maybe it is time to put in a tiny limited printf with the bootloaders |
23:56:41 | _bilgus__ | looks pretty standard bootloaders use printf snprintf springt {vsnprintf} |
23:56:59 | _bilgus__ | and I see %x %d %ld %s %02d 0x%02x %.4s |
23:57:26 | _bilgus__ | so standard types and still need precision and padding |
23:58:20 | _bilgus__ | wonder what our old printf looks like from before this expansion by JhMikes |