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.