On 31/01/19 19:13, Adam Dane wrote: > Mr. Simpkins, > > I'm a Debian user and occasional watcher of conference videos. One thing > I've noticed is that during Q&A at the end of a talk, there's often a > problem with microphones. Either there aren't any (and we hope the > presenter repeats the question), or there are runners to bring them to > people which delays the Q&A, or there are standing microphones that > people queue up for. > > But it's 2019, and most people have a radio-transmitting microphone > right in their pocket: a mobile! If there would be a way to let audience > members use their phones to ask questions, it could make the operation > much simpler and smoother. > > Anyway, that's the idea. It would take a bit of work to do, but it seems > plausible. The basic design in my head follows, but I don't really know > if it's the best way. > > 1. User has an app installed that connects to a channel for the talk, > and they can queue to ask questions at the end. > 2. At the end, the app assigns a color to each queued person. They hold > their mobiles up so the speaker can see them, and the speaker can call > on them by color. > 3. When called on, the app turns the mic on and transmits the audio to > the audio system, so it can be played over the PA and recorded on the > video. > > I'm not sure how you prevent audio feedback, but I assume that there's a > way to do that, since regular wireless microphones don't have feedback > if configured correctly. > > Thanks for your work on Debian, and for your work on Debconf, > > Adam Dane >
Hi Adam, I have copied this to the video team mailing list for other people to potentially respond as well. First of all thanks for the email. It is always good to know that there are people watching the videos. You may or may not be aware that there is an IRC channel for each talk room available for Live Q&A, however that is text only. This works for people outside the venue as well as inside, and typically questions are verbally asked by whoever is operating video equipment at the back of the room... As you have already noticed people have a tenancy to just shout out a question - I am afraid I very much doubt that having an app on a phone will cause them to wait for their turn either :-) On several occasions we have tried to get people to queue up in front of a microphone in order to ask a question - this ensures that there is both a microphone correctly set up, in position and a camera to record the question. Unfortunately we found that this puts a lot of people off from asking their question in the first place. That said your idea of using a phone's mic could speed up the time waiting for a mic 'runner'... I am not sure that the holding up of phones with colours would help much - are you suggestion that the colour would make it easier to identify the location of the person asking the question? In any case I would be willing to trial the idea and see if it works. I do foresee some problems with your proposal (listed below) but instead of simply dismissing your suggestion out of hand would you be willing to put together a demonstration? There would be no need to put together a finished product - just a proof of concept that reliably works on a small WiFi network containing just your phone, a WiFi access point, and a PC with wired connection to the AP to act as the server (and any user interface you might need to 'drive the demo). Best Regards /Andy #1 A mobile phone app - typically this would mean Android or iPhone. We like to eat our own dog food so would be looking for this to run on a Debian system. Perhaps a website using web RTC could be a good solution we wouldn't even need to write an app specific for different phones. The user could simply point their phone's web browser at the desired website (and authorise the use of their microphone). #2 WebRTC is probably good enough inside the talk room itself (although in a busy presentation we may struggle for WiFi bandwidth). Outside of the talk room we may struggle with latency - when watching a 'live' stream there is often as much as 40s delay between real time and the output buffer from a *local* video stream server. This is delay is typically caused by buffering at the video mixer, the end client machine as well as a small delay during transcoding. For this reason alone it may be best to limit participation to within the talk room. #3 Finally integration. We would need some mechanism to integrate into our existing work flow. This may be quite a complex task in itself. but let us ignore how to resolve this issue pending on a successful proof of concept demo...
