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:
On Sun, 2006-09-10 at 09:24 -0700, ron wrote: > 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:
> All comments on the tutorial or problems with it can be posted here.
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.
> On Sun, 2006-09-10 at 09:24 -0700, ron wrote: > > 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:
> > All comments on the tutorial or problems with it can be posted here.
> 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?
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. :(
> 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 :-)
> 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.
> > 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.
> 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?
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?
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
>> 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?
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?
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)
On Mon, 2006-09-11 at 04:58 -0700, ron wrote: > 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?
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...
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
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.
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.
On 9/12/06, Joe Born <jb...@neurostechnology.com> wrote:
> 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
> 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.
Joe Born wrote: > 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
> 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.
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.
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.
> Joe Born wrote: >> 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)?
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?
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.
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.
|
