Implementing Live Music Streams in to HiFi Domains


#1

Just looking to flesh out a discussion on the topic of streaming Music (not voice chat) through domains to the domain visitors as @Judas and I kind of touched on it in another thread.

For those who used SL, you will be aware of the feature to stream audio directly to your viewer (which is essential for live music, playing shoutcast streams etc)

In theory it shouldn’t be hard to do in terms of the Interface and Server model…

  1. Server receives an instruction to change the audio stream in either the entire domain, or (future proof) a sub-section/parcel/
  2. Server sends message to all those inside domain to adjust audio stream source subsequently.
  3. Interface connects to stream (MP3, OGG) and feeds it through the audio driver of the end-user’s computer.

Hosting a Shoutcast/Icecast server of course is another topic that is separate to High Fidelity altogether.

Thoughts/Suggestions on how best to implement this? Even from a programming perspective it should be relatively easy to put as it wouldn’t really affect the core code apart from the GUI where a feature to start/stop should be added.


Summary of Specification

  • Provide ability to stream and play multiple formats (i.e. Ogg, FLAC, Wave) - which most audio SDKs (i.e. FMOD) provide the ability to do regardless. This allows for multiple sources of audio (Icecast etc)
  • End-User must be able to enable/disable the music stream, either in the form of a Menu Item, or a Tool bar Icon.
  • Stream source to be determined by the server, and in future, be controlled by scripts (when permission system becomes available to ensure only authorised entities [owned by the server admin?] can adjust the source).
  • Ability (future proof) to have different streams for different zones.

Design Model Proposal

Domain Stack Control Panel Option


Implementing in to Interface Source (Example using FMOD as the sound API)

To explore an example of how it could be implemented programmatically, if we take FMOD as an example API for the audio (since FMOD is amazing, and can handle playing streams from remote sources natively);

You would essentially only have to wrap the FMOD native methods to interface it with the rest of the interface;


#2

Shoutcast is an option, but the default voice in hifi is 16 bit 48 so higher than cd quality so were also trying to think outside of the box.
My own thought is that shoutcasting with sam or winamp its kinda complicated id love a solution that anyone could use and use legally. My first thought was if we could play music already hosted online from maybe youtube or spotify and people in world would hear it synchronized. @KevinMThomas has been messing with the domain audio settings which are kinda interesting in that u can in essence set up locations to act as microphones so you can be heard domain wide from specific locations , kinda like in an amphitheater.
re audio format I think we should Look at FLAC its lossless its open source its smaller than a wav and unlike mp3 doesn’t sound like shit.


#3

I believe the focus for this should be on Icecast, mainly because of shoutcasts strange new business policies. No one likes enforced ads.


#4

ShoutCast is a tried and tested method, and with the licensing to the HiFi sourcecode, implementing a LAME decoder wouldn’t cause any issues;

Icecast is another alternative as it streams Ogg Vorbis (which is completely free of licensing restriction, and can offer the same quality at a lower bandwidth)

Consider if you have an Icecast server running on your server which can easily serve 50+ people with a 160kpbs (the standard I have always used for my SL club) then it wouldn’t matter what HiFi voice limitations are… Purely because the interface would only have to say to a component running inside it to connect to -insert stream here- and stream the audio, much like VLC or Windows Media Player would do.


#5

Flac is not an option, the bandwidth required would eat you alive. I speak from experience here, i help manage a rather big radio station.


#6

Yeah, FLAC would be the end-all to any server trying to serve people. 160kbps x 50 clients = 8mbps, which is nothing if you have a gigabit connection, and honestly? you wouldn’t be able to tell the different unless you have a sound studio sporting M-Audio Audiophiles, or whatever (I personally use Audiophiles and 160kbps is enough to give me shivers when a Markus Schulz track comes on)


#7

Flac would use less bandwidth than the current audio solution.Butttt. i believe the final audio solution is going to be some kind of cascaded system sharing the load amongst everyone which would be really cool @philip would be the person to ask


#8

How could a lossless codec use less bandwidth then a compressed one, exactly ?


#9

MP3 (320 kbps) – average size: 150mb to 200mb per album
CD Quality FLAC (16-bit / 44.1k) – average size: 250mb to 450mb per album.

MP3 (160kbps) - average size: 75 - 100mb per album.

Bare in mind CD Quality usually stands around the 128kbps mark. So, 160kbps is superior to CD quality, and you’re looking at almost 75% reduction in bandwidth required to stream.


#10

contentious reply - Music is an advert.
@KevinMThomas got shoutcast working but only on a mac the solution didnt happen in windows…
I’m desperate to just sit back and hear some tunes in world . Whats good is that potentially we can have all these solutions.


#11

re flac you can compress music losslessly
http://dsd-guide.com/size-comparison-chart-various-formats-dsd-wav-flac-mp3

Hifis sound is uncompressed 16 bit 48 so the same audio quality would be achievable the hit would be in latency through the codec.


#12

I can assure you that the ratio of noticable quality to size with FLAC would not be a viable solution for streaming audio, hence why Shoutcast/Icecast transcode the streams in either MP3 or Ogg Vorbis. The idea of being able to stream in FLAC to clients is a wet dream for me personally, but sadly one without a realistic payoff.

(Based on years of experience using servers to stream audio to clients, being a music producer/geek with a knowledge of the file formats used to store audio)


#13

Compression =/= Lossless.

If you compress it is no longer lossless. Which begs the question of why flac and not ogg, which is a format that is designed to be compressed.


#14

This is going to end up in one of those arguments where we start going "no u"
lossless storage. Lossless compression is a compression format where the un compressed file is identical to the original wav file going in.Its why us sad audiophiles buy 24 bit flacs from hdtracks.com, hangs his head in shame :stuck_out_tongue:


#15

How about a compromise then, have the proposed audio player component on the Interface be able to support Ogg/Wave/Flac (as most players tend to do) , that way it’s entirely up to the party who operates the audio distribution server (i.e. Shoutcast) to determine how the stream is transcoded.


#16

There is no “Lossless compression” there is only compression or lossless. As soon as you compress something it HAS to lose quality, because the way audio compression works is mostly by cutting away frequencies you can not hear or that you can not hear well, which is why higher compressions sound like dipping the audio into an acid bath: More and more frequencies disappear, leaving behind a rather ugly mass of leftovers at some point.


#17

To draw a line under the discussion of Formats to support, I’ve added this to the thread summary (on initial post)

Provide ability to stream and play multiple formats (i.e. Ogg, FLAC, Wave) - which most audio SDKs (i.e. FMOD) provide the ability to do regardless. This allows for multiple sources of audio (Icecast etc)


#18

Could the source from say mplayer be used as a client side player? it’s open source, cross-platform and supports a lot of codecs, and can be used as a backend/no-gui, so would work well as a built in player and already supports all the aforementioned codecs and then some. or if anyone has a better player solution in mind :smile:

As for the bandwith, in my experience (literally) a 256kbps MP3 stream will consume up to 260Kbps with overhead included.

edit: also a side note, you have to consider whats supported by the streamers/encoders that are already in wide spread use, and FLAC has virtually no support in terms of encoding software, my setup might be considered more advanced than the average joe using SAMBC or Winamp, but the only options I have are OGG/A and MP3 :expressionless: .


#19

mplayer is an option, but isn’t vlclib more widely supported ?


#20

VLC is another option i guess, though from a coding standpoint im not sure how more or less difficult that would be to implement in to the interface.