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.

Thanks! It's working now. I've only tested with moderate bitrate MP3s but it sounds fine.

Next I need to get the blue wire (amp remote) turned on and use the mixer to set the volume. I assume the blue wire is some GPIO pin but I need to figure out how to get to it from user space. I've seen some code for the volume control; that looks easy enough.

Is it possible the display on/off also controls the blue wire? I see some stuff in the FAQ that seems to indicate there is some connection there.

For right now I have the display off because I don't yet have the code for it and I don't want it to burn in. Maybe I will try blanking the screen but leaving the display on.

edit: Ah-ha, yes that's it. The display power is 'tied' to the blue wire. Now if I could figure out the volume. It looks like /dev/mixer supports the standard ioctl MIXER_WRITE(SOUND_MIXER_VOLUME) so I'm not sure why it's not working.

I've got the mixer working, Squeezeslave was trying to set the PCM volume instead of the master volume.

Playing a ~192kbit VBR MP3 consumes 20-40% of the CPU. I'm not sure if this is normal or not, but at least it seems like things are not on the verge of disaster. There is a stutter when changing tracks which I can get rid of with a bit of a delay; I'd like to come up with a better solution. I've tested Ogg Vorbis and FLAC and those are working too.

Now I'm working on the button input and I think I've got that figured out using /dev/ir. Also I need to get the player to shut down when the accessory power goes away, and /dev/empeg_power seems to be the trick to that one.

The front panel buttons/knob are working pretty good now. It seems like the knob has a bit too aggressive debounce on it, as spinning fast seems to drop out. It's understandable though with the mechanical rotary encoder, it's just that the squeezeboxserver has some velocity sensitive stuff that's pretty nice but if I try to get it to kick in the knob is holding me back.

Next up is the DSP equalizer. I've figured out how to read/write it, but I can't find information on how to calculate the constants. I've searched both the 7705 datasheet and user guide but it doesn't seem to have these. I can kind of figure out how to stuff the freq, Q, and gain into word1 and word2 but I don't know how to calculate the actual constants.

Yeah. IIRC, the 7705 came with a piece of software so that you could calculate preset EQs, and then your software would just push the constants into the chip. I think we reverse-engineered the algorithm (or found a private data sheet) so that we could implement the configurable EQ in the empeg.

For now I'm just saving the EQ data after running 'player' to a file and reloading it on startup. Not exactly user friendly but it works.

It's pretty far along now!

This looks great! Are you thinking of making it available once you've got it fully working ???

Cheers

Cris

Yes! I'm not sure if it will be part of Squeezeslave or a branch. I hacked apart portaudio pretty good too, I dunno how to make that "production" quality but at the least someone with a toolchain will be able to download the source/patch and make it themselves.

What the heck, in case I die tomorrow I've attached a diff from Squeezeslave r261.

Awesome !!!

I'm a total tool at stuff like this, can someone clever explain how I can get this working on my empeg please

Cheers

Cris

You'll need a crosscompiling toolchain and the development version of the os; it's not really trivial. When I get it to a stable place I'll try to make a *.upgrade file, might be a while though.

I've been running it for a while, it seems to work okay. Here are the files for download, the instructions are contained in the description for each file. Eventually I should do some instructions in the Wiki, but this should be enough to get going.

This only works with the Linux Squeezeboxserver as the Windows one is precompiled so it can't be patched.

http://code.google.com/p/squeezeslave/downloads/detail?name=squeezeslave-mk2-r272.upgrade
http://code.google.com/p/squeezeslave/downloads/detail?name=squeezeslave-mk2-sbs.patch

Let me know how it works for you!

The Windows version can be patched, just like the Linux one. The difference is that you need to download the Perl source separately and change the startup options so that it runs from the source rather than from the pre-compiled Perl that it ships with.

Looking at the patch, it should work fine on the Windows version of SBS.

That's good to hear Andy. I've never actually used the Windows version, I just took a quick look to see if the patch would work and I didn't see the source anywhere.

I would guess that after the server loads into RAM the performance should be the same regardless of whether it was precompiled or not.

I've posted an update to my thread on the squeezebox forum.

http://forums.slimdevices.com/showthread.php?89844-Vanputer&p=771117#post771117