Smart Party: Song Selection Kevin F. Eustice, Jason Stoops, Peter Reiher, Venkatraman Ramakrishna, Nam Nguyen UCLA

Voting Algorithm Overview (Eustice)‏ Each device nominates a song to be played next A ballot containing metadata of all these songs is sent out to all devices From a pool of points, devices then assign points to each song in ballot proportional to personal preference value associated with song Points are tallied by coordinator and the bottom half of candidates are dropped Process repeats until one song wins!

Point Assignment Matches attempted by devices for point assignment when filling out ballot: 1.Filename match --> points based on song preference 2.Artist, title match --> points based on song preference 3.Artist match --> based on average preference for artist 4.Genre match --> based on average preference for that genre 5.No match --> no points allocated to this candidate Averages for known genres and artists are computed at application startup

Ballot Compilation Logical ballot compilation ensures correct point distribution during vote:  Songs nominated by two different devices --> one ballot entry  Songs with same metadata but different filename -- > one ballot entry  Songs with empty metadata --> separate ballot entries.  Devices can look at history of songs played in room and songs heard by device, and nominate unheard songs. (LASR)‏

Robustness Vote coordination is done by application separate from Smart Party Location Application, or SPLA.  SPLA has had reliable Round Robin song selection algorithm built in since beginning (LASR).  If something goes wrong in voting, SPLA can detect this condition and fails over to Round Robin selection. Smart Party User Device Application, or SPUDA, is selection algorithm agnostic.  simply responds to various requests

Accomplishments for quarter Implement voting algorithm  Learn basics of Panoply framework  Build up side-by-side implementation of voting Initially entirely separate from Smart Party application  Integrate voting into SPUDA  Vote Leader is still separate for future work in Smart Party: Vote coordination may eventually be handled by SPUDAs Vote leader may be chosen dynamically in future

Accomplishments for quarter, cont. Matching for metadata and tracking average preference value for known artists, genres Fail over to Round Robin selection if vote coordinator dies for some reason Generally complete implementation of individual voting song selection for a multi-room Smart Party.

An interesting test Tested voting algorithm with 6 participants  Varied media libraries and preferences  Four people liked various songs by Artist A Not all people had all songs by artist, some had exclusive sets of songs.  Two other people had a CD by another Artist B  Overall, most music fell under Genre A. Result  Songs by Artist A in Genre A played first, then other songs in Genre A.

Satisfaction Of Proposed Goals Satisfied Checkpoint 1: implement voting algorithm in smart party  Algorithm is in use in 3 room demo in LASR lab  Laptops can connect, and party will select songs from users in each room. However, checkpoint 2 has changed significantly...

Next quarter... Checkpoint 2 Formulate user mobility model  How does music affect people moving between rooms in the party?  How does this affect fairness and user satisfaction of song selection algorithms? Investigate media-centric rooms vs. user-centric rooms  Look at ALL music in party vs. music in room  Create rooms based on preference groups “Rock” room, “Jazz” room, “Beatles” room, etc. Devices may suggest a room to user based on prefs

Acknowledgements Venkatraman Ramakrishna, UCLA LASR, for helping and guiding me during this project. Kevin F. Eustice, Nam Nguyen, and Peter Reiher, UCLA LASR