Hello ALUG,
I'm doing some work with one of the post-grads on a Web-based audio mixer for live sound sources.
The user will see each of the, say, half-dozen sound sources arranged on the screen and as he moves his cursor (or "joystick") towards one, it becomes predominant in the mix. Each of the sound sources will play either a continuous stream from a live microphone or continuous loops of interesting cached sounds.
My basic plan is to have this sort of "joystick" metaphor on the client side which responds to mouse gestures by sending lots of small HTTP requests representing Open Sound Control commands using AJAX to a PHP (or possibly the dreaded Perl) script on the server side which, in turn, forwards the OSC commands to the mixer software. The output audio stream from the mixer should then be MP3 encoded and streamed back to the client to play in his embedded media player.
I have a clear view of how I will implement everything up to and including the server side PHP (or Perl). After that I'm not so sure. There are two aspects that I'd appreciate anyone's wisdom on.
First is the mixing software. The reason why I've mentioned OSC is because my colleague is an experienced Max/MSP user and would like to use either that or PureData to handle the mixing. However, I'm worried about how well this will scale up when multiple users are connected. Will I have to run one instance of Max (or pd) for each client connection? Should I perhaps consider a more UNIXy tool like ecasound or something?
Second is the streaming software. I'm a bit surer about this: I've looked at Icecast and it seems to do MP3 encoding. I reckon it can probably handle multiple client sessions as long as each connection has its own distinguishable source audio stream which I suppose depends on how I choose to implement the mixer. Has anyone had any experience with it? Is it very resource intensive?
Any thoughts or experiences would be very welcome!
Cheers, Richard
On Tue, May 23, 2006 at 10:05:07AM +0100, Richard Lewis wrote:
First is the mixing software. The reason why I've mentioned OSC is because my colleague is an experienced Max/MSP user and would like to use either that or PureData to handle the mixing. However, I'm worried about how well this will scale up when multiple users are connected. Will I have to run one instance of Max (or pd) for each client connection? Should I perhaps consider a more UNIXy tool like ecasound or something?
PD has a command line mode, and is actually reasonably light, you can also set it to spool out mp3 and get sources from a variety of places... if each user is supposed to get a different experience, then, yeah - without a lot more work, you'd run multiple copies of pd. Then each person just has the output chunk of the running pd, should be relatively simple. I think. probably. (this is off the top of my head so might be wildly inaccurate :)
Second is the streaming software. I'm a bit surer about this: I've looked at Icecast and it seems to do MP3 encoding. I reckon it can probably handle multiple client sessions as long as each connection has its own distinguishable source audio stream which I suppose depends on how I choose to implement the mixer. Has anyone had any experience with it? Is it very resource intensive?
Icecast generally only provides one stream that you can connect to, or multiple defined streams, I'm not sure that it's what you're looking for in this case. Unless all users are supposed to hear the same thing?
Any thoughts or experiences would be very welcome!
If they're all getting their own streams, bandwidth will become an issue fairly quickly if it becomes popular ;) (10 people at 64kbps is going to eat most of a 1M connection, after overheads etc...)
Cheers,
On Fri, 2006-05-26 at 09:38 +0100, Brett Parker wrote:
On Tue, May 23, 2006 at 10:05:07AM +0100, Richard Lewis wrote:
First is the mixing software.
PD has a command line mode, and is actually reasonably light, you can also set it to spool out mp3 and get sources from a variety of places... if each user is supposed to get a different experience, then, yeah - without a lot more work, you'd run multiple copies of pd. Then each person just has the output chunk of the running pd, should be relatively simple. I think. probably. (this is off the top of my head so might be wildly inaccurate :)
Yes, I think I've decided that pd will be the best tool. Partly because the design of the patch is the responsibility of the other guy I'm working with and he has some experience with pd.
Part of the difficulty I'm having is finding information on using Open Sound Control with pd for two reasons: 1) the most often cited link http://barely.a.live.fm/pd/OSC for the relevant external is gone; and 2) "osc" in pd means an oscillator!
Second is the streaming software.
Icecast generally only provides one stream that you can connect to, or multiple defined streams, I'm not sure that it's what you're looking for in this case. Unless all users are supposed to hear the same thing?
I think Icecast will serve multiple streams using a "mount-point" paradigm. They are presented to the user as distinct URIs and you can set parameters for them like maximum listeners etc.
If they're all getting their own streams, bandwidth will become an issue fairly quickly if it becomes popular ;) (10 people at 64kbps is going to eat most of a 1M connection, after overheads etc...)
I think the most practical solution will be to have, say, ten always running instances of pd which each have a separate output stream on the streaming server. When a client arrives at the Web interface, he is allowed to choose one of the vacant sessions to play with and takes exclusive control of it or he can listen in to a session which someone else is playing with.
Thanks for your thoughts!
Cheers, Richard
Hi Richard
On Friday 26 May 2006 10:08, Richard Lewis wrote:
- the most often cited link
http://barely.a.live.fm/pd/OSC for the relevant external is gone;
Gone from the original host, but archived at http://web.archive.org/web/20050207163621/barely.a.live.fm/pd/OSC/
Regards, Paul.
-
Brett Parker -
Paul -
Richard Lewis