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.