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?

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.

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

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.

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

"The whole magilla" is just a slang term for "the entire thing."

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

Magilla as in Magilla Gorilla?

Or from something else?

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"...

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

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?

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

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.

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

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.

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.

>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..

>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

>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..

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...

.. by "slow" I meant that it might take a few more milli-seconds than it ought to take..

>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

False.

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

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

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.

False.

Okay, elaborate.

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.

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

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

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