mp3stream
This is the home of mp3stream. It's messy, but that's because I've thrown it together
in very short order. This is meant simply as a place to get information and the latest
code updates, so it doesn't need to be all pretty and flashy. It needs to be functional.
The latest version of mp3stream is v1.2.1 (April 23, 2001)
You can get it here
RedHat 6.2 RPMs are available for 1.2.0: i386 (source)
Contributed by Marc Lavallée (odradek@videotron.ca)
If you're looking to get in touch with me, the author, Matt Messier, you can email me
here
Updates will, of course, be made as new versions are released or relevant information
becomes available for posting.
Changes Since v1.2.1:
- Changed all calls to sprintf() to use vsnprintf() and handle buffer overflows gracefully.
- Bugs reported by John Chris Wren <jcwren@tinymicros.com>
- mp3stream_send() was improperly returning ESRCH when it completes without an error. This was also causing a deadlock because it wasn't releasing the stream's mutex.
- Fixed a race condition with passing the handle to the streaming thread in mp3stream_create().
- Minor cosmetic fix to example.c
Changes Since v1.2.0:
- When an ID3v1 tag is found, send it rather than ending the stream. Let the EOF actually end the stream.
- Fixed a problem with streams ending prematurely in some cases
- Fixed threading in the Python wrapper. Now uses TSD to keep track of Python thread states. Swapping them around is now much cleaner and safer wrt the global interpreter lock.
- Split the source up into multiple files rather than one large one
- mp3stream_t is deprecated for the public API. Applications should use an int. For compatibility, mp3stream_t is still publicly defined to be an int. It will remain until v2.0.0 (if ever there is such a version)
- There is now a maximum of 256 streams existing at one time. If this is too limiting, it is fairly trivial to increase it, but I'd be afraid to run more than 256 streams on one machine anyway.
- There is no longer a single global lock. Each stream has its own lock. There is still a global lock, but it's used far less and for far fewer things. This is how I should have done it to start with, but I didn't really plan on releasing this initially. It was just a quick hack ... This change ought to allow more streams to run concurrently without a problem.
- Fixed up placement of locks in the timing loop. The stream's lock is no longer held while sleeping and waiting to send more data.
- Added mp3stream_join() API. This will allow threads to wait for the streaming thread to finish.
- Added mp3stream_setblocking() API. This will set the blocking status of mp3stream_send(). By default, it is blocking.
- Cleaned up implementation of mp3stream_disconnect().
- COMPAT BUSTER: If a stream end hook is set, mp3stream_send() will still be blocking. Use mp3stream_setblocking() to force non-blocking.
- Added -O2 to CFLAGS for building.
Changes Since v1.1.1:
- Fixed connecting to icecast / non-icy servers
Changes Since v1.0.0:
- Added hooks for thread begin/end, stream begin/end
- Added mp3stream_gethook() and mp3stream_sethook() APIs
- If no hook for stream end, mp3stream_send() will blcok, otherwise it will not
- Changed default values for a stream to point to mp3stream names rather than icecast names (url: "http://www.prilnari.com/mp3stream/", genre: "mp3stream")
- Included Python module
- Corrected return codes for mp3stream_set*() functions. They now return EPERM if the stream is connected.
Last Update: Monday, Apr 23, 2000 19:19