Anyone ever give any thought to turning a RioCar into a Rio Receiver? I've got a spare 10gig RioCar, but I'd like it to pull all it's music from the network (permanent installation in home) like the RioReciever ... Has much thought ever gone into something like this?

Greg

To do so, you'd need to implement your own player software on the Rio Car. In fact, getting a working MP3 player with a working UI running locally on the carplayer is just the first step towards implementing a rio receiver client.

Some people over on the Rio Receiver BBS have already implemented working player clients on that platform. Perhaps it's as simple as porting one of those to the car player?

I've been wondering when someone would get around to making a replacement player binary on the carplayer. If it were open source, we could start throwing in features we've always wanted. Plug-in visuals, anyone? V2-tag-related features? Cross fading? Ogg/FLAC playback? Who's up for it?

What do we have to know in order to start on this? How much do we already know?

Interface/functions for DAC?
Interface/functions for EQ/DSP?
Interface to face buttons?
Interface to display?

Everything else is software related, directly, right? There is no decoding board luckily.

Greg

Oh, and also, if we want to remain compatible with the existing software, we'd need to use their file system and know how to get into their music database.

Greg

What do we have to know in order to start on this? How much do we already know?

We (the collective "we") already know everything we need to know to write our own player app for the car player. All of the hardware I/O is well known.

As far as the file system is concerned, we also know pretty well how the FIDs are stored. We might have to build our own database mechanism and our own method of synchronization (perhaps we'd choose to use Hijack's FTP daemon instead of the emplode protocol, or perhaps we'd try to make it emplode-compatible, who knows?), but it's do-able.

Then again, if the idea is to really make our own player app, perhaps we could just forget the existing file system and write our own. Maybe just store the MP3s raw along with M3U files and have our player app read them directly. Of course, the empeg guys deliberately did it differently than that because they wanted a low-overhead database instead of a read-everything-in-real-time file system, but for a start, it might be easier to try it as straight files.

see this post

You're pointing out that their player-app code isn't open source? Yes, I'm aware of that.

But that doesn't stop us from writing our own player-app from scratch. Everything we need to know in order to do this is available. It's just that no one has done it yet.

I'm implying he was implying the player software was way too timely/difficult to write by mere mortals. That whole thread was interesting.

Are you saying you want to stream the music from the empeg or use the empeg to stream from something else ?

I'm implying he was implying the player software was way too timely/difficult to write by mere mortals. That whole thread was interesting.

Oh, I know that writing our own player app would be difficult. Their player app is really great, and a lot of time and effort went into creating it. I don't expect that anything we write would come close to it in terms of usability and features. At least not right away. It would take a lot of open-source "stone soup" development before it got really good.

However, there are a lot of people who are asking for certain features in the player that simply can't be done without rewriting the player app. And with the player hardware being EOL, it's safe to assume that any new features are going to come along slowly, if at all, from the empeg guys.

So just because writing our own player app would be hard, and just because it wouldn't be as good as the original player app, doesn't mean it's not a worthy undertaking. I think now would be a great time for a project like this to get underway.

Are you saying you want to stream the music from the empeg or use the empeg to stream from something else ?

I believe he is staing he wants to use the empeg as if it were a Rio Receiver, having it play streamed audio coming from another computer (or a Rio Central) over the network.

The other side of the coin, having the empeg be a server for Rio Receivers, is a totally different issue. There's even a FAQ entry on it.

What would be best to iron out first?

1. Get a very simple UI up just to play mp3s, build from there.
2. Design a complex UI and build from the top down.
3. Build a good back-end to support what we hope to put in at later dates ... UI to follow.
4. Try and reverse engineer the current software, get the pants sued off of us and spend the rest of our days penniless or in prison.

I've typically done something like either 2 or 3 in other projects ...

Greg

That's the age-old development question, isn't it?

As far as number 4 goes, we don't need to reverse-engineer anything. All of the relevant information is out there in the open for us.

I wonder if we should go over some limitations first ... Is the empeg's resources too limited for a C++ player application and runtime? I know when we were first writing compilers for the Palm Pilot, we never even bothered working on a C++ compiler ... our libraries were just too big to run on the platform. I wonder if we should take extra care in this regard with the empeg?

Do we want to leave out the Mk. I owners? I know there are hardware differences but to what extent that will affect us when writing the new player, I have no idea.

Greg

I am reasonably sure that C++ is used to a great extent when developing the player application. There is some ARM assembler in the visuals I think, and possibly in the audio decoder engine, but for the most part, you're looking at an application written in C and C++.

Whether or not the Mk1 owners get left behind is a good question. Having ethernet on the Mk2 certainly simplifies things for a lot of the coding related to transferring files to the player, because you could just use FTP for that. If you want to implement USB for the Mk1 owners, then you're probably talking about a system whereby the user-written player has to work with emplode over USB. As I said, this is probably do-able, it's just more work.

The Mk1 owners also might benefit from the project discussed here, something I'd still like to see happen.

Apart from the kernel almost the entire player is written in C++ (are there other languages for serious software development then?)

Rob

Anyone ever give any thought to turning a RioCar into a Rio Receiver? I've got a spare 10gig RioCar, but I'd like it to pull all it's music from the network (permanent installation in home) like the RioReciever ... Has much thought ever gone into something like this?

You could do this with enough kernel hackery. Build and flash a NFS-root kernel and suborn the mount syscall to mount NFS volumes for /drive0 and /drive1 partitions too. I'm now slightly kicking myself for not buying a stack of £140 car-players and turning them into receivers: same price, quite considerably better screen.

Alternatively, get together with the guy who's rewritten the Rio Receiver client from scratch, plus the guy who's written the framebuffer layer for the car-player. Retargetting, or even rewriting, the Rio Receiver client is a lot simpler than implementing the whole car player with all its caching, mute and battery sense, etc.

Peter

You could do this with enough kernel hackery.

On thinking about it a bit more, you'll still have problems with the player software's use of swap while synchronising.

You'll either have to disable that (you might get away with it; only fsck actually needs it and you'll have to stub out fsck anyway), or suborn swapon to use network block device swap instead. But ISTR network block device swap doesn't really work.

That's if you want to remove the winchester completely, of course. If you don't mind having winchester noise when synchronising, you could always leave it in just for the swap partition, and suborn swapon() to spin up the drive and swapoff() to spin it down again.

Peter (word of the day is: "suborn")

Forth!

pca

...not quite. We still don't have access to the algorithm for calculating the eq coefficients.

I personally wish that Rob/SB would create an NDA suitable for allowing some of the coder types here access to the source so that we could modify the original player.

Personally, I'm looking forward to a return to Fortran programming in the .net framework...

Bryan.

In reply to:

---

Plug-in visuals, anyone? V2-tag-related features? Cross fading? Ogg/FLAC playback? Who's up for it?

---

What os Ogg/FLAC? Also, you imply that v2(multiple?) tag related features have a slim chance of ever being included in the player. That would be a worthwhile endeavor IYAM. If someone was to take the lead, I would be willing to assist.

Cory

Ogg and flac are two alternate methods for audio compression, other than MP3 or WMA. We are actually hoping for Ogg to make it into a future release of the official player software, but we do not have an ETA.

Peter brings up a good point ... and expanding on that ... People have already done a player for the Rio Receiver. Surely this would be a quick jump start for us. I know of two RioReciever player apps ... Grrr and RioPlay ... I don't know much about either one, since I don't have a RioReceiver to try them out on. Neither has much documentation by my standards.

This would at the very least get a framework up with streaming mp3's. This is, of course, assuming that we wouldn't want to roll our own, simply because the current third-party software is inferior to our vaporware, blah blah blah.

What do you guys think? Start from "scratch" or try and port something that's already working?

Who was it Peter was talking about who wrote the framebuffer layer for the empeg? Can someone go into more detail as to what this does and where to get it?

Greg

People have already done a player for the Rio Receiver. Surely this would be a quick jump start for us.

Right, which is why I said in my first reply to this thread:

Some people over on the Rio Receiver BBS have already implemented working player clients on that platform. Perhaps it's as simple as porting one of those to the car player?

Sure I remember you saying that now, but earlier today I was more forgetful!

Do you have a preference for which is more complete Tony? GRRR or RioPlay?

Talking to the guy doing RioPlay, he seems to think there would be very few changes needed to get it up and running.

Greg

Oh heck. I don't have a preference, I'm just cheerleading here. Trying to get some support stirred up for an open source player app on the car.

As I said, it's not because I'm disappointed with the current player app. I just like the idea of being able to see a request for a feature and being able to point them to the source code and say "write it yourself". :-)

I guess what I'm asking is since you have a RioReceiver, if you would mind trying out those two pieces of software and seeing what looks more complete, or attractive.

Greg

If I get time, I will check them out. I have not done so yet, and I've been wanting to look at them anyway. There are some streaming sites I've been interested in getting to work on the RR, so this will give me an excuse...

Ok, I've gone ahead and started with RioPlay.

I got it *almost* limping along.

1. Display works, no changes needed.
2. Key codes are different so I had to fake them to limp along with the empeg remote.
3. Menu system works though I think it thinks there is more room than there really is for displaying stuff. It seems to go off the bottom of the screen.
4. Once I put in new key codes, the remote works, for better or worse (long story).
5. I downloaded Dell's digital audio receiver software (RioReceiver clone) from some obscure hidden place, no where else could I find the real deal, for windows.
6. RioPlay found the windows (Dell DAR) server and songs ... I could jump to different tracks in the list. It displayed the names (for the most part) of the track on the VFD correctly.
7. Shoutcast attempts merely crash the application ... too late to go into searching for it now.
8. Audio doesn't work yet. But it doesn't complain either. I got MAD compiled and built with no real trouble ... but running "madplay" on a wav file doesn't produce anything but errors like "syncrhonization error, blah blah". When rioplay tries to play a song, it goes through MAD ... I don't see any errors then, but I also don't hear no tunes.

Sleepy.