New Neuros Device
Joe Born
You can find information here. Again, there are a handful of discounted units and I can send out pictures, screen shots etc to anyone interested (I didn't post here since we only have a handful of units and we're trying to avoid blog coverage). If you are a linux admin, hacker and watch TV, then we've love to have your participation.
http://wiki.neurostechnology.com/index.php/CODENAME_W.U.M.P has some basic information (obviously that's not the real name, but I thought it was funny)
One of the first things you'll notice about this is that it uses x86 and more off the shelf components than we've used before. burobjorn's post makes some of the case for this, but a recent conversation I had with Pavel also provides a good Q&A that highlights some of our motivation/thoughts.
In short, our doing an x86 product doesn't signal that we're leaving the embedded world, it's just an attempt to better leverage the large power of the off the shelf world of software and hardware to allow us to focus on that "final 5%" of making the product really work smoothly and seamlessly, and at the same time innovate and allow the community to participate in a more efficient way. There's little doubt that we'll take our progress on this product and weave it into our embedded devices.
+++++++++++++++++++++++++++++++++++
JB:> yep, h264, I've seen 1080p running on it. We're looking at
> a 45W 2.6 GHz Athlon processor
noisy, bulky, poor performer. Having worked with VIA Epia I'm
very skeptical about idea of using x86 for multimedia.
JB: VIA is largely embedded x86, what we're talking about is real PC hardware and processors. It's true that it's not as efficient as the embedded processors (and it is bigger) but at 45W, we can get the device very quiet and the case won't be larger than a standard component. The bottom line is that we're talking about a $299 device with the capabilities of playing back virtually at internet video, flash based or other. We can play anything that mplayer and vlc can play on the PC. Pandora, Last.fm are supported off the bat, as are all the photo sites, etc. It's even possible to play iTunes store content for those that want it. Most importantly it can playback everything that comes down the pike in the future. As a consumer looking at this space, I'd vastly prefer a $299 device that "plays everything" than struggle with some $199 device that plays some portion and hope that portion continues to contain everything I want going forward.
************************
JB:> we're not looking at any of the embedded processors (on this project) because of the
> software.
products. In fact, I think OSD1 as embedded cpu coupled with open
software was brilliant idea. I still believe OSD2 has all chances to become
even more successful if you do it right.
It's hard of course to judge the product without seeing it but my preliminary
opinion OSD2 is better suitable for multimedia applications.
JB: We have no intention of stopping using embedded processors. We think open embedded devices are the future too (as it seems, so does Linus, Google and Apple :)
**************************
JB> The whole point of the Neuros brand is openness
> and the ability to experiment.
device and openess is secondary feature helping to achieve
business objective.
Anyway, it won't make any good to openess if some business mistakes
(sorry) will kill potentially very good product.
Don't get me wrong, I like OSD lets hobbyists to implement their wild
projects. But I think much more important is the fact it's openess is
attractive to commercial clients which I believe is the real OSD market
that has been ignored so far.
Get the basics done (codecs and API), knock IPTV providers doors
and you'll have thousands more clients. You can give them SDK to do
integration (Netflix, NMT) or hire programmer and do it in house.
This way you'll get revenue stream to support "hobbyist" sales if you want.
Embedded devices are expensive to manufacture. Frankly, I doubt Neuros
will survive if you keep focuse on hobbyist market only.
Look at Syabas. Their NMT and siblings have enormous sales, yet their SDK
gives very limited control over what you could do compare to OSD. Still it's
good enough to add IPTV services.
Being more open OSD2 has advantage over NMT but lack of wmv is killing it
(at least for me).
JB: Fair enough, I should have said that openness and experimentation are our points of difference for our multimedia devices. I think it's pretty hard to maintain that point of difference with a device that's "partially open" with a very limited API on the device, particuliarly if that openness is targeted to commercial entities. That's not a lot different than what all the 3rd parties surrounding TI are offering, and it's not a lot different from what Sigma Designs and others offer their customers themselves. Maybe by being open Neuros could have some niche business that those companies essentially don't want, but I don't think this is a very strong differentiator in the world.
Compare that to building a community (hackers, influences and super users and ordinary users) around a bunch of open devices, and the commercial business is just a lot less attractive. The commercial side doesn't allow us to build a brand or a community, and I just don't feel its very defensible (assuming it's even a good business to begin with)
*********************************
JB:> To experiment you need software and lots of it. You need to
> be able to play adobe flash, you need a browser, you need
> peripherals and drivers. All of that is so much easier with x86.
market (which x86 become). There has to be something that
differentiates you from other manufactures. OSD has it's niche.
Moving to universal platform you're picking fight with big guys.
JB: I don't think the actually hardware was ever a real differentiator or very defensible. Our design was based off a public reference design with a few tweaks. The real protection/differentiation has always been on features and higher level functionality, including server side. Unfortunately, we got so bogged down in the low level stuff that we didn't have a chance to execute on our ideas for that.
I think it's easy for people to get confused about what Neuros is all about because we haven't been fully able to realize the vision we set out to acheive. Because so much of our efforts have been spent devoted to fixing low level defects and features, it's only natural to see us as an embedded company focused on those tasks. In fact, we always saw our hardware as a means to an end, with the vision being an open, innovative media device that could connect users and allow a community of developers and users to form. The vision was a device that would empower all those users to distribute and share media in ways that no closed device can. We continue to believe that's where the real potential for Neuros remains.
***********************************
JB: > Yes, the x86 hardware is more expensive,
could base their products on your platform.
JB: Maybe, if you are simply looking for a easy way to get to market with a dedicated product with a single function, then yes it's a disadvantage. To be honest, I'm not really sure that Neuros was really the ideal solution for that. Even with TI, our big advantage was the general purpose DSP over the dedicated hardware solutions. In fact, if it's only playback that you want, then there were (and are) cheaper solutions.
But again, as a consumer product (this one being focused on bringing internetTV to the TV), I look at the internet video space and I compare a $299 product that genuinely "plays everything" and it's vastly more attractive than a $199 that plays "most things." Suddenly, you realize that the "most things" just cut you off from netlfix, hulu, nbc.com, the bbc's iplayer etc (and a ton more) and that $99 cost savings seems pretty unattractive.
***********************************
JB:> Look at this very conversation. I can deliver you an x86
> box that does what you need today,
can do 1080p vc1/wmv. What I saw so far were all embedded.
JB: I haven't tested 1080p WMV, although I would guess it will work. $200 we can't do yet and again per the above, if that's all you want, then I'm sure we don't have an advantage for you. I personally have my doubts that kind of dedicated product will be successful in the market with so much content is excluded, so we aren't really targeting this segment.
***********************************
JB:> I want to deliver you a box that you can build your app
> on. I want you to deploy it to users everywhere, I want
> you to get feedback, tweak it and have a great success.
JB: Let's see, we haven't, by any means given up on it.
************************************
JB:> Then when its more mature and you know
> your base and the market and the exact application,
It's media extender (with OSD having unique recording
feature) used by individual and commercial users.
You just need to figure out what stops it from being a
winner over all those NMTs, Sage TVs, etc. And I
believe it's lack of codecs.
JB: Again, I don't feel it's known at all. Hulu is 9 months old or something, content is coming on in a variety of new forms every day. Communities are forming around this every day. Content providers are putting new content online everyday, and all kinds of new interactivity is springing up every day. The "future of TV" is not going to be just better, faster, cheaper, it will zig and zag in unexpected ways. Being able to provide those new experiences to users in a seamless TV experience is what will allow us to be a winner over the above.
see http://www.youtube.com/watch?v=qEnlEEel-8A
***************************************
JB: > then let's talk about cost reduction and
> moving it to embedded (TI Sigma designs or whatever)
JB: Again, I don't see it. When it takes the closed embedded guys months or years to add YouTube, I see us having a big advantage over all the closed solutions. Don't get me wrong, it's no guarantee that we'll win with this open, flexible strategy, but I think it's by far the most unique and attractive approach for us to take to this market.
*****************************************
JB> That, honestly, is the very very painful lesson I have learned
> over that last 7 years. I guess I'm not that smart that it's taken
> that long :)
and has lots of potential.
JB: we're not killing it, and I still have high hopes, I think 720p recording is a killer feature that is very attractive, An open, HD DVR will be a great product, and no one is more eager than me to use it.
Pat Gunn
neuros customers
are either people who have an intent to repurpose the devices (as
noted previously)
or are Linux enthusiasts. Offering devices closer to standard PC
hardware is not
particularly interesting to either - if we wanted devices like that,
we could put them
together ourselves. The actual cpu/isa/etc isn't so interesting as the
functional characteristics
of the device though - there are embedded x86 systems (like gumstix)
that are still
interesting from our perspective, but right about when one reaches or
surpasses the size
of the mac mini, when systems start to make noise and heat, when they
begin to be expensive
and delicate, when we can build them ourselves, those are the lines
where they cease to be
so interesting. I'm not sure what the new device is actually like, but
from the specs it looks
like it's well on the wrong side of that line.
I'm also concerned about the company having too many products,
especially given its size.
Having two sitting multimedia players that are different enough is a
bad idea, I think - resources
will be split between them and I don't really think that's good for
either. I'd far rather see Neuros
have one line of sitting media players and another line of portable
ones - my interest with Neuros
started a long time ago when they were the only company making a
decent portable player that
does OGG vorbis, and I'd love to see a really great portable player
that does everything it did and more -
there were intermediate devices I skipped out on, but where's the
442v2?
This entire issue is entirely orthoganal to whether going with TI was
a mistake or sticking with them was
a mistake. It's possible to change that (even if it's embarassing and
expensive) without slowly transitioning
everyone over to a small PC with a custom system image.
On Nov 6, 11:32 am, "Joe Born" <jb...@neurostechnology.com> wrote:
> Neuros has been internally experimenting with a new device (focused on
> internet television playback) and we've got a handful of them available for
> developers. Given that some of the recent discussions here have started to
> touch on some of the concepts (such as x86 and off the shelf components),
> You can find information here. Again, there are a handful of discounted
> units and I can send out pictures, screen shots etc to anyone interested (I
> didn't post here since we only have a handful of units and we're trying to
> avoid blog coverage). If you are a linux admin, hacker and watch TV, then
> we've love to have your participation.
>
Joe Born
I'm not sure how interesting this is for most of us - I imagine most
neuros customers
are either people who have an intent to repurpose the devices (as
noted previously)
or are Linux enthusiasts. Offering devices closer to standard PC
hardware is not
particularly interesting to either - if we wanted devices like that,
we could put them
together ourselves.
The irony is that in your conversation today on #neuros, you alluded to the fact that you have, in fact, put together a unit similar to what we're proposing (a PC connected to the TV). Now, on one hand you could say this makes your point, but I think that's looking at it a bit upside down.
Viewed on the highest of levels, If you could have thousands of friends putting the same device together along with you, hammering out the details/annoyances, from software to noise and cooling, yielding economies of scale on purchasing, and with the ability to assign certain folks to specific tasks, allocate some resources to the server side and making the operation seamless, that would seem to me a much better way to go than everyone duplicating effort, IMHO. Then there's the issue of how to allocate the profits, but that's really secondary, if the above proposition makes sense (as I think it does) then you can expect there's a way to divy up the benefits)
I've gotten a number of requests for the first devices, so I know theres at least some initial demand (BTW, if you want additional pictures, information, send me an email jborn at neurostechnology com) I'd post stuff but again, we have very few units at this point and I very much trying to avoid winding up on the blogs for the time being.
Pat Gunn
> fact that you have, in fact, put together a unit similar to what we're
> proposing (a PC connected to the TV). Now, on one hand you could say this
> makes your point, but I think that's looking at it a bit upside down.
>
> Viewed on the highest of levels, If you could have thousands of friends
> putting the same device together along with you, hammering out
though. Geeks like me enjoy putting together a box we're going to use
(we don't think of it as work) and hacking on it. What we need/want
most urgently from you and other geek-friendly companies with the
right expertise is accomplishments in hardware (plus, for many of us,
included software/firmware that works well enough to inspire us to
play with the device).
I don't know if there are enough people like this to make it a market
worth targeting, especially if you can't target other markets at the
same time - the development costs are likely intense, and you're
competing with companies that have a powerful economy of scale backing
them in a market where convergence is beginning to radically reshape
things and drive the likely consumer-acceptable price point very low.
I can't say that directly doing what I want would fit into a sound
business plan, but what would make me (and maybe others who think like
me) would be to focus on making fewer products, keeping them open (and
supporting codecs important to us - an area where by the way I have
always been very pleased with Neuros), and focusing as much as
possible on hardware a reasonably skilled geek could not put together
themselves.
Joe Born
. Geeks like me enjoy putting together a box we're going to use
(we don't think of it as work) and hacking on it. What we need/want
most urgently from you and other geek-friendly companies with the
right expertise is accomplishments in hardware (plus, for many of us,
included software/firmware that works well enough to inspire us to
play with the device).
If you enjoy the learning and experience of picking out parts and putting together a PC, figuring out compatibility, etc then probably at least some of what we're doing is redundant with that. That being said, I think there's enough hardware work to be done that we can contribute *plenty* there: right cooling/ low noise, right controller, case, etc.
Overall, I guess you could shorthand our new strategy as "the final 5%" ie. taking a 95% complete base and making it great, rather than a 70% complete base (an embedded reference design) and bringing that to 90%. I have been amazed over the course of my career at the companies that have had big success by taking seemingly very small parts of a product's development and really nailing them. The good news is that I think TI is coming much closer to the 95% level with their embrace of open source, but it's not there yet.
Burobjorn
representation of my internal brainstorm ;) than a clear neatly outlined
vision or opinion. Still I hope this might be interesting to others and
I'm curious about what you guys think of it.
I'm very happy to see Neuros willing to experiment with off-the-shelve
components. I think that by innovating on the user-experience and
getting the last 10% 'right' Neuros might have a much bigger chance on
delivering the best possible experience while maintaining its openess.
Think Apple (in user-experience & design) but open and hacker-friendly.
I disagree with Pavel on the embedded part. Personally I think that the
embedded market is very interesting from a technical viewpoint, yet
requires to much in developing the basics before the interesting parts
(at least for the end-users) can be given enough attention. Therefor it
might not be the best start for smaller companies with limited resources
such as Neuros Technology.
Instead if Neuros Technology would focus its energy in combining the
existing free/open-source software towards a system that will provide
end-users with the best possible user-experience while maintaining its
open and hackable identity it is in my humble opinion adding an unique
value to free and open-source software.
You could argue that this is the same as what Canonical has been doing
with Ubuntu and what made Ubuntu a very popular Linux distribution in a
short time.
In my again humble opinion its not so much about the hardware. If I
would generalize/exaggerate I would say that anyone can handle that
part. Its about the added value on top of the hardware: possible usage,
experience, extensibility etc.
Again Apple is a good example. Take the iPod. It came late to the market
(there were plenty more players) yet it took over the market due to its
design, user-experience and seamless (monopoly) integration. Off course
the hardware is an important factor as well, but I haven't heard about
someone who bought the iPod for its interesting hardware.
I'm not quite sure about the target group(s) for the Neuros devices.
Although in my arguments above I keep the average end-user in mind.
Somebody who likes a product that works and does what it promises from
the start. I belief that this is something all user archetypes would
like to have.
Anyway, if you look at these four archetypes, one question is quite hard
to answer: why would anyone chose a Neuros device instead of one from
its competitors? I'll try to answer this question for the three types
I've defined.
1) User-type: End-user
Wants:
An easy to use device for all their media usage. Enjoys new features,
but does not like to experiment and gets quickly annoyed/irritated if
the device does not work as it (in perception or reality) should be.
Why Neuros:
Value of usage increases instead of diminishes compared to competitors.
The device offers all what it promises and offers even more after sale
at least if the user updates its device. Due to openess third-parties
(developers but also other companies) can add extra value to the device.
Think durability and extensibility.
2) User-type: Power-user / Prosumer
Wants:
An easy to use device for all their media usage. Enjoys new features and
likes to enhance or change their device according to their abilities.
They might develop a new skin for a menu or create a physical mod of the
device so it fits better with their living room. Is a bit more forgiving
yet they still get quickly annoyed/irritated if the device does not work
as it (in perception or reality) should be.
Why Neuros:
Value of usage increases instead of diminishes compared to competitors.
The device offers all what it promises and offers even more after sale
at least if the user updates its device. Due to openess they can change
or add value to the device itself. Their work might end up on somebody
elses Neuros device ('ego-driven'?).
3) User-type: Developers (companies/hobbyists etc)
Wants:
An easy to use device for all their (or their clients) media usage which
is also open and extensible. Might be interested in developing
applications either to 'scratch their own itch' or for commercial
purposes. Has experience in developing desktop or webapplications. Has
no experience in embedded development(!). Is quite forgiving yet they
still get quickly annoyed/irritated if the device does not work as it
(in perception or reality) should. Needs clear documentation and
guidelines in how to quickly develop applications for the Neuros device.
Why Neuros:
Due to openess they can change or add value to the device itself. Their
work might end up on somebody elses Neuros device. Might be interested
in commercial purposes as well. Easier to develop for than embedded
systems(!?). Imagine an Android Market, Wii channels or the iPhone store
for third-party Neuros developers
4) User-type Hackers
Wants:
An easy to use device for all their (or their clients) media usage which
is also open and extensible. Is more interested in being able to
transform the hardware into anything they can think of than just using
the default to build upon (is that the difference between developer and
hacker?). Is very forgiving if the device does not work as it (in
perception or reality) should. Perceives this as an interesting
challenge and aims to fix it.. Lack of documtation is acceptable as long
as the sources and specs will be available.
Why Neuros:
Due to openess they can change or add value to the device itself. They
have searched and found Neuros to be the best solution for their problem.
Curious about any remarks, comments and so on this huge braindump.
Thanks for reading this far :)
All the best,
grtz
BjornW
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Concordiastraat 68-126
3551 EM Utrecht
The Netherlands
phone: +31 6 49 74 78 70
http://www.burobjorn.nl
> <http://nbc.com>, the bbc's iplayer etc (and a ton more) and that $99
luka
On Nov 6, 10:09 am, Pat Gunn <pgun...@gmail.com> wrote:
<skip>
> an intent to repurpose the devices (as noted previously)
> or are Linux enthusiasts.
OSDs for. They'd know if they reached intended markets and
what their sizes are.
I hope you're wrong assuming there're no end-users. W/o
commercial sales this is the only group that could help
Neuros recover expensive embedded development investments.
> Offering devices closer to standard PC hardware is not
> particularly interesting to either
who'd rather spend their time on software side than figuring out
magic set of hardware components (cpu, gpu, psu) that'll work for
them.
> I'm also concerned about the company having too many products,
> especially given its size.
are very expensive to develop. One should start it only having in
mind massive sales. Massive sales means end-users and
commercial buyers.
Now, Neuros has developed embedded device - OSD1. Unfortunately,
by the time it reached product state it fall behind mass buyers
expectations - no HD video that competitors have. In attempt to catch
up and at the same time capitalize on already made investments into
TI hardware Neuros comes up with OSD2. Good move! All they have
to do now is to work around the clock to move it from EDK state to
product state ASAP. Instead they diverted resources to new product
which IMHO targets limited hobbyists market.
luka
> keeping them open
yes
> (and supporting codecs important to us
> focusing as much as possible on hardware a reasonably
> skilled geek could not put together themselves.
luka
> I've gotten a number of requests for the first devices, so I know theres at
> least some initial demand (BTW, if you want additional pictures,
you'll loose OSD market (which I believe suppose to be much bigger
end-user market) and all those embedded investments will be wasted.
Joe Born
My concern is re-focusing to small hobbyists market with WUMP
you'll loose OSD market (which I believe suppose to be much bigger
end-user market) and all those embedded investments will be wasted.
We're certainly not focusing or refocusing on small hobbyists at all. The point of the W.U.M.P. project is that it can leverage all the mainstream content that's already out there nbc.com the bbc, hulu, etc. That I think is a unique product and one that goes where the interest is (for the mainstream) where the content is.
Fernando Cassia
As long as it helps maintain the boat afloat I'm all for it.
But please DO learn from the lessons of Prismiq Inc. Before they went under, they thought they could raise cash by diverting its efforts into "more profitable products" like wireless routers.
So they diverted attention to a new cash-cow, its bet failed, and they went under.
My humble advice would be: regardless of what you do, don't invest valuable HUMAN RESOURCES (and their time) into the new product. Assign the new product to a DIFFERENT TEAM so that the current team can FOCUS at FULL SPEED into bringing the OSDv2 to end-user product status.
Just my $0.02
FC
PS: Joe, ever managed to get your ebay-purchased prismiq up and running?. Noticed already what I said about the D-Pad on the Prismiq's remote?
luka
> I'm very happy to see Neuros willing to experiment with off-the-shelve
> components.
full attention to yet reach their target market.
> I disagree with Pavel on the embedded part. Personally I think that the
> embedded market is very interesting from a technical viewpoint, yet
> requires to much in developing the
out what's left to make it sellable and that depends what market they
are after. The fact is Neuros has unfinished product they need to
sell
in big numbers to recover heavy investments it's consumed. Targeting
correct market is crucial.
> basics before the interesting parts
> (at least for the end-users) can be given enough attention.
> Therefor it might not be the best start for smaller companies
> with limited resources such as Neuros Technology.
results.
> In my again humble opinion its not so much about the hardware.
> Anyway, if you look at these four archetypes, one question is quite hard
decision-making process than companies and hobbyists would
fall into separate groups. Where hobbyist will tolerate 50%
higher price to not deal with embedded development for
businesses that would mean loss of competitiveness.
Arguably, there's also not so much difference between
hobbyist, power user and hacker. So in my scheme
there're only three groups: end-user, businesses and
hobbyists. I'd assume they will assess below criterias
as following to decide which device to choose:
1) End-user.
price: very important
functionality: very important
reliability: very important
ease-of-use: very important
upgradability: important
openess: non-important
quiteness: important
size (CE form-factor): very important
2) Business.
price: very important
functionality: very important
reliability: very important
ease-of-use: important
upgradability: very important
openess: important
quiteness: important
size: very important
3) Hobbyists.
price: important
functionality: important
reliability: important
ease-of-use: not important
upgradability: very important
openess: very important
quiteness: ?
size: non-important
If above to be correct groups 1 and 2 will likely
pick OSD2 (provided it's completed and has
important codecs) and not WUMP. Group 3
might prefer WUMP. Speaking Neuros vs.others
group 1 will likely base their decision on
price/functionality, group 2 same plus openess,
group 3 on openess.
Finally, what above means if Neuros wants sales
they need to focuse on OSD2 functionality
(codecs, apps, api) and not WUMP.
P.S. Don't get me wrong, WUMP is interesting device.
I'm even planning to buy one myself, but will wait until
OSD2 supports wmv9 to buy that one in volume for
my company.
P.P.S. Burobjorn, my post is longer :-)
Martin Springer
> [...] Finally, what above means if Neuros wants sales they need to
> focuse on OSD2 functionality (codecs, apps, api) and not WUMP.
I second this.
--
Best regards,
Martin Springer
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
luka
It certainly has value to people who wants ultimate
openness. So please buy! By all means.
I just don't want Neuros to slowdown OSD2
that I believe is better fit for me personally.
Joe Born
PS: Joe, ever managed to get your ebay-purchased prismiq up and running?. Noticed already what I said about the D-Pad on the Prismiq's remote?
not yet, it's sitting on the shelf by my desk. It's on my to-do list though.
Burobjorn
>> basics before the interesting parts
>> (at least for the end-users) can be given enough attention.
>
> Could you please elaborate what are those interesting parts?
>
The interesting parts for an end-user will be the interaction and
integration possibilities. To give you an idea, I wrote down some
features that I would consider non basic yet end-users might be very
interested in it. Off course this would be guessing at the moment.
- The ability to scrobble (do they still call it this?) your audio usage
to last.fm This has only recently been added if I'm correctly.
- The option to view and down-/upload your own images to Flickr.com or
any other image storing facility.
- The option for an Electronic Programming Guide (EPG) which gathers
metadata to make recording a breeze, but also makes it easy to find
recorded programms afterwards.
- The option to quickly find more info about a media file either be it
audio or video. For instance I would like to find the IMDB score for the
movie I'm going to watch.
- The ability to easily download media files using something like
bittorrent. I know some might find this being questionable, but there's
plenty of free legal stuff available to make this a valid AND legally
sound option. The sharing of the material would also be possible, but
that might open a can of copyright worms although it might be a very
interesting feature from a social/communication perspective.
There's plenty more ideas that I can come up with. Imagine what ten or
possible hundreds of people can come up with. Personally I think that
the main objectives for Neuros Technology should be:
1) Creating an easy to use device that offers the basics promised and
partially delivered in the OSD1 and sell it for a reasonable price.
2) Make developing / hacking the device as easy and attractive as
possible. Adding surplus value and perhaps even create a 'second-market'
interesting for third-parties.
Now that I think of it. Neuros Technology could use something like the
bounties in combination with something like Dell's[1] or Ubuntu's[2]
Ideastorm in order to decided which non-basic features get implemented.
It could even be setup in such a way that users can offer small bounties
as well. So that very popular request could in theory be funded by the
community. Doing this might also strengthen the community between
developers and end-users and even create a 'second-market' for the
Neuros OSD.
All the best,
grtz
BjornW
[1] http://www.ideastorm.com/apex/ideaList?lsi=0
[2] http://brainstorm.ubuntu.com/
luka
> integration possibilities.
more difficult to do on OSD than on x86.
Cheers.
Burobjorn
Actually it is more difficult on an OSD than on x86, otherwise we would
already have these options. Instead the basics have only just gotten far
enough to make the OSD deliver its promises. I also have the feeling
(very subjective) that the interest / amount of developers doing
interesting stuff with the Neuros seems to be less than its potential.
Imagine having a more 'mainstream' system built upon commodity hardware.
The pool of potential developers is substantially bigger than using a
less mainstream system and more specialized hardware.
IMHO there are two options:
Neuros Technology needs to offer everything on their own with regards to
the basics to build upon, which has and will take significant resources
and the risks that it will be obsolete before it can be used.
Or they will use commodity hardware which has already the basics done
(lets say 80% is already there) and Neuros Technology invests in the
last 20% procent (which according to a common saying will take 80% of
the time ;)) to make it great.
Either way, it's up to Neuros Technology and I hope they will make the
right decision. I applaud their interest in experimenting with commodity
hardware and I'm very interested in using / developing for it.
All the best.
grtz
BjornW
luka
On Nov 12, 10:55 am, Burobjorn <burobj...@gmail.com> wrote:
> Imagine having a more 'mainstream' system built upon commodity hardware.
Joe Born
This statement gets right to the heart of the matter. In my experience, it's just not true. I'm not a developer and I'm not able to explain exactly why, but it's clear from observing, that the results tell the story. Look at the two gsoc projects we featured, just as examples, and there are tons more:
last.fm http://open.neurostechnology.com/content/lastfm-social-music-revolution-comes-neuros-osd
webkits http://open.neurostechnology.com/content/web-your-tv-why-it-makes-sense
These guys worked hard on these projects, but still basically spent the entire summer getting them working, which left them little or no time to do the really interesting stuff. That meant that their apps didn't reach the tipping point of users being able to really enjoy them and build momentum around them, and so they haven't got anywhere near the attention they deserved. They got some coverage on the blogs and such, but given all the "small impediments" they just didn't take off and I'm fairly confident it wasn't the concept that was the problem.
In one of the last meetings with TI, they asked just what are the missing software parts that they need to deliver in order to be more competitive in allowing experimentation. It's a response that now has been on my to-do list for months, but I haven't really been able to answer, but its pretty clear to me that it's there and it's real. A host of "small things" that add up to making all the difference in the world.
Thoughts?
Matthew Wild
>
>
> On Wed, Nov 12, 2008 at 11:03 AM, luka <ptkat...@shaw.ca> wrote:
>>
>> > The interesting parts for an end-user will be the interaction and
>> > integration possibilities.
>>
>> All you've listed doesn't involve kernel or DSP so won't be much
>> more difficult to do on OSD than on x86.
>
> This statement gets right to the heart of the matter. In my experience,
> it's just not true. I'm not a developer and I'm not able to explain exactly
> why, but it's clear from observing, that the results tell the story. Look
> at the two gsoc projects we featured, just as examples, and there are tons
> more:
>
> last.fm
> http://open.neurostechnology.com/content/lastfm-social-music-revolution-comes-neuros-osd
>
> webkits
> http://open.neurostechnology.com/content/web-your-tv-why-it-makes-sense
>
It's because, for one reason or another, the software on the OSD is
not easy to simply "hack". It has always attracted the more low-level
developers, with time on their hands. Over the time I've been around,
it has changed a lot. These GSoC projects would not have even been
possible last year :)
> In one of the last meetings with TI, they asked just what are the missing
> software parts that they need to deliver in order to be more competitive in
> allowing experimentation. It's a response that now has been on my to-do
> list for months, but I haven't really been able to answer, but its pretty
> clear to me that it's there and it's real. A host of "small things" that
> add up to making all the difference in the world.
>
The small things are the unified, open API - available in the
developer's personal language of choice (be it Lua, Python, or C/C++).
I've said this many times. Open-source is of no direct value to
end-users - none whatsoever - unless developers are hacking it. Most
open-source projects have a strong developer community, the OSD never
had this, because quite frankly the APIs didn't exist, and hence the
barrier to entry was just too high for the majority of people.
http://xbmc.org/wiki/?title=HOW-TO_build_Python_Scripts#Play_A_File
Playing an audio file in 2 lines of code. *That's* a successful
open-source project. The easier it is to write the code (that is, the
more help we give them), the more time developers can spend on being
innovative, creative, and productive.
We must not of course forget the documentation. But that's for another day.
Note that it is still my personal mission to achieve these things on
the OSD (1 or 2), and any other device I can lay my hands on.
> Thoughts?
>
:)
Matthew.
Gerry Boland
In one of the last meetings with TI, they asked just what are the missing software parts that they need to deliver in order to be more competitive in allowing experimentation. It's a response that now has been on my to-do list for months, but I haven't really been able to answer, but its pretty clear to me that it's there and it's real. A host of "small things" that add up to making all the difference in the world.
I'd like to try and give a point or two regarding this.
The ARM side of the dual-core arm-dsp chip is completely within our control - we can compile almost anything that runs on x86 for the ARM. However on the DM320, it runs at 203Mhz, which is slow in today's world. That increases to about 300Mhz for the OSD2.
For both these architectures, the ARM is responsible for generating the GUI, a task usually given to a dedicated chip which specialises in this task on a PC. The ARM isn't great at this job, and this task saps processor cycles that could be doing the other things the primary CPU does.
As an example, the OSD1 is stretched to its limit when playing an audio file with xmms2 while displaying the audio player GUI. The ARM needs to take the audio file, convert the contents to PCM format on the fly and pass it to the DSP (which does sod all), and update the GUI every second. That's a lot of work for a wee 203Mhz CPU.
I believe a solution to part of this would be a DirectFB interface running on the DSP. I believe this already exists on the OSD2, but it is sadly closed source. But this would offset the GUI generation to the DSP, which is far superior at this task.
However one side-affect I believe Crweb or Nero mentioned was that there then can be no on-screen GUI while the DSP is playing/recording video. This is a problem that should be looked at if possible. Either DirectFB is able to transparently run on the ARM while the DSP is busy, or parallelise the tasks somehow (the DSP does have 2 video layers).
The OSD1 & 2 are dedicated media devices. Trying to run something trendy like Compiz on them is daft. But a web browser isn't so daft, and while ravenexus did manage to run Webkit on the OSD1, it is dog slow, because 203Mhz isn't enough. Nor do I expect that 300Mhz will make it much nicer - even with the DDR RAM - there is still a speed issue. Offsetting the GUI generation to the DSP may improve this situation though.
What we all really want is experimentation with media. The decision to go with VLC on the OSD2 was a good one IMHO, it makes playing a wider choice of media more possible, especially those from the internet, however is does still rely on the ARM to transcode on the fly that which the DSP does not possess a codec for - something I don't think it can do fast enough for certain video formats. A more open DSP access would be nice, and while DaVinci is going that way, it appears that one still cannot write a new codec without going under NDA.
But with a machine that can play almost anything reliably, then wrapper apps can easily be made to play online streams. If it cannot play the codec, no such wrapper will ever be made. These wrapper apps are not processor heavy, current ARM processors will easily manage them. I think once the OSD2 get's the reputation of Play-it-All, then this work will appear.
-G
luka
> Look at the two gsoc projects we featured, just as examples, and there
wrong,
OSD and WUMP target very different audiences. OSD is multimedia
device with some openess, WUMP is open with some multimedianess.
I'd be curious to know (unless it's confidential) your sales ratio
(end
users+businesses/hackers) expectations at the start of OSD project,
actual today, and future ideal (OSD+WUMP). 1:10, reverse?
> " they just didn't take off and I'm fairly confident it
> wasn't the concept that was the problem.
> In one of the last meetings with TI, they asked just what are the missing
> software parts that they need to deliver in order to be more competitive in
get it,
if they want more their chips sales they better absorb codecs cost and
not
put it on your shoulders.
Vladimir Pantelic
> I'd like to try and give a point or two regarding this.
...
> As an example, the OSD1 is stretched to its limit when playing an audio
> file with xmms2 while displaying the audio player GUI. The ARM needs to
> take the audio file, convert the contents to PCM format on the fly and
> pass it to the DSP (which does sod all), and update the GUI every
> second. That's a lot of work for a wee 203Mhz CPU.
There is a couple of PMP products out there that have used the DM320 as their CPU and had no problems to play audio and
display a decent UI at the same time, so I do not buy this argument. Maybe 200Mhz is not enough to run a fancy
visualization, but updating the play time display every 1s is not so much of a burden. Ask the rockbox guys about what
they do/did with a 12Mhz SH-1.
But you still might have a point, because what the OSD1 does is to try to achieve the same but going through several
(more) layers like fancy UI toolkits, Window managers etc and this might be too much indeed.
> However one side-affect I believe Crweb or Nero mentioned was that there
> then can be no on-screen GUI while the DSP is playing/recording video.
Again, there exist products that did that on this very CPU.
> The OSD1 & 2 are dedicated media devices. Trying to run something trendy
> like Compiz on them is daft. But a web browser isn't so daft, and while
> ravenexus did manage to run Webkit on the OSD1, it is dog slow, because
> 203Mhz isn't enough. Nor do I expect that 300Mhz will make it much nicer
> - even with the DDR RAM - there is still a speed issue. Offsetting the
> GUI generation to the DSP may improve this situation though.
The issue with web browsing is that it has literally "exploded" over the last two years in terms of CPU performance
needed. HTML used to be a more or less static description on how to *render* a web page, now it is just the pipe to
transport the actual SW (javascript) that *runs* the web page in your browser. So yes, a 200-300Mhz ARM9 is not enough
for this task.
> What we all really want is experimentation with media. The decision to
> go with VLC on the OSD2 was a good one IMHO, it makes playing a wider
> choice of media more possible, especially those from the internet,
> however is does still rely on the ARM to transcode on the fly that which
> the DSP does not possess a codec for - something I don't think it can do
> fast enough for certain video formats. A more open DSP access would be
> nice, and while DaVinci is going that way, it appears that one still
> cannot write a new codec without going under NDA.
There is not much that you can transcode on the ARM, things like SPARK to MPEG4 are easy because they are more or less
the same codec with slight changes, but anything else is more like a decode/reencode, so no way.
> But with a machine that can play almost anything reliably, then wrapper
> apps can easily be made to play online streams. If it cannot play the
> codec, no such wrapper will ever be made. These wrapper apps are not
> processor heavy, current ARM processors will easily manage them. I think
> once the OSD2 get's the reputation of Play-it-All, then this work will
> appear.
The Davinci can play all these formats in SD:
MPEG2
MPEG4
DIVX3.11
WMV9/VC1
H264
RealVideo 9/10
On2 VP6
Some people claim that is does some HD as well, but the actual products show that this is not true, the playback cannot
keep up when the bitrate is too high or certain codec features are used.
So, you could end up with an SD play-it-all.
Ugo Riboni
> audio and display a decent UI at the same time, so I do not buy this argument. Maybe 200Mhz is not enough to
> run a fancy visualization, but updating the play time display every 1s is not so much of a burden. Ask the rockbox
> guys about what they do/did with a 12Mhz SH-1.
>
> But you still might have a point, because what the OSD1 does is to try to achieve the same but going through
> several (more) layers like fancy UI toolkits, Window managers etc and this might be too much indeed.
I agree there, the idea was that of having to choose a tradeoff
between complexity and CPU usage versus maintanability and ease of
development (also for 3rd parties).
We went with QT since we believed the trade off would be good enough
but of course I don't deny that we might have been wrong there, and
we're paying some price in areas where CPU is scarce.
However consider this: QT brought a host of good things that wouldn't
have been possible before, or being harder. The mediafly project
wouldn't have existed, the web browser, probably lastfm too, it's all
stuff that would've required a lot more time and effort if we remained
with nano-x and probably chased away the hackers.
Also it allowed us internally to have more manageable code with less
hacks (leaving aside the fact that sometimes the team ended up
mis-using QT in ways that can be much optimized) and MUCH easier to
fix, change and extend when needed.
In the end i believe QT is good for making the UI of the device for
most of its operation (again, granted that it can be optimized some
more), like settings, file browser, menus, etc.
However when doing recording (and possibly also playback) we may
benefit from something simpler (both for display and also for the
actual recording code itself).
There was some discussion on shutting down all of QT before recording
and displaying a very simplified recording GUI directly on the FB, or
using some extremely lightweight GUI toolkit in that case, or going
back to nanox (given we have now lots of space on the CF card to keep
more libs), to see if things were much better, but we didn't have the
chance to experiment much in that department yet.
Another option may also be to bypass the neuros media server (which
may introduce some latency, epecially when responding to commands) and
have the player app go directly to the ingenient framework, but again
not much was done on that too. I think Michael Gshwandtner will do
some research in that direction while working on some of the fuse
stream stuff soon enough.
Anyway, the CPU is capable of doing the stuff we need i believe,
Vladimir is right, but of course it all comes at the cost of more
complicated code or harder to maintain code, and possibly uglier (or
not seamless) appearance of the GUI (which i personally don't give a
damn about but the end-user does, unfortunately)
--
nero
Daniel Stenberg
> As an example, the OSD1 is stretched to its limit when playing an audio file
> with xmms2 while displaying the audio player GUI.
Out of curiousity: are all the codecs xmms2 is using fixed-point or does this
also suffer due to floating-point emulation?
--
Gerry Boland
I agree there, the idea was that of having to choose a tradeoff
between complexity and CPU usage versus maintanability and ease of
development (also for 3rd parties).
We went with QT since we believed the trade off would be good enough
but of course I don't deny that we might have been wrong there, and
we're paying some price in areas where CPU is scarce.
Yes, that's my main point. One can write a custom library from the ground up to perform well on the embedded CPU, but it is time-consuming and really hard work. This is evident when you compare how long it took Neuros to make the NanoX based UI, versus the UI using Qt.
If TI want experimentation, there needs to be a flexible and mature software foundation upon which people can hack. One which performs well on their architecture. The old NanoX-based libraries were hard to work on, there were no docs nor guides, whereas Qt is far easier to knock apps up in, with loads of info on the net. But Qt has a price, it is a bit heavy on 203Mhz. Too heavy IMO.
I'll be honest, I want pretty things. I want a UI with subtle animations and proper transparency. I'm very curious to see how the work of Rasterman's EFL will run on the OSD, whether these things can be done at all, and whether I'm being too harsh on Qt. Only experimentation will tell.
-G
Ugo Riboni
> proper transparency. I'm very curious to see how the work of Rasterman's EFL
> will run on the OSD, whether these things can be done at all, and whether
> I'm being too harsh on Qt. Only experimentation will tell.
When i tried it, it was ok, but didn't have exceptional performance.
Raster also said that from his experiments way back on the OSD,
without being able to tap into the DSP, there was no chance of having
anything with any serious eye candy (like you describe above,
animations, transparency, etc etc).
So I wouldn't expect too much there, from ARM alone, on OSD1.
There were also some problems with handling the hardware-based binary
transparency due to some dithering that the EFL libs were doing when
converting to rgb565, but i hear that has been fixed by now.
In any case, I would very much like to see what you can get out of it :)
Please do keep us updated,
--
nero
Ugo Riboni
>> with xmms2 while displaying the audio player GUI.
>
> Out of curiousity: are all the codecs xmms2 is using fixed-point or does this
> also suffer due to floating-point emulation?
The ones we use are all fixed point, as far as i know.
--
nero
Vladimir Pantelic
>
>
> 2008/11/13 Ugo Riboni <neroc...@gmail.com <mailto:neroc...@gmail.com>>
>
>
> I agree there, the idea was that of having to choose a tradeoff
> between complexity and CPU usage versus maintanability and ease of
> development (also for 3rd parties).
> We went with QT since we believed the trade off would be good enough
> but of course I don't deny that we might have been wrong there, and
> we're paying some price in areas where CPU is scarce.
>
>
> Yes, that's my main point. One can write a custom library from the
> ground up to perform well on the embedded CPU, but it is time-consuming
> and really hard work. This is evident when you compare how long it took
> Neuros to make the NanoX based UI, versus the UI using Qt.
>
> If TI want experimentation, there needs to be a flexible and mature
> software foundation upon which people can hack. One which performs well
> on their architecture. The old NanoX-based libraries were hard to work
> on, there were no docs nor guides, whereas Qt is far easier to knock
> apps up in, with loads of info on the net. But Qt has a price, it is a
> bit heavy on 203Mhz. Too heavy IMO.
As for TI, they were not really concerned about providing a sound platform for experimentation with the DM320, the Linux
offering on this was not really where their mainstream interest was. This chip is/was mainly for digital cameras running
some closed OS. The fact that Neuros used it for the OSD1 would not make TI support it heavily.
The real change comes with the OMAP3 (which is one generation after the Davinci), with a *really* powerful ARM and the
the same DSP as Davinci it makes a truly impressive embedded platform and TI is really supporting it on the open source
side. See the $150 beagleboard and the large following it managed to gather in a really short time.
(http://beagleboard.org/)
So, maybe Neuros could/should replace the Davinci CPU module inside the OSD2 with an OMAP3 based one :-)
luka
On Nov 13, 1:17 am, Vladimir Pantelic <p...@nt.tu-darmstadt.de> wrote:
> The Davinci can play all these formats in SD:
>
> MPEG2
> MPEG4
> DIVX3.11
> WMV9/VC1
that can play wmv9 at sd?
Thanks.
Vladimir Pantelic
Archos gen4 and gen5 devices
Joe Born
So, maybe Neuros could/should replace the Davinci CPU module inside the OSD2 with an OMAP3 based one :-)
Unfortunately, while it's true it has the same DSP, it runs 25% slower and doesn't have all the accelerators, so it hardly seems like the ideal choice for a video focused device.
Milan Svoboda
>It's because, for one reason or another, the software on the OSD is
> This statement gets right to the heart of the matter. In my experience,
> it's just not true. I'm not a developer and I'm not able to explain exactly
> why, but it's clear from observing, that the results tell the story. Look
> at the two gsoc projects we featured, just as examples, and there are tons
> more:
>
> last.fm
> http://open.neurostechnology.com/content/lastfm-social-music-revolution-comes-neuros-osd
>
> webkits
> http://open.neurostechnology.com/content/web-your-tv-why-it-makes-sense
>
not easy to simply "hack". It has always attracted the more low-level
developers, with time on their hands. Over the time I've been around,
it has changed a lot. These GSoC projects would not have even been
possible last year :)
I'm working on Mediafly application which may be similar to lastfm one and I have
to say that I like Qt and didn't find anything exceptionally difficult yet... At least not
with the Qt library itself.