Hey everyone,

I've also written a replacement player that runs on the Rio. It is compatible with the Rio supplied server software (should be compatible with JReceiver etc but I haven't tried it with that yet) and also supports Shoutcast streams. Currently the shoutcast stream addresses are loaded from a streams.cfg file in the /etc directory so you can't enter stream addresses at run time. I plan to include a web interface soon which will make it easier to change the list of streams while the player is running. Anyway more information and all the files are available here:

http://www.pier13.com/rioplay/

Wow, cool!

Hey, what's up with all the receiver clients? Two replacement players for the receiver, but no replacement players for the empeg car yet? Someone get on the ball.

Thank you Dave,

The ability to stream from an 'net broadcast was exactly what I was looking for. Looking forward to your next implementation.

John

Why replace perfection? I'd rather have an interface for the receiver that behaves exactly like empeg car....Along with the ability to play streams directly.

In reply to:

---

I'd rather have an interface for the receiver that behaves exactly like empeg car

---

Unfortunately I don't own an empeg car or Rio Car... What specifically about that interface do you like so much? I was under the impression that the empeg car and the Rio Receiver had basically the same player software in them (well, without all those fancy animations and such...)

Although the Rio Receiver and the Rio Car share some of the same "under the hood" code, the user interfaces and feature-sets are completely different.

One isn't necessarily better than the other in terms of UI design, but the car player has a greatly expanded set of features.

The feature set that the Empeg car has that I just totaly love is the fact you can adjust the playlist while it's playing. I'm so used to the buttons on the remote that lets you swap out the next songs with tracks that are like the current track(genre, year, album, artist), that I reach for the remote for the receiver to do the same thing, and then find out it doesn't work

Hi.... this sounds like just what I have been looking for.

I downloaded receiver.arf and dropped in place of the one that came with the rio software and now my rio won't boot. It finds the music server, but then it hangs with the message "Please wait". Have any suggestions on how to debug this?

I am running Windows XP.

Thanks in advance for any help.

Try re-downloading the "receiver.arf" file with a download-manager program such as GetRight. My guess is that the Pier13.com server doesn't properly send the file as a binary, and therefore your web browser downloaded it as ASCII.

This is just a guess, though.

If that turns out to be the case, may I suggest to the author that he zip his binary files on the server to prevent the problem in the future.

Good idea... but no joy. Thanks anyway. Got any other ideas?

Are you by chance using HPNA instead of Ethernet? I didn't include the HPNA driver in my receiver.arf distribution because I'm not sure if I'm allowed to. I'll look into this a little more. Maybe that arf patch program that's floating around would be useful here.

Yes, I am using HPNA instead of Ethernet. If you come up with anything I would be grateful.

Thanks!

OK I've got something for you to try. First, download the GNU tar utility for MS-DOS from ftp://ftp.gnu.org/gnu/tar/. Rename that file to tar.exe and put it in your path somewhere (like your windows directory). Next, make a directory c:\riotemp. Copy the original receiver.arf into this directory. In an MS-DOS window, cd into that directory and run the command:

tar -xvf receiver.arf

which will untar the original. You'll get some errors when untarring it but don't worry about them. Now delete the receiver.arf file. Then download a copy of my receiver.arf file and place it into this c:\riotemp directory. In your MS-DOS window, run these two commands:

tar --delete -vf receiver.arf ./il-binary.o ./zImage
tar -rvf receiver.arf ./il-binary.o ./zImage

This should delete my zImage and il-binary.o file and replace it with the original versions, respectively.

That should leave you with a receiver.arf that will work with HPNA. As I don't have HPNA set up, I really can't test this, but I don't see why it won't work. Let me know how it works out!

Dave,
This looks excellent ! However I'm having a few problems.
The Rio boots, I get the "RioPlay" splash screen, I hit menu and it gives me a menu of (from memory) "Select music" and "About player". At this point the rotatary control/select button doesn't function, all I can do is hit menu at which point it then looks like its trying to play a track but it has no track information at all.
At no point do I see any information to suggest its been able to pull any info back from jreceiver.
Have you any thoughts ?

Thanks

Dobbin.

In reply to:

---

At this point the rotatary control/select button doesn't function, all I can do is hit menu at which point it then looks like its trying to play a track but it has no track information at all.

---

Have you tried the remote? I looked at the code and realized that the way I have it set up now, the rotary knob controls volume at all times, even when a menu is active. I guess I need to change it so that when a menu is active, the rotary knob scrolls through the menu instead. The up, down and enter buttons on the remote should work just fine though.

It works! Thanks so much. I got stuck on the menu using the volume knob, but I saw your post and sure enough, the remote works and I have music streaming from SHOUTcast.

Using your tar instructions I figured out how to replace the streams.cfg file so I am ALMOST all set. The thing I am trying to figure out now is how to stream from my PC which I have been using as a SHOUTcast server. I can access it from anywhere on my home network my going to http://192.168.0.3:8000/listen.pls

How do I enter this in the streams file to make Rioplay recognize it? I have gotten as far as getting the title to appear, but I haven't been successful in my attempts at getting the http address correctly. Also, do I need to worry about the differences in how Linux and Windows handle <eol> and <CR> characters?

Thanks again for the help. Your program is very cool.

P.S. I am also looking forward to the version where the volume knob works the menu. :-)

Great to hear that it's working for you! As for your shoutcast stream on your server, I think the problem is you need to put the contents of the listen.pls file into the streams.cfg file. The listen.pls file should contain a list of one or more URLs which are the actual stream URLs.

Regarding the streams.cfg file, it probably won't work if it's generated on Windows due to the extra <CR> characters. I'll try to fix that along with the rotary knob menu selection tonight.

Can your player play back MP2 files as well as MP3s ?

If so I think I'll be making use of it as the Rio Receiver software cannot play MP2s.

In reply to:

---

Can your player play back MP2 files as well as MP3s ?

---

I've never tried it myself but my player uses the MAD mp3 decoding library and according to their site it should be supported. However depending on what server you're using you may have to trick it into indexing the mp2 file by renaming it to mp3.

OK I placed version 0.24 up on my site this morning. This version supports navigating the menus with the knob on the front of the receiver and supports DOS style text files (as well as Unix) for the streams.cfg file.

http://www.pier13.com/rioplay/

Wow.. quick work! I will try it out tonight. I got the entries for my SHOUTcast server right last night and it works great.

Thanks again.

I got a few minutes to try this out today. I added the HPNA drivers, my SHOUTcast addresses to the new streams.cfg and it worked first time. This is exactly what I have been looking for. I had figured out how to get it to work with JReceiver, but it was pretty clunky and way too much java and other overhead.

Thanks for all your efforts!!

Ouch.

What I'd hope was apparent to all but the casual observer is that what is being attempted with the development of jrec is to be far more than a host to the Rio.

Those of modest needs who only require a basic host should definitely stick with the provided Windows software. If direct streaming capabilities can then be provided from the Rio, so much the better.

--Reed

I don't actually want to play back MP2 files, I want to play back an MP2 stream. The reason for this is that my Wavefinder DAB digital radio tuner can be made to output a MP2 stream via HTTP.

Well the good news is that it works, sort of.

There are two problems, firstly the audio is choppy, as if frames are missing. However this problem appears to effect all the streams I try (including the default ones in streams.cfg) so I suspect that it may be a general problem with my setup. The Receiver is connected to my DSL line via a wireless network, I will try plugging it in direct over the weekend to see if that helps.

The other problem is that the stream plays back slightly slowly (you can notice that the pitch is lower than it should be) I think this may be due to the sample rate, the MP2 stream is a 48khz stream. Anyone know if there is anything that can be done about this ?

P.S. Should I be pointing the player at the stream itself, or the .pls file with the details in ?

In reply to:

---

The other problem is that the stream plays back slightly slowly (you can notice that the pitch is lower than it should be) I think this may be due to the sample rate, the MP2 stream is a 48khz stream. Anyone know if there is anything that can be done about this ?

---

Yes, the sample rate is the problem. The Rio hardware is locked at 44.1KHz. I'm sure it's possible to downsample, but I'm not enough of a physics person to know off hand how to do it. Anybody have any suggestions? Can we just drop every nth frame?

In reply to:

---

P.S. Should I be pointing the player at the stream itself, or the .pls file with the details in ?

---

Right now you need to point the player at the stream itself. I'm looking into adding code to handle the .pls files but it's not there yet. Eventually I'd like to have a better way of entering streams. I could make a web based interface to the receiver, but the stream URLs would not be persistent (as far as I can tell, the built in NFS server in the Rio software is read-only). Otherwise maybe I could write a supplemental server program that just serves up the stream addresses, but that seems overkill. I also considered hiding the stream URLs in a file that looked like an MP3, but that seems like a hack. Anyone have a good idea for this?

Thanks Dave, great work on the player by the way.

Sample rate conversion is a bit of a black art. To do it well requires a certain amount of attention from code in the CPU to prevent severe aliasing artifacts. Software packages which do the best job of it are patented, if I recall correctly.

Presumably the Rio Receiver and Rio Car code does the sample rate conversion in the player executable (I have not seen anything in the kernel to do with sample rate conversion) ?

Yes, but as a discussion on the Car Player BBS recently brought up, they don't do it particularly well. It's best to just feed them a proper 44khz file if you want it to sound good.

That isn't an option in this case. The MP2 data in question is getting stream raw out of my DAB digital radio tuner, the native format is 48khz MP2.

I have been digging through the mad source code. There is actually some resampling code in there. It is in resample.c and uses linear interpolation.

However, it appears that the resampling code is only called by the code in player.c and not by the main library. I don't suppose that someone could transplant in into Dave's player code ?

Dave,
You were spot on. I didn't think of trying the remote. However I've installed the new version and the problems resolved.
Thanks for all your effort in writing rioplay.

Dobbin

John

Don't suppose you could let me know how you got RioPlay to work with JReceiver.

Thanks

Dobbin

Sorry, I never tried rioplay with JReceiver.

I actually used rioplay to replace the need for JReceiver. I was very impressed with JReceiver's playlist management, but all I really used it for was SHOUTcast streaming. Since I am using Windows, rioplay made the server that came with the receiver good enough for me.

If I was going to try it, I would install JReceiver with the necessary rio receiver drivers and get that working. Then follow the instructions above (Dave's help in getting my HPNA issue resolved) for replacing the necessary files (il-binary.o and zImage) for rioplay. I don't know if this will work, but that's what I would try.

By the way, I used rioplay 0.24 for a number of hours last night and everything worked flawlessly. Thanks Dave!

Dave,

Ever thought of adding a configuration option allowing rioplay to jump right to playing a default stream or playlist on boot up? I think this would be great.... maybe my wife could even use the rio then. :-)

Thanks again for rioplay.

In reply to:

---

Ever thought of adding a configuration option allowing rioplay to jump right to playing a default stream or playlist on boot up?

---

I have considered doing something with it at bootup, rather than having it just sit there. However this really should only be an issue after it boots from being unplugged. Once it's up and running, pressing the power button to turn it off doesn't really do much except stop playback and power off the display. The application is actually still running. When you press power again, it should resume playing where it left off.

As for a default action from a cold boot, should it read this from some sort of config file? Then we run into the same problem as with the Shoutcast streams in that in order to change it, you have to mess around with TAR to replace a config file in the receiver.arf. Hmm... have to give this one a little thought.

I've also been browsing the "Wish List" forum for ideas to add to my software. I'm looking at the "Select by artist then album" idea and a few others... As well as adding a random option to the playback (I need that one soon... I really prefer just listening to my whole collection at random). Any other ideas that anyone would like to suggest?

Hello Dave

Got around to downloading Rioplay today and WOW! It works really well, I was streaming withing minutes. Awsome work! My only suggestion would be to include some more detailed instuctions on how to install it for us software challenged types...

Thank you again though, it's so sweet to finally be able to stream internet radio through the Rio

Thanks - John

In reply to:

---

Where do the files go? I placed the "receiver.tar" into my audio reciver directory (it is a .tar file, not an .arf file...should I be doing any extraction of this file? What do I do with the other two .tgz files?

---

OK, first problem is most likely caused by your browser. It's probably renaming the receiver.arf file to receiver.tar or something. Make sure it's named receiver.arf. (The .arf file is really just a tar file). This file goes into C:\Program Files\Audio Receiver\ and should replace another receiver.arf file that's already there. You should probably back up the old receiver.arf in case you want to revert back to it later. As for the other two .tgz files, you don't need them. One is the source code which is only useful if you feel like trying to modify the program and the other is just the player binary which is useful for people who are running off a Linux NFS server, for instance.

Seen...

I had already changed my post above because I was able to figure it out after I wrote it. Thanks for your speedy reply though, I'm very grateful for this software.

John

Any other ideas that anyone would like to suggest?

Sample rate conversion would be top of my list...

In reply to:

---

Sample rate conversion would be top of my list...

---

I took a look at that resample.c file last night and it looks like it'll be pretty easy to graft that into my player code, however I can't comment on what it'll sound like...

This looks like a seriously useful bit of software ... I'm especially tantalized by the placeholder Web interface C++ files in the source distribution! :-)

Unfortunately, on my Rio Receiver selecting any stream causes the rio to reboot back to the "Rioplay" splash screen, and selecting the 'Play file from Server' menu option hangs the Rio completely so that not even the power switch will work!

Has anybody else come across this behaviour?

Thanks,
Paul

Both my players freeze on occasion now, only solvable by removing the power from them. It don't mind it much because the streaming feature is so good. I imagine as Dave continues to tweek his code it will only get better and better. I wish Sonic Blue could get off their collective butts and issue some new software for the player but I'm not holding my breath....

In reply to:

---

Both my players freeze on occasion now, only solvable by removing the power from them

---

Hmm.. I'm disappointed to hear this. I've used both of my players for fairly long periods of time and haven't had them lock up yet. Is it only when using Shoutcast streams or does this also occur while using the Rio server software?

Regarding pbar's problem with the player restarting when you try to play streams, what kind of setup do you have for an Internet connection? Are you using connection sharing or NAT or something, or does your network require a proxy to access the internet?

Looks like I'll have to add some more code in to debug these problems...

Hi,

It seems that within every 20 seconds the shoutcast stream skips (i.e., it pauses audio) for just a split second. Any idea what that might be? Don't shoutcast streams contain metadata? Where do you parse that out? You just, because the screen updates with text from the shoutcast server.

My setup is a W2K machine acting as a Internet Connection Sharing (i.e., NAT) gateway. I am using 0.24 of your software after having updating the receiver.arf file with the zImage and il-binary.o file from the orignial arf file, because I am using HPNA.

Great software, btw.

Cheers,
Marc

I also often get lock ups of the player when I try to play streams.

My Internet connection is fairly straight forward. I have:

- a DSL modem
- connected to a 10Mb hub
- connected to a Win2kPro machine
- the Win2k machine has a 3Com wireless card and it set to route IP traffic between the LAN and the WLAN
- there is a NetGear ME102 wireless access point
- connected to a 10Mb hub
- which is connected to the Rio

Ok, so I guess it's isn't completely straightforward, but there is nothing unusual about it.

The Win2k box is also the Rio server and is the source of one of my streams (a raw MP2 stream from my DAB digital radio tuner). I also have the problem with once playing, streams dropping a second of audio every few seconds.

I know two things about these dropouts:

- they are not shoutcast specific because they effect both the shoutcast streams that came in the streams.cfg file and the raw MP2 stream, which contains no metadata, from my radio tuner
- they are not caused by problems with my Internet connection, again because they effect both local and remote streams

I am going to find some time later today to plug the Rio direct into my Internet connection, just to check that the drop outs can't be caused by the wireless LAN.

If you add debug output to the player it would be good if you made the player send the debug info in UDP packets to a known port on the server, I could knock up an Windows app to receive them and display them.

P.S. Once I have sucessfully started a stream I have never had a lock up and sometimes it doesn't lock up, just the stream doesn't start (and I can then try another one).

P.P.S. All of my network, including the Rio, uses real public IP addresses. There is no NAT or proxying going on, though there is a firewall on the DSL router blocking most incoming traffic (the only traffic going to the Rio will be TCP connections that it started).

It seems that within every 20 seconds the shoutcast stream skips (i.e., it pauses audio) for just a split second.

<AOL>Me too !</AOL>

Don't shoutcast streams contain metadata?

Don't think so, I have a stream that is pure MP2, with no metadata and it happens on that too.

I am using version 0.24 as well.

Dave,

Didn't want to just whinge so I spent most of today building rioplay from source to stick in some debugging code and work out what was going on (I whacked in a version of printf that sends UPD packets to my desktop machine)

It turns out that the wedging up when trying to play from the Rio Server was due to the broadcast SSDP packets not making it out on the wire. (I don't know why, but I get errno 101 "ENETUNREACH - network unreachable")

This was causing the RioPlayList code to hang waiting for a reply (since no retransmits). When I stuck in a hardwired address for my server things worked OK.

Took me a while to get the libmad stuff working since your source code distribution seems to require a more recent ARM-linux port of libmad than I could find on Jeff Mock's page. Managed to cobble together a build of the most recent version.

Managed to get the "playing from Rio Server" code to work in the end.

The streaming code causes a reboot due to AudioThread::OpenFile returning NULL when the socket connect() call failes. Once again this is errno 101 - ENETUNREACH.

My Rio is as you suggested behind a NAT firewall router... but my ISP has been up and down all weekend so this may have caused some problems. I haven't gone into much detail on this problem.

I was suspicious that the netmask may be a bit wierd since the Rio gets its DHCP reply from my NAT box, but I've tried all of the above with DHCP disabled on the NAT box and turned on in the AudioReceiver software ... makes no obvious difference. :-(

I don't know how routing is configured in the Rio linux world but that's my next avenue of investigation. Also not sure about DNS config, but all the streams in the config file seem to use numeric IP addresses anyway.

All in all, seems like a nice clean codebase and I'm looking forward to being able to use my Rio the way it always ought to have been!

(Still half tempted to lash together a minimalist web interface ... e.g. use wget to enumerate all Artists, Playlists, Tracks from the rio server, build some web pages that send a quick UDP packet at the rioplay code :-)

Thanks again for making this available.. reading such well commented and tidy code was a pleasure.

Paul

In reply to:

---

This was causing the RioPlayList code to hang waiting for a reply (since no retransmits)

---

Yeah, it occured to me earlier today that it only sends the player request packet once. I never thought to go back and add code to make it retry since it always worked on my network. Have to add that to the to-do list I guess.

In reply to:

---

Took me a while to get the libmad stuff working since your source code distribution seems to require a more recent ARM-linux port of libmad than I could find on Jeff Mock's page. Managed to cobble together a build of the most recent version.

---

Yes I used the 0.14.2b release of libmad. I was able to use it "out of the box" by using this configure line:
./configure --host=arm-linux --enable-speed --enable-fpm=arm --disable-debugging

In reply to:

---

The streaming code causes a reboot due to AudioThread::OpenFile returning NULL when the socket connect() call failes. Once again this is errno 101 - ENETUNREACH

---

Unfortunately the code as it stands doesn't handle error conditions very well as this illustrates. However I can't understand why you're getting ENETUNREACH. My first guess is that the Rio isn't getting it's default gateway set correctly. Do you have the ability to connect to your Rio with either a serial port or netcat or something? If not I'll build an ARF file that has some of those utilities. What I'm interested in is the contents of /proc/net/route.

In reply to:

---

Also not sure about DNS config, but all the streams in the config file seem to use numeric IP addresses anyway.

---

The Rio shouldn't need DNS unless you try to enter a Shoutcast stream that is not an IP address. I don't have mine here set up with DNS and it doesn't seem to be a problem.

In reply to:

---

reading such well commented and tidy code was a pleasure

---

Hmm.. I didn't think that I'd done that good a job commenting the code Glad to hear you could make sense of it.

Hmm.. I didn't think that I'd done that good a job commenting the code Glad to hear you could make sense of it.

Ah, but compared to most open source code it is well commented...

Dave,

Minor screen bug I ran into today. The title of a CD somehow made it onto the third "line" after having switched from menu mode back to play mode. Not sure how to better explain how this happenend. Will try to make this a repeatable problem.

Btw., your software has been working better for me than what was provided from RIO. So, please don't be discouraged by my bug reports.

Cheers,
Marc

In reply to:

---

I can't understand why you're getting ENETUNREACH. My first guess is that the Rio isn't getting it's default gateway set correctly. Do you have the ability to connect to your Rio with either a serial port or netcat or something? If not I'll build an ARF file that has some of those utilities. What I'm interested in is the contents of /proc/net/route.

---

That was my guess too... and the main reason I went back to using the armgr.exe as the DHCP server. I was planning to have a look at /proc/net/route this evening if I get chance. It's probably worth mentioning that the Rio boot loader receives the same DHCP information and *does* somehow manage to send a broadcast SSDP request to the armgr.

This is the first time I've really messed around with the Rio and didn't want to get into building kernels, opening it up to get at the serial line, etc. (I basically just rebuilt rioplay to put some debugging code in and replaced it in your .arf file.)

If you were planning on sticking anything extra into the .arf file then maybe tnlited/bash would be handy while debugging?

BTW, thanks for the config runes for libmad. ... it just moaned at me that it couldn't test the endianness when cross-compiling!

Not enough time is the problem.

We're not allowed to do any work on the receiver software simply because there are other more urgent software needs for us to work on in Cambridge. Hopefully, when some of these other projects are done & dusted then we'll get a chance to revisit (after about 2 years!) the receiver and sort it out with extreme prejudice. There's a lot of love for the receiver in this office, many of us use them at home.

Hugo

Hi Hugo

I figured as much (and my post was tongue-in-cheek), I know that you guys are busy with new projects....I just picked up two receivers a few weeks ago and I really love them...I'm just anxious to see their full potential realized

Dave,

Rioplay is still cooking along for me!

I see what you mean about power on. I had been spending time figuring things out so I kept cold booting to get the client reloaded.

On cold reboot, maybe you could add an optional default tag in the streams.cfg file that be the title of the stream (or playlist) to play on a cold boot. I know that perpetuates messing around with the tar file, but at least if you stick it there, when you get around to dealing with that you will have it all in one place :-)

Two cool features that I have thought of are MP3 Pro support and volume leveling so that songs recorded at varying voume levels are adjusted so that you don't have to continually adjust the volume on the stereo amp. Volume leveling doesn't seem to be necessary for Intenet Shoutcast streams, but when playing my own MP3s through a stream or from a playlist there is quite a bit of volume difference.

Rioplay is still cooking along for me!

Good to hear!

I see what you mean about power on. I had been spending time figuring things out so I kept cold booting to get the client reloaded.

I probably should have mentioned this before, but if the Rio is "on" (LCD is lit up), you can hold down the power button for more than 2 seconds but less than 5 to cause the player application to be restarted by the wrapper init. Hold it down for more than 5 seconds to cause the Rio to reboot.

On cold reboot, maybe you could add an optional default tag in the streams.cfg file that be the title of the stream (or playlist) to play on a cold boot.

I'm finding more and more config parameters that would be nice if they were user settable. I'm kicking around the idea of a very small server program to run in addition to the Rio server that will serve up configuration details to the Rio. I'd like to keep the code so that it will run with just the default Rio server app though so probably what I'd do is make it default all the config parameters if it doesn't find this "config server".

MP3 Pro support

Don't get your hopes up. From what I understand, this technology requires a license and per-unit royalty and I'm sure they wouldn't let me distribute the source code anyway.

volume leveling

This would be cool. I'm not sure how this is done, though. Would the software have to buffer the whole MP3, find the peak volume, then adjust to that? If so it probably isn't feasible. If however there is a way to do it on-the-fly then it might be possible.

Yeah, I figured that MP3 Pro might be an issue.

I was wondering about how to accomplish volume leveling on the fly too. There are some winamp plug-ins that claim to do it and so does Music Match. I know Music Match preprocesses the files and saves information in some way so that it doesn't do it on the fly -- so that kind of implementation would require some server-side code. I don't know about the winamp plug-ins. I will fish around the winamp site and see if I there is any discussion of how it is accomplished.

volume leveling -- This would be cool. I'm not sure how this is done, though. Would the software have to buffer the whole MP3, find the peak volume, then adjust to that? If so it probably isn't feasible. If however there is a way to do it on-the-fly then it might be possible.

Finding the peak volume and adjusting to it is called NORMALIZING, and all of the songs on almost all of your CD's were already normalized. So any routine that normalized the output would actually not make any change in the audio stream. The only way to do it is on-the-fly. A complete discussion of this topic can be found starting here and continuing down the page. You can't normalize, you must do dynamic range compression.

Fortunately, this dynamic range compression is already implemented in one of the available kernel hacks for the Rio Receiver. It is a port of Richard Lovejoy's "Voladj" code from the Car Player. I run it on my Rio Receiver right now. It works. It can be found elsewhere on this bulletin board as a kernel hack for the default software that comes with the receiver.

However, I wish that it would use different parameters than Richard's default ones, it currently pumps a bit too much for my tastes. Perhaps there will be a future version that can use the new default parameters that are found in the Car Player's Hijack kernel. HINT HINT!!!!!

I knew that I had seen that somewhere before... I remember reading the riocar.org page now that you mention it. Anyway if the dynamic range compression is available in a kernel hack it should work with my player just fine. I'm looking forward to trying that out.

Anyway if the dynamic range compression is available in a kernel hack it should work with my player just fine.

If you can get Mark Lord's "Hijack" version of it working, with his latest defaults in it instead of Richard's (and-- ooo--- selectable settings from the front panel with a default of "medium"), then I will probably switch to using to your player software instead of the default player software.

However, I wish that it would use different parameters than Richard's default ones, it currently pumps a bit too much for my tastes. Perhaps there will be a future version that can use the new default parameters that are found in the Car Player's Hijack kernel. HINT HINT!!!!!

Yeah, sorry Tony. I never have found the time to go back to my port of Richard's code and make it more useful. It is still on my lists of "TODOs", but I suspect someone may beat me to it now (the Linux kernel and C is not my normal enviroment, I find it scary in there).

Anyway what Tony was talking about is here on my site:

http://www.norman.cx/receiver/

although as Tony suggested it would be better to port the current version of it across from HiJack, or at very least the configuration values.

Something I never mentioned, but I think that there might be a bug in your port of Richard's code. I think it might be ignoring some of the parameters, even Richard's default ones. Because it pumps even worse than the car player did on Richard's default values. I seem to recall that Hijack deliberately has some bug fixes in it along those lines. So if you ever revisit it, you might want to look at Hijack's version closely to be sure.

Ok thanks Tony, that will be fun.

I have been using Rioplay to play streams orginating from my own PC using winamp and shoucast. It works very well.... even found a dynamic range compression plug-in that seems to work... thanks for the education on that one Tony.

Last night I tried a winamp cross-fading plug-in that sounds great on my PC, but when it streams to my Rio, there are gaps in the sound... right around where the cross-fade should kick in. I can't tell if this is a winamp DSP plug-in issue or something to do with the Rio. Could it be related to the other issue with gaps in streams described above?

Does anyone have any experience with this that could help me troubleshoot the issue?

Try streaming it via Shoutcast to another copy of Winamp, or something else. Preferably on another computer. This will enable you to discover whether the stream is OK.

After building a Rio linux kernel so I could put some debugging in, it turns out that the wierd behaviour I was observing (ENETUNREACH) is caused by a complicated chain of events:

Unfortunately, my Rio *has* to get its IP address from my firewall since there is no way to prevent the firewall from replying to individual machines. :-(

Unlike every other machine on my LAN, the DHCP request from the Rio does not contain a 'Parameter Request List' option (option 55) asking for its gateway (parameter 3)!

Instead, it contains an empty gateway option (option 3) ... which is ignored by the DHCP server.

This has never caused a problem in the past since the Rio then uses broadcast SSDP to find it's NFS server (armgr.exe) and boots normally.

The reason that rioplay has problems is that the Rio boot loader explicitly passes a 'command line' argument to the new linux kernel containing the bogus IP configuration, and explicitly *disabling* further DHCP and SSDP!

The argument looks something like this:

ip=192.168.168.19:192.168.168.129:21075::255.255.255.0:::off

This is parsed in net/ipv4/ipconfig.c as:

myaddr:servaddr:pmapport:gateway:netmask:hostname:devname:flags

The gateway is therefore left unset, and the 'off' flag prevents dynamic configuration!

The "fix" is to make the function ip_auto_config_enable() return immediately at line 1961 without parsing the bogus config string, and to put the appropriate option into the dhcp request.

i.e. add the following 3 lines to ic_dhcp_init_ext() just after line 843

if (type==DHCPDISCOVER || type==DHCPREQUEST) {

> *e++ = 55; // PRB: Parameter Request List option
> *e++ = 1; // length of option
> *e++ = 3; // gateway address parameter

...


Anyhow... with these small fixes, I now have my Rio getting a sensible network configuration and rioplay can both talk to the rio server and route out of the local subnet to fetch shoutcast streams.

Paul

Anybody know if Rob is planning an Ogg version of libmad now that Ogg Vorbis has gone 1.0? That would certainly make a nice combination on the Rio with this new player.