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...
I like the concept, but it needs work.
Most have phones, but not everyone. to be blunt and use trigger words: privileged people have phones.
I don't want to give priority to people with phones. If anything, I would de-prioritize them. People who walk up to a mic come first. I think. I can't see how to shuffle the two fairly.
Instead of holding up and being called on, the app can give your place in the queue, when it hits 0, you are live and should stand up and start talking.
I think the person operating the audio mixer would be charged with clicking "next" to bring up the next person in the queue. No idea what machine/app.whatever they would click on, but they would need something to connect the audio to, and they would be the one's adjusting levels, so seems like the logical choice.
--