Log from #neuros IRC channel

Darchon: ask may1937 too, he's gonna mentor that project, so he's more qualified to give you an opinion on that. also, after monday everyone who submitted will be able to improve applications for a while anyway.

so don't worry

ok, cool :)

I'll study the documentition more thoroughly then in the mean time

[11:56]

i have a small patch i'd like to submit. are there instructions on how to submit patches? note: i'm not at all familiar with svn.

[12:49]

sorune: just email it to the mailing list.

[12:49]

someone will review it and submit it if good

[13:07]

hello. i'm trying to setup neuros osd to access a samba share

[13:08]

i've set the share to guest ok = yes, but it prompts for the password

[13:08]

with smbclient, i can proceed without entering the password

[13:08]

but neuros throws an error (regarding credentials)

[13:09]

is there a howto for osd/samba share?

[14:00]

i gave up and created a neuros user for the samba share

[14:01]

and i'm able to access movies over the network

[14:03]

<napfi>

hi adam! this is martin

[14:17]

<napfi>

\msg nickserv

[14:26]

<napfi>

i'd like to talk about the google soc07 but i'm not sure if anyone receives my messages?!

[14:33]

<crweb>

nerochiaro: how did the meeting go

[14:33]

hello

[14:34]

<napfi>

hello

[14:35]

<crweb>

hi

crweb: not much happened, some SoC organization, some update from Gao. something else i don't recall right now

napfi: need info on SoC ?

christianix: hello

<napfi>

actually i've got a date with adam to talk about the arm/dsp project

ok cool, he's may1937 in here

<napfi>

and christianix is my second account for testing

<crweb>

most of the SoC applications for the bridge take the same route of placing dsp memory, and rest like my current designs i came up with on my own.

<napfi>

yes, you told me.

<napfi>

i tried to open a privat conversation, but that didn't work

crweb: the ones that take any route at all ;)

<napfi>

i haven't used irc much so far

<crweb>

nerochiaro: of course.

napfi: you need to be registered with nickserv

<crweb>

nerochiaro: the bridge would pretty much replace imange

<crweb>

manage

crweb: btw, your QT package didn't work, it had libc of a wrong version or something like that

<crweb>

you're on dapper right?

[14:39]

crweb: imanage is the thing that allocates pieces of contiguous memory, right ?

[14:39]

and yes, dapper

[14:39]

<crweb>

nerochiaro: that was my understanding. contiguous memory, and the memory used by the network card/usb, etc

[14:40]

<crweb>

the devices might only seem to be connected... I'm just going based on the errors i had a while back with the netcard and imanage not having enough memory

[14:40]

<napfi>

the precise name of the dsp is tms320vc5x, isn't it?

[14:40]

<crweb>

tms320C5409

[14:41]

crweb: better memory than me, i keep forgetting these last digits :)

[14:42]

<crweb>

the "generic" would be c54x not c5x

[14:42]

and for the imanage, how can the bridge replace it ? memory allocated inside the kernel can be allocated somehow contiguosly ?

[14:43]

<napfi>

about memory: does the dsp have it's own memory? mapped into the arm address space?

[14:43]

<crweb>

nerochiaro: i don't think the contiguous memory is as much a big deal as it is used for an excuse of vendor lockin

[14:44]

maybe, but until we can try, i'll keep assuming it's needed

[14:44]

i mean, that would be a pretty lame way to do lock in

[14:45]

crweb: i think i'll bite the bullet and update to edgy or feisty, i'm tired of stuff that isn't in this version

[14:48]

<napfi>

where could i find the neuros api specification?

<napfi>

i didn't find anything in the wiki ...

so

testing of my OSD continues

napfi: look in the source, there's no documentation so far. sorry

It seems as though some things play just fine, other things are unwatchable and there are some cases when things that play fine seem to skip a few frames.

[14:50]

I imagine a lot of the skipped-frame issues could be because it's loading from a disk.

[14:50]

rather than SD/MMC, etc.

[14:51]

Emmett: you will find that most stuff that relates to codecs falls into the "vendor black hole". but skipping can be caused that, although usually it happens when playing from network shares

[14:51]

Sure, but things like VLC will play them fine on a computer desktop.

[14:51]

<napfi>

did i get it right, that the kernel is a monterey linux with the bsp done by integient?

[14:52]

So they've at least gotten something right that the OSD does not.

[14:52]

Emmett: indeed one big problem we have is that codecs are not under our control, they are provided by a vendor. that's why i call it "vendor black hole"

[14:53]

napfi: not sure if it's based on monterey

[14:53]

Sure, understood

[14:53]

napfi: but the bsp is provided by ingenient

[14:54]

<crweb>

nerochiaro: if you're already shady, theres nothing stopping you from being more shady

[14:54]

<crweb>

we are talking about a vendor lockin market

[14:54]

nerochiaro: Still, this stuff will need to be fixed.

[14:55]

Emmett: yes, Neuros is whipping the vendor into doing that

crweb: right. that's the anti-paranoid in me that talks, sometimes.

Also, you've got to keep in mind that a lot of people are going to want the OSD to play stuff they get on BitTorrent.

Emmett: I, for one

This means that it's not really the vendor that's the problem in the equation, but the encoder.

[14:57]

There should be zero reason why the Neuros cannot play encodes by aXXo, as he's easily the most popular p2p sharer.

[14:57]

So testing could lean a little in that direction, too.

[14:58]

Grab stuff from BitTorrent, see what plays, see what doesn't and attempt to fix when possible, etc.

[14:59]

Certainly not the easiest of tasks, but the price one pays when releasing a media player.

[15:00]

Emmett: i know someone in the team is putting togheter a database of samples that need to play

[15:01]

Good, good

[15:01]

hi all

[15:01]

Emmett: although help on that direction identifying the problematic files is very much neeed

nerochiaro: the idea of the bridge is to replace imanage? i.e allocate contiguous memory only?

I may burn a DVD of problematic files with textfiles explaining the problem

and send it to chicago

turran: crweb was saying that. i'm not sure

Emmett: that would be absolutely appreciated. please do :)

hahaha

"

The U.N. Security Council unanimously adopts a draft resolution to impose sanctions against Iran over its nuclear program."

<napfi>

is imanage the current arm/dsp bridge driver?

or you can create very short clips of them and insert them as bugs into bugzilla

napfi: imanage handles the allocation of contiguous physical memory

<crweb>

nerochiaro: no its not

<crweb>

nerochiaro: we'd have to have some sort of memory manager though, otherwise we will conflict with imanage

<crweb>

or, we'd have to submit and use imanage

<crweb>

which, we don't know how to use

crweb: dunno if i follow this correctly, the bridge will coexist with imanage?

<crweb>

where else is th ememory for the dsp going to come from?

thought that part of the bridge was to also code an imanage replacement

<crweb>

that would be nice, but then we break the codecs

indeed

unless we find a way to stay compatible with it

<crweb>

we can't have both, our own system, and ingenient system

<crweb>

nerochiaro: raises a question of, do we want to be, or want to be dependant on imanage

i prefer not to be dependant at all

<crweb>

right, but then we have no codecs

at least would be the framework for codec writers :)

<crweb>

we either develop the bridge, the mm, and the codecs, or, _??__

[15:09]

<crweb>

codec writers would need the $3k dsp compiler

[15:09]

big questions. of course no codecs doesn't make sense

[15:09]

yeah, at my company we have those =) also codec writers :)

[15:10]

<crweb>

well, if your company can feel free to donate a bit ;)

[15:10]

turran: even if you do, everyone else won't

[15:10]

that's true.

[15:11]

btw, binutils has a c54x port

[15:11]

<crweb>

the kernel is going to have to have some sort of memory manager (continuous or not) to allocate and communicate between the arm and the dsp

[15:12]

<crweb>

imanage is part of ingenient's "bridge"

[15:12]

crweb: do you know what kind of interprocessor communication exists on the device? something similar to omap or davinci?

[15:12]

i think we can have someone at neuros look at how imanage works, and have him write one of these famous "API layers" that we is basically the same as imanage's, but that can be documented freely. so we can keep compatibility with imanage

[15:13]

<crweb>

nerochiaro: that would be the best

[15:13]

we still use it, but we know how to use it properly

[15:13]

<crweb>

nerochiaro: if that can be done even right now

turran: you want to write codecs fully in ASM ? ;)

well imanage has some headers documented with doxygen, but arent too informative

<crweb>

we could test continuous vrs discontinuous memory

nerochiaro: jejeje nope :)

turran: then forget binutils :P

turran: by the way, is "jejeje" some kind of spanish way of saying "hahaha" or something ?

[15:15]

nerochiaro: =) well i don't laugh with 'h' but with 'j'

[15:15]

turran: crweb: with documentation i meant some human-written documentation

[15:16]

turran: depends on how "ja" is pronounced in spanish, i guess ?

[15:16]

<crweb>

might beable to pull out some reverse engineering

[15:16]

nerochiaro: yeah, on spanish there's no sound for the 'h'

[15:17]

<crweb>

it is my nap time. I will think on the memory issue for a bit.

[15:17]

turran: now i understand

[15:17]

<napfi>

where do i find more information about that "imanage"?

[15:18]

napfi: check on the kernel include files, imanage.h, run doxygen will all the i*.h files and you'll see

[15:18]

will/with

[15:19]

did you see someone is going to submit a codec proposal?

[15:19]

<napfi>

may1937: hi adam!

he thought the bridge was getting to crowded

nerochiaro: within neuros osd developers do you have access to what ingenient coded?

hi there

hi may1937 =)

gao said they do not have the dsp sources

[15:21]

:(

[15:21]

<napfi>

may1937: how many people are interested in the arm/dsp bridge project for soc?

[15:22]

there have been 9 or 10 applications, most very bad and not acceptable

[15:23]

* turran hopes is not one of those

[15:24]

there were i think 3 good looking ones

[15:25]

turran: yes, i think i can access that code

[15:25]

turran: i'm not sure i'm good enough with that low-level stuff to document it, though

[15:25]

which is why this other guy wants to look at codecs, any of you other people looking at dsp bridge could feel free to submit a codecs application if they want

[15:26]

nerochiaro: regarding this patch, is there a certain format that is desired or just attach the whole file?

[15:26]

sorune: diff -u against current trunk or a specific tag

ok

may1937: do you know what the dsp/arm communication the architecture has? similar to omap's or davinci's?

craaaaaaaaaap !!!! i forgot a cake in the oven !

* nerochiaro runs

[15:28]

jaja =)

[15:28]

turran: i am not sure i have not looked at the others

[15:28]

may1937: mailboxes? shared memory?

[15:29]

nerochiaro: you've just been cooking up a storm, haven't you? :)

[15:30]

turran: there is shared memory, don't know about mailbox

[15:30]

oh right you are the guy who brought up dspgateway

srobertson: a storm that smells of burnt smoke in this case

srobertson: but it's mostly still edible

ah, that's all that matters then

* srobertson (well, his roommate, but...) set off the whole building's smoke alarm two days ago

srobertson: indeed. i have sprinkled the remains with chocolate chips so it will mask some of the burnt taste

srobertson: with food ?

<vzl>

hi [g2]

it's not burned, it's ...blackened

srobertson: right

yeah, my roommate used one of my off-limits pans -- because his friend came over and burned the hell out of it previously --

<[g2]>

vzl, hi

and it smoked up a storm. i take responsibility because i didn't explicitly warn him not to use that pan.

oh, wait, i did.

;)

turran: i will try to have a look at imanage source, see if i can do that and be of any assistence. also ask about what i can actually document after i see that

* srobertson should have thrown it away, tho

<[g2]>

vzl, should I know you ?

<vzl>

yes, as vmarks

turran: it looks like there is an actual mailbox register in omap, the dm320 doesn't have that, although you could build a similar software abstraction

<[g2]>

that's what I figured

<[g2]>

so the apple tv is up and running

srobertson: you should really throw away these things, not just mark them off-limits

<[g2]>

the ssh isn't working yet

srobertson: they're dangerous to health

[15:35]

<[g2]>

but the drive is imaged and backed up and it booted fine

[15:36]

<vzl>

so you need ssh working, and then off to the races.

[15:36]

[g2]: what are you cooking up with the appletv ?

[15:36]

<[g2]>

nerochiaro, the appletv is being hacked

<[g2]>

many have ssh root access already

<[g2]>

it's just an OS X machine really

[g2]: that's what i imagined

<[g2]>

so avi, divx are running

<[g2]>

I think I just saw vlc

[15:38]

Hmm. 0.84 is really rather nice. The interface is *much* improved.

[15:38]

pretty nice, although ... does it have hardware that makes it worth it ?

[15:38]

Improv: i really love that "coming soon" thingie

<[g2]>

nerochiaro, it does to me

Heya nerochiaro - dunno if we've chatted before :)

Improv: couple times maybe

<[g2]>

I think it can easily be a $299 720p pc

<[g2]>

and as a streaming devices it works ok too

[g2]: how much does apple price it now ?

<[g2]>

it's $299 now

Oh, you're talking about the AppleTV?

<napfi>

i still have a few questions about the arm/dsp project ...

napfi: i'm still here

<[g2]>

Improv, nerochiaro asked what I was playing with on the appletv

[g2]: what interesting bits of hardware does it have ?

<napfi>

does the dsp have a different address space then the arm? or do they share the same?

napfi: try asking

<[g2]>

nerochiaro, the things in my mind are NV 7300 chip with 64MB memory, Ethernet, and Intel processor

napfi: all the dsp's memory is inside the arm's memory map

<vzl>

nerochiaro: it's an intel 1ghz processor with an nvidia 7300 gpu, and a wifi card. It's basically a very affordable computer.

<[g2]>

ide drive and 802.11n are ok too

<vzl>

dang, I need to sign up on the wiki and edit nero's epg page.

vzl: So a somewhat cheaper MacMini..?

napfi: the dsp has 6 dma channels to manage memory transfers

<vzl>

Improv: that's about right.

<[g2]>

way cheaper

MacMinis are like $400....

<napfi>

but physically the dsp has it's own 2 memory areas (program, data)?

<vzl>

Improv: where?

<vzl>

current mac minis are 600.

<[g2]>

Improv, Intel Mac Minis ?

vzl: oh, oops, forgot - I work for a big university.

the dsp's memory is paged

[g2]: cool. is it completely fanless ?

<vzl>

Improv: yeah, edu is good. look up what discount you get on appletv?

<vzl>

nerochiaro: one fan.

<[g2]>

nerochiaro, there's a fan one the cpu

vzl: I'll have to check when I'm at work.

vzl: hopefully not noisy, or it wouldn't make any sense

<[g2]>

vzl, I'd be interested in making a new bottom to the case

<napfi>

on system startup i guess, the dsp does nothing until it get initialised?

<[g2]>

at a 120mm fan and a full 3.5 HD

may1937: indeed i am :)

<vzl>

nerochiaro: [g2] has one. he can tell yhou how noisy.

<[g2]>

I think it's silent

<vzl>

[g2]: wouldn't be too hard to make a new case bottom up.

nerochiaro: ok, good thing to document

<[g2]>

I haven't heard it

vzl: I recently moved my experiment lab to a bunch of MacMinis - they're really good as a lab computer..

<[g2]>

vzl, no it wouldn't and just the drive is on the case :)

napfi: correct

may1937: yeah we can build the same using shared memory and interrupt handlers

<vzl>

Improv: I keep thinking I need to do the same. replace the towers...

<vzl>

I would need to keep one tower for pci devices.

vzl: The only thing I worry about is subjects walking off with them.

[g2]: pretty cool, as soon as someone gets something non-osx running on it, i might fetch one. how big is the hdd ?

<[g2]>

Improv, nod, but the mini's don't have a graphics chip

<vzl>

Improv: kensington locks.

g2: ... pardon?

may1937: but dunno how all of this matches if the dsp doesnt has a mmu, or it has it?

<[g2]>

nerochiaro, stock is 40G, but I saw some guy running 130G

<vzl>

nerochiaro: 40gb. and there are already movements to get regular OS X on it, so a linux shouldn't be too hard.

dsp has no mmu

<[g2]>

Improv, the mac minii don't have a discrete graphics chip

g2: If you mean that their video capabilities arn't that fancy, that's not a big deal

[g2]: so it's relatively easy to open up and replace pieces

* [g2] is planning on streaming video

<vzl>

nerochiaro: very.

<[g2]>

nerochiaro, the chips are soldered on except for the wireless

cool, at $299 it's pretty neat

<vzl>

[g2]: I thought the intel chip was socketed.

None of the researchers in my group use 3d in their experiments.

[g2]: i was talking about replacing the hdd, mostly

<[g2]>

well the processor may be socketed too

<vzl>

nerochiaro: hdd replacement has already been successful. it's just a 2.5 pata ide.

<[g2]>

nerochiaro, hd is easy (power may be an isssue)

[15:48]

<napfi>

where is the d/a that outputs the data the dsp calculated?

[15:48]

[g2]: ok. 40G ain't that bad anyway

[15:48]

<napfi>

is it also memory mapped?

[15:49]

<napfi>

"where" refers to which bus

[15:50]

napfi: decoding to that would not be a goal of the bridge project, if we can get code transfered and running on the dsp with a framework for communicating with arm it will be a success

[15:52]

<napfi>

may1937: it's just good for testing to get some sound output

[15:54]

it is not memory mapped, it is a serial port

[15:54]

<napfi>

may1937: is the code of the actual bridge available? or where would i find the api/abi documentation?

[15:56]

<napfi>

may1937: or is it what the nda is about?

[15:56]

unfortunately those docs are closed

[15:57]

<napfi>

so there is only a binary kernel module in the bsp tree?

[15:57]

but yes with an nda you will get access to them

[15:57]

there are currently mainy binary kernel modules

[15:58]

<napfi>

the ones in kernels/kos?

[16:00]

bye all

[16:01]

yes those

[16:04]

srobertson: still around ?

[16:04]

napfi: isn't it ko64 ?

<[g2]>

vzl, I didn't disable the firewall

<[g2]>

that's probably why ssh isn't working

<vzl>

aha.

<vzl>

firewall on the appletv?

<vzl>

or on the mac?

[16:09]

<[g2]>

on the appletv

[16:17]

nerochiaro: 'sup

[16:18]

srobertson: you submitted for SoC for uPnP right ?

[16:21]

yes

[16:24]

srobertson: do you really want to do that, or any other project is ok ?

[16:28]

srobertson: i've got an application from a guy on upnp that is promising, and was thinking that you can either do it collaborating (like one the server and the other the renderer part)

[16:28]

or you could take another project

[16:29]

i mean, was just an idea

[16:29]

nerochiaro: I'm looking at the SoC site right now and planning to apply. I was wondering if you had a preference or glut of applications already as either the flickr browser or overnight transcoding...?

[16:30]

sorry folks, have to run

[16:30]

rprescott: please email me

[16:31]

ok

[16:36]

nerochiaro: sorry for the pauses, xchat's sposed to beep but it wasn't...

[16:36]

yeah, that's fine. i haven't really considered other projects yet, but I am happy to

[16:37]

unless you have a specific suggestion, i'm gonna poke around for a bit

[16:45]

<napfi>

bye! i'm going for a walk.

[17:26]

quick question: which block device is the CF card on the OSD?

[17:30]

<vzl>

[g2]: I'll be back later.

[17:30]

<vzl>

talk to you then!

[17:52]

is it not a simple 'mount' operation with a CF card? I was expecting it to automount. When that didn't work, I tried a couple of manual mounts with /dev/hda and /dev/hda1. I didn't see anything on the wiki at first glance, so I thought I'd through out what I thought was a softball question here. Do I need to dig deeper?

[17:52]

hi

[17:53]

its possible to modify firmware to it save videos in raw mode ? video in recording

[18:00]

kinocon: I don't know the answer to your question, but I'd like to understand what you are trying to do.

[18:01]

are you wanting to put RGB422 data onto the NAND flash or CF card?

[18:02]

into a memory card of corse

[18:02]

er, that should have been RGB or 422, etc.

I'm trying to figure out how many bits per second you are talking about writing...

well i got a microcamera that i put into a plane and i wanna record at ground the video at best quality possible doesent batter video size, and mpeg4 is not the best format... in fact i think is a little shit,

it might not even be possible to write it out if it is too many bits per second.

mmmmmmmm well, if raw is not possible, then the best format ?

well, it would probably depend on the resolution and what speed drive you put in...

mov... or mpeg2 is okey too,

if you put a fairly fast microdrive in there, you could probably do something in raw.

the best one... 740x ... dont remeber the other number