| 00:02:27 | *** | Saving seen data "./dancer.seen" |
| 00:10:26 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 00:14:51 | | Quit dconrad (Ping timeout: 255 seconds) |
| 01:00 |
| 01:38:37 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:359b:249c:dcdd:f70f) |
| 01:43:14 | | Quit ZincAlloy (Ping timeout: 255 seconds) |
| 01:49:16 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:359b:249c:dcdd:f70f) |
| 01:53:51 | | Quit ZincAlloy (Ping timeout: 255 seconds) |
| 01:59:42 | | Quit Bobathan_ (Ping timeout: 268 seconds) |
| 02:00 |
| 02:02:28 | *** | Saving seen data "./dancer.seen" |
| 02:13:10 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 02:17:34 | | Quit ZincAlloy (Ping timeout: 246 seconds) |
| 04:00 |
| 04:02:31 | *** | Saving seen data "./dancer.seen" |
| 04:25:04 | | Join Telehubis [0] (~Telehubis@dynamic-78-10-123-181.ssp.dialog.net.pl) |
| 04:25:14 | Telehubis | amachronic: thanks! |
| 04:26:05 | | Quit Telehubis (Client Quit) |
| 04:55:34 | | Quit ufdm (Read error: Connection reset by peer) |
| 05:00 |
| 05:18:21 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 06:00 |
| 06:02:32 | *** | Saving seen data "./dancer.seen" |
| 06:47:38 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 06:59:30 | speachy | huh, now coverity's emails get through promptly. |
| 07:00 |
| 07:20:04 | _bilgus | ideas on checking filedescriptors before passing to close() |
| 07:22:32 | _bilgus | I think all sane implementations should be fine.. |
| 07:26:16 | rb-bluebot | Build Server message: New build round started. Revision 48c29e3b3b, 303 builds, 8 clients. |
| 07:38:04 | rb-bluebot | Build Server message: Build round completed after 708 seconds. |
| 07:38:06 | rb-bluebot | Build Server message: Revision 48c29e3b3b result: All green |
| 07:40:14 | rb-bluebot | Build Server message: New build round started. Revision 8cd4b8da84, 303 builds, 8 clients. |
| 07:50:18 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 07:51:28 | rb-bluebot | Build Server message: Build round completed after 673 seconds. |
| 07:51:31 | rb-bluebot | Build Server message: Revision 8cd4b8da84 result: All green |
| 07:52:28 | yang | which is the most modern rockbox player, that is being fully supported? |
| 07:55:06 | | Join yang-idle [0] (~yang@user/yang) |
| 07:59:47 | speachy | munkis: btw, I didnt' see anything untowards in the buildserver log, your builder disconnected at some point and never came back. |
| 08:00 |
| 08:00:58 | _bilgus | I never did figure out how I was supposed to add a new build to coverity |
| 08:02:33 | *** | No seen item changed, no save performed. |
| 08:17:19 | Arsen | how can I expand on https://www.rockbox.org/wiki/IpodRuntime? I ran the battery benchmark with a random mix of media, around 5k tracks, majority of which were 320k mp3s, but with some flacs in there too, which should immitate the average usecase, and people may like to see my results too |
| 08:18:25 | _bilgus | you mean like you want to edit it? |
| 08:19:04 | _bilgus | just need a wiki account |
| 08:23:06 | Arsen | ah, sure |
| 08:24:15 | speachy | Arsen: send me a message with your full anme and email address, and I'll create the account for you. |
| 08:24:28 | speachy | (spammers are _still_ slamming the disabled registration page. sigh) |
| 08:25:47 | speachy | yang: The FiiO M3K is probably the answer to your question. But there are a lot of options depending on your dsired feature and prive points. |
| 09:00 |
| 09:13:41 | | Quit massiveH (Quit: Leaving) |
| 09:36:54 | yang-idle | which is a more recent fully supported player? |
| 09:37:56 | yang-idle | like, made after 2015? |
| 09:40:04 | yang-idle | ok speachy, thank you for reply |
| 10:00 |
| 10:02:34 | *** | Saving seen data "./dancer.seen" |
| 10:05:02 | yang-idle | is there any sound quality difference from listening music from fiio m3k compared to listening mp3s from an xiaomi mobile phone (newbie question) |
| 10:05:37 | speachy | ...maybe? |
| 10:19:45 | Arsen | I reckon that's pretty likely, but who knows |
| 10:19:56 | Arsen | depends on the dac in the phone/headphone adapter |
| 10:28:45 | speachy | plus quality of the headphones and the actual music files.. |
| 10:31:30 | | Quit munkis (Ping timeout: 252 seconds) |
| 10:33:45 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 10:37:49 | munkis | I was trying to figure out if it was dns issues, but it looks like it's not even on my network. |
| 10:38:03 | munkis | rebooting itis gonna suck. |
| 10:38:47 | speachy | munkis: am I correct in rememmbering it's a laptop shoved somewhere? |
| 10:38:56 | speachy | maybe it overheated or got unplugged or something like that. |
| 10:39:45 | munkis | just checked the hardware link light is light on both the builder and the laptop. |
| 10:40:29 | munkis | that's why I didn't think to check the router control panel untill a few minutes ago. |
| 11:00 |
| 11:06:29 | rb-bluebot | Build Server message: New build round started. Revision f0e3a36fe4, 303 builds, 8 clients. |
| 11:06:37 | yang-idle | speachy i looked up fiio m3k, its nice and costs 85 eur. are there other similar devices on the new market, or is m3k best supported (how many devs own one?) |
| 11:07:13 | speachy | it's the cheapest supported device that is still actively sold/supported by the manufacturer. |
| 11:08:03 | yang-idle | is it required to open it and solddr/desolder anything to install rockbox firmware? |
| 11:08:11 | speachy | no. |
| 11:10:09 | braewoods | yang-idle: anything "stable" doesn't require that unless it needs repairs. |
| 11:12:17 | speachy | the same goes for "unstable" ports. There has to be a reasonable installation method documented that does not require disassembly or special tools. |
| 11:17:40 | rb-bluebot | Build Server message: Build round completed after 670 seconds. |
| 11:17:41 | yang-idle | ok great |
| 11:17:42 | rb-bluebot | Build Server message: Revision f0e3a36fe4 result: All green |
| 11:18:36 | yang-idle | as i managed to briefly glance the instructions, m3k doesnt use u-boot to boot? |
| 11:30:41 | speachy | nope |
| 11:49:29 | braewoods | yang-idle: every embedded platform is different |
| 12:00 |
| 12:02:37 | *** | Saving seen data "./dancer.seen" |
| 12:18:26 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:adb3:bc70:bf84:fa90) |
| 12:47:18 | | Quit dys (Remote host closed the connection) |
| 13:00 |
| 13:17:35 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 14:00 |
| 14:02:40 | *** | Saving seen data "./dancer.seen" |
| 14:19:50 | | Join dys [0] (~dys@user/dys) |
| 15:00 |
| 15:00:07 | | Quit akaWolf (Ping timeout: 268 seconds) |
| 15:26:45 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 15:47:37 | yang | I like that it's possible to use dual boot with fiio m3k |
| 15:58:48 | | Quit lebellium (Quit: Leaving) |
| 16:00 |
| 16:02:43 | *** | Saving seen data "./dancer.seen" |
| 16:10:59 | braewoods | yang: most ports have that. there's only one i know of that doesn't. |
| 17:00 |
| 17:28:56 | | Quit munkis (Remote host closed the connection) |
| 18:00 |
| 18:02:47 | *** | Saving seen data "./dancer.seen" |
| 18:29:58 | | Quit ZincAlloy (Quit: Leaving.) |
| 18:30:09 | | Quit tomato (Ping timeout: 255 seconds) |
| 18:30:37 | | Join tomato [0] (~tomato@user/tomato) |
| 19:00 |
| 19:47:46 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 19:49:44 | dconrad | who would be the person to talk to about the pcm/software volume code? Presumably there's someone who knows it like the back of their hand? |
| 19:52:16 | speachy | hmm. of us active folks, I'm probably it |
| 19:53:17 | dconrad | sweet - do you think you could take a look at g#3603 sometime and see if I'm on the right track to do 32-bit software volume scaling? |
| 19:53:20 | rb-bluebot | Gerrit review #3603 at https://gerrit.rockbox.org/r/c/rockbox/+/3603 : Start of 32-bit software volume for native players by Dana Conrad |
| 19:53:51 | dconrad | it's a pretty rough copy-paste job from the hosted port, but I'm not sure what else might need to be changed to make it work |
| 19:54:53 | speachy | the internal audio path is 16-bit. that's baked into pretty much everything |
| 19:54:54 | dconrad | I think the general idea is use the digital volume factor for the actual scaling up to the 32-bit format (conveniently enough, we already have a double buffer, right?) |
| 19:55:26 | speachy | yes, but you're going to have to do it in the target pcm driver, by faking HW volume control |
| 19:55:28 | dconrad | as far as I can tell, the double buffer is the last thing before the port-specific code/dma takes over |
| 19:55:59 | dconrad | so I guess I thought it might make sense to make that 32-bit |
| 19:56:42 | dconrad | maybe that's not a good approach? |
| 19:56:43 | speachy | moving the whole core to being able to handle >16bpp wouldn't be a bad thing, but it's a pretty substantial undertaking. |
| 19:57:03 | speachy | I'd stick to doing it within the pcm driver for the time being |
| 19:57:15 | dconrad | alright, safer anyway I suppose |
| 19:58:42 | dconrad | so it would probably actually need another buffer after pcm_dbl_buf, or bypass pcm_sw_volume.c entirely? |
| 19:59:04 | speachy | the latter. you can look at the hosted pcm alsa driver for an example |
| 19:59:13 | dconrad | alright, sweet |
| 19:59:36 | speachy | the whole thing should be pretty easy to #ifdef away for targets that have hw volume control |
| 20:00 |
| 20:00:07 | speachy | thankfully on the erosq we have lots of RAM and double the CPU performance of the second-closest SoC. :) |
| 20:01:33 | dconrad | I did see it's 1 GHz, it truly is 2021! |
| 20:02:15 | dconrad | (if only the aic module did 32-bit audio data to the dac...) |
| 20:02:48 | *** | Saving seen data "./dancer.seen" |
| 20:04:12 | speachy | hmm, I'd have a look at the driver in the m3k linux kernel sources. That needed needed 32-bit audio supplied. |
| 20:04:41 | dconrad | I imagine they would have just truncated it down to 24-bit...? |
| 20:04:57 | dconrad | I suppose I aught to see if that's true |
| 20:05:10 | speachy | possibly.. but confirming what was done where would be informative |
| 20:06:04 | dconrad | oh god now I have to remember how that codebase is organized haha |
| 20:10:31 | speachy | I wonder. might also be conceivable that the codec is set to 32-bit @ X KHz, but the AIC thinks it's at 16-bit @ 2X KHz. same number of bits in the same amount of time either way. |
| 20:11:27 | dconrad | that would be weird |
| 20:11:40 | dconrad | I mean, there's no way that would work though, right? |
| 20:11:56 | dconrad | oh, no wait I think I get it |
| 20:11:56 | speachy | no inherent reason why not; as long as the bit ordering is set correctly on both ends |
| 20:12:11 | dconrad | oh that would be very clever if it would work |
| 20:12:40 | speachy | hardware folks being "clever" is responsible for half my missing hair. :D |
| 20:12:59 | dconrad | lol hey at least it's exciting |
| 20:13:57 | dconrad | ...except you would have to do 2 L samples in a row, then 2 R samples, as far as the AIC knows. Not sure if it would let you do that? |
| 20:15:46 | speachy | depends; typically things switch L/R on every clock cycle. |
| 20:16:38 | speachy | but yeah, might have to repack the data manually on the host side. |
| 20:19:46 | speachy | I guess it ultimately depends on what the PCM510x codec accepts −− do ou have to clock out the entire L or R sample? |
| 20:21:17 | speachy | ...nope, it appears that it needs the entire sample clocked out before LRCK toggles. |
| 20:22:22 | dconrad | ah bummer |
| 20:22:47 | speachy | but if you're doing rejiggering of the samples anyway, there's nothing stopping you from manually re-interleaving them. |
| 20:23:54 | speachy | wait, nevermind. the AIC's going to toggle LRCK after 16/24 bits anyway, so bah. |
| 20:24:11 | dconrad | yeah that was going to be my next question hah |
| 20:25:04 | dconrad | why they didn't just add 32-bit mode I don't get... they already require a 32-bit container for 24-bit audio anyway |
| 20:25:26 | speachy | the AIC FIFO requires 32bit padded samples for >16bit data anyway |
| 20:25:35 | speachy | yep |
| 20:25:47 | dconrad | just a weird omission |
| 20:28:30 | speachy | the mainline driver for the ingenic AIC is limited to 16bit @ 48KHz |
| 20:30:03 | speachy | ingenic kernel is 24bit @ 96KHz |
| 20:30:14 | dconrad | ... one more weird possibility: maybe tell it it's doing "4 channel" stereo, packed 16-bit? |
| 20:30:55 | dconrad | Then it, according to the programming manual anyway, does R1 R0, L1 L0? |
| 20:30:57 | speachy | the pcm5102 doesn't support that so it's moot. |
| 20:31:14 | dconrad | I guess I mean the AIC |
| 20:31:25 | speachy | that too. two channels only |
| 20:31:31 | dconrad | ah dang |
| 20:31:45 | speachy | (well, it can automatically do mono-to-stereo promotion) |
| 20:32:13 | dconrad | I thought maybe the AIC could do "4 channels" that might happen to look like 2 channels to the dac |
| 20:32:51 | speachy | it supports a non-pcm mode, allowing arbitrary data |
| 20:33:43 | speachy | but that might be sp/dif only, don't know if the digital interface would be compatible with the pcm5102 |
| 20:36:44 | dconrad | how do more than 2 channels over i2s work anyway? |
| 20:37:18 | dconrad | you've got bit clock, l/r clock, and the system clock, how would you indicate more than 2 channels? |
| 20:39:01 | speachy | depends on the codec's needs. |
| 20:39:36 | speachy | the "LRCK" is just an edge-triggered "next sample" indication |
| 20:41:16 | dconrad | so the dac would just assume that for instance, it would go perhaps l1 r1 l2 r2 regardless? |
| 20:41:31 | dconrad | I guess that makes sense |
| 20:54:05 | speachy | well, as long as the transmitter and receiver both agree on the logical sample ordering... who cares. :) |
| 20:58:55 | dconrad | here's another baffling thing in the programming manual... it claims that 32-bits are always clocked out regardless of the sample bit depth anyway (if I'm reading it right) |
| 20:59:12 | dconrad | just that it's padded with 0's out to 32 |
| 20:59:18 | speachy | yes, unless you're using packed 16-bit mode |
| 20:59:39 | speachy | (If I read it correctly) |
| 20:59:51 | dconrad | just kinda baffling haha |
| 21:00 |
| 21:00:39 | speachy | if you look at the pcm5102 manual, it seems to indicate that any data clocked in after what it needs for the given sample will be ignored. |
| 21:00:53 | dconrad | I think amachronic has said there's a lot of incorrect/undocumented behavior too in the PM |
| 21:01:15 | speachy | there always is for non-mass-market parts like this |
| 21:01:35 | speachy | but it's still worht looking at the fiio kernel sources |
| 21:01:50 | speachy | since it's such a hacky mess they might have done something that is undocumented |
| 21:02:00 | dconrad | that makes sense |
| 21:05:26 | speachy | doesn't look like it at first glance. |
| 21:06:13 | dconrad | it's pretty vanilla? |
| 21:06:25 | | Join F3l1x_10m_ [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 21:09:13 | speachy | at least the jz47xx i2s drivers are. |
| 21:09:40 | speachy | they might have hacked someting completely independent in there |
| 21:09:54 | | Quit F3l1x_10m (Ping timeout: 240 seconds) |
| 21:10:06 | dconrad | I mean, those devices actually have... y'know... volume controls |
| 21:10:17 | dconrad | so no need for wizardry |
| 21:11:13 | speachy | actually now that I think about it, the m3k uses the x1000's built-in codec so this is all moot |
| 21:11:28 | speachy | alsa probably truncates the 32-bit audio to 24-bit |
| 21:12:21 | speachy | the m5 kernel has some custom stuff |
| 21:12:23 | dconrad | ... how could that be? I was talking to amachronic about that and he was saying the internal codec is itself a dac (goes like aic −−> icodec) |
| 21:12:48 | speachy | it's not using the i2s controller. |
| 21:13:20 | dconrad | not using aic at all? |
| 21:13:23 | speachy | the m3k isn't technically using the aic, just the i2s. |
| 21:13:36 | speachy | s/just/not/ |
| 21:13:52 | dconrad | huh |
| 21:14:17 | speachy | ie "PCM interface" for the latter, "AIC" for the former. Chapter 7 and 8 of the Programming manual, respectively. |
| 21:15:19 | speachy | no wait, I might be wrong there. might be an internal pinmux going on. |
| 21:16:14 | speachy | nevermind, you're right, the AIC is bolted onto the side of the I2S interface, which is muxed with the external pins. |
| 21:16:34 | dconrad | ok, yeah that tracks with amachronic's explanation |
| 21:17:53 | dconrad | I will admit I got excited reading the icodec documentation due to all the volume control stuff, but it wasn't clear to me that it cannot drive an external i2s dac |
| 21:18:14 | dconrad | there is no free lunch, apparently :-P |
| 21:18:16 | speachy | and the m3k/m5 kernels have a non-mainlined ingenic alsa driver. |
| 21:19:02 | speachy | which is hacked further by FiiO. :D |
| 21:19:26 | | Join f1reflyylmao [0] (~f1refly@p4fc47709.dip0.t-ipconnect.de) |
| 21:19:32 | | Quit f1refly (Ping timeout: 255 seconds) |
| 21:19:40 | speachy | supposedly handling 384KHz sample rate... |
| 21:19:44 | | Nick f1reflyylmao is now known as f1refly (~f1refly@p4fc47709.dip0.t-ipconnect.de) |
| 21:20:30 | dconrad | that seems a wee bit overkill |
| 21:20:36 | speachy | only 24-bit from what I can tell so far |
| 21:21:26 | | Quit braewoods (Quit: WeeChat 2.8) |
| 21:22:02 | speachy | 8/16/24 I should say |
| 21:22:41 | speachy | actually I take that back, the PCM driver is 8/16 only |
| 21:22:58 | dconrad | oof |
| 21:23:27 | speachy | but I2S is up to 24 bits |
| 21:24:06 | speachy | assuming of course the kernel sources we have are what they're using on the m3k (which we know they're not) |
| 21:24:45 | dconrad | so either the AIC or PCM peripherals can use the I2S pins, as far as I can tell? |
| 21:25:45 | speachy | more accurate to say the I2S peripheral is switchable between the internal AIC or external pins |
| 21:26:31 | dconrad | oh, sure |
| 21:28:07 | speachy | so to summarize a long winded bit of exposition, it's most likely the erosq's driver is truncating 32-bit audio samples to 24-bit before sending them to the pcm5102 |
| 21:28:46 | dconrad | that makes sense |
| 21:29:49 | dconrad | I'll figure on trying to truncate the audio data to 24-bits to do the same |
| 21:32:52 | speachy | just do the existing 32-bit conversion+scaling and then >>8 before dumping over |
| 21:33:25 | dconrad | ok, I was wondering if that was the proper way to convert it |
| 21:33:45 | dconrad | or if it was more complicated than just bit shift |
| 21:34:36 | speachy | it's not optimal but it should be good enough to get the audio pipeline sorted out. |
| 21:35:24 | speachy | I don't recall if amachronic ever got circular DMA working but I suspect we're going to need it, especially at higher sample rates. |
| 21:35:59 | speachy | (since we're going to be doing a lot more work to refill the buffers) |
| 21:36:45 | dconrad | there is a note on the m3k's wiki page about using too much dsp at high sample rates, I think. Not sure if it's still applicable though |
| 21:40:59 | | Join braewoods [0] (~braewoods@user/braewoods) |
| 22:00 |
| 22:02:52 | *** | Saving seen data "./dancer.seen" |
| 22:47:26 | | Quit dconrad () |
icon identifies that the person is a core developer (has commit access).