Log from #neuros IRC channel

well thats fine and stuff.. but the major issue is, all of this is moot because the bridge, and ingenients modules can't both exist in the same memory space..

[00:04]

how is this moot?

[00:04]

<cr-tablet>

imanage uses that portion of ram that the kernel doesn't use. We don't know how much, or how it does it

[00:04]

exactly why we don't use imanage

[00:04]

<cr-tablet>

but ALL the codecs do

[00:05]

and thus we are ditching them

[00:05]

<cr-tablet>

theres no 1/2 and 1/2 solution, we need either all the codecs for our new system, or no new system

[00:05]

<cr-tablet>

whos going to write the codecs?

[00:07]

the goal of these projects is not to replace neuros's current codec lineup

[00:09]

<cr-tablet>

i'm just saying the idea that, joe's already said he doesn't want to become a codec developing company

[00:09]

<cr-tablet>

and open source interface for codec developers to use, would be awesome though

[00:10]

<cr-tablet>

it just can't coexist in the osd

[00:10]

<cr-tablet>

easily

[00:11]

<cr-tablet>

anyway, sorry got off track

[00:11]

i can't disagree with any of that, what was your point?

[00:12]

<cr-tablet>

different subject sorry

[00:12]

<cr-tablet>

may1937: what i meant by .ko and .so, the plugin for say mp3 libmp3.so would send the data to the dsp bridge the bridge would then put it in the dsp's memory space?

[00:14]

i believe the interface for all codec types could be the same and would not use a library, just a device node

[00:14]

<cr-tablet>

so.. nms calls function in libmp3.so which uses the dspbridge.ko which puts the data in dsp's input_buffer, dsp executes, nms calls read functions in libmp3.so which reads the data from the dspbridge.so that the bridge reads from the dsp's output_buffer

[00:14]

<cr-tablet>

playing files / encoding file

[00:15]

<cr-tablet>

err.. bad example.. i just made a mp3 -> mp3 transcoder..

[00:15]

<cr-tablet>

but whatever, I'm interested in the flow

[00:17]

more like nms opens /dev/dsp0, calls an ioctl to set the codec, and starts streaming data

[00:17]

<cr-tablet>

interesting

[00:18]

there would be no .so in my vision

[00:18]

a couple of the bridge applications mention a dspgateway project, have you looked at that?

[00:19]

<cr-tablet>

you'd still need a library to detect the file type, set the ioctl, and stream the file

[00:19]

<cr-tablet>

or let higher software worry about that?

[00:19]

<cr-tablet>

i read a little bit about it

[00:19]

<cr-tablet>

its not compat with us though

[00:20]

yes but that is not the job of a codec, and would all run on the arm anyway

[00:20]

<cr-tablet>

ok

[00:20]

<cr-tablet>

codecs job, take input, produce output to buffer

[00:20]

it is not compatible, but it is similar enough to be interesting

[00:21]

<cr-tablet>

might get some nice design ideas from it

[00:21]

we would probably maintain the same api for example

[00:21]

<cr-tablet>

it would take some investigation to make sure the api is actually suitable though

[00:21]

also, remember in the case of playback the dsp also has to handle the audio/video out

[00:21]

indeed

[00:21]

<cr-tablet>

OSS doesnt' always mean, best solution

[00:22]

to be fair it is sponsored by nokia and has a similar application domain

[00:22]

<cr-tablet>

i wouldn't want nokia controlling my api...

[00:23]

<cr-tablet>

but thats just me

[00:23]

it's already in mainline kernel

[00:23]

<cr-tablet>

corporate paranoia at its best :)

[00:24]

you don't want nokia controlling your api but you want to interoperate with some closed source codecs that seems to substantially change every few months

[00:24]

<cr-tablet>

the gateway project does look much more like the way i would expect the system to be designed

[00:24]

<cr-tablet>

dynamic loading of programs. Not 50 kernel modules

[00:24]

<cr-tablet>

for example

[00:25]

well it is always best to keep as much as possible out of kernel space, unless performance demands it, and who knows... maybe it did

[00:27]

<cr-tablet>

huh.. they have some excellent documentation

[00:29]

<cr-tablet>

their dsp memory shadows, thats how i would expect it to work.

[00:29]

<cr-tablet>

i'll be reading more. thanks may1937

[00:32]

hey.

[00:32]

<cr-tablet>

hey

[00:32]

the 1/8th inch to 9pin that ships in the box... is this a null modem adapter?

[00:32]

<cr-tablet>

no

[00:32]

hm.

[00:32]

<cr-tablet>

just a F -> F

[00:33]

ok...

[00:33]

could I put a null modem on it and talk to the console?

[00:33]

<cr-tablet>

yes

[00:33]

ah...

[00:33]

<cr-tablet>

well

[00:33]

better.

[00:33]

<cr-tablet>

i wouldn't suggest talking

[00:33]

<cr-tablet>

but hey, i guess it could work

[00:34]

just whistle 200 baud

[00:34]

* vmarks used to be pretty good at fooling 300/1200/2400 baud modems

[00:36]

<cr-tablet>

I'm out have a good morning,day, or night

[00:37]

nerochiaro: are you around still?

[00:38]

may1937: will be for a good while

[00:38]

any idea when we are going to sort out this SoC stuff?

[00:39]

may1937: i think we should set a day and get togheter all mentors to do it

[00:40]

good idea, too bad cr* left

[00:41]

[00:41]

woah 36 now

[00:42]

may1937: i'll send out a mail to all mentors, and we'll setup a date via email. or can you please do it ? ;)

[00:42]

may1937: they're pouring in nearer the deadline

[00:43]

<American-Tech>

How many are therre?

[00:44]

nerochiaro: just you me anders_ crweb ?

[00:45]

may1937: also anders i think

[00:50]

<American-Tech>

Has drunk to much tonight because he did not see the 26 above.. DOH!

[00:50]

<American-Tech>

36

[00:51]

may1937: aye

[00:58]

ok a shot in the dark on the time

[00:59]

what time is it now in the US ?

[00:59]

well many times, gmt -6 here

[01:00]

so, 1AM in the night ?

[01:00]

midnight

[01:01]

between 2AM on the Atlantic Coast all the way to something like 11PM on the Pacific Coast

[01:01]

don't forget hawaii!

[01:02]

i think i'll propose for a time around now, maybe one or two hours early

[01:02]

may1937: how does that sound for you ?

also maybe 28th ?

i already emailed

1600gmt 29th i said

i'll reply with proposal, but what you think of this, since you're here: tinyurl.com

[01:05]

or even 1h early than that

[01:07]

that would work but do you know what time anders is?

[01:07]

ah, right, he's in europe too. so no go for him, that's early morning

[01:09]

you are just a morning person?

[01:10]

may1937: wasn't until 2 weeks ago. i'm trying to adjust to China time to be at least some hours in sync with Xiamen folks

[01:11]

ouch

[01:11]

may1937: so at 18:00 i'm a bit wasted, as you can imagine ;)

[01:12]

but it's really not that bad. i really appreciate catching sunrise now that we switched to DST. and i'm more productive at morning, it seems

[01:34]

any svn expert-ish around ?

[01:47]

i know cvs better than i'd like, but that's about it :-P

hi all

hi turran

hey turran

=)

meh, i can't figure out how may1937 found the address of some register...

[05:07]

turran, have u looked at svn.neurostechnology.com

[05:07]

?

[05:08]

Darchon, indeed, i saw the code, an initial step :)

[05:08]

yeah

[05:09]

can u figure out how he got the address for the HPIB control register?

[05:09]

i guess he has the documentation

[05:10]

actually, nerochiaro, where's the documentation for the ARM side of the DM320?

[05:10]

I can only find stuff about the DSP

[05:10]

Darchon, all DSP's have a HPI, maybe on the dsp docs are the registers address?

[05:11]

yeah, but u reset the DSP from the ARM

[05:11]

so that address is within the ARM address range

[05:12]

I could find the HPI control reg address on the DSP

[05:12]

but not for the ARM

[05:16]

well we dont have the dm320 docs, but the docs of the dsp itself

[05:16]

myeah, I guess those docs are under NDA

[05:17]

Darchon, i guess so :(

[05:22]

I'm off for abit, cya

chau =)

crweb:Hi!!!

* shaddy waves hello

hey shaddy

nerochiaro:Hello

nerochiaro:Finally I get to meet you

[06:25]

nerochiaro:I wanted to apply for that BitTorrent Project

[06:25]

shaddy: sure, you're still on time

Of course.

hi all

hey shaddy

now i won't have to think about doing BT anymore ;)

[06:26]

daurnimator:Hi

[06:26]

daurnimator:Ok

[06:27]

nerochiaro:I have done a Journal/Survey about BitTorrent in my 5th semester.

[06:28]

so I am totally aware and very well know the BitTorrent Protocol and stuff

[06:28]

shaddy: mention that in the application, along with a detailed plan (possibly with timeline) of how you want to go forwards with the project

[06:28]

nerochiaro:Okay

[06:28]

shaddy: the more detailed you can be, the better chances you have to be picked up

[06:29]

nerochiaro:I get it.

[06:29]

ok

[06:30]

nerochiaro:I just wanted to know what restrictions will ARM arcitechture put on it,the limited address space issue is obvious, anything else?

[06:31]

we have a problem with storage

[06:31]

- OSD has no permanent storage

[06:32]

shaddy: well, you have to be very conservative in the size of your binary. also if you need to store temp files on something that is not the destination media for the downloaded files, you have to keep it very very small

[06:32]

client can download on the available storage

[06:32]

shaddy: yes, but maybe you need configuration files or something

[06:32]

shaddy: that's what i was mentioning

[06:33]

shaddy: also i stess that we have little space for the actual program binaries and libraries, so if it uses some cool but huge utility library, it's gonna have programs

[06:33]

er, problem

[06:36]

umm,got it.

[06:36]

so you mean to say I can only use the standard C libraries.

[06:36]

?

[06:37]

of course no, if you need other libraries you can have them, but don't go overboard

[06:37]

what about libtorrent?

[06:37]

does it fit in?

[06:38]

no idea how large that can be, you got to try and build it, strip it and see. i guess it's ok, but i'm not sure

[06:39]

yeah

[06:39]

you can use libtorrent

[06:39]

but making your own would be so much more fun ;)

[06:39]

I think the standard BitTorrent Client Protocol will be the only thing I can take from the other open source clients avilabele.Evrything needs to be optimized,including all the algorithms

[06:39]

daurnimator: and so much more bug-prone and time consuming ;)

[06:40]

nerochiaro: work for the $4500 ;)

[06:40]

Even i was thinkin on the same line, we will take only the features required for OSD.

[06:40]

daurnimator: there it work enough as it is without reinventing the wheel

[06:40]

from libtorrent

[06:41]

nerochairo:I totally agree with you.

[06:41]

shaddy: well, you can do that, but then it might be messy to keep up with libtorrent. if small, just use if

[06:41]

er, use it

[06:41]

I think may be libtorrent optimization can be done after SoC.

[06:41]

if even needed

[06:42]

shaddy: but.. rasterbar's libtorrent or rakshasa's libtorrent ?

[06:43]

yha!we will need to evaluate the performance, but I dont think it will affect as much as the protocol I mean if we use popular optimization techniques like "optimistic unchoking" etc. we wont face any problems.

[06:44]

shaddy: btw, be sure you mention all this stuff in the application

[06:44]

Even that is something I need to figure out.

[06:44]

nerochiaro, seems that nobody cares my new build system and package manager? Anyway, I'm still trying to get more familiar with current osd softwares and package them up to release my host-brewed image to boot from osd. Hoping this will spur everybody awareness of the build system and package manager

[06:45]

nerochairo:Arent you the Mentor?

[06:45]

shaddy: all this stuff you still need to research, say that you know there is such and such problem and you need research it

[06:45]

shaddy: i am one, there are others

[06:45]

nerochairo:Okay got it.

[06:46]

hellwolf: i mean to try your package manager, but have not had the time yet

[06:46]

hellwolf: there is also a build system ?

[06:46]

nerochairo:You mean I include eevrything I know.

[06:47]

nerochairo:I will try and include all the relevent details.

[06:47]

nerochiaro, yes, a build system , a package croping system ,and a package manager

[06:47]

shaddy: yeah, you include the potential problems you know of, so we know you are not clueless to what is to be done

[06:47]

hellwolf: can you describe better the "build system" part, i'm not sure i understand what you mena

[06:47]

mean

[06:47]

nerochairo:Yup!

[06:48]

nerochairo:I better start writing my application.I suppose you will be here for help.

[06:48]

nerochiaro, a build system eat a bunch of build scripts and generate a software repository

[06:49]

refer to this base one : ftp.fedora.cn

[06:49]

In it is a bunch of build script

[06:49]

it generates these : ftp.fedora.cn

[06:50]

And croped to these : ftp.fedora.cn

[06:50]

mipkg is ipkg based , so it use ipk

[06:51]

hellwolf: so one can make ipk with another tool and install them with mipkg ?

[06:52]

Waw, net split

[06:53]

nerochiaro, that could be so, but the dependencies may be hard to maintain

[06:53]

ok

[06:53]

nerochiaro, the build system also calc the dependencies automatically

[06:54]

so let me see if i understand. first you build RPM packages with the build system (which run the regular configure/make stuff). then you convert the RPM to ipk ?

[06:54]

Yes, not just convert

[06:54]

the crop stage is used to control the process of convert

[06:55]

You can choose what need what not need

[06:55]

For example the locales

[06:56]

I can control the crop system to get everything tagged with lang:zh_CN lang:en_US, but ignore other lang:*

[06:56]

ok. how does it know what files to take and what files to leave out ?

[06:56]

tag them

[06:56]

how do you do that ?

[06:57]

Some automatically, some to write overlay script to describe it

[06:57]

how does it work for automatically ?

[06:58]

and i suppose that to do it manually, you describe them in the %files section of .spec files ?

[06:59]

No, the tag infomation is not along with rpm spec indeed. Tag is done in a seperate place

[06:59]

The tag facility is not designed completetly, franckly speeking

[07:00]

ok

[07:00]

nerochairo:Okay one last thing Can you tell me how many candidates have applied for this project till now?

[07:00]

My mind is to make every osd software into a bunch of build script, since it's more like portage and maybe more easily maintainable

[07:01]

hellwolf: much better. anyway, how does this work with the OSD ? i mean, this might is a good general purpose package manager, but does it keep in mind the OSD has issues like read-only root fs, little flash space, need to install stuff on removable media, etc

[07:01]

shaddy: i think around 3

[07:02]

nerochairo:Okay.Thanks.

[07:03]

nerochiaro, mipkg is multirepo, that is to say, the database of packages is distributed, it resolve the problem of removable media. And about the ro root, I'm plaining to make a ro flag to addrepo function

[07:03]

wait, what does it mean multirepo exactly ?

[07:06]

repos : main / / , opt1 /media/disk1 /opt , opt2 /media/disk2 /opt this is an example of three repo, the dependencies is resolved between each of them.

[07:06]

with repo you mean the place where the package is installed or where the metadata about the package is kept ?

[07:06]

yes

[07:06]

<case>

a local repository of packages disseminated through various target directories?

[07:06]

which one ?

[07:07]

<case>

nerochiaro, good morning/afternoon

[07:07]

err... all

[07:07]

case: you too

[07:07]

hellwolf: sorry, i'm not sure i understand

[07:08]

<case>

hellwolf, i'm not understanding this, so could you have a go at rephrasing the intent of mipkg?

[07:08]

Ok, let me try to give a concret case.

[07:09]

<case>

nerochiaro, 66.102.9.104

[07:10]

<case>

nerochiaro, seems to be his old blog as well :D

[07:10]

case: i know

[07:10]

<case>

oh alright :)

[07:12]

System started, in init script, mipkg add a main repo, whose location is "/" and it will be redirect the prefix to "/"(no special action). When a USB inserted, hotplug script or udev script(not yet done) will add a new repo, whose location is "/media/diskX" and will redirect the prefix to "/opt"(redirection is done by symlinks currently). Packages whose dependencies is met will be included. For install a new software, you choose a repo to install t

[07:12]

o firstly ,and the dependencies will be resolved across all repos

[07:18]

hellwolf: but i stil don't understand what you mean with "repo". what does "repo" contain ? binaries ? metadata ?

[07:18]

Binaries and metadatas all in it,

[07:19]

ok. why each repo should have a different prefix ?

[07:23]

Well, I know, if use things like unionfs, you can just ignore this. But if not use special file system, the different value "prefix" and "location" of repo will caused mipkg to build a symlink farm package, it's just optinal. I don't know if the unionfs better or symlink farm better indeedly. nerochiaro

[07:24]

ok, i understand now

[07:25]

the part that build the packages seems a bit messy, but i need to try it and see

[07:25]

Seems that my english is still understandable, though may be too hard..

[07:25]

hellwolf: your english is pretty good

[07:26]

haha, thanks. And also there's many ways to build the ipk package, my goal is to maintain everythin easily

[07:28]

the part that is most interesting for OSD is the part that manages and install packages on board of OSD. how to make them can be fixed later, once the format of the package is well-defined

[07:28]

and well-documented

[07:28]

ipkg format is really easy-defined indeed

[07:29]

where is documentation for that format ?

[07:30]

nerochiaro, handhelds.org

[07:31]

nerochiaro, but if you unpack some ipk, you will see everything it , it's just a tar archive or ar archive

[07:33]

so they have no metadata inside them ?

[07:33]

there's a control.tar in it

[07:33]

That's the metadata

[07:33]

where is the format documentation for that ?

[07:35]

handhelds.org --> "What is the .ipk format?" Maybe it's too simple to document

[07:38]

"/control.tar.gz contains meta-data and scripts for the package. It must contain a file named control. It also may contain the following files: conffiles, preinst, postinst, prerm, postrm. Heck, it may contain anything else for that matter, but it wouldn't be useful."

[07:39]

you see, this is what annoys me of ipkg, documentation is a very bad

[07:40]

Then rpm is well documented only if you can afford it them ;).

[07:40]

then

[07:40]

rpm ?

[07:42]

Ok, just joke, stop that. And what else document do you need about ipkg? The format? The programming api?

[07:42]

the format, so that if someone else wants to create something another tool to build ipkg packages, they can do it

[07:43]

a ipkg-build script is enough to do that, ant it's very short

[07:44]

If you think source is document tooo

[07:44]

ok, it's good too

[07:52]

nerochiaro, what's the address width on the ARM?

[07:53]

it's 32bit?

[07:55]

it's 32bit, yes

[07:55]

I do not really understand the the BitTorrent client idea description

[07:56]

it says when using libtorrent u have to be carefull of the limited address space in the ARM

[07:56]

but isn't it as limited as any desktop CPU then?

[07:57]

OSD has 64M sdram IIRC, isn't it enough for bittoreent?

[07:58]

Darchon: i'm not sure who wrote that part, actually

[07:59]

if it were a 16-bit processor... I would understand that sentence :P

[08:00]

Darchon: try asking srobertson :)

ok :)

ick. Blog spam :(

again ??

yup

I nuked it

JoshMalone: thanks.

we need to figure out how they do it though

[08:13]

yeah

[08:13]

* JoshMalone isn't very familiar w/ this CMS

i can just use it

hehe

meh

how come TI only lists C54x DSPs with an ARM7

[08:15]

is OSD a custom solution offered to you by TI?

[08:16]

the DM320 processor is a normal TI offering, IIRC

[08:16]

cuz it says on the wiki that the DM320 SoC is a dual-core solution of an ARM9 and a C54x DSP

[08:18]

so it's ARM9. not 7

[08:18]

yeah

[08:18]

but I can't find such a combination on the TI site :(

[08:20]

sure enough, I can't find it either

[08:21]

I've forgotten the exact part used in the OSD. TMS320DMsomthing

[08:21]

actually, it's hard to find any description of the DM320 platform :P

[08:21]

TMS320DM320

[08:22]

Darchon: the TI site gives me bad dreams at night, so i usually don't go there, sorry

[08:23]

haha

[08:23]

hehe, that's cool

[08:23]

i dun like it either :P

[08:23]

can't sleep, texas instruments will eat me

[08:24]

can't sleep, there's a texas instruments lurking in the closet

[08:24]

the texas part is the most scary

[08:26]

hi all

[08:26]

hiding under the blankets from Zombie Jack Kilby

hey JoeBorn

howdy

hey Joe

sorry, away all weekend, did I miss anything?

[08:28]

* JoshMalone has finally gone psycho and is re-ripping his entire CD collection to ogg & flac

[08:28]

JoshMalone: good times

JoshMalone: ogg?

wtf

always lossless