RFC: Split Music Player Into Separate Machine

[zachreizner]

This is related to implementing #13 and #15. I propose that we write a thin client that connects to the main server and identifies itself as, for example, room 1404. The server would then respond to the client the item to play along with a url for it. The client would then play the item as well as drive the display for playing YouTube or album art. The backend would keep multiple queues, one for each client. The backend/client connection would persist for playback control purposes, but the client would determine when a song has completed and the queue should be advanced.

Advantage to this architecture is that this would make the playback devices very cheap allowing many instances i.e. rooms. The users would be connecting to the ACM servers which are powerful enough to handle multiple concurrent users. This means a smoother web experience for users. Taking the user traffic away from the playback devices prevents awful sound glitches that happen on heavily loaded machines. The downside is that this complicates the architecture of the project and would likely increase latency of the whole system.

TL;DR
Thin music/video playback device that connects to server to play songs from the queue for a room

Side Note
This change also has the unrelated advantage of allowing adhoc rooms using somebody's laptop as a playback device, perhaps connected to the speakers of room 2405. I'm pretty sure something like this already exists, but it would be nice to unify the web interfaces and music libraries.

Any comments? @CJS7070 for network purposes. @kevinwang for design considerations.

[calvin-shirley]

So right now the traffic is hitting our main load balancer/proxy (www-s.acm.uiuc.edu) and then all traffic destined to /beats/1104/ is sent to the player directly (also redirected to SSL as appropriate). If we continue the current model to run the full-featured player, we'd add a similar directive for traffic going to /beats/1106/ etc.

I'd like to continue to proxy all of the traffic through our load balancer (instead of having a direct link) -- though we can change the URL patterns and destinations as need be. Lots of benefits to doing this, like SSL and being able to add/remove/change the player infrastructure with minimal impact.

[colegleason]

I don't think this would actually be a problem since we can still server
the player from beats/1104 and then it just uses javascript to load the
media stream, correct?

On Sat, Aug 30, 2014 at 4:55 PM, CJS7070 notifications@github.com wrote:

So right now the traffic is hitting our main load balancer/proxy (
www-s.acm.uiuc.edu) and then all traffic destined to /beats/1104/ is sent
to the player directly (also redirected to SSL as appropriate). If we
continue the current model to run the full-featured player, we'd add a
similar directive for traffic going to /beats/1106/ etc.

I'd like to continue to proxy all of the traffic through our load balancer
(instead of having a direct link) -- though we can change the URL patterns
and destinations as need be. Lots of benefits to doing this, like SSL and
being able to add/remove/change the player infrastructure with minimal
impact.

—
Reply to this email directly or view it on GitHub
#20 (comment).

Cole Gleason
Chair, Association for Computing Machinery
Student, University of Illinois at Urbana-Champaign
Computer Science, Class of 2015
cg@colegleason.com | colegleason.com

[zachreizner]

The way I imagined this system working would be to have only one public facing /beats/ plus associated API endpoints. acoustics2web would have some kind of room selector for queues, voting, and player control purposes.

[calvin-shirley]

So I included the /1104/ in the link because everything is currently standalone, and I imagined we would be running a separate instance for 1106.

Using one single interface for all rooms is fine, but I'd like to keep the URL structure intact (eg. going to /beats/1106/ should take them to the 1106 player interface... doing this via redirect and comparing the URL is fine but I just don't want to break the links people might be using).