Well, I finally got around to adding some fun features, and fixed a bug dealing with the playing of streams. To get your weather forecast, edit the configuration and add a 'zipcode' field like..

zipcode=94521

It will query www.weather.com and parse the resulting html. My goal is the pause the audio and have it actually say the wether out loud. I'll get to that soon enough.

Again, you can find the relevant files at

http://www.reza.net/rio/files/

and I've added some more snapshots of the web and front-end interface here

http://pics.boom.net/cgi/index2?id=158

-Reza

p.s. anyone else got any ideas things to add? I'll probably get around to adding a clock, but I supose that requires adding a mechanism to configure the clock on the rio itself.

There's two things i think would be good.

1. Synchronising the Rio's so that you have two or three playing at a party without echo/delay.

2. Think about interfacing to a standalone VFD device through a serial port. The display on the Rio will never amount to much so getting a display like the one used in the Slimp3 is the way to go. This standalone display could be sent other messages as well, such as send caller id.

bill

1. I only own 1 rio reciever so I'm not going to be able to work on this feature. If someone wants to hook me up with a nother one, it shouldn't be terribly difficult to accomplish this. I've tried buying another one off ebay, but used ones are still going for like $200 and that's beyond my budget.

2. This would require buying the display, which will probably cost like $100, and opening up the rio, as the serial port is on the inside. I'm not too sure people want to do this. I do have an alterrnative approach. With regards to the weather forcast feature, I'm going to be making it such that rather than displaying the current weather, it will pause the audio and you'll hear the conditions out loud. Same could be true for caller id info.

but thanks for the suggestions. again, if someone wants to hook me up with a second rio, please do so

Synchronising the Rio's so that you have two or three playing at a party without echo/delay

I'm currently playing around with this in RioPlay. It's a lot harder than it sounds due to multiple levels of buffers involved in the playback. The kernel audio driver has a buffer large enough to hold .8 seconds of audio, so when two different applications play a sample, depending how full each kernel's buffer is, there can be a large delay. I've been able to more or less work around this already.

The other problem is that you have to stream the encoded music which means you have to send out MP3 data to multiple players and then somehow synchronize the decoded samples on both. Also not the easiest thing in the world.

I have cobbled together something that works well but only under certain conditions (you have to start the "slave" player before the "master" player). I think I can overcome these last few problems but it will require rewriting my Mp3Decoder class to use MAD's low level API instead.

OK, I guess I didn't really mean to go into that much detail. Oh well. I'm very interested in having this feature available for my house (I have 2 receivers now), so hopefully this will be possible eventually.

I've been lurking for a while, and haven't yet setup to start hacking my Rio Recivers (I actually have 3 that I haven't even opened yet, since I've been too busy with tivo hacking)

Even though I haven't had time to do any actual rio coding, I've been giving a couple of the problems presented a thought.

What about bypassing mad alltogther, instead just send audio decoded on the server via multicast to all the rio recivers. Assuming your network doesn't have too much other traffic on it, you shouldn't have any issues.

I've been trying to get information about cobranet (http://www.peakaudio.com/Index.htm) which appears to basically do this (encode audio in raw multicast or broadcast frames, send it out, then all the "players" tune to a specific "bundle" and just play it. CobraNet claims to be able to easily support 64 48khz 20bit channels on a 100mb repeater (hub) network... so we shouldn't have any problems sending 2 channels of 16 bit audio to all the recivers, even over the phoneline networking... in theory this can actually scale to transmitting multiple "channel groups" and having each reciver tune to the right multicast group.

I don't have time to work on coding this for at least 2 weeks so I thought I'd throw it out. Does this seem like a valid approach, and is there anyone far enough along to work on this? If it's of interest but nobody gets to it, I can work on it when my schedule gets clearer.

Also, does anyone actually have detailed documentation on the cobranet protocol, like a packetcapture with a framing description, I haven't been able to find anythign like this on the net?

I don't have time to work on coding this for at least 2 weeks so I thought I'd throw it out. Does this seem like a valid approach, and is there anyone far enough along to work on this? If it's of interest but nobody gets to it, I can work on it when my schedule gets clearer.

I tried this myself. I set up a multicast group and then when the Rio was about to send the audio to the sound card it would just write that same data out on a multicast address. Unfortunately this caused gaps in playback on both the master and slave Rios. I'm not sure if the limiting factor was the network or the CPU. Plus, synchronization is still a tricky problem. If anyone has any ideas on how to solve this, I'd like to hear them.

Unless my math is wrong, 48000 samples/second * 20 bits/sample * 2 channels (I assume these are stereo streams) * 64 streams = 122Mbps. If they're actually capable of this, they must be compressing somehow. Even if they're mono streams, that's still 61Mbps which in my experience might be possible but definitely at the edge of what 100Mbps Ethernet is capable of. Certainly looks like an interesting technology though.

I tried this myself. I set up a multicast group and then when the Rio was about to send the audio to the sound card it would just write that same data out on a multicast address.

Have you tried having the server do the decode, and basically treating every rio as a slave?

My "guess" is the CPU may be the limiting factor... though again, I've done ZERO analysis of this on the Rio yet, but think about the amount of context switches alone (and again maybe there is a software optimization I don't know about...)

1) Recive packet (kernel)
2) push packet to decoder (kernel->userspace) + some delta of CPU time
3) push decode to hardware (audio) (user->kernel)
4) push decode to hardware (ether) (user->kernel)

Also take into account, that you actually would have to insert delay into the playback of the decode on the master in your scenario... as he actually know's what to play, before any other receeiver ever gets the decoded packet, obviously complicating sync.

Based on my limited (no hands on knowledge) of cobranet, you can actually calculate the latency between encoding audio and transmiting it to all hosts... assuming you have a hub based net for just the rio's the latency should be identical for all units... therefore they should actually inhernetly keep sync (assuming they have to do no decode)

So we are looking at...
1) Server decodes MP3/OGG/FLAC/etc to raw audio
2) transmit raw audio to multicast/broadcast
All latency in decode/buffer has already occured now
3) rio recives packet (kernel)
4) push to userspace to push to hardware (can this be skiped... ie DMA or some other kernel space move direct to audio hardware?)
5) push to hardware (audio)

so in theory, as long as every frame is enough to reproduce sound, any rio could join/leave a channel and be exactly in sync

I don't think I've missed anything, but worse comes to worse, we might need a "metronome" multicast heartbeat

now this method does waste bandwidth, in theory we could do some minimal compression... but that may actually add some latency (think context switch to deal with remote, robs a cycle or two from the decode)... if compresion is added, we most likely would need the metronome.

Unless my math is wrong, 48000 samples/second * 20 bits/sample * 2 channels (I assume these are stereo streams) * 64 streams = 122Mbps.

nope, each channel is that... a channel... so it's only 61Mbps for 64 channels... but remember you can go full duplex if you go switched, and in a switched enviornment you'd also be able to optimise what channels are where on the net.

As for the rio... the proposal would be to transmit 44.1k * 16bit * 2 channel (stereo) audio... which brakes down to 1.41mbps, so we should be able to fit 6 seperate stero streams onto a 10mb network easily... a 7th might fit.

Is the rio ethernet 10mb or 100mb?

I'm assuming the best you can do on the phoneline net is 10mb?

I tried this myself. I set up a multicast group and then when the Rio was about to send the audio to the sound card it would just write that same data out on a multicast address.

Dave,

Can you make this code available in case I do get some free time in the next couple of weeks?

-TT

On the subject of sync'd broadcast TivoTechie writes:

> 1) Server decodes MP3/OGG/FLAC/etc to raw audio

What jrec needs to do this is a pluggable content engine.

At present the content engine is pretty simple, supporting client pull of mpeg/flac/ogg/wma/raw via http GET. It will eventually be modified to support http://www.jrev.org, http://www.jcraft.com/jroar/ and other streamers in a generic fashion.

Adding support for a synchronizing streamer could fit into this framework.

--Reed http://jreceiver.sourceforge.net

so in theory, as long as every frame is enough to reproduce sound, any rio could join/leave a channel and be exactly in sync

If only it were that easy... Once the player app pushes the audio to the kernel it enters a buffer in the kernel (capable of storing about 0.8 seconds of audio). So what happens is that a Rio that is already joined to a channel receives a packet and pushes it to the audio driver. This causes it to be placed at the back of the buffer, potentially 0.8 seconds away from being played. Another receiver just joined the group and this is the first packet it receives. It pushes it to it's audio device, which has an empty buffer, and therefore it gets played almost immediately.

now this method does waste bandwidth, in theory we could do some minimal compression... but that may actually add some latency (think context switch to deal with remote, robs a cycle or two from the decode)... if compresion is added, we most likely would need the metronome.

If we add compression at this stage, why not just send the previously compressed MP3/FLAC/whatever in the first place? As soon as you add compression back into the mix, you have to deal with another buffer to hold the decompressed audio before it's sent to the audio device.

The method I'm currently looking at involves broadcasting the MP3 data from one Rio to the others and then (on another mutlicast channel) broadcasting a signal of the current frame that the "master" is playing. So essentially the slave Rios would hold onto decoded frames whose frame numbers haven't been sent to the multicast address yet and throw away any frames which have frame numbers less than the last received frame number.

I doubt there's a reason that your idea of decompressing at the server and then multicasting the decoded audio wouldn't work, however it seems inefficient to be pumping all that audio data onto the network. I'd be concerned that opening up an FTP session on the local network could interrupt the broadcast. And of course if you're not providing any real buffering at the client side other than the kernel buffer, even a small drop in network performance can cause an audio dropout.

As for the rio... the proposal would be to transmit 44.1k * 16bit * 2 channel (stereo) audio... which brakes down to 1.41mbps, so we should be able to fit 6 seperate stero streams onto a 10mb network easily... a 7th might fit.

7 * 1.4 = 9.8Mbps and that's just for the data, not counting protocol overhead. That will never happen. Even 6 streams (8.4Mbps) is unlikely, though it may work on an isolated network without much other activity. Remember 10Mbps ethernet will never actually reach 10Mbps due to collisions, protocol overheads, acks, etc. I don't think I've seen a 10Mbps segment do much better than 8.

1) Server decodes MP3/OGG/FLAC/etc to raw audio
2) transmit raw audio to multicast/broadcast

One other thing: if you're multicasting or broadcasting this, that means UDP. If it's UDP, then there's no flow control. So, either the server has to be able to throttle itself or else the clients have to have a mechanism for requesting that the server pause/continue the stream. It's not as easy as just dumping decoded audio into a packet and onto the network.

Can you make this code available in case I do get some free time in the next couple of weeks?

Hmm... I'll see if I still have it around. I don't know if I kept it or not because it was such a simple change and it didn't really work. I just had to do two things: create a multicast socket, then add a sendto() call right after the write() call which writes the audio to the sound device.

Maybe we could borrow some ideas from the slimp3 device? They support synchrotnized playback:

In reply to:

---

To synchronize multiple players, combine the "start" and "pause" codes (0x03) to tell the player to fill its buffer without playing anything. Then, send "resume" commands to each of the players to make them unpause the stream. You can specify a delay in ms before the command takes effect, if necessary.

---

http://www.slimdevices.com/support/protocol.html

also

In reply to:

---

Version 2.3 is finished. This release adds two long awaited features, a MacOSX Aqua interface, plus the ability to synchronize multiple players. For our MacOSX customers, we are now shiping the SliMP3 software as a proper standalone application, with a nice Aqua interface for controlling the server software. Just drag it to your hard disk to install. You can also put in your dock.

---

http://www.slimdevices.com/news.html

1. re:Sync.
As someone has already mentioned, the Slimp3 has a mechanism for doing this already. The only way i got close to syncing the Rio's at present was when i was using my home shoutcast server, once both Rio's were on the this station, i would kill the shoutcast server and after a few seconds, restart it. You can then see the streams being re-connected in the shoutcast log and maybe 30% of the time they would be close enough to be perceived as in sync. I never tested it for any long durations though.

2. Re:VFD

I think the prices are a good bit less than $100, but i think its the server PC that would need to interface to it and not the clients. I'm thinking along the lines of the VFD acting as a general purpose display in a room.

bill

If only it were that easy... Once the player app pushes the audio to the kernel it enters a buffer in the kernel (capable of storing about 0.8 seconds of audio). So what happens is that a Rio that is already joined to a channel receives a packet and pushes it to the audio driver. This causes it to be placed at the back of the buffer, potentially 0.8 seconds away from being played. Another receiver just joined the group and this is the first packet it receives. It pushes it to it's audio device, which has an empty buffer, and therefore it gets played almost immediately.


hmmmm, so this buffer is for the "raw" audio?

a couple of ideas that might work...
1) Starve the buffer (so it always needs a frame from the wire to play)
2) Broadcast the metronome (current frame) again a flat network, everybody should get this at the same time
3) Bypass the buffer (is this possible?)


I doubt there's a reason that your idea of decompressing at the server and then multicasting the decoded audio wouldn't work, however it seems inefficient to be pumping all that audio data onto the network. I'd be concerned that opening up an FTP session on the local network could interrupt the broadcast. And of course if you're not providing any real buffering at the client side other than the kernel buffer, even a small drop in network performance can cause an audio dropout.


I agree, but I am proposing an isolated network for the rios (this is the setup I have now) so dropouts shouldn't be an issue... this is based on how cobranet does it (I think), they don't reccomend mixing data w/audio

* 1.4 = 9.8Mbps and that's just for the data, not counting protocol overhead. That will never happen. Even 6 streams (8.4Mbps) is unlikely, though it may work on an isolated network without much other activity. Remember 10Mbps ethernet will never actually reach 10Mbps due to collisions, protocol overheads, acks, etc. I don't think I've seen a 10Mbps segment do much better than 8.

I don't think I was clear before, I was actually proposing using layer 2 multicast (ethernet multicast) not TCP/IP or UDP/IP multicast. And I'm also proposing doing this on an isolated network so I think 12 channels (6 stereo groups) should work fine, even with a bit of overhead for a raw broadcast/multicast of start/stop messages, and maybe a "catalog stream" which would contain a list of what's playing in each bundle.

So is the rio a 10mb or 100mb device on it's ethernet side?

As for network contention, this should be minimal, at least in the isolated network side... assuming no client want's to play/pause/stop the bundles, then the only TX device is the server (master) everybody else just listens and picked the bundle they want.

hmmmm, so this buffer is for the "raw" audio?

a couple of ideas that might work...
1) Starve the buffer (so it always needs a frame from the wire to play)
2) Broadcast the metronome (current frame) again a flat network, everybody should get this at the same time
3) Bypass the buffer (is this possible?)

It's been a while since I looked at the kernel code, but if I remember correctly, the audio device uses DMA to read out of this kernel buffer. Because of this, I don't think starving the buffer is much of an option, same for bypassing the buffer. As for the "metronome" as you call it, this is basically the same method that I've been trying (broadcasting a frame number to play). This still has the issue of making sure that each Rio has roughly the same amount of data sitting in the above mentioned kernel buffer.

So is the rio a 10mb or 100mb device on it's ethernet side?

10mb.

So, i found someone selling one for $150 on yahoo - which I just paid for. I'm hoping I'm not going to get burned on this. There are a few retailers sellin them for around $350 which is silly.

I've spent some time thinking of this, and it seems like what you'de need to do is first use something like ntp to sync the time on both rio's, then determine how long each frame of data should take to decode. The various rio's pick a time in the future to start, they both wait till that point, then they start at the same time. They also would keep track of how much time has elapsed and what frame they should be decoding. If they're ahead, they pause. if they're behind,they skip frames till they catch up. the key being that they both start the decoding of a frame at a key pre-determined time. But that's just my theory so far.