What's the best protocol for live audio (radio) streaming for mobile and web? -

i trying build website , mobile app (ios, android) internet radio station. website users broadcast music or radio , mobile users listen radio stations , chat other listeners.

i searched week , make prototype wowza engine (using hls , rtmp) , shoutcast server on amazon ec2.

using hls has delay 5 seconds, rtmp , shoutcast has 2 second delay. result think should choose rtmp or shoutcast.

but not sure rtmp , shoutcast best protocol. :(

what protocol should choose? need provide various protocol cover platform?

this broad question. let's start distribution protocol.

streaming protocol

hls has advantage of allowing users stream in bitrate best connection. clients can scale up/down seamlessly without stopping playback. particularly important video, audio mobile clients capable of playing 128kbit streams in areas. if intend have variety of bitrates available , want change quality mid-stream, hls protocol you.

the downside of hls compatibility. ios supports it, that's it. android has hls support still buggy. (maybe in year or 2 once android 3.0 folks gone, won't of issue.) jwplayer has hacks make hls work in flash desktop users.

i wouldn't bother rtmp unless you're concerned flash users.

pure progressive streaming http route choose go. everything can play it. (even palm pilot's default media player 12 years ago.) it's simple implement , understood.

shoutcast http, poorly implemented version has compatibility issues, particularly on mobile devices. has non-standard status line in response breaks lot of clients. icecast alternative, , recommend production use today. option, have created own streaming service called audiopump http well, , has been built fix compatibility oddball mobile clients, such native android players on old hardware. isn't available yet, can contact me @ brad@audiopump.co if want try it.

latency

you mentioned latency of 2 seconds being desirable. if you're getting 2-second latency shoutcast, wrong. don't want latency low, particularly if you're streaming mobile clients. start 20-second buffer @ minimum, flushed client fast can receive it. enables immediate starting of stream playback (as fills client-side buffer can begin decoding) while providing protection against buffer underruns due network conditions. it's not uncommon mobile users walk around corner of building , lose nice signal quality. want stream survive best possible, if have sent data cover drop out, user doesn't have know or care connection became mediocre short period of time.

if require low latency, you're looking @ wrong technology entirely. low latency, check out webrtc.

you can tweak traditional internet radio setup reduce latency, idea.

codec

codec choice dictate compatibility more else. mp3 compatible, , aac isn't far behind. if go aac, better quality audio given bitrate. folks use reduce bandwidth bill.

there licensing fees mp3, , there may aac depending on you're using codec. check lawyer. not one, , licensing extremely complicated.

other codecs include vorbis , opus. if can use opus, licensing wide open , quality bandwidth. client compatibility here though killer of opus. (maybe in few years better.) vorbis mediocre codec, free , clear.

on extreme end, have stations doing streaming in flac. lossless audio quality, you're paying 8x bandwidth medium quality mp3 station. flac on http streaming compatibility not code @ moment, works alright in vlc.

it common support multiple codecs streams. depending on budget, if can't that, you're best off mp3.

finally on encoding, don't go lossy codec lossy codec if can it. try output stream close input possible. if re-encode audio, lose quality every time.

recording browser

you mentioned users streaming browser. built couple years ago web audio api audio captured , encoded , sent off icecast/shoutcast servers. check out here: http://demo.audiopump.co:3000/ brief explanation of how works here: https://stackoverflow.com/a/20850467/362536

anyway, hope helps started.