Ever had just one person drop out?


I was listening to one of my jam sessions on ninbot.com today and to my horror I heard that I played my drum track straight on top of someone else's live drumming (my apologies to "rp"). Fortunately for me he gracefully switched instruments and continued without a hitch.

However during the live jam session in Jamtaba I specifically remember seeing that he was not transmitting anything. I had heard drums from his channel for a while but then they stopped for a few minutes (his level meters all dropped to zero), but the other jammer who was playing guitar was still audible on my side.

It was at that point that I decided to hook in my drum track. But again, listening to the final recording on ninbot.com, it seems the drummer was still playing (and the ninbot.com bot could hear him) though I couldn't hear him.

This is the first time (I hope) that this happened to me. I was using Jamtaba. Have you ever seen a similar phenomenon where you can't hear one guy in the room, even though he is still playing, but you can still hear the other guys in the room?

Oops, missed this thread

Oops, missed this thread getting a reply.

Yup, with Torben - use hardwired networking end to end if possible.

It's not like NINJAM is buffered, it's just synchronised, so if your network loses a packet and needs to retransmit and that takes too long, you lose. You can never make that time back - you're in real time.

Your questions:
#1 Tricky to get my head around it; if player A connects just as player B's interval ends but just as player C's interval starts, what happens to what they hear? To what player D hears?

For player D, it will depend on how long before player A's interval arrives. If it's after the start of the previous "latest" interval from B and C, it will sync to the start of the earliest next interval, I'd think.

#2 If you lose sync, I think the server kicks you - that is, if you're trying to send more data that can arrive in the available time, you're doing something wrong.

Ya friendly reminder to use

Ya friendly reminder to use ethernet if you can, and the logging in/out of the room usually helps, but if you're on spotty shared wifi and careless about your bandwidth it can create those kinds of problems..

Thanks for the comment

Thanks for the comment pljones. A few questions if I may:

1. In the ideal case, the audio you hear from all other participants will be delayed by only 1 interval. What causes this delay to increase from 1 interval to 2 intervals? Is it insufficient bandwidth on the upload and/or download side that then forces the receiving client (due to insufficient received data) to delay the audio by one further interval?

2. If the delay between user A's transmission and user B's reception has increased from 1 interval to 2 intervals, and if user A continues to play without ever stopping, is it correct that the lag will never decrease? In other words, as long as A continues transmitting without interruption, the server will without fail continue to transmit all of A's data in sequential order to B (never throwing away any of A's transmitted data), which means that any extra lag that occurs (due to slowness of upload or download) is permanently cumulative, causing B to hear audio that is further and further delayed (by an increasing number of intervals) from A?

3. If my interpretation of #2 is correct, is it (theoretically) possible to inform a receiving client of how many intervals of "lag" exist between each other sending participant? This way, if you see that you are getting farther and farther behind one or more participants, you could log out and log back into the room to "reset" all the buffers/queues/lag and ensure you are closer in sync with the other participants. Or maybe it might even be conceivable to implement a mechanism to "reset" (i.e. discard) the buffers without logging out of the room.

Taking this idea further, it should even be possible to display a real-time updated graph showing how "in sync" each participant is with every other participant. In text form it might look like this:

User A:
- hears B with 1 interval delay
- hears C with 2 intervals delay
- hears D with 1 interval delay

User B:
- hears A with 2 intervals delay
- hears C with 1 interval delay
- hears D with 2 intervals delay

etc.

For example, this way, you can get an idea of how fast your ideas are propagating to other participants, and also how fast others' ideas are propagating to you.

With some more thought you could probably make a nice graphical visualization of this information.

Do you think the ninjam protocol has enough information such that a custom client could show this information?

If you're on one of the

If you're on one of the ninbot servers, "nb levels" tells you the rough level over the last full interval that the bot received (I think only for the "first" channel for clients with multiple channels).

I've not had that disagree with what I hear in ReaNINJAM. But you have to remember, you're hearing intervals at a completely different time from the bot, earlier or later. (And, of course, at a different time from everyone else.)

So you might be hearing silence - even for several intervals - but the bot claims it heard sound. It might be one or more intervals ahead of you or behind you. And the opposite is, of course, true, too.

---
...But how do you play with people, for people. Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world. -- Tony Williams

That happens sometimes. I

That happens sometimes. I think it's related with internet bandwidth.



    © 2013 ninbot.com All rights reserved