--- Log for 27.09.121  Server: sodium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot_  Version: Dancer V4.16  Started: 1 day and 5 hours ago

00.54.20 Quit    nephi (Remote host closed the connection)
01.12.40 Quit    scorche (Ping timeout: 252 seconds)
01.16.58 ***     Saving seen data "./dancer.seen"
01.32.00 Join    scorche [0] (~scorche@70-59-234-150.phnx.qwest.net)
01.32.00 Quit    scorche (Changing host)
01.32.00 Join    scorche [0] (~scorche@user/scorche)
01.48.34 Quit    CasBot (*.net *.split)
01.48.43 Join    CasBot [0] (~matrixbot@connolly.tech)
01.54.42 Quit    hook54321 (*.net *.split)
01.54.43 Quit    user890104 (*.net *.split)
01.54.43 Quit    Rondom (*.net *.split)
01.54.43 Quit    olspookishmagus (*.net *.split)
01.54.43 Quit    ParkerR (*.net *.split)
01.54.52 Join    olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr)
01.54.52 Join    ParkerR [0] (ParkerR@znc.withg.org)
01.54.56 Join    user890104 [0] (~Venci@freemyipod/user890104)
01.54.56 Join    Rondom [0] (~rondom@user/rondom)
01.55.29 Join    hook54321 [0] (sid149355@user/hook54321)
03.17.01 ***     Saving seen data "./dancer.seen"
05.17.06 ***     No seen item changed, no save performed.
06.38.30 #       <speachy> forgot to enable the nightly build/manual/voice cronjobs...oops!  Re-running them by hand now, so far so good.
06.39.28 #       <speachy> this nightly stuff (especially voice builds) will be where we see the main impact from the reduced CPU performance vs the old host.
07.14.14 Join    petur [0] (~petur@77.77.179.66)
07.15.30 #       <speachy> all finished.  everything took under an hour.
07.17.08 ***     No seen item changed, no save performed.
07.40.50 #       <braewoods> speachy: found the issue. maybe it's time to transition our python scripts to 3. it was complaining about missing python install. debian only ships python3 by default now. it's still available but who knows for much longer.
07.41.57 #       <braewoods> ok. installed the packages to keep it building.
07.43.15 #       <braewoods> i'll clean up after I confirm this is working
07.43.47 #       <braewoods> builder back online here
07.44.25 #       <braewoods> the distributions i've been using have made it clear they're phasing out python 2.
07.44.40 #       <braewoods> it's probably a good idea to make sure we're ready for a python 3 only future.
07.45.29 #       <braewoods> i can work on that later this week when i'm done with some more urgent projects
08.32.38 Join    MarcAndersen [0] (~no_znepna@85.218.172.116)
08.35.42 #       <MarcAndersen> Will you still be doing voice builds in the future, because if not I'll have to do it when I update.
08.39.20 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
08.48.07 #       <braewoods> MarcAndersen: i doubt it. they're expensive so they'll probably be done on a different schedule.
08.48.48 #       <MarcAndersen> Maybe you could set it to only english?
08.52.12 #       <braewoods> ask speachy; i don't deal with infrastructure stuff like this.
08.52.20 #       <braewoods> i just provide some builders.
08.57.12 Quit    speachy (Quit: WeeChat 3.2)
08.58.12 Join    speachy [0] (~speachy@rockbox/developer/speachy)
08.58.12 Mode    "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
08.59.07 #       <speachy> braewoods nothing in the builds or infra should use python2 -- I don't even have py2 installed on any of my builders at the moment.
08.59.35 #       <speachy> what specifically broke?  Or was it just a missing symlink to /usr/bin/python ?
08.59.57 #       <braewoods> speachy: missing symlink. i assumed it was expecting python2 since that was python2 for a long time.
09.02.12 #       <speachy> hmm, it's the thumb-cc.py script.  Really should rewrite that in perl so nothing in the normal build flow needs python.
09.03.07 #       <speachy> or better yet, ditch it altogether.  
09.03.15 #       <braewoods> what does it do even?
09.04.04 #       <speachy> tries to force thumb mode for certain ARM targets, and if it fails, retry without it.
09.04.47 #       <braewoods> does it help with any of them? it sounds like something we could just configure on a per target basis
09.05.10 #       <speachy> it's likely a holdover from older toolchains that didn't handle things reliably
09.06.05 #       <speachy> or, possibly, some specific source files (probably external stuff we pulled in) aren't thumb-clean and this was deemed the simplest way to handle it.
09.07.10 #       <braewoods> to put it bluntly, this script looks like something we could do in shell if it was important to keep
09.07.31 #       <braewoods> it basically does some argument manipulation and pipeline setup.
09.07.34 #       <braewoods> stuff shell is designed for.
09.07.37 #       <speachy> clipv1, m200v4, c200v2 only (ie really resource-constrained ams v1 targets)
09.11.31 #       <speachy> so the script always turns on -mthumb-interwork, and tries to compile with -mthumb, and if that fails, recompiles without it.
09.13.18 #       <speachy> and... boom, yeah, it's inline asm that's getting us in random places.
09.17.11 ***     Saving seen data "./dancer.seen"
09.17.25 #       <braewoods> speachy: i'll see if i can write a shell replacement
09.17.52 #       <speachy> shell's gonna be pretty ugly
09.18.17 #       <braewoods> true but not many options.
09.18.18 #       <speachy> perl's going to be a lot closer to a 1:1 mapping of how this already works, and we already need perl.
09.18.46 #       <braewoods> ok, then you give it a whirl then.
09.18.50 #       <braewoods> :D
09.19.00 #       <braewoods> i don't know perl well enough
09.36.32 #       <MarcAndersen> I found out that the voice crackling only happens when my clip zip is running on battery and not when it's connected, how can that be?
09.37.59 #       <speachy> ....current draw?  
09.39.16 #       <MarcAndersen> it's on 412e76b487
09.50.24 #       <_bilgus_> MarcAndersen, likely your device needs the voltage level for the processor increased by a bit, my guess would be that its browning out on high cpu activity
09.53.06 #       <MarcAndersen> How do I do that? That sounds like it
09.58.01 #       <_bilgus_> https://gerrit.rockbox.org/r/c/rockbox/+/1894
10.00.46 #       <MarcAndersen> Will this be merged into master at some point?
10.01.14 #       <_bilgus_> no
10.01.36 #       <MarcAndersen> So that means that from now on I need to build everything myself?
10.02.02 #       <_bilgus_> if that works then Ill up it a bit till its reliable that patch maxes em out
10.02.52 #       <_bilgus_> figure it decreases the playtime of every clip zip so try to keep it minimal, although this would be the reason I wanted to make it a setting
10.05.40 Quit    massiveH (Quit: Leaving)
10.08.03 #       <_bilgus_> its likely CVDD1 the last item in that patch, currently the zip is at 20 it likely needs to be 22, thats the easy one
10.09.05 #       <MarcAndersen> Sorry, but I don't remember exactly how to apply a patch.
10.09.49 #       <_bilgus_> https://www.rockbox.org/wiki/WorkingWithPatches
10.11.48 #       <_bilgus_> dont forget the path stripping -(p0 p1 p2 p3)
10.11.59 #       <MarcAndersen> I get  that, but what do I need to download from the Gerrit page?
10.12.58 #       <_bilgus_> ah thats chnaged since I last did it in getrrit goto download patch and see the link at lower left?
10.13.18 #       <_bilgus_> says: patchfile 
10.13.29 #       <_bilgus_> grab the one ending in .zip
10.14.06 #       <_bilgus_> https://gerrit.rockbox.org/r/changes/rockbox~1894/revisions/2/patch?zip
10.14.35 #       <_bilgus_> then unzip that to your rockbox source directory
10.15.22 #       <_bilgus_> and finally use patch -p[0,1,2] < thatfileyouunzipped.patch
10.15.56 #       <_bilgus_> or jut do the chnages by hand these aren't big patches or anything
10.17.38 #       <MarcAndersen> Thanks. this Gerrit thing is not that accessible with a screen reader
10.18.39 #       <braewoods> MarcAndersen: it's a system for development change management. not too surprised by that unfortunately.
10.19.34 #       <_bilgus_> its not much more accessible with sight, not much liking the new gerrit but progress!
10.20.35 #       <braewoods> isn't it funny how progress can end up being a regress instead
10.20.37 #       <braewoods> :D
10.22.34 #       <speachy> _bilgus_: can you fire off a build for him?
10.22.46 #       <MarcAndersen> It says patch: **** strip count '[0,1,2]' is not a number
10.22.56 #       <_bilgus_> sorry its just one of them
10.23.03 #       <_bilgus_> either p0 p1 p2
10.23.17 #       <MarcAndersen> What's the difference?
10.23.29 #       <_bilgus_> I can do a build at luch time (4 hours from now
10.23.45 #       <_bilgus_> it strips the first part of the paths
10.23.53 #       <_bilgus_> p0 does no stripping
10.24.04 #       <_bilgus_> p1 strips the first directory p2 the second
10.24.31 #       <_bilgus_> so /A/b/c -p would be /a/b/c p1 would be /b/c p2 would be /c/
10.25.13 #       <MarcAndersen> I applied it
10.25.48 #       <_bilgus_> it'll fail if the paths don't match so if successful it sould sat succeeded
10.25.55 #       <_bilgus_> say*
10.26.47 #       <_bilgus_> then if that works let me know and we can try and minimize the runtime hit while keeping your hardware happy
10.26.50 #       <MarcAndersen> It's building now
10.27.17 #       <MarcAndersen> From the latest master + the patch
10.27.35 #       <_bilgus_> you should be able to use the current voice file then
10.28.09 #       <MarcAndersen> I don't think so because that was the build that started with 412
10.28.10 #       <_bilgus_> really you just need to copy the .sansa file to the .rocbox directory 
10.28.38 #       <MarcAndersen> But I can build one myself
10.29.06 #       <_bilgus_> not sure what 412 means but if you are on master we didn't change enough to make it not match the stuff up on rb.org
10.29.58 #       <_bilgus_> likely you don't even need to use the zip file just copying the .sansa file to the .rockbox directory is enough
10.30.13 #       <speachy> he's referring to commit 412e76b
10.30.13 #       <_bilgus_> (with small chnages)
10.30.39 #       <speachy> (not sure what previously worked.  but very little has meaningfully changed on a performance front in a while...)
10.31.04 #       <_bilgus_> ah its not been built yet, then yes probably need to do your own
10.31.31 #       <MarcAndersen> It's building all the rocks, it takes a lot of time.
10.32.22 #       <_bilgus_> yes I used to do my own builds like the build server to test things but itd take me 6-8 hours
10.32.51 #       <_bilgus_> my new rig is probably a bit faster than that but still
10.36.06 #       <MarcAndersen> It didn't work
10.36.27 #       <MarcAndersen> I mean it still has some crackling
10.44.47 #       <_bilgus_> well thats not it then
10.46.38 #       <_bilgus_> I didn't hear any artifacts in my build on the player (likely a month old or so)
10.46.52 #       <_bilgus_> I'll try tonight an reproduce it at head
10.47.48 #       <MarcAndersen> It's mostly when it reads long things like playing time or version number
10.48.21 #       <_bilgus_> maybe a buffer underrun IDK
10.48.38 #       <speachy> wonder if we're not boosting the CPU?
10.48.51 #       <speachy> but when we're plugged in we're always (or more often) boosted?
10.48.55 #       <_bilgus_> I think it does automatically
10.50.08 #       <_bilgus_> but idk about the plugged vs unplugged I dont think it has that logic inbuilt
10.50.35 #       <_bilgus_> but the cpu boost / unboost might be a possibility
11.11.27 #       <braewoods> speachy: very plausible. i recall dmix causing crackling if the host cpu couldn't handle it.
11.12.45 #       <braewoods> crackling could also mean trying to do more than the cpu can handle in realtime
11.13.05 #       <braewoods> MarcAndersen: what kind of audio files are you trying to play
11.13.15 #       <braewoods> maybe we could formats that are known to be less demanding
11.13.54 #       <MarcAndersen> It does it even when nothing is playing, that was the first thing I tried.
11.14.19 #       <braewoods> oh, ok that means it's either not present or an issue in addition to another.
11.17.12 ***     Saving seen data "./dancer.seen"
11.30.38 Join    Saratoga [0] (~Saratoga@209.107.182.153)
11.33.17 Quit    Saratoga (Client Quit)
11.34.51 Join    saratoga [0] (~saratoga@cpe-98-10-205-66.rochester.res.rr.com)
11.35.37 Quit    petur (Quit: Connection reset by beer)
11.35.47 #       <saratoga> I think audio problems are more likely to be an analog voltage problem than a CPU core voltage, since if the CPU isn't getting enough voltage you are going to crash really quickly
11.36.30 #       <saratoga> voltage are generated from internal regulators, so they should not matter if you are on battery or external power unless something has gone very wrong
11.36.55 #       <saratoga> do any of the voltages in the debug screen actually measure different when on internal vs external power?
11.37.03 #       <saratoga> and does the distortion depend on the player's volume level?
11.37.42 #       <MarcAndersen> We don't have speech in the debug menu, so I can't tell. We really should have that.
11.38.04 #       <MarcAndersen> And it's not destortion, it's small pauses in the speech
11.38.29 #       <saratoga> that sounds like a CPU load issue
11.39.21 #       <saratoga> i can't think of any reason that would depend on the external power though
11.41.19 #       <MarcAndersen> It works perfectly when plugged in, but as soon as I disconnect it it does it again, even in the middle of a speakout
11.43.12 #       <saratoga> _bilgus_:  does the boost behavior change when running on external power?
11.44.04 #       <saratoga> MarcAndersen:  if you push a button or similar to wake up the UI does the effect change?
11.44.42 #       <MarcAndersen> What do you mean to wake up the ui?
11.45.09 #       <saratoga> when you push a button the screen will turn on and the CPU will boost up to a higher speed (unless that has changed)
11.45.51 #       <MarcAndersen> But I have to be in a menu to make it happen, it's while it reads some numbers and stuff
11.46.38 #       <saratoga> i see, so should already be boosted
13.10.00 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:50ca:dd6:3847:ec8d)
13.13.37 Join    lebellium [0] (~lebellium@2a01cb04012c0900ccbb79fe2cd3c41e.ipv6.abo.wanadoo.fr)
13.17.14 ***     Saving seen data "./dancer.seen"
13.36.26 #       <speachy> amachronic's  usb control api rework is quite nice
13.36.37 #       <speachy> about halfway through it, finally getting to the meat
13.37.21 #       <edhelas> is there some impact on stability/performances ?
13.46.50 #       <speachy> performance, no, but there were a lot of corner cases in the old code that didn't quite work properly, leading to flaky initial USB enumeration and so forth
13.47.07 #       <speachy> if nothing else the new code is far cleaner and maintainable.
14.06.49 Join    whatfor [0] (~whatfor@84-84-97-124.fixed.kpn.net)
14.07.32 #       <spork> for the x1000's there is performance
14.08.40 #       <whatfor> different browser, different OS, same IP address, and the forbidden complaints from the website go away. so now I have to use chrome on windows instead of firefox on linux to access the site. it's a different iceberg, but it's still wrong.
14.08.47 Quit    whatfor (Client Quit)
14.14.53 #       <speachy> yep, whatfor, it's wrong, but it's not rockbox's wrong.  You would be well advised to get your own house in order before casting shade on others.
14.26.54 Join    bilgus_ph [0] (~bilgus_ph@172.58.171.3)
14.28.02 #       <bilgus_ph> I've been using Firefox on Linux to access rb.org and I'll for at least the last 2 year
14.28.44 #       <bilgus_ph> Saratoga I don't think we boost more on external power I'll double check this evening when I try and repro
14.30.00 #       <bilgus_ph> Rb.org and ILK* I guess my phone doesn't like that word
14.40.08 #       <speachy> yeah, that's all I ever access it with.
14.41.12 Quit    bilgus_ph (Ping timeout: 265 seconds)
14.41.42 #       <speachy> and besides, still hasn't provided an IP for us to investigate anything on our end.  so, whatever.
14.55.11 #       <paulcarroty> found a battery for fuze (maybe good for + too) - https://www.alibaba.com/product-detail/383541-3-8mm-3-7V-530mAh_60628618825.html
15.01.27 #       <speachy> the '41' is supposed to be the thickness.  :D
15.04.01 #       <paulcarroty> Size: 3.83541mm
15.04.53 #       <paulcarroty> 3.8x35x41
15.06.13 Quit    speachy (Quit: Connection closed)
15.17.16 ***     Saving seen data "./dancer.seen"
15.53.59 #       <braewoods> speachy: evidently 'whatfor' isn't interested in getting to the bottom of it. oh wow.
15.54.01 #       <braewoods> well*
15.54.43 #       <braewoods> if a different browser works it's probably not an IP block.
15.55.01 #       <braewoods> still without knowing more
17.09.31 Join    Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
17.17.19 ***     No seen item changed, no save performed.
17.24.23 Join    speachy [0] (~speachy@taster.shaftnet.org)
17.24.23 Quit    speachy (Changing host)
17.24.23 Join    speachy [0] (~speachy@rockbox/developer/speachy)
17.24.23 Mode    "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
17.28.40 #       <speachy> braewoods: there are some rules blacklisting firefox versions older than v60 (thank you, bots) but anyone using a >3 year-old browser to do anything online is asking for a world of hurt.
17.29.05 #       <speachy> (heck, I don't think v60 will work with our SSL certificate anyway!)
18.19.04 Quit    ZincAlloy (Quit: Leaving.)
18.26.19 Quit    lebellium (Quit: Leaving)
18.32.23 Join    _bilgus [0] (~bilgus@162.154.213.134)
18.41.16 Quit    _bilgus_ (Quit: Leaving)
18.41.31 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:5a9:86f1:63f8:14ac)
18.45.56 Quit    ZincAlloy (Ping timeout: 250 seconds)
18.51.26 Join    amachronic [0] (~amachroni@user/amachronic)
19.02.36 Quit    amachronic (Ping timeout: 245 seconds)
19.02.57 Join    amachronic [0] (~amachroni@user/amachronic)
19.12.29 #       <amachronic> i wonder if supporting UASP would be a good idea.
19.12.56 #       <amachronic> in addition to our current mass storage driver
19.14.21 #       <speachy> the main reason to support USAP with it is offers better theoretical performance.  But we're not exactly limited by MSP's bottlenecks.
19.15.35 #       <amachronic> from some basic profiling I did it seems about 60% of the time is spent in IO with the USB bus idle.
19.16.24 #       <amachronic> i can't understand how linux is pipelining the IO on the M3K's OF. unless it just sits in cache?
19.17.20 ***     Saving seen data "./dancer.seen"
19.43.05 Quit    amachronic (Quit: amachronic)
19.45.44 Join    dconrad [0] (~dconrad@208.38.228.17)
20.18.07 #       <dconrad> is there an easy way to get a rough benchmark of usb speeds?
20.18.14 #       <dconrad> on linux/macos
20.22.59 #       <dconrad> fio seems to be the popular tool
20.31.19 #       <speachy> dconrad: running 'dd' is probably a good start for raw throughput.
20.31.28 #       <speachy> it won't get any faster than that
20.32.03 #       <dconrad> I'm historically pretty wary of dd, do you have an easy test command?
20.32.14 #       <dconrad> (pretty sure you can do some real damage with it)
20.32.18 #       <speachy> as long as you don't swap the input and output.. :)
20.32.47 #       <speachy> eg 'dd if=/dev/sdX of=/dev/null bs=2K count=1024K'
20.33.09 #       <speachy> (1024 2K blocks, for a total of 2MB)
20.33.31 #       <speachy> that'll give you read speeds.  obviously writes are more difficult to benchmark
20.33.37 #       <dconrad> hmm, I'll try it
20.33.41 #       <speachy> due to inherent destructiveness
20.34.04 #       <speachy> oh, one caveat -- Linux will cache reads, so if you run the exact thing again you'll find it magically FAST
20.34.04 #       <dconrad> I tried fio but got like 54 B/s, which can't be right
20.34.16 #       <dconrad> we'll see what happens on macos
20.34.48 #       <speachy> you can add skip=NNN to pick a different starting block offset
20.35.12 #       <dconrad> 9.5 MB/s, it gave me
20.35.17 #       <dconrad> seems low?
20.35.57 Join    ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
20.36.43 #       <dconrad> looks like macos caches same as linux, subsequent reads gave 229 MB/s and then 437 MB/s
20.37.17 #       <speachy> that's not too bad, actually
20.38.48 #       <dconrad> let's try 4MB... 9.7 MB/s again
20.40.26 Quit    ZincAlloy (Ping timeout: 252 seconds)
20.54.54 #       <_bilgus> MarcAndersen, I think I hear it its like  bit of sizzle on the end of some of the words?
20.58.01 #       <_bilgus> Idk it doesn't change for me when I put it on charge though
20.58.38 #       <_bilgus> I wonder if it could be a bad sd card?
20.58.48 #       <MarcAndersen> Let me take it out
20.59.22 #       <MarcAndersen> No change
21.00.06 #       <_bilgus> If I really listen hard I can hear a electrical noise like the sound a motor makes when stalled
21.00.21 #       <_bilgus> just sometimes though
21.00.21 #       <MarcAndersen> Can you try to let it read the system info?
21.01.04 #       <MarcAndersen> Try the build number for example, or the free space
21.01.12 #       <_bilgus> when it did battery level from system I heard a hesitation lets see if it does it again
21.01.40 #       <_bilgus> yeah on first entry to the menu I can hear a click
21.01.49 #       <_bilgus> lets see if it changes on charge
21.03.44 #       <_bilgus> MarcAndersen, if you put it on charge and exit the menu then re enter does it do it 
21.04.08 #       <_bilgus> the first plug it didn't but I exited the menu and tried again it then did it
21.04.20 #       <_bilgus> and it sounds like the player is bogging down
21.04.42 #       <MarcAndersen> So you get it now?
21.05.18 #       <_bilgus> yeah exiting the menu and returning to it seems to make it stutter and miss a bit
21.05.34 #       <_bilgus> the disk space one works best for me
21.05.43 #       <_bilgus> (or worst rather)
21.05.53 #       <MarcAndersen> And there are small pauses in the speech right?
21.06.11 #       <_bilgus> yeah like its bogging down
21.06.19 #       <braewoods> MarcAndersen: I didn't know we had a william shatner voice.
21.06.21 #       <braewoods> :P
21.06.40 #       <MarcAndersen> what?
21.07.00 #       <braewoods> william shatner, he was well known for pauses in his speech
21.07.03 #       <_bilgus> marc anderson boosting the cpu makes it isappear for me
21.07.09 #       <_bilgus> disappear*
21.07.28 #       <_bilgus> let me make you a boosted build and lets see how that works
21.09.13 #       <MarcAndersen> Cool
21.11.47 #       <_bilgus> MarcAndersen, are you using english.voice or some other language
21.11.56 #       <MarcAndersen> english right now
21.13.08 #       <MarcAndersen> The fun thing is that it only happens when reading long things with numbers, and only on battery.
21.17.24 ***     Saving seen data "./dancer.seen"
21.17.58 #       <_bilgus> yeah lets see if this makes it work properly I already included the voice file so just unzip over your existing install or rename the existing..
21.18.16 #       <_bilgus> http://www.mediafire.com/file/7mmnfupeq1zpvhu/rockbox-full.zip
21.21.20 #       <MarcAndersen> It sure does! Thanks! Can you send the patch, or will it be put into master soon?
21.21.30 #       <_bilgus> no I won't do that
21.21.40 #       <_bilgus> thats gonna really sap the runtime
21.21.59 #       <_bilgus> but I can use that info to decide where to focus next lol
21.22.10 #       <MarcAndersen> But can you send the source?
21.22.18 #       <_bilgus> like maybe see why its not staying boosted
21.22.29 #       <speachy> so it's voltage-related?
21.22.36 #       <_bilgus> no cpu speed
21.22.43 #       <speachy> we do un-boost after being "idle" for a while
21.23.01 #       <_bilgus> I'm thinking its unboosting before its done talking
21.23.02 #       <speachy> keystrokes reset the idle counter
21.23.11 #       <speachy> so longer spoken stuff exceeds the timeout
21.23.18 #       <speachy> (just a theory)
21.23.22 #       <_bilgus> agrre sounds plausible
21.23.25 #       <saratoga> the audio buffer getting low should boost the CPU
21.23.47 #       <saratoga> even for speech, although maybe that is broken at some point
21.24.14 #       <_bilgus> my thought as well esp with all the churn lately
21.24.16 #       <saratoga> i'm pretty sure it once worked since we could do audio playback and voice on 80 MHz iPods
21.24.16 #       <speachy> this happens when stuff isn't playing so perhaps the check for "low buffer" that doesn't kick in?
21.24.39 #       <_bilgus> or its just too late
21.24.43 #       <speachy> s/that doesn't kick/isn't kicking/
21.25.14 #       <_bilgus> wonder if its related to the bug report that sometime on startup the player stutters
21.25.18 #       <speachy> well, for all we know the PP500x iPods are fine.
21.25.40 #       <_bilgus> Ive seen that one like 1/75 boots
21.26.34 #       <speachy> only thing I have handy is the x3 which doesn't downclock
21.27.14 #       <MarcAndersen> But what are you going to do with it now? What did you change?
21.27.35 #       <_bilgus> MarcAndersen, all I did was make it stay at full clock speed
21.27.38 #       <speachy> MarcAndersen: IIUC he just maxed the CPU speed at all tmies
21.27.59 #       <_bilgus> I literally commented out the low speed and left only fullspeed
21.28.32 #       <_bilgus> I was going to tell you how to do it manually but it doesn't voice prompt in that menu
21.29.00 #       <_bilgus> FWIW you just go into the cpu speed debug menu and upclock it a few and itll stay boosted
21.29.03 #       <MarcAndersen> That's another thing, we need voice in the debug menu
21.29.11 #       <_bilgus> never going to happen
21.29.35 #       <_bilgus> too much text to add to the voice files for seldom used stuff
21.29.49 #       <_bilgus> now dumping it to disk I could agree with
21.29.54 #       <speachy> and we'd end up having to add a non-voiced debug menu so we can then debug the debug menu
21.30.11 #       <MarcAndersen> I am going to do it anyway at some point, and now seams to be the right time when I need it myself
21.30.38 #       <_bilgus> problem being is that all these targets have TERRIBLE debug menus
21.30.56 #       <_bilgus> all hard coded because it was never intended for the end user
21.31.47 #       <_bilgus> I wonder how hard it would be to build a english lang for the debug menu though
21.32.06 #       <_bilgus> I mean in theory we have the ability to load several sets of clips
21.32.23 #       <speachy> I
21.32.28 #       <_bilgus> like a english_debug.lang file and associated voice
21.32.33 #       <MarcAndersen> Sorry but I can use debug menus in android and other systems with speech, why shouldn't everyone have access to it here also? Sorry if I'm getting caught up but I don't like being put down that way
21.33.10 #       <_bilgus> its not a question of why as much as how much work for little benefit to the end user
21.33.34 #       <MarcAndersen> I see, sorry.
21.33.35 #       <speachy> MarcAndersen: much of it is target specific too, literally things like register dumps that are refreshed in realtime
21.33.48 #       <_bilgus> like if you wanna do that more power to you but I'm telling you its a tall order
21.34.21 #       <_bilgus> but like I said I can see dumping it to a file that you could parse on a machine
21.34.26 #       <_bilgus> with a screen reader
21.34.47 #       <speachy> (for example, getting the kinks worked out of alternative numeric voice orderings is a lot less work, for far more benefit)
21.35.12 #       <MarcAndersen> It's more the settings I'm interested in
21.37.21 Quit    saratoga (Ping timeout: 265 seconds)
21.40.37 #       <MarcAndersen> So what you're saying is that I can use a normal build if I could access that menu?
21.40.39 #       <_bilgus> most of them are of little use in day to day use in my experience
21.41.08 #       <_bilgus> its more of a temporary way to test things
21.41.15 #       <MarcAndersen> Is it then saved in the cfg file?
21.41.29 #       <_bilgus> I wouldn't want a build that I had to go into the debug menu to use
21.41.40 #       <_bilgus> no thats why I say its a temporary way
21.41.53 #       <MarcAndersen> Oh
21.42.41 #       <_bilgus> already that build will be about 20-30% less runtime I wouldn't want it boosted constantly unless it wasn't on battery
21.43.22 #       <_bilgus> no ill have a look in the next few days and see what I can see
21.46.10 #       <_bilgus> hmm it already has the logic to boost the cpu in the voice thread queue
22.05.57 #       <MarcAndersen> bilgus, 
22.06.17 #       <MarcAndersen> Would you be able to send the source file?
22.17.47 Quit    _bilgus (Read error: Connection reset by peer)
22.18.01 Join    _bilgus [0] (~bilgus@162.154.213.134)
22.25.12 Quit    dconrad ()
22.29.04 Quit    Moriar (Ping timeout: 265 seconds)
22.34.23 #       <_bilgus> Interestingly if I first play a file and stop it I can't reproduce the issue
22.34.54 #       <_bilgus> I think what is happening is that there is a default buffer the voice system tries to alloc if it doesn't have one available
22.35.11 #       <_bilgus> I bet its quite small
22.36.02 #       <_bilgus> MarcAndersen, If you play and stop a file first does the issue disappear?
22.37.48 #       <_bilgus> nope nevermind
22.39.12 #       <MarcAndersen> With a normal bhuild, yes. but not with yous of course
22.42.21 #       <_bilgus> its weird I can see what is happening it gets a call to stop the boost and never boosts back
22.50.26 #       <_bilgus> ok so I added a delay till unboost and it seems to help I'll try a few more times
22.50.50 #       <MarcAndersen> _bilgus: In which file did you change it?
22.51.12 #       <_bilgus> apps/voice_thread.c
22.51.30 #       <_bilgus> give me a few Ill put up a patch if i can't reproduce it again
22.52.04 #       <MarcAndersen> What about the first boost thing? My player got faster by that
22.53.30 #       <_bilgus> we of course it did
22.53.34 #       <_bilgus> well*
22.53.48 #       <_bilgus> but it eats battery!
22.55.33 #       <MarcAndersen> That's not that big a deal
22.55.48 #       <_bilgus> for that its firmware/target/arm/as3525/system-as3525.c
22.58.41 #       <_bilgus> https://pastebin.com/rXhqAWJk
22.58.51 #       <_bilgus> MarcAndersen, there you go 
22.58.55 #       <speachy> okay, it works!  g#3832
22.58.57 #       <rb-bluebot> 3Gerrit review #3832 at https://gerrit.rockbox.org/r/c/rockbox/+/3832 : 3talk:  Add support for languages that swap the tens position in numbers by Solomon Peachy
22.59.31 #       <speachy> I tested it with the english-us "Translation"
22.59.35 #       <_bilgus> that is the cpu boost file on pastein
23.00.59 #       <speachy> instead of hardcoding the exception to the language update rules I need to make someting more general (eg repurpose the 'user' field?) and also fix the translate site to not flag/fix it.
23.01.49 #       <MarcAndersen> Thanks everyone for all the help! I'm going to bed now, it's 5 AM
23.02.40 #       <_bilgus> cya
23.06.26 #       <speachy> ok, what's up is ready for review, barring any necessary fixes to the translate site.
23.17.28 ***     Saving seen data "./dancer.seen"
23.21.40 #       <_bilgus> speachy, whats the + 18 at line 1210 of talk.c?
23.25.42 #       <_bilgus> nm I see whats its doing ick
23.25.47 #       <_bilgus> lol
23.42.39 #       <_bilgus> #g3846 asppears to fix the stuttering
23.42.49 #       <_bilgus> g#3846
23.42.52 #       <rb-bluebot> 3Gerrit review #3846 at https://gerrit.rockbox.org/r/c/rockbox/+/3846 : 3voice_thread.c ensure cpu gets re-boosted after Q_VOICE_STOP event by William Wilgus
23.43.59 #       <_bilgus> what I was seeing was the force_enque function calls Q_VOICE_STOP which cancels the cpu boost but quiet_count >0 so next run it didn't reboost the voice thread
23.44.53 #       <_bilgus> it actually appears to have made the player much more responsive when voice is enabled
23.45.10 #       <_bilgus> which makes plenty of sense
23.47.29 #       <rb-bluebot> Build Server message: 3New build round started. Revision 4695f80230, 303 builds, 10 clients.
23.58.24 #       <rb-bluebot> Build Server message: 3Build round completed after 655 seconds.
23.58.27 #       <rb-bluebot> Build Server message: 3Revision 4695f80230 result: All green