Hi.

A friend of mine, Jon Andrews, whom you may remember from such projects as this, got a bit carried away with the software he wrote for the thing and basically kept going. The end result is pretty much a clone of the empeg player software, admittedly currently missing one or two things but also having several options the original didn't have. He wrote it to run on a Raspberry Pi, driving a display board I did for him with a 256x64 OLED display, IR, buttons, and rotary encoder, which oddly enough looks almost exactly like the empeg panel...

However, I mentioned that he should make sure it ran on the original empeg hardware. He complained that this would be too hard, but did it anyway It works on all versions of the empeg. It will play files from network sources or from local storage, has visuals, can be controlled by a remote, uses the original controls, and so on. He's adding tuner support soon.

One quite neat addition is a master/slave mode, where one player can be designated as the master, and others as slaves, which will then act as repeaters of whatever the master is playing. Unfortunately at the moment the empeg-native version doesn't quite have the power to run a master mode player, but it runs slave mode perfectly. He has players that run on the empeg, the RPI, and normal PC linux. Porting it to other devices would be fairly simple.

He has a sourceforge page where the code will live here, although there's nothing there at the time I'm posting this as he is writing some documentation. It should be up within the next day or two.

The player requires a late version of Hijack to be installed, but other than that replaces the original empeg player software completely.

pca

Very cool! What protocol does it use for the synchronisation?

It's all done via UDP broadcasts, I believe.

pca

Using custom messages designed by Jon, or something like xPL?

superb - however please introduce him to github; it's where all we cool kids hang out these days

I'm too old fat and bald to be cool :-)

Hey Jon, welcome to the bbs

Impressive entrance!

Thanks for the welcome :-)

Very impressive, thank you for the work on it Jon, and welcome to the community. I'll try it out soon.

Feel free to use the boards here for soliciting feedback or bug reports, this is definitely empeg related. It's good to see that well over a decade later, the hardware is still a good enough platform to host developer projects such as this.

Hey Jon! Good to see this going public now!

Yes, indeed. But be careful... IIRC, the last time there was such an impressive software project, it was the Hijack kernel, and now look at Mark's post count!

Welcome.

I'm curious to know, aside from the forthcoming tuner support, what's missing. And, how does it deal with the limitations of the old player, wrt large song databases? Does it still use the existing FID layout, etc? Are we going to need a new version of emplode/jemplode?

I'll post the readme_empeg file from the software, as it answers a few of your questions.

"wrt large song databases? Does it still use the existing FID layout, etc? Are we going to need a new version of emplode/jemplode? "

I'm hoping other people will pick up that challenge. Personally I could live without emplode, I never really made it work!, I hear jemplode is stable but I have yet to try it. I can understand that some poeple will want emplode, or at least proper database style playlist management!

I concentrated on getting the real time bits (displays, audio, menus etc) to work, it should be pretty simple bolt extra functionality onto it later.

The player will accept instructions to play a named track (or with a bit more hacking a FID). It should be possible to write another stand alone process to manage playlists and control centro player, failing that someone could always fork the code and add anything they like :-)

As for large databases on the MK1, i've no idea. The playlists stored in RAM are simply a list of partial path/filenames, should not eat much RAM. It would be possible to split the task partially into files if RAM becomes a problem. I've not noticed any specific MK1 problems but my playlist is only a couple of thousand tracks.

At the moment the player has no proper mp3 database at all so its all open for grabs. I might get time to re-visit the subject it in a few weeks.

Thanks, Jon

>Feel free to use the boards here for soliciting feedback or bug reports,

Thanks :-) Good idea. Its great to see the board still alive and kicking with a loyal user base.

I hope to have a desktop empeg style player kit for the raspberry Pi board in the next few months, the player software was made with that in mind. I will post photos/some links to video here as soon as I have something worth looking at :-)

Fantastic stuff, Jon. Looking forward to playing with it ASAP.

Wow nice, the one thing I would really ask Santa (Jon) for is wildcard searching. And please don’t lose the “Press 2 to enque more artist songs.”

A couple of vidos to show the code in action. First one on a MK1 player.
The second video is a MK2 player, also demos slave mode with the master being a Raspberry Pi board.

http://youtu.be/c1wXFo_blmI

http://youtu.be/qs0bEXLIAek

One quick solution could be a script that scans the FIDs, and does soft links to an MP3 filename for centro to scan/use. If I remember right, emplode simply passes the MP3 file through, preserving ID3 tags while also writing the second FID file with the relevant ID3 info.

Many people here who use it in car and at home may like a sort of dual boot situation. Stock empeg player in the car, and centro in the home. No promises from my end, but I may look to tackle a bit of this.

I don't suppose there's much that's "special" about using a Raspberry Pi as the "Master", or is there?

Could I use an ordinary Linux notebook computer instead, possibly with a few mods to the display output?

>possibly with a few mods to the display output?
The player works in UDP packets, nothing needs modding!

>don't suppose there's much that's "special" about using a Raspberry Pi as the "Master", or is there?

Nothing special at all, you can use anything you like as a master:-) The empeg cant be an effective master simply because its fractionally too slow, works well as a slave though.

The player on platforms other than the empeg has no display of its own, it uses UDP to send display data and accept button push data from either a process on the same machine or stations on the LAN.

The script ./compile will build the player binary for/on most linux hosts. I've yet to try a Sparc (I do have one, I must dust it off, we use an Ultra 10 as a coffee table !) or MIPS but I have tried numerous PCs plus the Pi board and another generic Arm linux board :-)

Two display programs for Centro player are in the sources, "display_on_x11" is a scalable X11 128x32 display, display_on_framebuffer is similar but for raw framebuffer, both require 16 bit per pixel displays at the moment.

The master is a UDP broadcast source, it sends audio data (called audio plus in the sources) and display data as UDP streams, any number of slaves on the LAN can decode it. I pretty much guarantee it will only work on networks with real cables !

Master/Slave is network transparent, if both players are on the same LAN and in the same subnet you simple select mode->master on one and mode->slave on the other (or push the rotary encoder button to toggle between normal and slave mode on a player).

I must write some kind of manual or docs for this when I have time :-)

Almost forgot, "buttons_x11" gives a virtual set of buttons, both the display and buttons code will drive Centro player,or the original empeg player software if you use this code on the empeg:

http://www.jonshouse.co.uk/download/broadcastfb_proc.tar.gz
(binary in is in the tar, code for original player only Centro includes the functionality)

This is what it looks like from the linux desktop:
http://www.jonshouse.co.uk/display_on_x11.jpg
(will make a windows version one day maybe)

To use the entire player on a linux desktop PC just

cd player
./compile

run ./bin_x86/display_on_x11
and ./bin_x86/buttons_x11 127.0.0.1
and ./bin_x86/player_pulse (or works less well on desktops, player_alsa)


No empeg required to play, that is how I did most the coding, I compile for Pi board and empeg after the changes are tested on the PC.

Jon

PS If anyone is confused dont worry, I'm confused and I wrote it ........

"One quick solution could be a script that scans the FIDs, and does soft links to an MP3 filename for centro to scan/use. If I remember right, emplode simply passes the MP3 file through, preserving ID3 tags while also writing the second FID file with the relevant ID3 info."

Yes, that would work quite well :-)

If Centro is pointed at the FIDS direcory it will play the non-text files within it, it just displays the name as "/FIDS/NNN" rather than anything useful. Eiether your idea of a set of links or some extra code to make Centro aware of FIDS would do the job :-)

I thought about replacing the filename with the ID3 tag but not all files have the tag populated, what the player needs to do it recognise FIDS, produce a playlist with only the real mp3 data files and then fill in the title text using the text data in the text FID file. I wont have time this week to look at it.

The other way is just as valid, a set of symlinks would work short term. Just change "MP3DIR0=/drive0" to "MP3DIR0=/drive0/links" in player.cfg and create directory of links. Works well if the link filenames are meaningful :-)

Jon

Wow! VERY nice! Thank you for all your efforts you've put into this!
I myself am looking very forward to this RPi 'desktop' solution.

I currently drive a car that doesn't have the option to build in an Empeg anymore, no more DIN slot unfortunately, like most modern cars... It does have RCA in though, so I could see myself fitting an RPi board with an SSD disk into the glove compartment, all controlled by a small touch screen. (or maybe my iPhone?) That would be awesome! (and would give me my empeg experience back, which I'm still missing after 5 years of being without one)

As it happens, yesterday I coincidentally received my first RPi board. Sure I bought it for another project, but now I know this is coming up, I'll probably buy a few more!

Again, THANK YOU!!!!

Your welcome :-) I've always been an empeg fan. The project was a bit of a vanity project for me, i've bult some displays and gadgets but I needed the software to make them useful. The software is probably not feature complete from an empeg perspective.


Very much in theory here..... if you put a bog standard Pi board with a good DC/DC converter on it and a suitable USB wifi stick it would be possible to run the player application (and hostAP) with no head and use an Iphone (or tablet) to control it. I dont have any Iphone or similar front end available but it should not be a huge job to write one.

The important to thing to note is that my player software does not require a display at all, its nicer with one - but is not required. It all functions with UDP packets, the player is not aware of the front end. Practial upshoot is you can connect or disconnect a display/keys at any point (or have multiple displays or key inputs), the player continues regardless.

For anyone who wants to write a front end, specify -ptx <port> (for just display data) or -master (display and audio data) on the player command line. The UDP display packet is identical to an empeg framebuffer (I thought ahead here). Its 2048 bytes of two pixel per byte 2 bit data. An example (a little crude) of the display end is "display_on_framebuffer.c"

From memory format is XXPPXXPP for a byte, X unused PP two bits of pixel data.


For reference networking (and player process) looks like this: (some might claim overkill here!) On empeg substite "madplayer" for "mplayer"

http://www.jonshouse.co.uk/player.png

The player listens for buttons (from any host) on UDP port 5050
It optionally sends UDP display data on a port specified with -ptx.
It sends UDP display data on port 5051 but only to localhost (127.0.0.1), except on the empeg version where it drives the VFD instead.

In master mode it sends UDP display data on UDP BROADCAST port 4040
in master mode is sends AUDIO + (see source, sorry) data on UDP BROADCAST port 2500
If a master is already present the player will refuse to enter master mode.

In slave mode it receives UDP display data on port 4040
in slave mode it receives AUDIO+ data on port 2500

Jon

Thanks for the info Jon, very informative! Unfortunately, I can't do this myself, since I can't code. (I simply don't have the skills)
So here's to hoping somebody will pick up the task of writing such a front end. That would be awesome!

I am just reading this and I am so amazed.

In the ideal world, I'd LOVE to have an empeg-type player, with all its great features, capable of managing an MP3 collection directly, without converting to FID.

Should this happen, I'd reconsider immediately a car PC project.

This would be the perfect interface to bring back an empeg experience. A simple synch of the file systems between a home collection and the car PC would bring back the magic in a simple, effective way.

Thank you thank you Jon!!

Can you explain what you would like to see ?

Currently Centro player has no "real" mp3 management at all. You tell the player the path of (upto 16) directories of mp3s, it crawls those directories and generates a "playlist". The playlist is really just a list of partial path/filenames in a text file. It then can play tracks from the list sequentially or randomly. To get tracks onto an empeg ftp is about the only way...

The software also runs on a linux PC so give it a go :-)

I've not had any feedback so far and only 11 souls have downloaded the source so I'm guessing the demand is not huge ;-)

I've borrowed a tuner from PCA, next job is to add tuner support and audio input support.

Just for fun I made this, my larger display also runs it but this size is about right for a living room:
http://youtu.be/pi-5hULYxv8

Cheers,
Jon

There is always mp3tofid. Allows you to do exactly what you describe, albeit via an intermediate step.

Yes, I definitely wasn't detailed in my previous post.

This is what I would like to see (and thank you so much for being here to listen in the first place!) :

I've always been interested in having a Car PC. At the same time, I've never seen any better player and GUI (in Car) than the Empeg's. I could get both in my car if:

1. A player software replicating the Empeg GUI and feature set was available on PC, possibly TOUCH based.

2. The above player could create it's track DB (and Empeg player related features) by looking at a specific directory tree on the local HDD/SSD containing an MP3 collection.

I am thinking that playlists could be created on a PC in one of the several ways already there: M3U lists, and similar.

At that point, one would simply decide which MP3s to put in the carPC, and possibly perform simple synch among home PC and car PC, or cloud, etc.

Also, currently there are several x86 (even just Atom) touch tablets that would work nicely as in-car PCs (I am thinking Lenovo Tablet 2, Microsoft Surface Pro), actually. In that case, It'd be nice a Windows player (or a Win8 App).

I'd really like to dock a tablet in my car and use it that way.

I hope this is clearer.

One or the other ! If its touch based then its not replicating empeg GUI. Centro player is true emulation for some of the empeg front end.


Ok, it does this. At the moment it doesnt offer much more though. Its a little primitive but works.


Hmmmm .... welll errrrr hmmmm ....

Centro will compile on Liux/Intel and Linux/ARM - so a tablet with linux will run the software. In theory it would build for windows with a little work, I have no plans for a windows version though.

As an embedded developer I find your logic fuzzy. My aim was to create an empeg style player that will run on modern hardware. PC, Raspberry Pi etc. Later adding a real display and button hardware to the raspberry Pi to create a player device.
The software is pretty flexible and will work in many configurations but it does not have a GUI as such, nor is it windows like, cloud like, or touch screen. I would go as far as to say that if it was any of those things it would not be like an empeg at all.

Cheers,
Jon