This may be too broad a question, but how is soundcloud actually programmed?
To be more specific,
What language was used to program it?
How does it display the frequency data?
If user uploads a file in a format different from MP3, is it converted MP3 or gets played as is? If former, how does the conversion work?
How does it "graphically" appear on a browser as it does? Is it also HTML 5 thing which I don't know anything about?
I'm a big fan of the soundcloud and couldn't stop wondering how all of these work!
Please help me out :)
SoundCloud developer here,
The API and the current website are built with Rails. For information about the architecture/infrastructure and how it evolved over the last 5 years, check out Evolution of SoundCloud's Architecture. The "next" version of the website (still in private beta) is built entirely with Javascript, and just uses the API to get its data. There's a lot more detail available in Building The Next SoundCloud.
I'm not sure exactly what language/libraries are used to process the audio, but many audio libraries do provide frequency data, and we just extract that.
Users can upload AIFF, WAVE (WAV), FLAC, OGG, MP2, MP3, AAC, AMR or WMA files. The originals are kept exactly as is for the download option, but for streaming on the site, they're converted to 128kbps MP3 files. Again, I'm not sure of the software/libraries, but I'm pretty sure it'd be ffmpeg.
For displaying the waveforms, on the back-end when the audio files are processed when they're uploaded, the waveform data is saved into a PNG file. On the current version of the website, we simply load that file. On Next, the png is processed to get the original data back out, and then it is drawn to a canvas at the exact dimensions needed (which keeps the image crisp). We're currently experimenting with getting waveform data in a JSON format to speed up this process.
I am copying the following info posted by David Noël somewhere else in 2010.
Web tier: Varnish, nginx, haproxy, thin
Data Management: Cassandra, MongoDB, mySQL master/slave cluster, memcached
Web framework: Ruby on Rails
CDN: Akamai and Edgecast
Transcoding/storage: AWS EC2/S3
Related
I am trying to build a web application which will need to have audio streaming functionality implemented in some way. Just to give you guys some context: It is designed to be a purely auditive experience/game/idkhowtocallit with lots of different sound assets varying in length and thus file size. The sound assets to be provided will consist of ambient sounds, spoken bits of conversation, but also long music sets (up to a couple of hours). Why I think I won't be able to just host these audio files on some server or CDN and serve them from there is, because the sound assets will need to be fetched and played dynamically (depending on user interaction) and as instantly as possible.
Most importantly, consuming larger files (like the music sets and long ambient loops) as a whole doesn't seem to be client-friendly at all to me (used data consumption on mobile networks and client-side memory usage).
Also, without any buffering or streaming mechanism, the client won't be able to start playing these files before they are downloaded completely, right? Which would add the issue of high latencies.
I've tried to do some online research on how to properly implement a good infrastructure to stream bigger audio files to clients on the server side and found HLS and MPEG-DASH. I have some experience with consuming HLS players with web players and if I understand it correctly, I would use some sort of one-time transformation process (on or after file upload) to split up the files into chunks and create the playlist and then just serve these files via HTTP. From what I understand the process should be more or less the same for MPEG-DASH. My issue with these two techniques is that I couldn't really find any documentation on how to implement JavaScript/TypeScript clients (particularly using the Web Audio API) without reinventing the wheel. My best guess would be to use something like hls.js and bind the HLS streams to freshly created audio elements and use these elements to create AudioSources in my Web Audio Graph. How far off am I? I'm trying to get at least an idea of a best practice.
To sum up what I would really appreciate to get some clarity about:
Would HLS or MPEG-DASH really be the way to go or am I missing a more basic chunked file streaming mechanism with good libraries?
How - theoretically - would I go about limiting the amount of chunks downloaded in advance on the client side to save client-side resources, which is one of my biggest concerns?
I was looking into hosting services as well, but figured that most of them are specialized in hosting podcasts (fewer but very large files). Has anyone an opinion about whether I could use these services to host and stream possibly 1000s of files with sizes ranging from very small to rather large?
Thank you so much in advance to everyone who will be bothered with helping me out. Really appreciate it.
Why I think I won't be able to just host these audio files on some server or CDN and serve them from there is, because the sound assets will need to be fetched and played dynamically (depending on user interaction) and as instantly as possible.
Your long running ambient sounds can stream, using a normal HTMLAudioElement. When you play them, there may be a little lag time before they start since they have to begin streaming, but note that the browser will generally prefetch the metadata and maybe even the beginning of the media data.
For short sounds where latency is critical (like one-shot user interaction sound effects), load those into buffers with the Web Audio API for playback. You won't be able to stream them, but they'll play as instantly as you can get.
Most importantly, consuming larger files (like the music sets and long ambient loops) as a whole doesn't seem to be client-friendly at all to me (used data consumption on mobile networks and client-side memory usage).
If you want to play the audio, you naturally have to download that audio. You can't play something you haven't loaded in some way. If you use an audio element, you won't be downloading much more than what is being played. And, that downloading is mostly going to occur on-demand.
Also, without any buffering or streaming mechanism, the client won't be able to start playing these files before they are downloaded completely, right? Which would add the issue of high latencies.
If you use an audio element, the browser takes care of all the buffering and what not for you. You don't have to worry about it.
I've tried to do some online research on how to properly implement a good infrastructure to stream bigger audio files to clients on the server side and found HLS and MPEG-DASH.
If you're only streaming a single bitrate (which for audio is usually fine) and you're not streaming live content, then there's no point to HLS or DASH here.
Would HLS or MPEG-DASH really be the way to go or am I missing a more basic chunked file streaming mechanism with good libraries?
The browser will make ranged HTTP requests to get the data it needs out of the regular static media file. You don't need to do anything special to stream it. Just make sure your server is configured to handle ranged requests... most any should be able to do this right out of the box.
How - theoretically - would I go about limiting the amount of chunks downloaded in advance on the client side to save client-side resources, which is one of my biggest concerns?
The browser does this for you if you use an audio element. Additionally, data saving settings and the detected connectivity speed may impact whether or not the browser pre-fetches. The point is, you don't have to worry about this. You'll only be using what you need.
Just make sure you're compressing your media as efficiently as you can for the required audio quality. Use a good codec like Opus or AAC.
I was looking into hosting services as well, but figured that most of them are specialized in hosting podcasts (fewer but very large files). Has anyone an opinion about whether I could use these services to host and stream possibly 1000s of files with sizes ranging from very small to rather large?
Most any regular HTTP CDN will work just fine.
One final note for you... beware of iOS and Safari. Thanks to Apple's restrictive policies, all browsers under iOS are effectively Safari. Safari is incapable of playing more than one audio element at a time. If you use the Web Audio API you have more flexibility, but the Web Audio API has no real provision for streaming. You can use a media element source node, but this breaks lock screen metadata and outright doesn't work on some older versions of iOS. TL;DR; Safari is all but useless for audio on the web, and Apple's business practices have broken any alternatives.
I've seen using the html5 api it's possible to record/upload video content straight from the browser. This issue in a project I'm currently working on is the video recordings can be very long/big and I'd like to mitigate upload time for the user.
Ideally the video would be uploaded in one of two ways:
As it's being recorded (streaming upload).
For worse network connections, upload the video in smaller chunks (so store locally and then upload a chunk every 5 minutes, let's say).
Does anyone have any guidance on if these could practically work with the current level of html5 functionality and if so, if there any good resources on the subject?
WebRTC based MediaStream Recording (http://www.w3.org/TR/mediastream-recording/) sounds like it is what you are looking for, as Robert suggest in the comments.
There is a Javascript library available on GitHub which looks like it should meet your needs:
https://github.com/streamproc/MediaStreamRecorder
In particular they note:
MediaStreamRecorder is useful in scenarios where you're planning to submit/upload recorded blobs in realtime to the server! You can get blobs after specific time-intervals.
I have thousands of mp3 files in a database and a website that lets people listen to them. I'm using a flash player but want to move to html5 audio player. Does this mean that I need to make ogg and wave versions of all my audio files? What is a good approach to making these files more accessible?
In short, yes you need to support multiple formats. (Assuming you care about decent browser support.)
If you are lacking disk space, don't get a lot of traffic, and don't mind some delay before the data gets to the user, you can convert these on the fly. Just write some code so that on request, it checks the conversion cache to see if you have already converted the file. If not, convert it on the fly (with something like FFMPEG) and write the data to disk at the same time you are writing it to the client.
As Imre pointed out, browser support is changing all the time. Look up what codecs are supported from time to time.
I'm using Windows Azure Media Services to upload videos, I want to know if there is a way to merge several video files into a single file.
If it's impossible, which the best API for video merge effects, I already sent a request to get access to Animoto API, but still no response.
WAMS does not offer that feature/functionality.
You can do that sort of thing with many tools prior to upload, this is considered video editing.
Wams offers a range of platform services: secure uploading, encoding, encryption, streaming, adaptive streaming, dynamic transmuxing, secure egress, with many more features to come.
But video editing is not on the roadmap.
Is there any media player solution that will play audio and video files in Firefox,Chrome, Safari and IE.
I've tried MediaElementJS but it fails on .mov. This project has clients uploading a movie file and there can only be one version of each file. I can programatically change the code for each type of file and the user's OS/browser but I still couldnt get .mov's to download progressively.
What am I missing here? I'm not very familiar with media file types. Just wondering if anyone had any suggestions.
Take a look at the JW Player. It's highly configurable. Best combination is with a real streaming server provider. If you want to let your clients switch to different positions in your media files it might best work that you "normalize" all your different media types to one format (converting them after the upload) - be it .flv/flash - and focus on one player like the above. The files could be streamed with modules from webservers like nginx or lighttpd - but a real provider like Bits on the Run will convert most of the files for you very easily and handle the streaming more reliably.