Unoffical empeg BBS

Quick Links: Empeg FAQ | Software | RioCar.Org | Hijack | jEmplode | emphatic
Repairs: Repairs | Addons: Eutronix | Cases

Page 1 of 2 1 2 >
Topic Options
#220999 - 14/02/2002 17:44 A Challenge to Mark Lord
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
Okay, this is a pie-in-the-sky idea. But here goes...

It occurs to me that the Hijack kernel for the car player, with its streaming audio web server, is about 75 percent of the way towards being a server for the Rio Receiver already.

All it would need to do is:

1) Respond to commands from the Receiver on the proper port, and format its web-interface output in the way that the Rio Receiver expects to see it. Which is really not that different from how it outputs the queries from web browsers right now.

2) Be able to hand over the .ARF file when the receiver asks for it. Easy, just have the end-user drop it on the car player's hard disk (have them put it in EMPEG/VAR please so that we don't need to reinstall it each time the player is upgraded).

3) Be able to respond to the boot-up broadcast message the receiver sends and then feed the receiver an address. This might be the hard one, as I don't know if there's any lightweight DHCP code that would fit in the kernel. Then again, maybe if you implemented a simplified subset (limit the number of served receivers and put hard-coded addresses for them in the config.ini) then it wouldn't be a big issue?

Mark, have you thought about this before, already?
_________________________
Tony Fabris

Top
#221000 - 14/02/2002 23:33 Re: A Challenge to Mark Lord [Re: tfabris]
andy
carpal tunnel

Registered: 10/06/1999
Posts: 5676
Loc: Wivenhoe, Essex, UK
You realise that step 2 involves putting an NFS server into the kernel aren't you (or running NFS and portmapper outside of the kernel).

Step 3 is actually easy if you just decide not to support DHCP and let the player use a uPNP IP address.
_________________________
Remind me to change my signature to something more interesting someday

Top
#221001 - 15/02/2002 04:04 Re: A Challenge to Mark Lord [Re: tfabris]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4140
Loc: Cambridge, England
the Hijack kernel for the car player, with its streaming audio web server, is about 75 percent of the way towards being a server for the Rio Receiver already

Receivers do two separate network discovery sessions for their software server (which does DHCP and NFS and has the arf file) and their music server (which does HTTP).

As long as you don't want the Receiver to boot only from the car player over a crossover cable -- in other words, as long as you've got a software server on a PC -- being a music-only server is much easier for Hijack. Except that some of the queries (artists menu, etc) will be expensive on a car-player. And I'm not sure whether the consumer Receiver software on the PC makes it easy to disable music serving independently of software serving.

Peter

Top
#221002 - 15/02/2002 10:12 Re: A Challenge to Mark Lord [Re: peter]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
My idea was not to combine the PC server and the hijack server. My idea was to have the car player be the whole magilla.

I didn't realize that the ARF file was sent via NFS. You're right, that would be a big job for the player kernel. And I understand that aritst queries would be expensive. So maybe it's not so easy after all.

Like I said, this was pie-in-the-sky.
_________________________
Tony Fabris

Top
#221003 - 15/02/2002 11:17 Re: A Challenge to Mark Lord [Re: tfabris]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4140
Loc: Cambridge, England
My idea was not to combine the PC server and the hijack server. My idea was to have the car player be the whole magilla. [snip] Like I said, this was pie-in-the-sky.

Sure; I was just pointing out that, while turning Empeg into a music server may be pie-in-the-sky, turning it into a software server too is an entire patisserie.

What's a magilla? Dictionary.com doesn't have it.

Peter

Top
#221004 - 15/02/2002 11:37 Re: A Challenge to Mark Lord [Re: peter]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
"The whole magilla" is just a slang term for "the entire thing."

Sort of like "the whole kit and kaboodle" or similar.
_________________________
Tony Fabris

Top
#221005 - 15/02/2002 14:00 Re: A Challenge to Mark Lord [Re: tfabris]
number6
old hand

Registered: 30/04/2001
Posts: 744
Loc: In The Village or sometimes: A...
Magilla as in Magilla Gorilla?

Or from something else?

Top
#221006 - 15/02/2002 14:26 Re: A Challenge to Mark Lord [Re: number6]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
I had trouble looking up the origins of the phrase. Don't know where it came from. Possibly one for discussion on the OffTopic forum over on the carplayer BBS under "Origins of Mister Happy"...
_________________________
Tony Fabris

Top
#221007 - 17/03/2002 20:06 Re: A Challenge to Mark Lord [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13494
Loc: Canada
I don't have a receiver here (and thus don't visit this BBS often), but perhaps I will find one some day. And then the very first task would be to have my Empeg act as the server for it.

I think a stripped down NFS server would not be difficult to pull together, just enough to send the ARF to the receiver. Ditto for DHCP (if needed).

And then the KHTTPD server would do the rest.

Not a huge job. Just needs hardware.

Cheers

Top
#221008 - 17/03/2002 20:24 Re: A Challenge to Mark Lord [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
And then the KHTTPD server would do the rest

Not completely...

When you finally see the Receiver in action, you'll find that it no longer depends on playlists. Soup views are fully implemented on the Receiver and that's its default mode of operation. So you would have to have the car player respond to artist/album/genre/year queries independently of playlists. As was stated earlier in this thread, that's expensive.

Then again, the Empeg Guys were planning on implementing Soup views in the car player eventually, so it can't be PROHIBITIVELY expensive...

And I can already see that getting artist/album/genre/year queries working in the hijack KHTTPD server would be useful even without a receiver. The current Hijack screen only shows Playlists, it would be nice to see it also give us Soup.

Then, it's just a minor extension beyond that to give us Soup from the Hijack main menu. Then, bingo, you've implemented Soup on the player, one step ahead of the Empeg guys... Ooo, now that would be an achievement, eh?
_________________________
Tony Fabris

Top
#221009 - 18/03/2002 06:40 Re: A Challenge to Mark Lord [Re: tfabris]
rob
carpal tunnel

Registered: 21/05/1999
Posts: 5315
Loc: Cambridge UK
Peter's Receiver Server for the car player would seem to work just fine, except it eats into most of the cache memory and requires the disk to spin continuously. One idea was to enable the server only in home mode.

Rob

Top
#221010 - 18/03/2002 06:56 Re: A Challenge to Mark Lord [Re: rob]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
I hadn't thought about the disk-spinning-continuously thing.

Ideally, it would only spin the disk continuously when a receiver was streaming tunes from it, and it would spin down the disks when the receivers were idle.
_________________________
Tony Fabris

Top
#221011 - 18/03/2002 08:12 Re: A Challenge to Mark Lord [Re: rob]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4140
Loc: Cambridge, England
Peter's Receiver Server for the car player would seem to work just fine, except it eats into most of the cache memory and requires the disk to spin continuously.

It didn't, I'm afraid, do the queries properly; the car player's database doesn't have indexes, so things like the artists menu would be hard to make work and impossible to make efficient. The playlist menu worked, and the all tracks menu worked, but that was about the size of it. Never confuse a semi-rigged demo with a shippable product!

One idea was to enable the server only in home mode.

The Right Thing here is to have a PC program that connects to a car player and then serves its music over the Receiver protocol. Everyone with a car player has a PC, or they wouldn't have been able to get music on in the first place. That way, you could even serve Receivers from a Mk.1.

Peter

Top
#221012 - 18/03/2002 15:51 Re: A Challenge to Mark Lord [Re: peter]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
Now when *I* suggested having a PC run server software to server the empeg to a Reciever, I was told there was no point in my idea...... Oh well, I didn't do a good idea backing myself up.
_________________________
Brad B.

Top
#221013 - 18/03/2002 15:56 Re: A Challenge to Mark Lord [Re: SE_Sport_Driver]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
Now when *I* suggested having a PC run server software to server the empeg to a Reciever, I was told there was no point in my idea.

I still think there would be no point in doing it that way.

The only reason I think it would be neat to see the car player work as a receiver-server is so that it could be a Poor Man's Jupiter, i.e., a server that doesn't require an always-on PC computer.
_________________________
Tony Fabris

Top
#221014 - 18/03/2002 16:45 Re: A Challenge to Mark Lord [Re: peter]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13494
Loc: Canada
>the car player's database doesn't have indexes,
>so things like the artists menu would be hard to
>make work and impossible to make efficient

Well, I can see at least two ways to do this: (1) just scan through the Empeg's "database" file, identifying unique artists (or whatnot) on the fly.. slow, but the database file on my player is only half a megabyte or so in size (5000+ tracks), so not that slow.

Or perhaps just have an add-on program (or even built into the kernel) to quickly generate the extra indexes from the "database" file.. perhaps having it run automatically at the end of any "sync" operation.. Hijack could do this with ease.

Mmmm..


Top
#221015 - 18/03/2002 16:48 Re: A Challenge to Mark Lord [Re: rob]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13494
Loc: Canada
>it eats into most of the cache memory
>and requires the disk to spin continuously.

Mmm.. I suppose it would likely have to buffer on the order of 20 seconds worth of music, to allow time for spin-up. This might amount to say, half a megabyte or so of stolen cache space.. significant, but "okay" on a 16MB Mk2a.

And just spin the disk down when not in use, using an auto-spindown timeout value (Hijack currently uses 30 seconds, or was it 60? -- user settable).

-ml

Top
#221016 - 18/03/2002 16:50 Re: A Challenge to Mark Lord [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13494
Loc: Canada
>I didn't realize that the ARF file was sent via NFS.

Even worse, the ARF file is not actually sent at all. Instead, pieces of the enclosed filesystem are fed on demand to the Receiver. This means Hijack will need a reasonable subset of a read-only NFS server implementation.

But I suspect that once the Receiver's player software is running, the ARF image is probably never accessed again, so a quick and dirty (slow and inefficient) NFS implementation may be very feasible for this.

I've always wanted to write an embedded NFS server..

Top
#221017 - 18/03/2002 17:18 Re: A Challenge to Mark Lord [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
But I suspect that once the Receiver's player software is running, the ARF image is probably never accessed again, so a quick and dirty (slow and inefficient) NFS implementation may be very feasible for this.

True. However, for some people, this would be a relatively frequent ocurrence, as the Receiver must re-grab the software each time it loses electrical power. At my house, that would be in the neighborhood of once or twice per week.

Mind you, this whole idea is really not even for me at all. Since the Jupiter is still safely humming away on my server shelf, I actually have no need for the Receiver-on-the-empeg feature. I was just thinking about what an interesting and challenging project it would be...
_________________________
Tony Fabris

Top
#221018 - 18/03/2002 17:22 Re: A Challenge to Mark Lord [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13494
Loc: Canada
.. by "slow" I meant that it might take a few more milli-seconds than it ought to take..

Top
#221019 - 19/03/2002 04:21 Re: A Challenge to Mark Lord [Re: mlord]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4140
Loc: Cambridge, England
>it eats into most of the cache memory
>and requires the disk to spin continuously.

Mmm.. I suppose it would likely have to buffer on the order of 20 seconds worth of music, to allow time for spin-up. This might amount to say, half a megabyte or so of stolen cache space.. significant, but "okay" on a 16MB Mk2a.


The server doesn't need to cache music for the receivers. But all the extra code in the server cuts down the cache space.

And just spin the disk down when not in use, using an auto-spindown timeout value (Hijack currently uses 30 seconds, or was it 60? -- user settable).

Yes, but the point is that in the steady state a Receiver asks for a new chunk (resetting the timeout) every second and a half. So the disk never spins down unless the Receiver is paused. This shouldn't be a problem, but it's certainly a much heavier duty cycle than running the car-player software alone.

Peter

Top
#221020 - 19/03/2002 04:30 Re: A Challenge to Mark Lord [Re: tfabris]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5524
Loc: London, UK
False.
_________________________
-- roger

Top
#221021 - 19/03/2002 07:04 Re: A Challenge to Mark Lord [Re: peter]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13494
Loc: Canada
Mmm.. a second and a half isn't much of a buffer, so the server likely WILL need to keep several seconds of read-ahead on hand.

The "extra" code likely isn't much in the case of Hijack, perhaps 4-5 pages of RAM.

Cheers

Top
#221022 - 19/03/2002 07:37 Re: A Challenge to Mark Lord [Re: mlord]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4140
Loc: Cambridge, England
Mmm.. a second and a half isn't much of a buffer, so the server likely WILL need to keep several seconds of read-ahead on hand.

There is plenty of read-ahead in the client. A second and a half (32Kbytes of playback) is the rate at which the client asks the server for more data to top up its read-ahead. The only reason you'd want to buffer more than that in the server, is if you thought you could spin the disk down -- but the client doesn't expect you to be doing that sort of thing, and will (for instance) freeze the audio on track skip until you've spun back up. And bear in mind you could have lots of receivers; it's a caching strategy nightmare. Best to just keep the disk up as long as at least one client is currently playing (the UDP protocol does tell you this). That's what the Central does.

Peter

Top
#221023 - 19/03/2002 08:23 Re: A Challenge to Mark Lord [Re: tfabris]
drakino
carpal tunnel

Registered: 08/06/1999
Posts: 7849
Loc: Seattle, WA
I still think there would be no point in doing it that way.

I don't have a single 60gb hard drive anywhere in my house. I have one PC on all the time. So it seems logical to get that PC to grab music off the empeg to then reserve to Rio Recievers instead of trying to load a limited subset of my music on that PC. Plus it eliminates a need for a sync of music.
_________________________
Tom

Top
#221024 - 19/03/2002 08:57 Re: A Challenge to Mark Lord [Re: Roger]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30555
Loc: Seattle, WA
False.

Okay, elaborate.
_________________________
Tony Fabris

Top
#221025 - 19/03/2002 10:30 Re: A Challenge to Mark Lord [Re: tfabris]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5524
Loc: London, UK
There's the chance that it can go back to the NFS server for portions of the code that have been swapped out. I believe that the player is memory locked on the Receiver, but this is probably no guarantee.

More relevantly, a low-performance NFS implementation is going to be a major chore -- a bug in ours caused the bootup time for one Rio Receiver to exceed 10 minutes.
_________________________
-- roger

Top
#221026 - 02/04/2002 08:38 Re: A Challenge to Mark Lord [Re: Roger]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13494
Loc: Canada
Okay, I'll avoid that bug then.

But remember.. this server will be running under Linux, not MS-Win. So even a poor implementation (unlikely from me..) will still have incredible performance, due to the underlying page-cache system.

cheers

Top
#221027 - 26/08/2002 20:24 Re: A Challenge to Mark Lord [Re: mlord]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
RioPlay is working on empegs ... and it doesn't need NFS. If you want to start experimenting with serving audio via another empeg player, this should be enough to get going right?

Greg
_________________________

Top
#221028 - 06/10/2003 09:48 Re: A Challenge to Mark Lord [Re: Roger]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13494
Loc: Canada
Mmm.. I have another approach for this in mind now.

Assuming I can locate the kernel source for the RioReceiver, the need for NFS can be almost 100% replaced by simply replacing it in the Receiver kernel with FTPFS instead. Which is tiny, read-only (for 2.2.x kernels), and will work as-is with the existing Hijack KFTPD server. So, no need for NFS at all on the Empeg, no extra code needed even. The only possible issue would be the initial kernel download by the Receiver's firmware -- I don't want to touch the firmware, so the NFS mount/read of zImage will have to be spoofed by Hijack. Probably not too much code for that one special case.

Cheers

Top
Page 1 of 2 1 2 >