Log from #neuros IRC channel

raw, we don't support, i think. most wav we can. you have two ways: the easy way is to do it via xmms2. if it's always the same file especially this is the best method, i think. don't know about the latency

[04:56]

<pEEf>

It does decode the media info correctly if I pass it an MP3 with ID3 info.

[04:57]

<pEEf>

So it seems to be opening the file correctly.

[04:57]

hmm, maybe it's some wav format we don't support ?

[04:57]

<pEEf>

I tried xmms2. It's VERY slow.

[04:57]

slow to add the file, or slow to playback

[04:57]

?

[04:57]

<pEEf>

Takes about 2 seconds, and of course, disrupts the OSD interface.

[04:58]

disrupts how ?

[04:58]

<pEEf>

I need something that will play a sound within 50ms and not interefere with the GUI.

[04:58]

<_sev|work>

nerochiaro: thanks for the info

[04:58]

<pEEf>

the xmms player screen comes up

[04:59]

pEEf: you can use xmms2 directly, without starting the audio player GUI

[04:59]

pEEf: either via the "xmms2" command line program, or using the xmms2 client library

[04:59]

the latter is faster, of course

[04:59]

<_sev|work>

Another question which is difficult to answer without owning the device. Is it possible to run homebrew from the flash card with standard firmware?

[04:59]

_sev|work: homebrew apps ?

[05:00]

<_sev|work>

nerochiaro: develop some application, but binary on the card and launch it

[05:00]

<_sev|work>

but = put

[05:00]

<_sev|work>

or a custom fw should be developed?

[05:00]

_sev|work: especially with the newer firmware we will be releasing soon, it will be possible

[05:00]

_sev|work: but it's possible now alread

[05:00]

<pEEf>

I'll try playing with it some more, but I want to play short tones for events, and it would be nice if this would be possible at any time, such as when already playing music.

[05:01]

<pEEf>

If the driver cannot mix, then I'd have to interrupt it somehow.

[05:01]

_sev|work: the only exception now is that if your app needs some lib that we don't have on board, you will either statically link it, or do some tricks with LD config path to make it find it

[05:01]

<_sev|work>

nerochiaro: ok, is the code in SVN, or some precompiled snapshots available?

[05:02]

<pEEf>

And If xmms2 was already playing a user playlist, I'd have to clear it, play my file, then reload it. messy!

[05:02]

<_sev|work>

nerochiaro: I see. makes sense

[05:02]

<_sev|work>

nerochiaro: I am talking about ScummVM here: forums.scummvm.org

[05:02]

pEEf: you can't do that anyway, if you are playing other audio or video. the system is locked exclusively by whatever is playing audio or video, you can't mix your tone over it

[05:03]

pEEf: you can play your tone only when nothing else is playing

[05:03]

_sev|work: sweet !

[05:03]

_sev|work: i think you will have some issues to get that running decently fast though

[05:03]

<_sev|work>

nerochiaro: it depends on how fast your framebuffer is

[05:03]

<pEEf>

I'd settle for that, at least for now, but I'd really rather not invoke xmms2.

[05:04]

<_sev|work>

nerochiaro: and whether there are some speed-up things such as memmap'ing it

[05:04]

_sev|work: run some DSL benchmarks before starting to mess with SCUMM

[05:04]

<pEEf>

Is there something that changed in nmsd?

[05:04]

<pEEf>

(that prevents audiotest.c from working)

[05:05]

pEEf: a bunch of things properly, off of the top of my head i wouldn't know what

[05:05]

<_sev|work>

nerochiaro: basically speaking of GFX, I will need to implement a method in a manner copyRectToScreen(byte *ptr, x, y, w , h);

[05:05]

pEEf: the strange thing that it plays mp3 just fine

[05:05]

<_sev|work>

nerochiaro: if that will be possible to do fast, then the port will run well

[05:05]

pEEf: so i'm thinking it may not know how to handle the WAV you hand to it

[05:05]

<pEEf>

I tried, it decodes the media info, but still returns the same error.

[05:06]

_sev|work: framebuffer is a mapped memory area. you can manipulate it any way you please

[05:06]

<_sev|work>

nerochiaro: but well, ScummVM runs pretty good even on GP32 with 66MHz ARM and framebuffer

[05:06]

_sev|work: we don't have any hardware-acceleration API

[05:06]

<pEEf>

I'm on Arizona 3.33-2.04

[05:06]

<_sev|work>

nerochiaro: sweet. I need to see how fast is lock/unlocking it

[05:07]

_sev|work: what do you mean by unlocking ?

[05:07]

<pEEf>

is there some restriction on the type of MP3 it will play?

[05:08]

<_sev|work>

nerochiaro: I don't know your hardware details yet, i.e. whether you need excusive access to the framebuffer in order to update it

[05:08]

<_sev|work>

usually that's expensive operation

[05:08]

pEEf: frankly, i have not been playing audio with NSM for a long time now, since all our audio went thru xmms2. however, you can maybe look at how vplayer sets up the nms to play video and how to start playback, and then apply the same logic to audio ?

[05:08]

<crweb>

the major factor in the framebuffer details is there is no 2d accelleration like there is in GP32

[05:08]

pEEf: vplayer is the most curent example of how to talk to nms

[05:08]

_sev|work: you don't need exclusive access

[05:08]

<pEEf>

ok, thanks for your assistance, nerochiaro!

[05:09]

_sev|work: that means, you should shut down other apps, or they will draw over you

[05:09]

<_sev|work>

nerochiaro: well, then I do not see why there could be problems with speed

[05:09]

pEEf: look at vplayer, if you still have issues, post your example program in ML (as simple as possible) and we'll go from there

[05:10]

_sev|work: all i'm saying is: try some benchmarks before going crazy porting the VM

[05:10]

<_sev|work>

nerochiaro: you playback video. is that accelerated? or you just copy to fb?

[05:11]

_sev|work: video is done via the DSP, and is output to video layer directly, it doesn't go to framebuffer. framebuffer is layered on top of video layer

[05:11]

all by hardware

[05:12]

<pEEf>

nerochiaro: Thanks. It would probably be a good idea to label that example program as no longer working in the wiki.

[05:12]

<_sev|work>

is DSP API exposed?

[05:12]

_sev|work: no, unfortunately. you can't output your stuff to video layer

[05:12]

_sev|work: you can turn on/off some layers, set transparency of fb layer in respect to video

[05:12]

that's pretty much it

[05:13]

<_sev|work>

ok

[05:13]

<crweb>

the DSP doesn't work as a video device even if API was exposed

[05:13]

that too

[05:13]

<crweb>

it is kind of like a general purpose cpu. it runs DSP compiled applications "codecs"

[05:13]

<_sev|work>

but again, we do have ports with slowwwww framebuffered devices, and it performs pretty well there

[05:14]

_sev|work: the bottleneck will probably be the input, actually

[05:14]

<_sev|work>

crweb: but I suppose it could perform a superfast memory copying

[05:14]

<_sev|work>

nerochiaro: what do you mean?

[05:14]

_sev|work: doing SCUMM with a remote seems a problem ...

[05:14]

<_sev|work>

nerochiaro: heh, ever tried ScummVM with a mobile?

[05:14]

<crweb>

it uses the same memory as the OS...

[05:14]

_sev|work: nope

[05:15]

_sev|work: how do they do it ?

[05:15]

<_sev|work>

nerochiaro: that one with 12 buttons on it. it works

[05:15]

<crweb>

mobile's usually have 2d accellerated interfaces. or REALLY small resolutions

[05:15]

_sev|work: i still don't understand how you move Guybrush around

[05:15]

<_sev|work>

nerochiaro: moreover, already mentioned GP32 has one directional pad and 4 additional buttons. PSP is similar. :)

[05:15]

<crweb>

_sev|work: i'd say your lag will come from input system also. but this would be cool to get working

[05:15]

<_sev|work>

nerochiaro: you move cursor and then perform clicks

[05:16]

_sev|work: the problem is that our IR input is not really good for moving a cursor precisely along long distances

[05:16]

_sev|work: unless you have a cool way to internally handle autorepeat of keys, which you probably do

[05:17]

<_sev|work>

nerochiaro: that's why there is an acceleration in some ports. i.e. longer you move in same direction, faster you go

[05:17]

<_sev|work>

nerochiaro: alternatively it could be implemented just like in AGI games

[05:18]

<_sev|work>

that is, you press a directional key, and it goes into that direction until you press it again

[05:18]

_sev|work: sounds good to me. let's see what you come up with :)

[05:18]

<_sev|work>

it depends on whether I get the device :D

[05:18]

<crweb>

ui.c:564: warning: implicit declaration of function `rpl_malloc'

[05:18]

<crweb>

freaking GNU...

[05:18]

_sev|work: come on, they are getting cheaper now :)

[05:19]

<_sev|work>

that price tag is still big for me, being in a 3rd world country ;)

[05:19]

_sev|work: which one ?

[05:20]

crweb: nick was asking me how we handle the help text for menu items in the new menu system. it's a good question...

[05:20]

<crweb>

nerochiaro: thats where desktop files come in..

[05:21]

<crweb>

nerochiaro: him and i talked about it for a bit

[05:21]

<_sev|work>

nerochiaro: Ukraine

[05:21]

crweb: that text can be pretty long

[05:21]

<crweb>

nerochiaro: qt does have a help system..

[05:21]

_sev|work: wow, i can see it being a problem to get an OSD there without being killed by shipment costs

[05:22]

<crweb>

nerochiaro: i think maybe we should rethink exactly what we give help on, and how it works

[05:22]

<pEEf>

nerochiaro: One more question; Does xmms2d play it's audio through nmsd or does it go directly to the driver? I can't find the xmms2 source in my current source tree, looks like only the binaries are there.

[05:22]

<crweb>

should main-menu give help on items, or on how to use main menu

[05:22]

crweb: we give help on the function that such menu item is going to activate usually

[05:22]

crweb: not on the whole menu

[05:22]

<crweb>

i think we should go to: help by app. not Preemptive help

[05:23]

crweb: John disagrees

[05:23]

JohnDesigner: do you ?

[05:23]

<crweb>

preemptive help is heavy

[05:23]

<crweb>

you have to store all the help a user may never even view

[05:23]

pEEf: it goes out directly via the plugin, as explained in my email

[05:23]

hnmm?

[05:23]

<crweb>

post-help in app. very light. it only needs to store help for itself

[05:24]

<_sev|work>

nerochiaro: well, I really doubt that shipment will go higher than $50. I'd say $30 is a normal, unless you will use some courier post

[05:24]

pEEf: you need to go into the xmms2 dir in the source, and call "make rebuild", then you will have full source (patched alraeady) in _build folder

[05:24]

_sev|work: i was thinking customs office taxes. they are incredibly expensive here (27% or worse)

[05:25]

<_sev|work>

here everythin under 200EUR is custom free

[05:25]

crweb: the current system needs to support a help text for the currently highlighted item or app.

[05:25]

<pEEf>

nerochiaro: thanks. I will look at that.

[05:25]

<crweb>

JohnDesigner: thats my point

[05:25]

pEEf: if you do that, look into xmms2 output plugin called "nms", to see how it loads the neuros plugin and send raw PCM audio out thru it

[05:26]

<crweb>

JohnDesigner: if there are 1 pages of text, for every item in a menu. main-menu is 8 pages of text

[05:26]

<crweb>

plus all the translations

[05:26]

crweb: the point i guess is that one user has to know what a menu item does before wanting to enter it

[05:26]

<crweb>

its called reading

[05:26]

<crweb>

if you can't figure out Play.Browse is. send the f'ing thing back

[05:27]

<crweb>

j/k of course.

[05:27]

crweb: i share your sentiment, but users are idiots, you know that

[05:27]

;)

[05:27]

<crweb>

but maybe go to "light help"

[05:27]

* nerochiaro spoken in the voice of Torvalds

[05:27]

<crweb>

and leave the details for applications

[05:27]

crweb: i tried to stay out of the what content the help files specifically contain.

[05:28]

<crweb>

main-menu's help at most should be tool tips better explaining the item

[05:28]

<crweb>

this would be easy to implement

[05:28]

or the exact implementation method, as long as the system supports displaying a help text for *any* highlightable item.

[05:28]

<crweb>

the "pages of help" should be in the application

[05:29]

<crweb>

i mean, Play|Browse help contains stuff about playing video's etc

[05:29]

JohnDesigner: the point is: how much text should the highligteable item have ?

[05:30]

talk to Collin and Jason if you would like to change the content and where it is displayed

[05:30]

<crweb>

nerochiaro: we should have 1 line that can go in the .menu file

[05:30]

<crweb>

application "usage" help. should go in the application

[05:31]

nerochiaro: I dont know really. So there is a cost for having the capability to display 1 page vs 8 pages?

[05:32]

yes

[05:33]

a short text, we can use a simpler system to store it all in the menu. a long text, and we have to implement a way to load from disk on-demand

[05:33]

because otherwise keeping the 8 pages in memory all the time kills us

[05:33]

8 pages for each item, that is

[05:34]

not to mention, sub-menus load slower since they have to load all pages of help in memory all the time

[05:34]

OSD loads those 8 pages for each item on each active screen?

[05:34]

JohnDesigner: now, yes

[05:34]

we want to make that go away

[05:35]

So the new limitation would be what. 2 pages of text possible or a few lines?

[05:36]

I can say for sure that the amount of text limited in a connomon 'tool tip" would not fly

[05:36]

err common

[05:36]

<crweb>

JohnDesigner: i'd perfer. A line

[05:37]

<crweb>

let the pages of text be in the application itself

[05:37]

crweb: its not about what you and I prefer. I dont care if it has help at all to tell the truth

[05:38]

its about a perceived need to have expansive help files for neophytes.

[05:38]

<crweb>

well, i'm not saying eliminate them

[05:38]

so a couple of lines will not cut it

[05:38]

<crweb>

but how often do you need help with filebrowser, when you are in the Menu

[05:38]

<crweb>

you don't need to know how to use filebrowser yet. you hit help to see what the item was

[05:39]

I am not going to debate the uses of it. This is not my argument.

[05:39]

<crweb>

but you'll be the one presenting it to the guys ;)

[05:40]

<crweb>

j/k. i just know, we can't keep it all in memory

[05:40]

<crweb>

and file i/o is going to kill us if we have to keep all those translations and all that data for each menu item

[05:40]

please put the performance costs of the current system and guidelines for lite system in an email pls

[05:41]

I'll see how it flys

[05:41]

FYI, the original want was for FAQ style help files

[05:41]

crweb: i'll tell nick to release without any help monday. we will add help back in when it's decided how to do it

[05:42]

<crweb>

good choice

[05:42]

crweb: or if he has too many issues in his patch, we just tell him to fix and if help instructions are avail before he's done, he will add help too

[05:43]

<crweb>

i tried explaining a new object helper method to him. but ended up saying screw it and told him to do what you said

[05:43]

the only way I'll get an agreement to have breif help texts is if the performance gain is explained in laymans terms.

[05:43]

<crweb>

so, i'm sure he'll get back to you monday

[05:44]

<crweb>

well, they don't need to be brief

[05:44]

<crweb>

they need to be moved to the correct places

[05:45]

<crweb>

it can be a manual for all we care. but the manual needs to be in the FB application. not in main-menu's FB item list

[05:45]

I assumed the cost would have been variable based on the amount of a given text file and you are saying yes, it should be that way but isnt

[05:45]

<crweb>

yeah, the cost is variable on the amount of text.

[05:46]

put it this way, if none of the current help texts need to be rewritten, then great. no problem

[05:46]

<crweb>

but the more text, the more we have to change the menu design to even larger problems

[05:46]

<crweb>

JohnDesigner: push "help" on FB item

[05:47]

the authors of the help text have some specific notions about what to say where.

[05:47]

Fb?

[05:47]

<crweb>

sorry, Play|Browse

[05:47]

<crweb>

"press (back arrow) line can be standard text. no issue there.

[05:47]

<crweb>

the 1st section, great. very good. could be trimmed

[05:47]

<crweb>

the 2nd section. worthless

[05:48]

<crweb>

who the hell cares about playing video when help is for the browser.

[05:48]

<crweb>

playing video notes should be in the video app

[05:49]

<crweb>

that first part is about the max amount of text we want

[05:50]

put your concerns and performance gain in an email pls.

[05:50]

<crweb>

no prob

[05:50]

or a bug report and address it to Jason

[05:52]

crweb has pushed it a bit here, maybe, but the issue is not really the help text per se, but how much of it we present in menu, and how much of it we present in the application. this is the balance we need to fix.

[05:52]

the actual text, it's not really important

[05:52]

crweb: just make that clear in email

[05:57]

I dont know what the current longest text is, but I can bet you will meet resistence in cutting it down.

[05:58]

unless a readily noticable performance gain will result

[05:59]

memory gain. that is not noticeable immediately, but when recorder crashes we have the right to blame who didn't cut the menu help text ;)

[06:00]

crweb: in any case, loading long help text on-demand, from disk files, when the user press HELP on a menu item... how feasible is that ?

[06:02]

<crweb>

well, its going to break translation

[06:02]

crweb: no more than menus are breaking it

[06:02]

<crweb>

right, but the menu's need 2 words translated

[06:02]

still out of linguist. 2 words or 10 is the same

[06:03]

<crweb>

not when you're talking about a new file for every menu item, per every language

[06:03]

hmm, right about that

[06:04]

what about making menu text in resource libraries, loaded on demand. that keeps linguist, and we get the hit only when we actually use help, which is rarely

[06:04]

<crweb>

the more you move out of linquist, the more auto sync you break

[06:04]

<crweb>

that is what i suggested to nick

[06:04]

<crweb>

but it its "cloudy"

[06:05]

that's his problem. and yours since you got to help him uncloud, with the help of Hunt

[06:05]

<crweb>

the only thing linking the menu and the library is "text"

[06:05]

<crweb>

no i mean cloudy as, defined in documentation and practice, not by code

[06:06]

<crweb>

and it gets more complicated too

[06:06]

we can give each menu item an unique ID, as a field in the menu file. and the same id will be used to index inside resource.

[06:06]

<crweb>

ok.. scratch that

[06:06]

<crweb>

just for argument sake

[06:07]

<crweb>

what if we place the menu text in a lib the same way?

[06:07]

isn't it the same thing i'm saying ?

[06:07]

<crweb>

and if a flag says "Neuros Menu" load the txt from lib. and if flag says "User Menu" add the text from .menu file

[06:07]

isn't it the same thing i'm saying ? ;)

[06:08]

a resource library is a library

[06:08]

it's just also linguist-able

[06:08]

<crweb>

well, i thought i was expanding it to include menu text + help text

[06:08]

<crweb>

but yes

[06:08]

but didn't you just say the library is "cloudy" ?

[06:08]

<crweb>

i said scratch that

[06:09]

<crweb>

my brain was doing lookups via text

[06:09]

<crweb>

you said go to id's

[06:09]

well, seems natural going ID since we may have two items in two menus with same text. adn text is regionalized anyway

[06:10]

<crweb>

you won't need to library it in this case.

[06:10]

how would it work

[06:10]

?

[06:10]

<crweb>

the translations are already libraries

[06:10]

but the english isn't

[06:10]

<crweb>

oh wait. i see. yes. for that part 1 library

[06:11]

ok, so can you lay down the guideline for doing this to nick ?

[06:11]

<crweb>

i was off on some tangent of 1 library for every lang

[06:11]

<crweb>

yeah. I'll write it up for him for monday

[06:12]

thanks. and say to JohnDesigner that we can have 8 pages of text for each menu item, now

[06:12]

:)

[06:12]

so no more worries

[06:12]

<crweb>

still think its dumb

[06:12]

* crweb smiles big

[06:14]

maybe, but we can just shrug as long as it works

[06:14]

and say "feh, end-user support"

[06:14]

;)

[06:15]

crweb: now, that patch about uuid, what dir is that against ?

[06:15]

<crweb>

e2fsprogs

[06:15]

isn't that part of bbox ?

[06:15]

<crweb>

Neuros-Cooler/external-libs/e2sprogs

[06:15]

oh, ok

[06:15]

good

[06:15]

<crweb>

some of it. I found more tools in there a bit ago

[06:16]

<crweb>

i went to add e2fsprogs and found that it exists...

[06:17]

i added it a while back, IIRC

[06:18]

<crweb>

parted wants readline, termcap, libuuid, and the list goes on

[06:18]

<crweb>

all things busybox replaces..

[06:18]

<crweb>

parted wants the .so's though

[06:19]

<crweb>

and has an option to disable readline, causing the compile to fail on any arch

[06:19]

<crweb>

after it tells you to disable readline

[06:20]

<crweb>

i'm goign to start leaving the GNU of linux just out of spite

[06:20]

<crweb>

err GNU off of Linux

[06:20]

can i ask you why don't we use libparted ?

[06:20]

<crweb>

would require core-updater to link to it

[06:20]

<crweb>

guess we could though

[06:20]

<crweb>

it won't build either

[06:20]

<crweb>

parted depends on it

[06:21]

but libparted doesn't depend on all the term and readline crap

[06:21]

<crweb>

the package won't build

[06:21]

isn't it a separate packages ?

[06:21]

<crweb>

no

[06:21]

way to go GNU !

[06:22]

<crweb>

libparted is the backend to parted

[06:22]

ya, so it should be separate and buildable stand-alone

[06:22]

in case one wants to add another frontend

[06:22]

<crweb>

definitely not

[06:22]

<crweb>

that'd be you know.. useful

[06:22]

indeed. anyway, i'm still in favor of libparted

[06:23]

<crweb>

no problem there

[06:23]

isn't there any embedded-specific parted replacement ?

[06:23]

<crweb>

nope. been looking for a while now

[06:23]

tried to poke busybox people ?

[06:23]

<crweb>

i read all the docs

[06:23]

<crweb>

could try that yeah.

[06:24]

they must have a channel where you can go bugger some poor fella, maybe they know of the replacement you couldn't find, even if it's not part of bbox itself

[06:25]

<crweb>

you mean "the" poor fella

[06:25]

<crweb>

odd how OSS works like that

[06:26]

<crweb>

GNU really needs to resctructure its apps

[06:26]

<crweb>

i've never had a GNU app build from source correctly

[06:26]

<crweb>

most of the time its stupid stuff like non-terminated strings etc

[06:27]

<crweb>

don't they test this crap?

[06:28]

probably works ok on x86 ?

[06:28]

<crweb>

nope

[06:29]

you follow the ususal autofoo dance ?

[06:29]

<crweb>

yep

[06:29]

beats me then

[06:31]

* nerochiaro goes eating

[06:32]

<crweb>

yeah.. its almost funny in that sad.. you make me want to throw a monitor out the window.. way

[06:32]

bugger GNU people

[06:32]

they are there for a reason

[06:32]

<crweb>

hah

[06:36]

<crweb>

if you want to see something really interesting, checkout the libs to parted. it ships with its own malloc and all kinds of stuff

[06:59]

that feels... evil. there has to be a reason of course, such as performance of their allocator in the specific case of formatting a partition. just guessing

[15:09]

Hey

[15:09]

<MP0>

hi

[15:09]

Anyone who has "administrative rights" on the server that hosts the wiki around?

[16:26]

man.

[16:26]

that joeborn guy is a quitter.

[21:07]

<MP0>

Question: the wiki mentions efforts to rewrite itfb as OSS... is that still going on? dropped?

[21:39]

<MP0>

I always wonder where they get people for writing data sheets... finding an enjoyment of writing and engineering and writing about engineering all in the same person must be difficult.