MAD has some empeg specific items throughout the sources, but I'm having some difficulty getting my compiled binary to actually play anything.

I get the usual output from madplay:
MPEG Audio Decoder 0.14.2 (beta) - Copyright (C) 2000-2001 Robert Leslie
Title: lotltheme
Album: Untitled - New CD (1)
Track: 7

But no audio at all is to be heard. (God I love passive voice).

Here's the configuration I ran to at least get it running on the box:
./configure --enable-speed --enable-fpm=arm --host=i686-linux --target=arm-empeg-linux --disable-mmap --with-gnu-ld

I'm real curious if I've just ganked up the target somehow, while guessing at what it should be.

For those who have MAD running, please post a config string you used, or maybe I could just borrow your binaries?

Greg

The following line should configure MAD properly for you. You get the no audio problem if it doesn't think that it needs to use the special Empeg output routines.

CC=arm-empeg-linux-gcc ./configure --host=arm-empeg-linux

- Trevor

Unfortunately I haven't been able to get this to work, yet.

The result is the same as my previous attempts ... no audio, but no errors. And just to make sure it wasn't a hardware problem, I've played the same test mp3 through the normal player software with good audio.

I've tried this on a clean source tree of mad-0.14.2b, his latest release, as well as an earlier release used by the RioReceiver guys, mad-0.12.5b (using Jeff Mock's fixes).

Is there something more substantial I should be puttting in the command line for madplay other than just the name of the test mp3 file? From what I understand it should work with that argument alone right?

In off-subject, I've seen demo code that uses /dev/dsp as the audio device, and then other demo code that uses /dev/audio ... which one is the one to use?

Thanks a bunch for any help you can send my way!
Greg

Hmm. I'll try it out again. Last time I touched MAD was months ago when I had the idea of writing my own player software. I don't remember anything too special I needed to do to get it working though but I may have forgotten.

- Trevor

Ah okay. I've remember what you need to do now
You must turn off soft mute before it will play anything. I've attached pcmplay.c to this message, it should show you what ioctls you need to call.

- Trevor

Boo-Yah!!!! She sings!!!! Madplay now works with minor changes.

I'm including the appropriate file to drop into the mad-0.14.2b folder ... Please note, this is Rob Leslie's stuff, I didn't write all this code. See his license agreement before using it. I'd use patch, but I don't know how to make one.

So, if this goes as well as I hope, I'll have running RioReceiver software on my empeg within a couple of minutes.

Greg

So, if this goes as well as I hope, I'll have running RioReceiver software on my empeg within a couple of minutes.

Hey, here's an interesting thought. Kind of lateral thinking.

If you can get the Rio Receiver software working, perhaps theres a way to modify it so that it can get a list of playlist links from a web page. In fact, I think that would actually be simpler in the code than what it currently does to grab the playlists from the Rio Receiver Server.

Then, tell it to do localhost (127.0.0.1) to get the web page and that way it pulls up the Hijack web server software.

Therefore, you could have the Hijack kernel streaming the local MP3 files to the local Rio Receiver software. Bam, open-source local player app for the empeg.

Okay, it's a dirty way to do it. I was just thinking since Hijack already indexes the playlists for us...

Or another option would be to run a local shoutcast server on the empeg, wich rioplay can use. Not elegant, but it would work.

[Status Update]
So now I have rioplay getting songs from a music server on my lan and blasting them out my empeg. The rioplay software isn't very advanced yet, simple menus, little control over the "transport mechanism" of searching, pausing, etc. But it's working.

Problems I now have ...

The display size isn't right, so some menus are off the bottom of the screen. From what I can tell, a bunch of the display constants are hard coded with little documentation.

Shoutcast streaming causes a segmentation fault.

If the display isn't easily fixed shortly, I may try the GRRR distribution, so long as it can use the standard Rio Receiver Audio Server. I don't feel like hassling with a bunch of mess in MySQL just to get JReceiver running.

Shoutcast, I'm not so worried about ... it's a neat trick if it works, but not pivotal.

You use diff. Most patches these days use the unified format (man diff).