| 00:14:51 | | Quit ZincAlloy (Quit: Leaving.) |
| 00:16:56 | | Quit ender` (Quit: Anyone who thinks people lack originality should watch them folding maps.) |
| 00:53:20 | *** | Saving seen data "./dancer.seen" |
| 00:58:15 | TorC | Bilgus: I can see that. Then again, the merits of boosting CPU vary with settings. I tend to run a 10s LCD timeout, so I expect the temporary boost would be inconsequential next to the backlight draw over that time. |
| 01:00 |
| 01:00:00 | TorC | Also, if you haven't done so, consider deactivating Sel BL when plugged in. I probably run plugged into wall and external speakers at least half the time. Usually at those times if I want to see the display I want it to show up immediately. |
| 01:01:02 | Bilgus | that shouldn't happen unless you have a timeout set on your backlight while plugged |
| 01:01:20 | TorC | Fun fact: The BL delay hides the effect of the screen not being updated when the BL is off. Original behaviour is that when BL (and screen) comes on, the display still shows the old screen for a fraction of a second. |
| 01:01:42 | TorC | Currently I have a 45s timeout when plugged in. |
| 01:02:42 | Bilgus | well yeah it gives the screen one more second to update |
| 01:03:35 | Bilgus | I'm doubtful boosting the CPU will help and have already discarded the changes I tried out today since it was little benefit and a whole lot of extra code |
| 01:03:49 | Bilgus | but I did fix the backlight timeout issue you spoke of |
| 01:04:36 | TorC | Ah, well. Glad you found the one issue. That is annoying, since there is otherwise a delay to get the display to come back when it goes off prematurely. |
| 01:05:12 | Bilgus | about the only other thing I can think of is to make every context able to be polled for its State and that would knock out some overhead |
| 01:06:52 | Bilgus | right now you have to wait for the button to be added to the queue and then wait for get_action to call get_action_worker then look throught the list of contexts till it finds a match where as the regular backlight code gets a button press sends BACKLIGHT_ON dumps it in a dedicated queue and turns on the BL |
| 01:08:39 | Bilgus | kinda hard to compete with the difference if I had context data available at the button stage though I could look them up much earlier in the process and maybe have a chance but I'll have to have a look at the main_menu code maybe I can store what context it has selected last or something |
| 01:09:35 | TorC | Ah... Now I see more clearly where the delay comes from. |
| 01:11:42 | TorC | I'd still wonder about setting Sel BL to only operate on internal battery. I also have an external battery I occasionally charge from, and while it is usually oversized, its capacity isn't infinite. |
| 01:13:39 | Bilgus | along with the added (strictly superficial) constraint of not being able to touch APPS code from FIRMWARE code it makes it pretty much untenable except to do the lookup within the button code I suppose |
| 01:14:13 | Bilgus | I'm not sure how you would be able to tell if you were on internal battery or external battery? |
| 01:16:15 | Bilgus | if you mean only when not charging it wouldn't be hard to make that change but i'm more focused on delay issue atm that is just menu stuff |
| 01:18:53 | TorC | I was inclined to simply make the plugged in/on battery distinction, which is already made at some level in the player. I don't see how the player can tell the difference between a wall charger and external battery, so I wouldn't ask you do divine the impossible in your code :P |
| 01:21:06 | Bilgus | Here is the fixed SANSA CLIP ZIP firmware https://www.mediafire.com/?y1qrvo5dl0v3mnn |
| 01:21:48 | Bilgus | I'm going to explore ways to get the context earlier and store the button maps |
| 01:23:56 | TorC | I'm installing it now. |
| 01:29:56 | TorC | I can't claim experience in this kind of coding, but it seems the current context ought to already exist as a variable somewhere. The player needs to know what to bring up when activated and what each key does so it can behave correctly when "first keypress enables backlight" is disabled (as I keep it). |
| 01:30:40 | TorC | On WPS, a click down does nothing, which makes it a useful key to turn on the BL without doing anything anyway. |
| 01:31:25 | TorC | BTW, initial testing found no errant BL turn off behaviour. |
| 01:31:39 | TorC | Good work there. Thanks. |
| 01:32:08 | Bilgus | nope it doesn't have the context stored you only get it when the wps/recording/ FM screen calls Get_action(context, timeout) |
| 01:33:11 | TorC | Ah, well. "They" don't like to make things easy, do they? :P |
| 01:33:48 | Bilgus | https://github.com/Rockbox/rockbox/search?p=4&q=Get_action%28&utf8=✓ |
| 01:34:25 | Bilgus | half way down is the WPS apps/gui/skin_engine/skin_display.c and at the bottom the radio |
| 01:35:22 | Bilgus | those are all hardcoded from the function num { CONTEXT_STD = 0, /* These CONTEXT_ values were here before me, there values may have significance, so dont touch! */ CONTEXT_WPS = 1, CONTEXT_TREE = 2, CONTEXT_RECORD = 3, CONTEXT_MAINMENU = 4, /* uses CONTEXT_TREE and ACTION_TREE_* */ CONTEXT_ID3DB = 5, /* Add new contexts here, no need to explicitly define a value for them */ CONTEXT_LIST, |
| 01:35:35 | Bilgus | they just correspond to numbers |
| 01:36:22 | Bilgus | but its not anything about making it hard it is 1. most efficient and 2. selective backlighting was never planned on |
| 01:37:44 | Bilgus | anyway I'll bbl gonna go get dinner |
| 01:38:41 | __builtin | Bilgus: what have you been working on? |
| 01:39:38 | Bilgus | http://gerrit.rockbox.org/r/#/c/1417/ , http://gerrit.rockbox.org/r/#/c/1418/ |
| 01:39:53 | TorC | I know it wasn't to make it hard. I was joking, as I tried to make clear. Text doesn't always transmit tone accurately. |
| 01:41:21 | Bilgus | I'll probably separate selective softlock from selective backlight and commit it separately since it is nearly perfect |
| 02:00 |
| 02:04:13 | __builtin | Bilgus: nice |
| 02:05:45 | | Quit alexweissman (Read error: Connection reset by peer) |
| 02:06:22 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 02:24:54 | | Quit krnlyng (Ping timeout: 260 seconds) |
| 02:37:12 | | Join krnlyng [0] (~liar@77.116.82.193.wireless.dyn.drei.com) |
| 02:53:22 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:12:29 | | Quit girafe (Quit: Leaving) |
| 03:28:48 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 49.0.2/20161019084923]) |
| 03:32:01 | | Join Bilgus1 [0] (4cf32773@gateway/web/freenode/ip.76.243.39.115) |
| 03:33:57 | Bilgus1 | I found a function that I think will get me the current context ahead of get_action .−−>.enum current_activity get_current_activity(void) |
| 03:39:41 | | Quit Bilgus1 (Quit: Page closed) |
| 04:00 |
| 04:45:20 | | Quit michaelni (Read error: Connection reset by peer) |
| 04:53:26 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:03:09 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 06:00 |
| 06:06:18 | | Quit TheSeven (Ping timeout: 245 seconds) |
| 06:06:52 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:20:02 | | Quit toli (Ping timeout: 256 seconds) |
| 06:21:28 | | Join Senji [0] (~Senji@85.187.103.250) |
| 06:21:43 | | Quit Senji (Read error: Connection reset by peer) |
| 06:22:48 | | Join Senji [0] (~Senji@85.187.103.250) |
| 06:23:24 | | Quit Senji (Read error: Connection reset by peer) |
| 06:23:53 | | Join Senji [0] (~Senji@85.187.103.250) |
| 06:23:54 | | Quit Senji_ (Ping timeout: 250 seconds) |
| 06:28:29 | | Join Senji_ [0] (~Senji@85.187.103.250) |
| 06:31:24 | | Quit Senji (Ping timeout: 260 seconds) |
| 06:37:56 | | Quit Bilgus (Quit: Page closed) |
| 06:53:30 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:05:52 | | Quit Bray90820 (Read error: Connection reset by peer) |
| 07:07:33 | | Join Bray90820 [0] (~bray90820@50-83-212-56.client.mchsi.com) |
| 07:50:16 | | Join toli [0] (~toli@62.235.115.54) |
| 07:50:39 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 07:54:33 | | Quit alexweissman (Remote host closed the connection) |
| 08:00 |
| 08:14:20 | | Quit pixelma (Quit: .) |
| 08:14:20 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 08:15:21 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
| 08:15:22 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
| 08:17:30 | | Join johnb2 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 08:18:43 | | Quit johnb2 (Client Quit) |
| 08:25:50 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:48:31 | | Quit akaWolf (Ping timeout: 260 seconds) |
| 08:49:17 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 08:53:32 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:05:06 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 09:06:03 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:f508:9277:7b26:94ae) |
| 09:06:45 | | Quit ZincAlloy (Client Quit) |
| 09:09:31 | | Quit alexweissman (Ping timeout: 260 seconds) |
| 09:10:12 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 09:18:07 | | Join ZincAlloy [0] (~Adium@ip1f12fb9e.dynamic.kabel-deutschland.de) |
| 09:22:51 | | Quit ZincAlloy (Client Quit) |
| 09:39:11 | | Quit pamaury (Ping timeout: 246 seconds) |
| 10:00 |
| 10:33:02 | | Join johnb3 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 10:36:58 | | Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) |
| 10:36:58 | | Quit pamaury (Changing host) |
| 10:36:58 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 10:53:34 | *** | Saving seen data "./dancer.seen" |
| 10:56:23 | | Quit johnb3 (Ping timeout: 260 seconds) |
| 12:00 |
| 12:51:07 | | Join edhelas [0] (~edhelas@eurosites-gw1.ter1.tc3.par.cust.as8218.eu) |
| 12:53:36 | *** | Saving seen data "./dancer.seen" |
| 12:58:24 | | Quit Moarc (Ping timeout: 256 seconds) |
| 12:59:06 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 13:00 |
| 13:14:04 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
| 13:16:18 | | Quit paulk-minnie (Quit: Leaving) |
| 13:17:01 | | Join xorly| [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) |
| 13:37:14 | | Join johnb3 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 14:00 |
| 14:01:19 | | Join lebellium [0] (~chatzilla@ren77-h01-176-151-188-9.dsl.sta.abo.bbox.fr) |
| 14:06:15 | | Join robertd1 [0] (~as@201.208.231.245) |
| 14:09:24 | | Quit johnb3 (Ping timeout: 248 seconds) |
| 14:10:30 | | Quit JanC (Read error: Connection reset by peer) |
| 14:10:47 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
| 14:10:47 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
| 14:14:53 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 14:48:14 | | Join johnb3 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 14:53:41 | *** | Saving seen data "./dancer.seen" |
| 14:54:01 | | Join TheLemonMan [0] (~root@unaffiliated/thelemonman) |
| 14:57:10 | | Quit Guest66888 (Ping timeout: 244 seconds) |
| 15:00 |
| 15:07:03 | | Join Guest7162 [0] (~Slayer@c-73-86-128-62.hsd1.va.comcast.net) |
| 15:10:58 | | Join guest12345 [0] (d9c3a602@gateway/web/freenode/ip.217.195.166.2) |
| 15:11:04 | | Quit knittl (Ping timeout: 260 seconds) |
| 15:11:08 | guest12345 | hello |
| 15:11:25 | | Join knittl [0] (~knittl@unaffiliated/knittl) |
| 15:11:54 | guest12345 | what are the hardware and system requirements for rockbox? |
| 15:12:19 | guest12345 | does it use an OS or does it run mare metal? |
| 15:13:05 | guest12345 | in what ballpark is the required CPU power and memory? |
| 15:15:53 | | Join robertd11 [0] (~as@201.211.53.103) |
| 15:18:22 | | Quit robertd1 (Ping timeout: 245 seconds) |
| 15:20:17 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 15:23:48 | guest12345 | also on a more practical side the Sansa Clip+ has favorable reviews and is marked as in-production on the wiki but it seems that information is outdated. The Clip+ model is no longer easily available and the supposed successor blackboxwise is Clip Jam. Any idea what's inside that one and if there is good chance running rockbox on it? |
| 15:25:17 | [Saint] | It is a full replacement OS on all but a very small subset of devices |
| 15:25:44 | [Saint] | And, regarding the Clip Jam, yes, and no, it never will. Ever. |
| 15:26:16 | [Saint] | Same with the Sport. |
| 15:26:25 | lebellium | pamaury: do you think you still get something to try out this week? |
| 15:29:51 | guest12345 | what's the problem with the new hardware? |
| 15:30:58 | [Saint] | Not even close to enough resources. |
| 15:31:54 | guest12345 | and what is enough resources? |
| 15:34:12 | [Saint] | 2MB RAM is considered a bare minimum I believe. But you're looking at it wrong I suppose. It isnt like you have any other options than the supported devices. |
| 15:34:43 | [Saint] | Rockbox is built as a unique binary for each supported device |
| 15:35:11 | [Saint] | New ports are often hundreds of man hours work. |
| 15:36:01 | [Saint] | And if you want Rockbox on $DEVICE, you're expected to be the one to facilitate that. |
| 15:40:25 | guest12345 | I am looking for something to run on nRF51822 or nRF52832 or something like that |
| 15:41:30 | [Saint] | Rockbox has a list of supported devices clearly listed on the main page. |
| 15:41:55 | [Saint] | Anything not listed there you're either doing yourself or it plain isnt happening. |
| 15:42:01 | [Saint] | Possibly both. |
| 15:42:34 | guest12345 | that's not a device. those are ARM Cortex M based microcontrollers with bluetooth radio |
| 15:42:36 | [Saint] | It is not a multipurpose OS. It is a targeted OS. |
| 15:42:47 | [Saint] | And, I'm aware. |
| 15:43:12 | [Saint] | It doesn't change the statement. |
| 15:44:04 | guest12345 | if 2MB is bare minimum then it's not going to work. |
| 15:46:07 | guest12345 | Either I need an extra processor to run the controlling software and use the nRF as peripherial or need something much smaller. So much for reusing something with audio codecs and event loop already integrated in one piece |
| 15:58:35 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 16:00 |
| 16:05:57 | | Quit robertd11 (Ping timeout: 256 seconds) |
| 16:15:02 | | Join wo [0] (51d02624@gateway/web/freenode/ip.81.208.38.36) |
| 16:15:44 | wo | pamaury: It seems radio driver in sony uses standard radio v4l2 interface |
| 16:36:53 | | Quit johnb3 (Ping timeout: 244 seconds) |
| 16:42:51 | guest12345 | hm, nRF52832 has a FPU but still only 64k ram |
| 16:43:27 | guest12345 | what is sane interface for connecting audio codec on uderpowered SoC? |
| 16:43:51 | wo | rockbox is almost 100% fixed point so FPU doesn't help much |
| 16:44:21 | wo | guest12345: what you mean? Usually codecs are connected by i2s |
| 16:44:38 | guest12345 | yes, I am aware of FPU being superfluous with all those fine fixed-point codecs |
| 16:45:22 | | Join johnb3 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 16:45:30 | guest12345 | I vaguely recall some spi and/or i2c audio drivers in linux |
| 16:46:13 | guest12345 | nRF52832 has i2s but nRF51822 has only i2c and spi |
| 16:46:46 | guest12345 | also even with soc that has i2s not all kits make it available |
| 16:52:45 | | Quit pamaury (Remote host closed the connection) |
| 16:52:57 | | Join Saratoga [0] (32b117cb@gateway/web/freenode/ip.50.177.23.203) |
| 16:53:27 | Saratoga | guest12345: if you want audio decoding it might make more sense to start with an audio soc and then add Bluetooth |
| 16:53:43 | *** | Saving seen data "./dancer.seen" |
| 16:54:02 | Saratoga | Rather than try to add audio to a device without enough memory or IO |
| 16:57:20 | [Saint] | Well put. |
| 16:57:31 | [Saint] | We're literally spoiled for choice. |
| 16:57:55 | [Saint] | We don't need to grab the shoehorn and jerryrig these things. |
| 16:58:16 | [Saint] | Its a couple of bucks of silicon. |
| 17:00 |
| 17:04:31 | | Join johnb2 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 17:07:29 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
| 17:08:21 | guest12345 | the reason to use nRF5x would be to try codecs other than the default sbc for BT audio |
| 17:08:41 | wo | and btw you can easily create i2s with spi block + a tiny bit of software |
| 17:08:43 | | Nick JanC is now known as Guest90855 (~janc@lugwv/member/JanC) |
| 17:08:44 | | Quit Guest90855 (Killed (niven.freenode.net (Nickname regained by services))) |
| 17:08:44 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
| 17:09:04 | guest12345 | the usefulness of different codecs that is questionable, no doubt |
| 17:10:33 | guest12345 | wo: that sounds useful because i2s is the only extra hardware feature nRF51822 lacks besides cpu power |
| 17:11:38 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 17:14:15 | wo | guest12345: you'd need one free gpio though for channel signaling |
| 17:15:13 | wo | or you can add some ttls to generate channel signaling based purely on clk |
| 17:17:59 | | Quit toehser (Remote host closed the connection) |
| 17:21:17 | | Quit johnb2 (Ping timeout: 245 seconds) |
| 17:23:13 | [Saint] | Hmmm...I think I see now. Did the 'ds' falls off your 'wo'? |
| 17:23:36 | [Saint] | Or is this some odd coincidence? |
| 17:25:49 | wo | [Saint]: 'ds' striped |
| 17:26:47 | wo | 'dz' to be precise |
| 17:27:25 | guest12345 | there is more than enough of gpio on either nRF |
| 17:27:38 | | Join robertd1 [0] (~as@201.208.231.245) |
| 17:27:38 | [Saint] | We really are living in the future. wodz (the s was a typo, sorry) is running in RAID. |
| 17:28:06 | wo | :-) |
| 17:31:04 | | Quit Saratoga (Ping timeout: 260 seconds) |
| 17:51:07 | | Part robertd1 |
| 17:52:24 | | Quit edhelas (Quit: Leaving.) |
| 17:53:27 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
| 18:00 |
| 18:00:03 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 18:04:30 | | Quit johnb3 (Ping timeout: 256 seconds) |
| 18:09:34 | guest12345 | regarding the couple of bucks worth of silicone ... there are chips like CSR8630 which do full BT audio solution in hardware |
| 18:11:07 | guest12345 | and they probably work well enough that if I get one I will never take out the programmable chip an try to do something with it |
| 18:12:39 | [Saint] | Is this a bad thing? |
| 18:12:49 | guest12345 | the other thing is that ESP-3212 has 520kb ram so it looks like more likely target for development than the nRF chips |
| 18:13:27 | guest12345 | it depends |
| 18:14:06 | guest12345 | the blackbox manufacturers try to beat each other by supporting more codecs |
| 18:14:34 | guest12345 | but all you want is one decent codec and be done with it |
| 18:15:11 | guest12345 | sbc is good enough to get some sound across, sure |
| 18:16:42 | | Join girafe [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr) |
| 18:16:58 | guest12345 | I was wondering if something like celt could give better results |
| 18:17:22 | guest12345 | and for what definition of better |
| 18:18:05 | [Saint] | All BT audio is shit, really. |
| 18:18:48 | guest12345 | if you are forced to encode with shitty codec 95% of the time no wonder |
| 18:22:17 | | Quit Guest7162 (Ping timeout: 244 seconds) |
| 18:35:32 | | Join johnb3 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 18:44:54 | | Quit johnb3 (Ping timeout: 260 seconds) |
| 18:45:09 | | Quit wo (Ping timeout: 260 seconds) |
| 18:45:24 | | Join johnb3 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 18:45:27 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:c8a:b501:3ad4:9c86) |
| 18:53:46 | *** | Saving seen data "./dancer.seen" |
| 18:57:16 | | Join saratoga [0] (26615e12@gateway/web/freenode/ip.38.97.94.18) |
| 18:58:59 | saratoga | i think if you want better than SBC that is what APTX is for |
| 18:59:09 | saratoga | but at these bitrates, most subband codecs should do very well |
| 19:00 |
| 19:00:23 | saratoga | not sure CELT really makes sense, the advantage of subband is that you can basically just use some ASIC block to do a subband decomposition and then all you have to do in software is basic quantization and huffman coding |
| 19:02:08 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:05:17 | | Quit saratoga (Quit: Page closed) |
| 19:06:38 | | Nick megal0maniac is now known as Guest99130 (~megal0man@unaffiliated/megal0maniac) |
| 19:06:38 | | Quit Guest99130 (Killed (niven.freenode.net (Nickname regained by services))) |
| 19:06:41 | | Join megal0maniac [0] (~megal0man@unaffiliated/megal0maniac) |
| 19:28:16 | guest12345 | well, aptx is commercial so I need commercial blackbox for *both* ends which is not going to happen |
| 19:29:43 | guest12345 | also I don't think I have an ASIC block for subband decomposition at my disposal |
| 19:30:31 | guest12345 | which is of course amendable by changing the hardware |
| 19:33:21 | guest12345 | CELT authors boast in some presentation how the lite version of the codec is undemanding of CPU resources and how it degrades gracefully on lower bitrates compared to some other codec |
| 19:33:53 | guest12345 | which does not mean there is no better codec for the job |
| 19:34:53 | | Join Guest7162 [0] (~Slayer@c-73-86-128-62.hsd1.va.comcast.net) |
| 19:35:07 | guest12345 | Especially given AC3 or what codec passthrough is a thing in PC audio drivers you could avoid recoding if your audio happens to be compatible |
| 19:35:42 | guest12345 | but it saves processing power only on the PC where you need it least |
| 19:47:28 | | Join Guest66888 [0] (~Slayer@c-73-86-128-62.hsd1.va.comcast.net) |
| 19:50:07 | | Quit Guest7162 (Ping timeout: 244 seconds) |
| 19:51:39 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:6584:a8a0:7ec4:fe4) |
| 19:54:01 | [Saint] | MUST you use a wireless transfer? |
| 19:55:33 | | Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) |
| 19:55:49 | saratoga | why not just buy something that uses APTX and use that? |
| 19:55:57 | | Part ZincAlloy |
| 20:00 |
| 20:14:02 | | Quit johnb3 (Ping timeout: 260 seconds) |
| 20:53:47 | *** | Saving seen data "./dancer.seen" |
| 20:54:46 | | Quit xorly| (Quit: I quit, that is all) |
| 21:00 |
| 21:06:58 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 21:11:18 | lebellium | pamaury: not on your list but might the NWZ-M504 be linux-based too? |
| 21:11:52 | lebellium | I assume the B-series isn't. But the M500 is more high-end |
| 21:18:33 | | Join Guest7162 [0] (~Slayer@c-73-86-128-62.hsd1.va.comcast.net) |
| 21:21:34 | | Quit Guest66888 (Ping timeout: 244 seconds) |
| 21:27:45 | pamaury | it's not on sony open source website so I assume not |
| 21:27:55 | pamaury | give the form factor and the screen, it seems very unlikely |
| 21:28:47 | lebellium | only color-display devices run linux? |
| 21:34:16 | guest12345 | saratoga: I can buy something that uses aptx but I cannot reliably (or at all) get aptx on the other side |
| 21:34:38 | guest12345 | so the aptx part is useless either way |
| 21:35:32 | guest12345 | on the other hand, if I get something where the codec can be programmed I can set up both sides to use any opensource codec of my choice |
| 21:39:24 | guest12345 | [Saint]: I am quite well set up for wired transfer. Unfortunately, it's impractical at times. So for those occasions I want wireless. I tried off-the shelf FM analog headset which was comfortable and sounded terrible and a BT headset which sounds passable and is not very comfortable. |
| 21:41:24 | guest12345 | I find lack of choice in wireless headsets in general so I am looking for modular solution that can turn wired headset or speakers into wireless when needed and gives me all the choice of wired equipment. The choice of blackboxes for this purpose is not very good either. |
| 21:42:43 | | Join johnb3 [0] (~johnb2@pD9565650.dip0.t-ipconnect.de) |
| 21:42:51 | guest12345 | so building my own sounds like a fun project that might give something usable not easily obtained otherwise |
| 21:44:27 | pamaury | lebellium: I'm not a 100% sure but given the hardware in the linux based player, it wouldn't fit in a small device, and it makes no sense to have such a powerful cpu in such a small device I think. But Sony open source page remains the reference anyway |
| 21:44:44 | pamaury | I would say try to put te M500 in recovery mode and see what the USB ID is |
| 21:46:59 | lebellium | I don't have it |
| 21:47:17 | lebellium | and won't buy it if porting Rockbox to it is not possible |
| 21:48:04 | lebellium | but I like those kinds of USB-key players like Samsung U series and Sony B series |
| 21:48:51 | lebellium | it's a pity we don't have any of them supported |
| 21:49:25 | pamaury | no one seems to buy them... |
| 21:50:03 | lebellium | If Samsung released 7 Models from U1 to U7 and Sony even more, it's probably cause these are the bestseller |
| 21:50:31 | lebellium | I'm sure many people buy them, but those people are not around :P |
| 21:51:43 | pamaury | the problem with those players is that they tend to use super underpowered cpus with low memory |
| 21:53:58 | lebellium | YP-U5 and U6 use a Sigmatel STMP3770 like the Creative you own |
| 21:54:06 | lebellium | Sony B-series I don't know |
| 21:54:12 | pamaury | and this one only as 512 KB of RAM |
| 21:54:28 | pamaury | the STMP3770 is quite unlike the other STMP37xx |
| 21:54:58 | lebellium | 512 KB instead of 2 MB required? |
| 21:55:02 | pamaury | yes |
| 21:55:22 | lebellium | ah yes, you actually only completed the port for the 3780 devices |
| 21:56:00 | pamaury | we have a port for the STMP3700 (ie STMP3700/3710/3730) and STMP3780 |
| 21:56:12 | pamaury | but with only 512KB, it's hopeless for the STMP3770 |
| 21:56:57 | pamaury | maybe 1MB could be enoug but that remains to be seen |
| 21:57:07 | | Quit Galois (Ping timeout: 245 seconds) |
| 21:58:25 | lebellium | ok |
| 22:00 |
| 22:00:45 | lebellium | when do you think you get something to try out on my A850? |
| 22:05:18 | pamaury | this week-end, I have been very busy this week, more than I expected |
| 22:06:08 | lebellium | ok |
| 22:07:15 | | Quit akaWolf (Ping timeout: 250 seconds) |
| 22:15:29 | | Quit johnb3 (Ping timeout: 250 seconds) |
| 22:19:01 | [Saint] | guest12345: Have you considered using Chromecast Audio? |
| 22:19:21 | [Saint] | Seems like a very obvious solution to me, and fits the modular requirement. |
| 22:19:59 | [Saint] | Going by the solutions you have proposed thus far, I believe it would also fit the requirement of form factor, even though you haven't directly set one. |
| 22:21:34 | [Saint] | One benefit with Chromecast Audio would be very widespread off-the-shelf compatibility with existing solutions. Almost anything that can beam WiFi is suitable for output, and anything that has a 3.5mm stereo TRRS jack are eligible for input. |
| 22:24:56 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.0/20161104212021]) |
| 22:33:36 | guest12345 | http://www.omgubuntu.co.uk/2016/08/cast-ubuntu-desktop-audio-chromecast for the send part |
| 22:33:40 | | Quit alexweissman (Remote host closed the connection) |
| 22:34:01 | guest12345 | for the receive part there is only 1 device which does not include a battery afaict |
| 22:34:26 | guest12345 | so it's powerbank + the chromecast audio device |
| 22:35:18 | guest12345 | also the protocol is not well defined |
| 22:35:39 | guest12345 | what the 'search for chromecast devices' entails? |
| 22:37:34 | guest12345 | are the devices paired afterwards in some way or do you connect any random transmitter to any random receiver at any time? |
| 22:38:19 | guest12345 | how does the transmitter actually connect to the receiver with WiFi when it also uses WiFi for its own connectivity? |
| 22:38:45 | guest12345 | do you need a WiFi network into which both devices are connected? |
| 22:39:31 | guest12345 | if so, is WPA enterprise supported? is authentication using random web forms supported? |
| 22:40:54 | guest12345 | [Saint]: I guess chromecast does not seem like that great idea after all |
| 22:43:54 | guest12345 | but did not know such thing existed. kind of nice gadget until you try to think about usability |
| 22:44:33 | [Saint] | The questions you're asking are all very clearly answered in Google's own documentation. |
| 22:45:48 | [Saint] | I believe it is the most suitable, and cheapest, off-the-shelf solution that does what you want it to do (at least in the most part if you're a little liberal with the requirements). |
| 22:46:27 | [Saint] | And it has the benefit of not using BT(LE) and can do straight passthrough without transcode. |
| 22:47:55 | guest12345 | From the documentation it shows you connect both the source device and the sink to common WiFi network |
| 22:49:01 | scorche|sh | i think we have gotten a bit offtopic... |
| 22:49:20 | guest12345 | the documentation does not specify what network is supported so I would expect WPA PSK only. Not WPA enterprise, not random web form |
| 22:49:34 | [Saint] | We have indeed. To be honest it was offtopic as soon as we established the silicon desired wouldn;t ever run Rockbox. |
| 22:49:55 | [Saint] | It does WPA-Enterprise. |
| 22:50:17 | guest12345 | So to connect you either need an extra device (AP) or use your WiFi for SW hotspot and not own connectivity |
| 22:53:10 | [Saint] | In all fairness, who doesn't have wifi deployed? The solution you proposed initially sure as shit didn't sound portable. At least not portable in a practical sense. |
| 22:53:50 | *** | Saving seen data "./dancer.seen" |
| 22:54:16 | [Saint] | Or, even if we say it is portable, who doesn't have a hotspot capable smartphone? |
| 22:54:27 | __builtin | would writing a software bitmap antialiasing filter for rockbox be a good idea? |
| 22:54:57 | __builtin | mainly, would any target be able to run it at realtime or faster? |
| 22:55:13 | [Saint] | You had some (very real) concerns about sound quality with Bluttooth( Low Energy). These concerns are negated with a solution such as Chromecast Audio. |
| 22:55:26 | [Saint] | If you like we can move this to #rockbox-community |
| 22:55:37 | [Saint] | It's our 'anything goes' sister channel. |
| 23:00 |
| 23:02:59 | | Quit Senji_ (Ping timeout: 250 seconds) |
| 23:05:24 | | Join Senji_ [0] (~Senji@85.187.103.250) |
| 23:11:08 | | Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-51a.dhcp6-bl.indiana.edu) |
| 23:11:15 | | Quit krabador (Quit: Leaving) |
| 23:13:19 | | Quit The_Prospector|2 (Quit: when in doubt, kernel panic) |
| 23:21:55 | | Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) |
| 23:29:05 | | Quit pamaury (Ping timeout: 256 seconds) |
| 23:38:13 | | Quit alexweissman (Remote host closed the connection) |
| 23:43:37 | | Quit paulk-collins (Quit: Leaving) |
| 23:45:16 | [Saint] | guest12345: as this /is/ Rockbox related...you would want to look at, and can compile and play with: |
| 23:45:16 | [Saint] | https://github.com/Rockbox/rockbox/tree/master/lib/rbcodec/test |
| 23:45:25 | [Saint] | Which is derived from: |
| 23:45:26 | [Saint] | http://gerrit.rockbox.org/r/#/c/135/ |
| 23:45:44 | [Saint] | fs-bluebot: g135 |
| 23:45:45 | fs-bluebot | Gerrit review #135 at http://gerrit.rockbox.org/r/135 : Add the warble test program. by Sean Bartell |
| 23:46:52 | [Saint] | (warble was a POC library created for us under guidance and supervision during a Google Summer Of Code event) |
| 23:48:58 | [Saint] | As you can see from warble.c, assuming you're familiar with or have a basic understanding of the language, the POC includes a basic playback library and hooks to the codecs. |
| 23:49:58 | [Saint] | There's support for start/stop/pause/seek/play-from-offset/and I believe also some rudimentary playback speed control) |
| 23:50:20 | [Saint] | Oh, as well as volume control and replaygain. |
| 23:52:37 | | Join alexweissman [0] (~alexweiss@149-160-180-37.dhcp-bl.indiana.edu) |
| 23:53:43 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
| 23:54:11 | [Saint] | guest12345: as you can (or might be able to...) see on warble.c around like 540 there is some breathing room in (input_buffer). |
| 23:56:14 | [Saint] | It is currently 32*1024b - this doesn't give you a hell of a lot of breathing room really, come to think of it, but you could very easily slim this down quite significantly and maintain realtime playback. |
| 23:58:36 | [Saint] | You could also conceivably remove the entirety of the metadata parsing and display passthrough, which IIUC you will have no use for. |
icon identifies that the person is a core developer (has commit access).