Wireless support is finally working on the OSD

[ron]

As some of you know already I have been working on wireless support via
the USB Host port for quite some time now. And a few days ago I finally
managed to get it working!! Many thanks goto zongchiqiu for all his
support and of course all the others who helped me realizing this
(Thomas for his support on the packed structs!).

I've written an extensive tutorial which hopefully enables other people
to setup wireless support:

http://wiki.neurostechnology.com/index.php/Recorder_III:setting-up-wireless-support

All comments on the tutorial or problems with it can be posted here.

[Joe Born]

This is incredible Ron, thanks so much for documenting everything?

First, if you don't mind, I'll move the page to OSD:setting... just so
it'll be less confusing.

All, what are the next steps here? Get USB Host figured out with the
new kernel?

Is this hardware special should we try to source some of these dongles
or should we assume this will work with other chipsets?

I really think this wireless functionality is pretty crucial for a lot
of the stuff that regular users will want to do with this, I'd love to
move this project forward.

Thoughts?

[Dragon Wisard]

I belive wireless drivers can be touch to the chipset and sometimes the version of the chipset they were written for. You can find them on the internet, but it's hard to just walk into a store and find one on the shelf (at least in the northern DC area). There are only a few that work and usually only particular versions. I've gotten bitten by that because I bought a Netgear dongle from a CompUSA and when I opened the box I found it was an incompatible version. :(
 

[ron]

>
> First, if you don't mind, I'll move the page to OSD:setting... just so
> it'll be less confusing.
>

sure go ahead :)

> All, what are the next steps here? Get USB Host figured out with the
> new kernel?

What I heard is that the manufacturer is working on the USB Host driver
at this moment. So it probably won't take long before that's fixes and
we can just use the normal kernel for wireless support.

>
> Is this hardware special should we try to source some of these dongles
> or should we assume this will work with other chipsets?
>

Dragon Wisard is right. You should be very careful with buying a
wireless dongle. The dongle I used howver can be bought almost in any
shop and as far as I know there is only one version of it available at
this time. Before buying any other dongle you should first search the
internet for an open source driver so you can port it and compile it
for ARM.

> I really think this wireless functionality is pretty crucial for a lot
> of the stuff that regular users will want to do with this, I'd love to
> move this project forward.
>
> Thoughts?

It would be really neat to just add the chipset to the board itself :-)

[Joe Born]

> What I heard is that the manufacturer is working on the USB Host driver
> at this moment. So it probably won't take long before that's fixes and
> we can just use the normal kernel for wireless support.
>

Yes, that's the basic idea.

> Dragon Wisard is right. You should be very careful with buying a
> wireless dongle. The dongle I used howver can be bought almost in any
> shop and as far as I know there is only one version of it available at
> this time. Before buying any other dongle you should first search the
> internet for an open source driver so you can port it and compile it
> for ARM.
>

I was asking more as the manufacturer. I'm a neuros employee. So my
question was more should we, Neuros, buy a few of these dongles, or,
assuming we can find others that work, buy different ones. I guess my
question was really directed at how hard it would be to find others that
work (and get them working). I think we should sell dongles that end
users (with no hacking) can just plug in and expect to work.

> It would be really neat to just add the chipset to the board itself :-)

well, of course we could do that, but it'd require everyone to buy it,
regardless of if they wanted it or not. I guess it would add $10-15 to
our cost, which are obviously somehow going to get passed along.

[Michael Gao]

> > All, what are the next steps here? Get USB Host figured out with the
> > new kernel?
>
> What I heard is that the manufacturer is working on the USB Host driver
> at this moment. So it probably won't take long before that's fixes and
> we can just use the normal kernel for wireless support.
>

A newer version 2.6.15 USB host driver is under test now, will update on
this soon.

[patacongo]

> Dragon Wisard is right. You should be very careful with buying a
> wireless dongle. The dongle I used howver can be bought almost in any
> shop and as far as I know there is only one version of it available at
> this time. Before buying any other dongle you should first search the
> internet for an open source driver so you can port it and compile it
> for ARM.

And the situation is worse because many of the major wireless
manufacturer's use proprietary wireless chips. In this case, there is
no open source driver available for Linux.

However, there is one trick that has worked form me: NdisWrapper --
http://ndiswrapper.sourceforge.net/ . This is a utility and a kernel
module. It accepts a WinXP driver and "wraps" it to create a Linux
driver. It is pretty scary stuff, but it works. I have never tried
NdisWrapper with a USB network device but there is a list of support
for USB wireless here:
http://ndiswrapper.sourceforge.net/mediawiki/index.php/List .

I use NdisWrapper to port the LinkSys wpc54g (PCMCIA) which is based on
a proprietary Broadcom chipset so only the WinXP is available (in
binary format). However, using only NdisWrapper and the WinXP drivers
on the CD that came with the wpc54g (and Google), I got it running on
my laptop. I'm using it now.

If you Google, there are are lots of tips for getting "unsupported"
wireless sets to work.

Hmmm.. I wonder if there are any legal issues about linking proprietary
driver binaries into GPL code?

Greg

[Daniel Stenberg]

On Mon, 11 Sep 2006, patacongo wrote:

> However, there is one trick that has worked form me: NdisWrapper --
> http://ndiswrapper.sourceforge.net/ . This is a utility and a kernel module.
> It accepts a WinXP driver and "wraps" it to create a Linux driver. It is
> pretty scary stuff, but it works.

The Neuros are not x86 so it'd be fun to hear how you get this to work on an
ARM! ;-)

> Hmmm.. I wonder if there are any legal issues about linking proprietary
> driver binaries into GPL code?

Yes, there are.

[Kaspar Rothenfußer]

If you offered some of these wireless dongles, it would be quite cool if
it was possible to buy a "sesigned for OSD" dongle at your webshop.
This would facilitate the choice and could be designed in
OSD-style.(i.e. just put a diferent housing around it).
Kaspar

[Kaspar Rothenfußer]

patacongo schrieb:

I think Ndiswrapper will just work on x86.
Kaspar

[patacongo]

You are right! It is early in the morning here and I'm not think
clearly because I haven't had my coffee yet.

Greg

[ron]

If you are planning to buy such dongles I think the Asus dongle, or
from another brand based on the same Ralink chipset, is a good idea.
The dongles are available at low prices and there is an active
community working at it:
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page

The asus dongle however comes with a lot of useless stuff (printed
manual, cd with drivers, a keycord, a usb connecten/extension cable and
a usb universal joint). Only the last item is useful for the neuros
because it enables you to point the dongle upwards. So maybe you could
close a deal with asus to deliver these dongles OEM with the unversal
joint?

[ron]

I also looked into the ndiswrapper. But I think indeed that problems
arise because the .dll is still x86, but I'm still not 100% about this.
I don't know what the ndiswrapper does to load the dll driver.
Furthermore the ndiswrapper isn't intended as a stable driver for
wireless support... it wouldn't be a good idea to advice neuros buyers
to use the ndiswrapper... (assumed it would work)

[Joe Born]

At this point, I'd just like be a able to get a few and offer them on
our website. Let's see how they do...

[Joe Born]

We're thinking of offering some Bounties for some hacks, third party
projects, whatever. We've tried this once or twice before with
reasonable success and we certainly learned some things.

#1 It's a lot easier to get folks to get a basic "hack" working than it
is to get them to create a finished program.

#2 Multiple people will work on the same projects and reach completion
at about the same time.

#3 choosing a winner will be very subjective.

anyway with all that said, there are definitely some things we could use
done that would at least lay out a framework for others to finish,
particularly the China team. Things like doing the basic research about
how things work (and should work) and proof of concept can be very
valuable for a) showing how things can be done and b) sparking other
folks interest and c) getting some early user experimentation.

As many of you know, our initial Beta launch in 8 days will be almost
exclusively focused on hackers, and as an additional incentive to buy,
we'd like to have some bounties listed by that time.

Here are some thoughts that I had, and I'd love to get any of yours

1) youtube or google video "browser." Srobertson has a proposal for
this, now we just need someone to cobble it together
http://wiki.neurostechnology.com/index.php/Online_video_browser_proposal

Bounty: $1000

Standard: has to work. It may not be perfect, but it has to "work" at
least in the hands of some one other than the hacker.

2) browser for flikr: assume much of the setup and interactivity is
done on the PC, but should be able to view recent photos from your
friends and your own photos. This is pretty much entirely a UI project.

Bounty: $600

Standard: has to be reasonably usable. Enough that a patient person
could figure out how to use it and then it'd be useful at parties, etc.

3) music player hack: This is essentially another UI project to get the
OSD to play music using a WiFi PDA as the remote. A lot of the basic
pieces are there, per sitwon's recent blog, but the UI needs to be
tweaked. This would be the foundation for us putting out a wifi, non
touchscreen remote.

Bounty: $500

Standard: has to be reasonably usable, and should not require a stylus.
I don't know what's already enabled, but it shouldn't be a complete
gimme. Depending on what's already there, it would be nice if it'd
allow the creation of playlists, etc.

4) TiVo for radio: hook up the OSD to a FM/AM or Satellite receiver,
and do timed recordings, or FF/RW and Pause Live Radio. I understand
the OSD can handily do simultaneous encode and decode. One other added
benefit of this is that it could insert a delay into the radio that
would allow sports fans to listen to the radio while watching the video
from the TV. For those of you who are not sports fans, take my word
this is an issue.

Bounty: $700

Standard: has to be reasonably usable.

Thoughts? Comments? Other bounty ideas? Remember you all are eligible
to get these two, so feel free to throw in your favorite project.

[Derek Pedersen]

I like your ideas, but 'reasonably usable' is quite subjective.  I would just be careful with this when offering money.  Someone who thinks they have met the requirements might get really mad when you tell them he does not get the money.  Just make sure you clearly state that 'reasonably usable' is at the sole discretion of the Neuros Technology and NT will be the judge of completion.

--
http://www.shareasale.com/r.cfm?B=41776&U=175298&M=8602

[Nathan True]

How about a Shoutcast / Live365 internet radio station browser /
timeshifter?

[Joe Born]

On Tue, 2006-09-12 at 07:54 -0700, Nathan True wrote:
> How about a Shoutcast / Live365 internet radio station browser /
> timeshifter?

How hard is that do you think? Have you looked into the alsa thing or
followed Adam (May1937's work)?

[Nathan True]

Shoutcast and Live365 stations are just streaming MP3 audio.  If the framework can do streaming from an Internet source then listening to Internet radio should be trivial.

[Nathan True]

Oh, and a hack for timeshifting would just be having the framework connect to a local port, where an application is running between the framework and the Internet server, caching the MP3 data as it comes in and doling it out as necessary.

[Joe Born]

On Tue, 2006-09-12 at 10:07 -0700, Nathan True wrote:
> Oh, and a hack for timeshifting would just be having the framework
> connect to a local port, where an application is running between the
> framework and the Internet server, caching the MP3 data as it comes in
> and doling it out as necessary.
>
> Nathan True wrote:
> > Shoutcast and Live365 stations are just streaming MP3 audio. If the
> > framework can do streaming from an Internet source then listening to
> > Internet radio should be trivial.

No idea if the framework can do streaming, Gao or one of the folks can
answer.

Regarding time shifting, there was a program that captured the MP3s and
broke them into different files and even populated the ID3 tags, I
think I found out about it from the Neuros forums in fact. I'm not sure
if it was open source or legal to be honest. Anyone know anything about
it, is it still around?

I vaguely remember there was some lawsuit regarding streambox and Real
networks. IIRC correctly, streambox was shut down because the "broke
the protection scheme" of the stream. It was just a bit or something,
but per the DMCA, that was adequate. Would it be necessary to do
something similiar with Shoutcast.

On the other hand, I believe total recorder, etc type programs are still
around because they just "intercept" audio streams before they hit the
DAC. I guess this is more of what you had in mind? But then we'd miss
the ID3 tag stuff?

[Nathan True]

Joe Born wrote:

On Tue, 2006-09-12 at 10:07 -0700, Nathan True wrote:
  

Oh, and a hack for timeshifting would just be having the framework
connect to a local port, where an application is running between the
framework and the Internet server, caching the MP3 data as it comes in
and doling it out as necessary.

Nathan True wrote: 
    

Shoutcast and Live365 stations are just streaming MP3 audio.  If the
framework can do streaming from an Internet source then listening to
Internet radio should be trivial.
      

No idea if the framework can do streaming, Gao or one of the folks can
answer.  
  

Failing native support, a fake file could be used (a named pipe) which would read data from another app, which has supposedly connected to the server and already buffered the MP3 data.

Regarding time shifting, there was a program that captured the MP3s and
broke them into different files and even populated the ID3 tags,  I
think I found out about it from the Neuros forums in fact.  I'm not sure
if it was open source or legal to be honest.  Anyone know anything about
it, is it still around?
  

I've seen programs of that nature.  In the basics, they are very simple.  Shoutcast stations give the appearance of an HTTP download of an MP3 file.  If you use wget to grab a shoutcast stream, and rename it to MP3, it will play just like a real MP3.  Song information is embedded therein using special MPEG packet types or something.

I vaguely remember there was some lawsuit regarding streambox and Real
networks.  IIRC correctly, streambox was shut down because the "broke
the protection scheme" of the stream.  It was just a bit or something,
but per the DMCA, that was adequate.  Would it be necessary to do
something similiar with Shoutcast.  

  

MPEG frames have bits for "original" and "copyrighted" streams.  Neither of them (to my knowledge) indicate a restriction on what an application can do with them.  For our purposes, I would recommend not saving the MP3 data for any longer than it takes to be played out of the speakers.  As far as we're concerned, the radio station will always be there - so why save its content when we can just reconnect and get it again?

Also, (some) Live365 stations do not transmit song data.

On the other hand, I believe total recorder, etc type programs are still
around because they just "intercept" audio streams before they hit the
DAC.  I guess this is more of what you had in mind? But then we'd miss
the ID3 tag stuff?

  

Nothing I've suggested deals with audio after it's decoded.  I was just talking about manipulating MP3 streams.

[ron]

Sounds interesting... I'll think about this, but I agree with Derek
that 'reasonably usable' should be specified clearly.

What about running Skype on the neuros?

[Josh Malone]

I've not seem Skype for Linux-ARM, only Linux-x86 and WinCE-ARM.

-Josh

--

Joshua Malone www.ubergeeks.com/~jmalone
Power Users Use The Power To Serve www.freebsd.org

[ron]

There is an dynamic binary for Skype available. It needs QT to run, but
I'm not sure if it's possible to get QT compiled & running on the OSD..

I was however thinking of an alternative, open source, implementation
of the skype protocol. There is enough information available about the
protocl itself
(http://www.rootsecure.net/content/downloads/pdf/skype_protocol.pdf) so
I expect there is probably somewhere out there an open source
implementation of it available. This code can be changed so it
collaborates with the audio in/output channels of the OSD and maybe
becomes part of the OSDmain application.

[Josh Malone]

On 9/12/06, ron <ron.g...@gmail.com> wrote:
>

> There is an dynamic binary for Skype available. It needs QT to run, but
> I'm not sure if it's possible to get QT compiled & running on the OSD..

For linux-arm? Please link

[ron]

something like this?
http://www.trolltech.com/products/qt/qt3/platforms/embedded

On second thought I think it would be better to use something else then
skype for voip on the OSD. Skype protocol is still closed source and
this can cause a lot of problems. I don't think there is anything open
source for it available at this moment...

[Joe Born]

It's a great idea and I think the approach above is the right one. I've
also not seen a linux ARM implementation and further I'd note that the
WinCE ARM implementation, does not really work. It's not a bandwidth
issue, but I assume horsepower (and I'm using a 624MHz Xscale), I'm
guessing that a more careful implementation (ideally using the DSP)
would do the job.

It would certainly be a cool project.

[Josh Malone]

On 9/12/06, ron <ron.g...@gmail.com> wrote:
>

> something like this?
> http://www.trolltech.com/products/qt/qt3/platforms/embedded

That's just info for Qt-embedded, not Skype.

[ron]

Josh Malone schreef:

> On 9/12/06, ron <ron.g...@gmail.com> wrote:
> >
> > something like this?
> > http://www.trolltech.com/products/qt/qt3/platforms/embedded
>
> That's just info for Qt-embedded, not Skype.
>

This is the download page for skype on linux:
http://www.skype.com/intl/nl/download/skype/linux/

This is the dynamic QT binary:
http://www.skype.com/go/getskype-linux-dynamic

[Kaspar Rothenfußer]

As an example for an app like this that grabs mp3-streams, you could try
out the OS-Software streamripper.
http://streamripper.sourceforge.net/
Integrates well with winamp, is (IANAL) perfectly legal for what I know,
but misses the timeshifting feature. 'Though I don't think that would be
too hard to implement...
Kaspar

[Kaspar Rothenfußer]

Forget about Skype and rather go with an XMPP/Google Talk implementation
as this is a truely open, well documented approach.
Skype is working pretty well but still a proprietary, hardly documented
protocol which comes with no linux ARM code and is only suited for
powerful desktop linux systems at the moment.
Kaspar

[jb...@neuros.us]

Sorry to be dense, but doesn't stream ripper create mp3 files on your local machine from streaming MP3s?  Isn't that time shifting?

[Dragon Wisard]

On 9/13/06, jb...@neuros.us <jb...@neuros.us> wrote:

Sorry to be dense, but doesn't stream ripper create mp3 files on your local machine from streaming MP3s?  Isn't that time shifting?

Timeshifting requires the simultaneous encoding to an mp3 on your local machine and the decoding of that mp3 asyncronously. stream ripping is just half (probably the harder half) of Time Shifting.

-----Original Message-----
From: Kaspar Rothenfußer
Sent: Wed, September 13, 2006 12:47 pm
To: Neuros-DM3...@googlegroups.com
Subject: Re: Bounties: Will "Cash Money" Taint our Beautiful Relationship?


As an example for an app like this that grabs mp3-streams, you could try
out the OS-Software streamripper.
http://streamripper.sourceforge.net/
Integrates well with winamp, is (IANAL) perfectly legal for what I know,
but misses the timeshifting feature. 'Though I don't think that would be
too hard to implement...

Kaspar

--
http://www.dragonwisard.net/

[Kaspar Rothenfußer]

Dragon Wisard schrieb:
>
> On 9/13/06, *jb...@neuros.us <mailto:jb...@neuros.us>*

> <jb...@neuros.us <mailto:jb...@neuros.us>> wrote:
>
> Sorry to be dense, but doesn't stream ripper create mp3 files on
> your local machine from streaming MP3s? Isn't that time shifting?
>
>
> Timeshifting requires the simultaneous encoding to an mp3 on your
> local machine and the decoding of that mp3 asyncronously. stream
> ripping is just half (probably the harder half) of Time Shifting.

Just what I wanted to say.
Streamripper seams to be quite portable, it seems to be already
possible to use the commandline version in Linux for ARM (debian).
Perhaps it could be extended by a playback component to do true time
shifting. Timed recordings are already possible.
Kaspar

[Joe Born]

Is XMPP/Google Talk consensus or are there others? I'm in agreement
that Skype seems like a hack since it's not really their strategy to
embrace 3rd party clients.

[Kaspar Rothenfußer]

Joe Born schrieb:

There's the well documented SIP Protocol as well, but it still has
Problems with firewalls and does not have this Instant-Messenger like
system.
There are a lot of companies offering SIP to Phone Gateways for a small
fee though.
Kaspar

[Joe Born]

> There's the well documented SIP Protocol as well, but it still has
> Problems with firewalls and does not have this Instant-Messenger like
> system.
> There are a lot of companies offering SIP to Phone Gateways for a small
> fee though.
> Kaspar

I guess the question is should we restrict the bounty to XMPP? In my
experience, the IM systems basically "just work" and if that's the case
with XMPP, I'm inclined to go with that for starters. Is that true?

On a related not, what about an IRC client on the OSD. Basically I'm
thinking of a read only thing. The reason I think of this is that it
could be cool advertising for the #neuros channel in a very geeky place,
like http://barcampchicago.com/index.php?wiki=ChicagoCoWorking

I'm thinking you'd have a TV hooked up with an OSD and just let the IRC
scroll. Thoughts?

[Kaspar Rothenfußer]

>
> I guess the question is should we restrict the bounty to XMPP? In my
> experience, the IM systems basically "just work" and if that's the case
> with XMPP, I'm inclined to go with that for starters. Is that true?
>
>

I think you should not do that but restrict it to a non corporate open
standard protocol. BTW, I think Jabber/XMPP is a good choice and has
proven to be stable and easy to use (I use it everyday).

> On a related not, what about an IRC client on the OSD. Basically I'm
> thinking of a read only thing. The reason I think of this is that it
> could be cool advertising for the #neuros channel in a very geeky place,
> like http://barcampchicago.com/index.php?wiki=ChicagoCoWorking
>
> I'm thinking you'd have a TV hooked up with an OSD and just let the IRC
> scroll. Thoughts?
>

Great idea, but I would not connect that. You need a fully functional
keyboard to use IRC(and/or text based instant-messaging).
Kaspar

[Thad Ward]

On Wed, Sep 13, 2006 at 01:50:43PM -0400, Dragon Wisard wrote:
> On 9/13/06, jb...@neuros.us <jb...@neuros.us> wrote:
> >
> > Sorry to be dense, but doesn't stream ripper create mp3 files on your
> > local machine from streaming MP3s? Isn't that time shifting?
> >
>
> Timeshifting requires the simultaneous encoding to an mp3 on your local
> machine and the decoding of that mp3 asyncronously. stream ripping is just
> half (probably the harder half) of Time Shifting.

I don't see why decoding and re-encoding a stream is required for
timeshifting. Satellite and Digital Cable capable DVRs (that is, combo
decoder box and DVR units) time shift by simply dumping the stream they
receive, with no decoding or encoding, until the user plays the
recording. (It may do the decryption, though).

Additionally, stream ripping an mp3 stream is hardly difficult, as long
as you are talking about just dumping th stream without attempting to
automatically split on song boundaries and such. All you have to do is
talk to the server pretty much as if it were an HTTP server and dump the
non-header data the server sends you to a file on the disk.

[Dragon Wisard]

On 9/13/06, Thad Ward <code...@grnet.com> wrote:

On Wed, Sep 13, 2006 at 01:50:43PM -0400, Dragon Wisard wrote:
> On 9/13/06, jb...@neuros.us <jb...@neuros.us> wrote:
> >
> > Sorry to be dense, but doesn't stream ripper create mp3 files on your
> > local machine from streaming MP3s?  Isn't that time shifting?
> >
>
> Timeshifting requires the simultaneous encoding to an mp3 on your local
> machine and the decoding of that mp3 asyncronously. stream ripping is just
> half (probably the harder half) of Time Shifting.

I don't see why decoding and re-encoding a stream is required for
timeshifting. Satellite and Digital Cable capable DVRs (that is, combo
decoder box and DVR units) time shift by simply dumping the stream they
receive, with no decoding or encoding, until the user plays the
recording. (It may do the decryption, though).

Timeshifting is the "pause live TV" functionality. It requires the data that is recieved 'live' to be cached and the player to read from the cache. This caching allows you to view from and to an point in the stream that the device has thus far observed. The caching or recording continues when you hit pause, but the playing stops. This means that you can go directly from the source to the output, instead you create a file (in the case of an mp3 steam it may just be dumping with no re-encoding) and then reading from that file (which will require decoding since it is a compressed format).

Additionally, stream ripping an mp3 stream is hardly difficult, as long
as you are talking about just dumping th stream without attempting to
automatically split on song boundaries and such. All you have to do is
talk to the server pretty much as if it were an HTTP server and dump the
non-header data the server sends you to a file on the disk.

That may be how mp3 streams work. I haven't looked at them in detail. Still, that's only have the job, you still need to decode and play them.

>
> -----Original Message-----
> > From: Kaspar Rothenfußer
> > Sent: Wed, September 13, 2006 12:47 pm
> > To: Neuros-DM3...@googlegroups.com
> > Subject: Re: Bounties: Will "Cash Money" Taint our Beautiful Relationship?
> >
> >
> > As an example for an app like this that grabs mp3-streams, you could try
> > out the OS-Software streamripper.
> > http://streamripper.sourceforge.net/
> > Integrates well with winamp, is (IANAL) perfectly legal for what I know,
> > but misses the timeshifting feature. 'Though I don't think that would be
> > too hard to implement...
> > Kaspar
> >
> >
> > >
> >
>
>
> --
> http://www.dragonwisard.net/
>
>
>

--
http://www.dragonwisard.net/

[Thad Ward]

On Wed, Sep 13, 2006 at 06:24:22PM -0400, Dragon Wisard wrote:
> On 9/13/06, Thad Ward <code...@grnet.com> wrote:
> >
> > I don't see why decoding and re-encoding a stream is required for
> > timeshifting. Satellite and Digital Cable capable DVRs (that is, combo
> > decoder box and DVR units) time shift by simply dumping the stream they
> > receive, with no decoding or encoding, until the user plays the
> > recording. (It may do the decryption, though).
>
>
> Timeshifting is the "pause live TV" functionality. It requires the data that
> is recieved 'live' to be cached and the player to read from the cache. This
> caching allows you to view from and to an point in the stream that the
> device has thus far observed. The caching or recording continues when you
> hit pause, but the playing stops. This means that you can go directly from
> the source to the output, instead you create a file (in the case of an mp3
> steam it may just be dumping with no re-encoding) and then reading from that
> file (which will require decoding since it is a compressed format).

The term "Timeshifting" goes all the way back to the Sony v. Universal
("betamax") case of 1979, when there certainly were no DVRs. It refers
to recording some linear media stream (analog TV also is essentially a
stream) to some storage medium (disk, tape, whatever) to be viewed at a
more convenient time for the owner of the shifting device.

[Dragon Wisard]

In that case, "my bad!"
I interpreted the phrase to mean that Joe wanted "pause live TV" functionality. In any case, you still need to decode that stream. And assuming the source is anything other than an already encoded stream it will have to be encoded to be saved on the device.

[Joe Born]

>
> In that case, "my bad!"
> I interpreted the phrase to mean that Joe wanted "pause live TV"
> functionality. In any case, you still need to decode that stream. And
> assuming the source is anything other than an already encoded stream
> it will have to be encoded to be saved on the device.
>

Well originally I was talking about pausing live radio (PVR or Tivo is
what we've been calling it even though it's not video). Then Nate
suggested applying it to shoutcast, etc. Which I think makes sense too.
I got confused simply about the terminology since I though VCRs
qualified as "time shifting" as well.

[Joe Born]

On Tue, 2006-09-12 at 07:54 -0700, Nathan True wrote:
> How about a Shoutcast / Live365 internet radio station browser /
> timeshifter?

Nate, if you want to create a description for this one, I'll post it.

[Steven Robertson]

How about:

1. Setting up a better build environment

or

2. Creating a package manager for the OSD (as in, something that can
add an app to the OSD without having to re-burn the firmware)?

[Joe Born]

Ok, with me. Someone needs to write up something simple as a
description. For reference, here's what I have for some of the others

2) browser for flickr: Assume much of the setup and interactivity is

done on the PC, but should be able to view recent photos from your

friends and your own photos, with automatic login, etc. Basically the
project is not to show a jpeg on the OSD, that already works, the
project is to show how browsing flickr with a remote can be a good
experience. This is pretty much entirely a UI project.

Bounty: $600

Standard: has to be usable. Given that most folks already have a PC
nearby, it hasn't be easy and automatic enough to be useful enough that
the big screen is not overwhelmed by the cumbersome nature of using it.

3) Digital Music Receiver: This is essentially another UI project to
get the OSD to play music using a WiFi PDA (or PSP) as the remote. A
lot of the basic pieces are there, per sitwon's recent blog, but the UI
needs to be tweaked, and it's not working yet. This would be the
foundation for us putting out a wifi, non touchscreen remote.

Bounty: $500

Standard: has to be usable, and should not require a stylus. If no one
coplete's it without a stylus, we'll consider entries with a stylus.

4) TiVo for radio: hook up the OSD to a FM/AM or Satellite receiver,

and do timed recordings, or FF/RW and Pause Live Radio. In addition,
timed recordings could be easily copied to a card or portable (listen to
pre-recorded radio on an iPod for example)

The OSD can handily do simultaneous encode and decode of audio on the
ARM9 core, so the horsepower is there.

One other added benefit of this is that it could insert a delay into the
radio that would allow sports fans to listen to the radio while watching
the video from the TV. For those of you who are not sports fans, take
my word, this is an issue.