Note: You can propose changes using the forum below.
A headless daemon facilitating lossless webradio broadcasts originating from either studio or live event sites.Change History:
Project goals / features (In order of priority):
1. The app is to be headless.
2. The server(s) will cluster and loadbalance between themselves to accomodate high load.
3. The cluster will accept and broadcast a live feed from a show site.
4. The preferred audio format for the stream is .flac, however a sub-project which introduces a new, more suitable lossless format to the industry is acceptable, however it would be preferable to not have to undertake such an effort.
5. The app will be written to take advantage of paralellism, such that it can be set to utilize a set number of CPU cores, as defined during installation.
6. The server(s) need to be able to create and play a playlist whose files are located on multiple SMB shares.
6a. This since the pool of files from which the server will be choosing files to play will one day exceed 2TB easily, and as such will likely be distributed across multiple file servers.
7. The server plays multiple playlists, and treats a playlist as if it were a file in a larger, overall sequence of what gets played. Each playlist will contain its own specification as to whether it plays itself in order or at random, before moving on to the next playlist in the sequence.
7a. For example, 'Playlist 1' contains a list of files, and specifies that these files will be played in order before the playlist exits and the system moves on to 'Playlist 2', which specifies that its list of files be played at random, once each, before the system moves on to 'Playlist 3', which has its own parameters.
8. Each file in a playlist will have a parameter to define whether it has a gap of (definable x.xx) seconds at the beginning &/or end of the file.
9. There will be two primary streams offered to listeners, the lossless stream, and another .mp3 stream broadcasting at a slightly above average bitrate.
9a. This so that listeners can experience the contrast between the lossy & lossless audio, and so that a live spectral analysis visualization can be featured on the website, allowing users to see what's missing from the lossy stream.
An added benefit of offering a simultaneous .mp3 stream is that the station can then qualify to be listed on popular webradio directories, and will presumably draw the attention of audiophiles, and highlight the lossless mission of the station by featuring a show whose title includes the word 'lossless' on a directory whose content is all lossy.
10. The server will provide a secondary stream in the .aac format, suitable for use on mobile devices such as Blackberry, which will be able to play the stream in the browser, such as what SomaFM provides.
11. The app will produce a realtime spectral analysis visualization contrasting the lossy & lossless streams, which will be featured on the website in order for users to see the difference between the frequency response in each of the 2 primary streams.
12. The spectral analysis will do it's thing preferably without the use of client-side scripting such as java or flash.
12a. This so people such as myself who use NoScript won't have to create exceptions to use the site, and so browsers not supporting scripting can display the page- not to mention that it'll facilitate super-quick page loads.
13. A feature to make whatever's currently playing fade out at a prespecified time, and begin a certain playlist.
13a. This so that the day's programming can be going on as normal, and a featured event, be it a certain recording, or a live show's feed can be begun at a previously advertised time.
14. The app will be written to run in a Debian environment, and there will be a software repo created that's fit for inclusion in a Debian distribution, based on their standards.
15. There will be a .deb package created that's installable with dpkg which will automate the installation of the repo and its GPG keys so users can easily install the app with package managers such as Synaptic.
16. A listener queue so people who want to listen can be placed in line during periods when the available bandwidth is already in use by other listeners.