Take the 2-minute tour ×
Sound Design Stack Exchange is a question and answer site for sound engineers, producers, editors, and enthusiasts. It's 100% free, no registration required.

I'm looking to implement some live audio broadcasting functionality within a Ruby on Rails site for a client and was hoping I could get some input from people who have tackled this type of thing before.

Essentially what I need to do is capture and record a user's audio (via microhpone, line in, etc), then stream that to 1,000+ listeners with very little latency, like sub 2 second if possible.

So it looks like we've got 3 parts:

  1. Web-based audio capture (likely with Flash or JS)
  2. Server to accept audio feed and stream to listeners (likely Icecast or Wowza)
  3. Actual audio player (maybe HTML5 w/ Flash as a fallback? Maybe this jPlayer fork)

Does RTMP makes sense here? Or maybe HTTP? What's the most 'future-proof' way to make this happen? Building with mobile in mind, but still want to be able stream to anyone.

I've found lots of potentially helpful threads and software but I'm struggling to get an idea of how it all fits together. I'm a front end guy and way out of my comfort zone so if anyone has insights to offer, I'd love to hear them.

share|improve this question
add comment

migrated from avp.stackexchange.com Jan 24 at 12:01

This question came from our site for engineers, producers, editors, and enthusiasts spanning the fields of video, and media creation.

2 Answers

Why not use existing services?

I’ve been using a Shoutcast streaming plan for years to broadcast my church’s services live. It’s worked like a champ.

Part 1 – Audio Capture I’ve been using an old P2 Win98 box for years with an older version of Winamp & the Shoutcast plug-in. (There are of course modern versions of those.) “SAM Broadcaster” is a very popular option, but there are free alternatives as well.

Part 2 – I have an account with http://www.sleepyengineers.com for a reasonable price.

Part 3 – I have a http://www.wavestreaming.com/player/free-shoutcast-flash-player embedded into my church’s website.

share|improve this answer
add comment

HTTP is ubiquitous, so I'd definitely support that. Other than that, what about a plugin system so that other methods could be added later? That's about all I can think of for future-proofing: a plugin API, the more modular (the more formats the plugins can request data in: streaming, chunked, compressed?) the better.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.