The biggest pain point with Bucket Brigade has been that you generally wanted to be running a video call in parallel. You kept needing to switch windows, and you needed to remember to mute and unmute in the call at the beginning and end of each song. Solstice used Twilio Video, which packages up WebRTC with server-side support and a developer-friendly API, and I decided to integrate it as well. Now when you join you'll see it ask for camera permissions:

Before showing your video to anyone else, it will ask you whether you are OK with it:

Since I have an external camera with a better angle, I'll press "Switch camera":

Now I'm happy, so I'll choose "Use this camera", but it will also work fine if you choose "Continue without camera".

Once you're in, you'll see all the people in their buckets:

During a song you hear people via Bucket Brigade, and the rest of the time you'll hear people through the video call. Since we aren't doing anything custom for the videos, you'll see people out of sync with their singing. At some point it would be nice to try routing videos through a server we control, so we can add appropriate amounts of latency. Adding latency on the server would not be precise enough for audio, which we need aligned at the millisecond level, but I think it would be ok for video? Of course there's nothing you can do for video for buckets after you...

The hardest part of the integration was getting it to behave correctly around people turning their video on and off. Twilio's recommended approach doesn't turn the camera light off when you turn your video off, which seems broken to me, so I took their not recommended approach of unpublishing video tracks. This changed which events I need to listen to for video being re-enabled, but once I got it all working it seems reliable.

Previously Bucket Brigade was cheap to run: it essentially only needs CPU and bandwidth, and the bottom-tier VPS (~$5/month) that powers can handle about 40 simultaneous users. Twilio calls cost 25¢/person/hour, which is reasonable but not negligible. I'm hoping to keep it free to play with, and if the cost starts adding up we'll probably ask if frequent users could chip in?

Comment via: facebook

New Comment
8 comments, sorted by Click to highlight new comments since:

I just scheduled a Swarthmore sing for 1:30pm EST this Saturday, and plan to give the video portion a try rather than a concurrent Zoom session.

But I also use zoom's screen-share feature to enable everyone to see the sheet music of whatever we're singing at the moment; can you think of any way for me to duplicate that via your server?

Long-term I think the way to do this is to support the leader copy pasting lyrics in, which can be ephemeral, just for the current song. I haven't written that, though.

Another possibility would be to add screenshare support, which I think the video call API I'm using (Twilio) includes.

If I don't get to that between now and Saturday, I guess have a concurrent zoom session that just stays muted? At least then the call support in bucket brigade means you don't need people to be muting and unmuting all the time.

A followup: We tried the server today, with video, with seven people. There were lots of problems where different people weren't shown some other people, just blank white boxes. (Some were close to square, others wide but not high; we suspect the latter were people who had chosen the Don't Show Video option, but the former had opted for video - and in fact could see themselves - but some problem prevented some others from seeing them.) 

One other person got errors saying the video was being used in unsafe ways.


We ended up turning video off and using audio only - which was still quite useful.

And we used zoom to screenshare the PDFs of the sheet music.

Thanks for the update! I'll try to reproduce the problem with the blank boxes. Do you know what browser(s) they were using?

Wide white boxes is what is expected if someone chooses not to show video. Squarish white boxes is not supposed to happen.,

Do you happen to have a screenshot or the text of the error talking about the video being used in unsafe ways? Or any more information that would help me debug that? That's very strange.

I was using Chrome, and saw a few of the large white boxes as well a a few normal videos. I don't know what others were using. 

I've got an email in to Joel asking if he remembers what the alert message he got said. As far as I know he was the only person to get such a warning. But it resulted in his video image looking very unusual -- as seen by him and by everyone else. It was in black and white, twice the height of other boxes, and pulsed/flickered. I'm sorry that I didn't think to take a screenshot...

Joel was running Windows 10 (on a Microsoft Surface). The error he got was


NotReadableError: Could not start video source

Here's the full email he sent me:

Here's the error I got, and was able to recreate it today.
To recreate:

1.  In a Zoom meeting, start the video (so camera is in use)

2.  Go to Bucket Brigade

3.  Calibrate latency and mic volume

4.  Receive the error, and be unable to do anything else on bucket brigade due to the error page being the only available page.

This error was also encountered by successfully calibrating, turning off video on bucket brigade, starting video on zoom, and then attempting to start video again on bucket brigade.

This was avoided by turning off video in Zoom.  Once it was off, the bucket brigade page would load and I could turn off the video there; once that was off, I could turn the video back on in zoom and use bucket brigade normally - just so long as I didn't turn on video there.

I believe that Lane was experiencing the same issue, but Jim seemed to be able to have video in both Zoom and bucket brigade.  [I was. Though I started the BB video before Zoom  -Jim]


It sounds like on some devices maybe only one program can be using the camera at once? If so, I should figure out where exactly that fails and add some sort of "continue without camera" logic.