I'm currently working on an open-source re-write of the client software for the rio receiver (http://www.reza.net/rrr.html). The device is based on a linux ARM processor built by the empeg team. I've noticed the audio_empeg.c file which is probably the way I want to go, but I'm not sure what to use for documentation. I've looked at both minimad.c and madlld.c files, but I still don't have a good feel for the best way to go about implementing the code. I basically have two buffers, one with raw MP3 data, and one where I need to write the post-processed data in empeg-friendly format. Any suggestions for a good reference? Should I go the low-level or high-level route?
Thanks, Reza
On Thu, 2 May 2002, Reza Naima wrote:
I basically have two buffers, one with raw MP3 data, and one where I need to write the post-processed data in empeg-friendly format. Any suggestions for a good reference? Should I go the low-level or high-level route?
I opted for this:
/sbin/rtpdump 224.0.1.2 5004 | /sbin/madplay - 2>&1 | /sbin/udpcat 10.0.1.188
which I'd call decidedly "high-level" :) (udpcat is just a debugging tool I wrote to dump stdout across the network to a listening netcat process)
Anyway, being one to do things "quick and dirty", I'd feed madplay a named pipe on one end, nice it up high so that it wouldn't drop frames, and then run the UI and what-not in another process. At least, that's basically what I'm planning to do in -my- rewrite of the Rio Receiver firmware :)
Yeah, that sounds fairly high level. I've implemented most everything but the decoding already. So, how do you plan on doing backward seeking with your implementation?
-Reza
On Fri, May 03, 2002 at 03:02:26AM -0400, Tripp Lilley sent me this...
On Thu, 2 May 2002, Reza Naima wrote:
I basically have two buffers, one with raw MP3 data, and one where I need to write the post-processed data in empeg-friendly format. Any suggestions for a good reference? Should I go the low-level or high-level route?
I opted for this:
/sbin/rtpdump 224.0.1.2 5004 | /sbin/madplay - 2>&1 | /sbin/udpcat 10.0.1.188
which I'd call decidedly "high-level" :) (udpcat is just a debugging tool I wrote to dump stdout across the network to a listening netcat process)
Anyway, being one to do things "quick and dirty", I'd feed madplay a named pipe on one end, nice it up high so that it wouldn't drop frames, and then run the UI and what-not in another process. At least, that's basically what I'm planning to do in -my- rewrite of the Rio Receiver firmware :)
On Fri, 3 May 2002, Reza Naima wrote:
Yeah, that sounds fairly high level. I've implemented most everything but the decoding already. So, how do you plan on doing backward seeking with your implementation?
I don't. I've scrapped the original Receiver model of retrieving a song and playing it. I've turned the Receiver into a dumb decoder of RTP streams and displayer of screen blit updates and a collecter and dispenser of IR / keypad inputs (though the display server and input dispatcher are as-yet unimplemented).
Basically, in my world, the server is responsible for dumping out an RTP stream, to which the Receiver(s) tune in. I'm planning on updating the server (Obsequieum, currently) to support "locked" and "unlocked" streams, then giving the Receiver's inputs to the server to control the "unlocked" streams.
A "locked" stream is one that several receivers (and other RTP listeners) might be listening to, therefore it wouldn't do to have them competing for "control" of the stream. An "unlocked" stream is one that one Receiver is listening to (presumably, although you could opt for anarchy). All of that receiver's inputs would be able to modify the unlocked stream's contents.
Right now, I just use the web interface to Obsequeium, and don't even bother with any controls on the receiver.
* Tripp Lilley (tlilley@perspex.com) wrote:
On Fri, 3 May 2002, Reza Naima wrote:
Yeah, that sounds fairly high level. I've implemented most everything but the decoding already. So, how do you plan on doing backward seeking with your implementation?
I don't. I've scrapped the original Receiver model of retrieving a song and playing it. I've turned the Receiver into a dumb decoder of RTP streams and displayer of screen blit updates and a collecter and dispenser of IR / keypad inputs (though the display server and input dispatcher are as-yet unimplemented).
Sounds exactly like the model used by the SliMP3 player. You may want to check it out if you haven't already -- the server is written in Perl and GPL'd.
Joshua
On Fri, 3 May 2002, Joshua Haberman wrote:
Sounds exactly like the model used by the SliMP3 player. You may want to check it out if you haven't already -- the server is written in Perl and GPL'd.
Yeah, the SliMP3 was pretty much my inspiration, but I had a gift certificate from Amazon, and Amazon carried the Rio :) I plan to add an Audiotron and a SliMP3 as soon as I get further out of debt.
I know it's probably overly ambitious, but I was wondering if anyone else has thought of using libmad in PHP? I'm not sure if it's even possible as it stands right now.
-Joe
On Sun, May 05, 2002 at 12:10:16PM -0400, Joe Webster wrote:
I know it's probably overly ambitious, but I was wondering if anyone else has thought of using libmad in PHP? I'm not sure if it's even possible as it stands right now.
I started doing some swig bindings which would allow all scripting languages to use libmad and libid3tag, but I never got very far.
I think this would be a good idea though. There is still no standard python module for doing ID3v2.
sam
-
Joe Webster -
Joshua Haberman -
Reza Naima -
Sam Clegg -
Tripp Lilley