I'm planning a music system for my RV camper. I already have a Dockstar running Squeezebox Server; that part is great, it only takes 6 watts to run! Squeezeslave can run as a client on the Dockstar but there is no way to control it.

I need something to control the music with, and I have a MK2a that would be perfect for this. It seems like porting Squeezeslave to the Empeg would be a perfect setup. Has anyone attempted this?

I thought about it at one time but don't really have a use case for it anymore (the only empeg I use now is in my car.) At that time, it seemed pretty doable, but looking at it now, it seems they've added a bunch of dependencies that might be hard / impossible to build for the empeg. If I were doing it, I'd start with an older squeezeslave release to minimize these dependencies, though you may run into incompatibilities with newer squeezecenter releases, so it's a tough call.

You'd have to hack up the audio output code quite a bit to get it going, see here.

It might be worth looking at SlimRio. I found it struggled on the Rio Receiver, but it would probably work better on the empeg with more memory and a faster CPU.

I have no idea how much work would be involved to get it running on it though.

http://empeg.org.uk/slimrio/

Thanks for the comments guys! Hmm SlimRio, yes I have used that a few years back. My main niggle was the screen layout was wrong (wrapped lines). It actually looks like the Squeezebox Boom has a very similar screen resolution to the Empeg.

Is the hardware similar between the Empeg and RioReceiver? Makes sense they would be similar. I'm having a hard time finding specs, need to dig around archive.org a bit..

I'm about to get started on the development of this and I have a couple questions.

Are there any web links for help with Empeg development? I've found this cross compiler:
http://www.empeg.mars.org/devel/software/toolchain.php

Is the hard disk needed or could I store my program in on-board flash? My drive needed a sharp whack to get it going again, I'm not sure how long it's good for. I suspect that I will need some kind of storage device though, and in that case I will use a compactflash or something similar.

Thanks for any help guys, and I'll post progress reports as I go along.

The onboard flash is a very limited resource, so much so that, as Mark Lord has been adding features to his Hijack kernel, he's been carefully budgeting which bits of Flash are used for storing settings. So yeah, you need an HDD on the 'peg for your dev work.

Unless you intend to completely replace the kernel on the 'peg with your own kernel, in which case, yes, you need to use the flash for the kernel.

The basic division of labor is: Flash=Kernel, some flash-based kernel settings. HDD=Swap, temp storage, and usermode apps. I'm sure there are exceptions to all of the above but that's about it.

For other dev resources, there's a few bits here.

Also, rather than a hard drive, you could go with a fast CF card and a CF to IDE adapter very inexpensively. To implement squeezeslave, you could use a very small CF card. That way, you'd still be using solid state memory and it'd be faster and less likely to fail than a hard drive.

Thanks for the info Tony and John. Looks like a CF adapter is easy enough.

I know I've seen this here before, but the post is eluding my search. I'd like to make the Ethernet plug a blind mate so I can use the dock without manually unplugging it. I swear I saw some pics of this long ago. Any pointers?

There have been a few home docking solutions, some more advanced than others.

You can mod a car sled. I've done some, and there shots of others in the FAQ here:

http://riocar.org/modules.php?op=modload...mp;faqent=64#64

The best would have been if you could have gotten one of Mark Lord's custom docks, which are awesome (I also have one of those, it's the best of all worlds).

Indeed, they are awesome. They only rarely come up for sale on the board, so if you see one, grab it before it's gone.

Thanks again Tony, the hot glue worked great!

If that's in the *car* be careful, because the interior of some parked cars gets hot enough to melt hot-melt glue. I know from experience. If it's just indoors, though no worries.

Yes, that's in the camper. I looked at the hot glue sticks and apparently they are of the high temperature 380 F type. I'll take my chances, thanks for the heads up though. At least hot glue isn't as bad to remove as other glues.

I am able to get the Ethernet to work on my gigabit hub but when I plug direct into the server the link light is lit but no data is received. It is an Auto-MDI/X (gigabit) port so I should not need a crossover cable, but I'll try that next. I know the Empeg is a bit finicky with it's 10baseT port.

That's exactly right: Its 10baseT port is finicky. There are documented accounts where doesn't get along with some 10/100 switches, and probably plenty of anecdotal evidence that the same might happen with gigabit switches. You sometimes need to put a cheap-ass hub in between the 'peg and the faster switch to get it to work.

My mk2 and mk2a definitely work with Netgear GS108 GigE switches.

Well, it was through no fault of the empeg that the Ethernet wasn't working. My Iomega iConnect that is my music server needed some patches applied to the kernel in order for the Ethernet to work at any speed other than 1000baseT.

Using a straight-through cable now works thanks to the Auto-MDI/X on the server and it connects at 10baseT half duplex.

Is there any way for the empeg to play a network stream like http://server:9000/stream.mp3?

Mark Lord's hijack kernel has that built in. Depending on the format of the URL, it will either download an MP3 file, stream the file, or download an M3U playlist for streaming. There's even a rudimentary Web UI already built into hijack that allows you to browse the playlists.

To get started:
http://www.riocar.org/modules.php?op=mod...;faqent=202#202

I think he means stream a file from the LAN (e.g. a Squeezebox server) not for it to stream files to the LAN. I don't know of anyone who's gotten the former to work.

Isn't that what the Rio Receiver Edition firmware does?

Yes I want to stream a file *from* the LAN. It would be an interim thing until I get the native player coded up.

I saw the Rio Receiver Edition but I didn't want to hassle with getting the SSDP, TFTP, etc. stuff all set up. Maybe the empeg doesn't need that though, I've only had experience with the actual Rio/Dell Receiver.

I now have the CF card and adapter, I just need to set up the new drive.

The compactflash adapter worked great, I used the one here:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140523993608

After beating up Squeezeslave for a bit I have it running on the empeg. Some of the code was not written to work with the 2.95 compiler but that was easy to manage. There were a bunch of other little things, mostly because the toolchain/kernel is outdated.

I do not have sound yet, I'm trying to figure that out. The newer empeg kernels removed the OSS ioctls, so I had to do a hack job on PortAudio to rip that out. I don't see any errors in the kernel log about the 4608 /dev/audio size problem, I attempted to make PortAudio write in that block size.

Out of curiousity, has anyone got a more modern kernel working on the empeg?

I suppose you could just reconfigure/rebuild the existing kernel to include OSS if that's needed.

This is how I set up /dev/mixer:

That's a good idea, I'll give it a shot!

Easiest way to get a kernel built is probably to grab the Hijack Kernel source tree, plus the tools from the link on the Hijack pages.

cheers

After a bit of digging it looks like OSS support is a no-go. The Mk2 has a CS4231A codec. It seems the empeg CS4231A driver is implemented as a simple character device, so it has no OSS support. I guess the driver for the Mk1 had OSS support.

In any case I don't think I can get it to work that way, unless you have another idea. I guess I'll have to focus on PortAudio.

If you're trying to output via the CS4231A then it won't work. It is purely there to handle the mic input and sample the aux/tuner for visualisations. All output is via the Phillips DSP.

Which driver provides /dev/audio? That's what I'm using.

Looking at the datasheet for the SAA7705H, it doesn't look like it has any parallel bus interface to the CPU. It actually looks like the SA1100 is actually providing the audio stream... I will investigate further.

Yeah, the SA1100 has no I2S on it, so the I2S is actually generated by an SPI port, with some external logic to make the word select. If it glitches at all, word select resyncs so the first worked after a falling CS is left (or right... whichever, it's always the same one). That, and the display interfacing to CLCD using every 4th pixel and a PIC was thought of on the train to and from London

The HW is locked at 44,100 too.

This may impede you finding any audio drivers for it, simply because the SA1100 didn't really have I2S audio in the first place (I think it had PCM?)

If you just rebuffer your audio output it into 4608 byte chunks you should be just fine, however.

The "DSP" does no decode at all. It's a car audio DSP designed to be used with a CD and/or tape mechanism. It does EQ and FM stereo processing, balance, loudness boost, dynamic range compression type of thing. It is fed the vanilla I2S by the SA1100.