Virtual Jamming: Effects of Network Lag on Approaches to Online Music Collaboration

Virtual Jamming:  Effects of Network Lag on Approaches to Online Music  Collaboration           

Akash Puthraya  24 March 2014         

  Abstract:   In  this  age  of  rapid  globalization,  collaborations  are  being  spawned  by  every  field  of  work.  However,  real­time  applications  requiring  high  fidelity  and  low  lag,  like  online  music  collaboration,  are  hindered  by limitations on transmission speed, and transmission quality. Such  challenges  have  given  rise  to  some  very  interesting  approaches  to  this  task,  which  this  paper  aims to analyze.  1. Introduction  Throughout  the  history  of  computer  networks,  and  especially  after  the  advent  of  real­time  voice  communication  over  such  networks,  the  mitigation  of  network lag has been one of the key  areas  of  research.   Limits  on  bandwidth  contribute greatly to network lag [2]. However, it is safe  to  say  that  in  today’s  networks,  the  severity  of  this  lag  has  been  made  negligible  for  most  practical purposes. For example, provided that our internet connectivity is fast and stable enough,  we  are  now  able  to  speak  with  our  teammates  as  we  game,  make  phone  calls  over  the  internet  experiencing  minimal  glitch,  and  conduct  video  conferences  with  multiple  participants  and  multiple  capabilities  without  really  letting  the  effect  of  network  lag  affect  the  coherence  of  our  meetings.    However,  there  are  always  niches  that  remain  untouched.  One  such  niche  is  real­time music  collaboration  over  the  internet.  Jamming,  a  term  frequently  used  in  the  music  industry,  refers to  collaborative  improvisation  by  a  group  of  musicians.  The  ideal  online  music  jamming  session  demands  high  (infinite)  fidelity  and  low  (zero)  network  lag.  This  presents  us  with  a  paradox  of  sorts.  The  User  Datagram  Protocol  (UDP)  works  well  when  fidelity  is  not  a  primary  criterion.  Video  and  audio  chats  online  allow  for  the  random  packet  loss  here  and  there.  Also,  it  is  ok  to  wait  a  few  milliseconds  for  the  voice  to  reach  us  from  the  other  end.  Conversations  are  able  to 

afford  this  callousness  online,  but  unfortunately,  jamming  does  not  allow  for  such luxuries. The  Transmission  Control  Protocol  (TCP),  on  the  other  hand,  increases  delay,  although  it  provides  minimal  packet  loss.  So,  this  leaves  us  with  a  real­world  application  that  holds  considerable  business potential, but is also error­sensitive and delay­sensitive at the same time.    This  paper  discusses  how  three  major  innovators  in  the  nascent  stage  of  online  music  collaboration  ­  Musigy,  NINJAM  and  eJamming,  endeavored  to  overcome  this  challenge  by  adopting  essentially  different  methods,  giving  rise  to  various  innovative  approaches  to  the  business of online music collaboration.     This  paper  contains  five  sections  including  the  introduction.  Section  2  discusses  the  challenges  that  the  presence  of  network  lag  throws  at  application designers. The fixes employed  by  these  companies,  based  on  hardware,  software  and  musical  concepts,  shall  be  discussed  in  Section  3.  In  Section  4,  the  business  impacts of network lag is discussed. Conclusions are drawn  in Section 5.  

2. Challenges  As  discussed  in  section  1,  lag  in  communication  networks  presents  a  variety  of  challenges, without overcoming which jamming on the internet would be rendered impossible.   Telephonic  communications  are  generally  able  to  withstand  lags  of  up  to  200  ms  ­  300  ms.  Beyond  this  range  of  lags,  communication  might  not  be  coherent.  However,  for  jamming  sessions  with  multiple  participants,  this  limit  on  lag  is  not  feasible.  It has been observed that for 

successful  collaboration  between  musicians,  the  lag  needs  to  be  limited  to  a maximum of 50 ms  [1].    Let  us  assume  the  speed  of  light through the fiber optic cable to be the major factor affecting  the  lag.  Assuming  the  fiber’s  refractive  index,  n  to be 1.54, we get the speed of light through the  fiber  to  be  v  =  c/n  (where  c  =  3x108  m/s).  This gives v = 195 km/ms. Assuming a lag margin of  20%,  we  can  see  that  for  a  transmission  delay  of  50  ms,  we  may  transmit  a  total  of  195  x  50  x  (1­0.2) ≈ 8000 km [1].    However,  the  speed  of  electricity  through transmission equipment is considerably lesser than  that  of  light  through  glass,  and  depends  on  various  factors  such  as  the  current,  the  area  of  cross  section  of  the  conductor  and  the  charge  flowing  through  the  cross  section.  Moreover,  these  signals  are  subjected  to  processing  at  every  router.  This  introduces additional delays. In order to  still  maintain  a  network  lag  of  less  than  50  ms  with  all  of  the  aforementioned  impediments,  the  range of transmission is cut down from 8000 km to 3200 km [1].    Stan  Vonog  from Musigy, in September 2006, exhibited the abilities of his team’s solution to  the  problem  of  network  lag,  through  an  event  called  Jazz  @  the  Speed  of  Light.  In  this  event,  performers  from  Russia,  Ukraine,  and  the  UK  jammed  with  each  other  in  real­time  using  Musigy’s  software, across a distance of 2600 km [1], which is still lesser than the estimated 3200  km.   

As  for  eJamming,  founder  Alan  Jay  Glueckman  sets  the  range  of  acceptable  lag  time  from  15  ms  ­  20 ms. At this range, the range of acceptable distance for physical separation of the  participants is from 320 km ­ 800 km [1].   

3. Solutions  The  purpose  of  this  paper  being  the  discussion  of  the  solutions  employed  by  the  three  chosen  incumbents,  viz.  Musigy,  eJamming  and NINJAM, this section will be discussed in three  parts.  i. Musigy  Musigy  employs a combination of four tactics to overcome lag. These may be summarized as  follows [1]:  a.  An  incoming  packet  containing  at  least  one  bit  of  the  audio  signal  belonging  to  the  application  is  directly  sent  to  the  audio  card,  bypassing  the  microprocessor’s  queue.  This  eliminates queuing delay, which contributes significantly to the lag.  b.  The  codec  used  by  the  application uses an algorithm for coding and decoding that is faster  than  the  standard  MP3  algorithm  by  a  factor  of  10.  This  algorithm  introduces  a  delay  of  10 ms.  With  a  goal  of  achieving a lag of less than 50 ms, this leaves a window of 40 ms (50 ms ­ 10 ms)  to accommodate all other delays.  c.  In  the  event that a bit sequence from the audio signal is missing, the application waits for a  fixed  amount  of  time,  and  extrapolates  this  missing  sequence  based  on  the  median  value  of  previously received packets. 

d.  At  the  beginning  of  a  jam  session,  the  application  conducts  a  “weather  forecast”  by  gauging  the  standard  lags  between  the participants. The result of this forecast is used to optimize  the settings for each participant.  ii. eJamming  Understandably,  eJamming  works  with  UDP  [5]  in  order  to push maximum data through the  network. It employs a three­pronged solution to alleviate the effects of network lag:  a.  eJamming  uses  a  codec  developed  in­house,  based  on  the  MIDI  compression  standard,  in  order  to  achieve  compression  in  the order of 10 3 . This means that a file taking up megabytes will  be  compressed  to  a  few  kilobytes.  Despite  the  high  compression  ratio,  the  quality  of  sound  is  maintained at a level higher than the usual MP3 files [1], [2].  b.  Participants  in  the  jam  session  are  connected  directly  to  each  other,  instead  of connecting  to  a  server.  This  peer­to­peer  architecture  introduces  just  half  the  network  lag  that  client­server  architecture  would,  since  the  information  from  each  participant  goes  directly  to  every  other  participant,  instead  of  to a server. This technique eliminates both unnecessary transmission delay  and processing delay.   c.  Like  other  similar  technologies  such  as  IP  telephony  and  video  conferencing,  online  jamming  requires  synchronous  communication.  For  this  reason,  the  audio  stream  from  each  of  the  participants  is  “time­stamped”  to  the order of milliseconds, which enables the clocks on each  of  the  hosts  to  be  synchronized.  This  ensures  that  all  the  participants  are  keeping  time.  This  is  important  because  the  music  played  by  each of the participants is played back after a delay of 30  to 100 ms [2].  iii. NINJAM 

NINJAM  overcomes  the  effect  of  network  lag  by  accepting  and  utilizing  it.  Each  participant  is intentionally lagged by exactly one bar [1]. The aim of this technique is to create an  audio  track,  similar  to  a  canon.  A  canon  is  a  musical  piece  in  which  a  certain  tune  begins  at  different  points  in  time,  in  succession  (the  quickness  of  which  is  at  the  discretion  of  the  musicians),  with  the  intended  effect  provided  by  the  overlap  of  these  successions.  Like  eJamming,  since  the  music  heard  by  the  participants  is  recorded and played back, this technique  cannot  be  considered  real­time  [2].  NINJAM  works  with  TCP  over  port  #2049  [6].  This  is  a  sensible  decision  since  the  approach  here  is  not  to  fight  network  lag.  Since  the  aim  is  not  to  minimize  the  delay,  emphasis  may  be  laid  on  receiving  all  the  transmitted packets correctly, the  result being better tracks of higher quality.   

  Figure 3.1: Sheet music for “Row, row, row your boat” played by three players on NINJAM [4] 

  The  initiator  of  the  jam  session  specifies  the  beats  per  minute  and  the  beats  per measure  through  the  software  interface,  based  on  which  a  metronome  track  runs  in  the  background  [1],  for  the  purpose  of  perceived  synchronicity.  Since  each  user  hears  different  audio  tracks,  this  technique is not synchronous. 

4. Business Impacts  Research from the Stanford University’s Center for Computer Research in Music and  Acoustics has resulted in software that works on an extremely high­bandwidth network, called  Internet2 [2]. Owing to the near absence of bandwidth limits, the jamming experience over this  network is nearly lag­free. However, Internet2 is available only to research staff, and has not  been deployed as a consumer network. Hence, in applications outside research circles, varied  approaches have been used by the incumbent software to tackle network lag. This has given rise  to varied business models.   Musigy’s Stan Vonog advocated a two­tier pricing scheme to market its services. Its  basic jamming and recording services were intended to be free of cost. However, its  effectiveness in reducing lag enabled it to conduct live concerts. This service would attract a  premium charge. Apart from this, uploading the recordings of rehearsals on the website would  also be a charged service, understandably due to the storage space that Musigy would have to  pay for [1]. Musigy works with a latency of about 50 ms. For a pace of 120 beats per minute, this  translates into a significant loss of 10% of each beat [120 beats/60 seconds*50 ms = 0.1 beats].  Therefore, Musigy can be satisfactorily used only for slow­paced jams.    With the introduction of its AUDiiO package, eJamming gained the ability to have 16  MIDI links and eight other regular audio tracks [1]. This is in accordance with the fact that MIDI  files may contain up to 16 different tracks. This property of General MIDI [3] translates into  participants using 16 different hosts to jam with low­bandwidth tracks in addition to eight 

high­bandwidth tracks. Following the footsteps of NINJAM, eJamming also expressed interest in  delving into social media and virtual world applications like Second Life, where the players can  create online personas for themselves and jam at the same time. eJamming faces the uphill task  of winning over the users of its archrival, NINJAM. Loyalists have a strong affinity to NINJAM,  owing to its price, ease of customizing, and primarily, the opportunity to contribute to the  development of the application. Moreover, the music being played by the musicians can only be  heard to them with a delay of 30 ms ­ 100 ms [2], which takes a lot of practice in order to adjust  to.    NINJAM has been available on Second Life since before July 2007. It is open source and  free to use, and this makes it highly popular. NINJAM’s user base is said to be fiercely loyal to  the platform [2]. NINJAM makes its purpose clear. Since the players are delayed by a bar each,  the application can be used only for improvisation and experimental music [1], true to the spirit  of jamming. It does not allow for jamming already conceived music. It is not suited for highly  frequent changes in riffs or frequent tempo changes. 

5. Conclusion  Musigy  fought  lag  by  cutting  down  on  the  incremental  delays  that  exist  in  the  network.  As  of  today,  Musigy  ceases  to  exist.  eJamming  fought  lag  by  compressing  its  data  as  much  as  possible.  eJamming,  although  still  active,  has  neither made news, nor any updates to its products  since  2010.  NINJAM  did  not fight the lag, but embraced it. Today, NINJAM is still going strong  with  its  services  as both a desktop application, and also as part of Second Life. This might not be 

surprising  considering  the  general  move  in  the  software  industry  towards  open  source  and  freeware.  However,  the  success  of  NINJAM  and  the  loyalty  of  its  customers  lie  in  the  fact  that  NINJAM  remains  least  prone  to  the  ill  effects  of  network lag. Therefore, the best solution to the  problem  of  network  lag,  apart  from  the  obvious  elimination  of  delay,  is  to  utilize it to the user’s  advantage. 

 

 

 

6. References  [1] M. Anderson, “Virtual Jamming”, IEEE Spectr., vol.44, no.7, pp 53­56, Jul. 2007  [2] K. Greene. “Jam Online in Real­Time.” Internet:  http://www.technologyreview.com/news/407965/jam­online­in­real­time/ , May. 25, 2007 [Sep.  19, 2013]  [3] H. Jeffrey. "Introduction to Computer Music: Volume One." Internet:  http://www.indiana.edu/~emusic/etext/MIDI/chapter3_MIDI10.shtml  [Mar. 17, 2014]  [4] H.Leonard. “Row, Row, Row Your Boat Sheet Music.” Internet:  http://www.onlinesheetmusic.com/row­row­row­your­boat­p386915.aspx  [Mar. 17, 2014]   [5] J. Bauer. “Welcome eJAMMING Customers ­ eJAMMING AUDiiO” Internet:  http://portforward.com/ejamming/  [Mar. 17, 2014] 

[6] Cockos Incorporated. “NINJAM Server Setup Guide” Internet:  http://www.cockos.com/ninjam/server­guide.php  [Mar.17, 2014]