C#: Streaming an Audio file from a Server to a Client

Question

I am currently writing an application that will allow a user to install some form of an application (maybe a Windows Service) that will open a port on it's PC and given a particular destination on the hard disk, will then be able to stream mp3 files.

I will then have another application that will connect to the server (being the user's pc) and be able to browse the hosted data by connecting to that PC (remotely ofcourse) given the port, and stream mp3 files from the server to the application

---

I have found some tutorials online but most of them are about File Servers in C# and they download allow you to download a whole file. What I want is to stream an mp3 file so that it starts playing when a certain number of bytes are download (ie, whilst it is being buffered)

---

How do I go about in accomplishing such a task? What I need to know specifically is how to write this application (that I will turn into a Windows Service later on) that will listen on a specified port a stream files, so that I can then access the files by something of the sort: http://<serverip>:65000/acdc/wholelottarosie.mp3 and hopefully be able to stream that file in a WPF MediaPlayer.

---

[Update]

I was following this tutorial about building a file server and sending the file from the server to the client. Is what I have to do something of the sort?

[Update]

Currently reading this post: Play Audio from a Stream using C# and I think it looks very promising as to how I can play streamed files; but I still don't know how I can actually stream the files from the server.

Solution 1

There is no effective difference between streaming and downloading. They're the same thing. Any difference is purely semantic.

If you wanted to, you could "download" an MP3 from any web server and start playing it while you were downloading it. It just requires that you buffer some of the data and start sending it to your decoding and playback routines right away.

Similarly, even so called "streaming" servers can be downloaded. You just have to save the bytes as they are being sent across the wire to a file.

"Streaming" applications are just apps that are not designed to save the files to disk.

EDIT:

There is an exception. Two really:

First, if you are streaming "live" audio, such as radio or other types where you don't need 100% reliability, then they stream using UDP. This can still be saved if you want, but it's more packet oriented than stream oriented.

The second is when encryption is used, in which case you can still probably save the file, but it would be useless without the encryption algorithm and keys.

Solution 2

This is simply not true.

The difference between a file download and an HTTP multimedia stream is the encoding header, which is set to chunked encoding for a stream. In addition, a file download has a Content-Length header, so the recipient system can know the file size in advance.

There is no Content-Length header with a multimedia stream, therefore there is no expected end point. Rather, just a continual series of chunks of data are received and processed, for as long as they continue to appear.

Comments

[Rick Rat]

You can stream from IIS or use "Cassini" server to write your own. It's not hard to do. Plop them in a folder on the website. Just remember that spaces are either %20 or + in web stuff. like server/john%20Cougar%20Mellencamp.mp3 or server/john+Cougar+Mellencamp.mp3

[Erik Funkenbusch]

I think you're assuming that "streaming" means live, never ending content. That's not necessarily true. Pandora, for instance, streams individual files, as do other music services. Videos are often "streamed" but have definite end and start points. Stream refers to the act of playing a file as it is being transmitted, not that it is a neverending stream of data.

[Brian]

@MystereMan - There may be a disconnect between Fred's answer and your interpretation. He isn't suggesting that the stream cannot have a defined endpoint, but rather that the client is never made aware of where that endpoint will be until it arrives there. As far as its concerned, it could go on endlessly.