Desktop Conferencing

Last Wednesday saw the second of our Megameeting-delivered ‘Coffee Break’ sessions.

The subject matter was very interesting once again – ‘How can I use Moodle for Diagnostic Assessment’ by Kevin Renfrew (for further info on this topic, see the case study at: http://blogs.bath.ac.uk/casestudies/2009/01/21/using-the-moodle-quiz-for-diagnostic-assessment/). Its nice as a behind-the-scenes developer to see another example of Moodle’s potential being realised so effectively at Bath.

Technically, things were adequate for participants – the sound could have been better (which was most likely down to microphone issues in this instance). The format of the meeting seemed to work well, with participants asking some questions via text chat afterwards and a supporting Moodle resource being created for further discussion.

Unfortunately we had problems with recording of the session – Camtasia on the host machine was unable to capture sound and the deskshare application provided by MegaMeeting, installed on a participant laptop suffered very poor sound quality.

These issues may have occured for a number of reasons and are unlikely to have been due to the MegaMeeting application itself (especially in the latter case). We did discover and try to solve these an hour or so before the session started but had to admit defeat due to running out of time (although because of the subject matter, this recording was being made as a test and for the speakers reference anyway rather than for public dissemination).

There are a number of things I’ll be looking at to try and solve these issues including going through the computers configuration again when there isn’t a session about to start. Some problems such as poor audio quality were likely due to poor microphone quality and/or audio hardware. This is a known issue and we’ll be looking at the possibility of USB microphones which are relatively cheap and generally resolve those issues (on this occasion we were using an analogue external mic, which was an improvement over that particular laptops internal one but probably still not optimum…).

The additional degradation in audio recording quality may be down to the type/specification of machines we were attempting to record on. I’ll be trying it with ‘full spec’ av laptops for recording and broadcasting, the latter with a high quality microphone and if the results are ok, will work back from there. I am surprised by the difference in what I could hear through my headphones ‘live’ and the quality through the same headphones on the same machine when playing the recording, so maybe there are some configuration tweaks that would help (although the live quality wasn’t great, so this probably won’t prove to be a complete solution if successful).

This ties in with looking at our meeting room setup for audio/video-conferencing in general. Common issues I’ve encountered when doing AV broadcast/conferencing in the past include things like acoustics and residual building noise (due to people and things like heating systems etc. making noise/causing electrical interference). Lisa mentioned that in a previous incarnation of the meeting room (it use to be larger and used as a studio) there were some issues with electrical noise. There are then the hardware issues such as quality of equipment and positioning of speakers/microphones to look at (to avoid/minimise feedback and pickup of background noise). We’re also using the laptop’s integral webcam which is pretty good quality, but attaching an external one would make our lives easier when re-positioning rather than dragging the laptop and its assortment of cables around the table.

Over the next few weeks, I’ll be creating a list of setup tips, plus a suggested hardware list to scrape together if we’re able…

I’ve now used Megameeting for two 1-2-1 meetings with Mark Russell from the University of Hertfordshire. Audio and video quality have been absolutely fine both times and we’ve used the Share My Desktop function in order to collaborate on Powerpoint and Word documents. However, this has taken the form of us discussing what to do and then me doing it; no funky power-sharing antics!

During the second meeting, Mark was suddenly ‘booted off’ after about 45 minutes. He tried to get back into the meeting several times but we ended up finishing off the meeting through Skype. At first I thought I must have mistakenly set a finish time for the meeting but setting the finish time doesn’t appear to be an option! So I’m not sure what happened there…?

Yesterday we tested MegaMeeting with up to 8 video feeds and up to 9 audio feeds, some of which were of MegaMeeting staff, one of whom was in Los Angeles. This was to see whether we could replicate some of the flakiness we’d experienced in real meetings, and to ask them a question about tests we’d done with viewing Flash-based video feeds without problems straight after a problematic meeting.

The test went fine. Video and audio were smooth, both across our network and on wireless connections, and with (almost) all audio feeds locked on. As Geraldine pointed out, it’s the Easter break for students, so our network isn’t under the pressure it may well have been a few weeks ago – and so it will be good to repeat this test when these normal conditions are reached again. There was no direct answer to our specific question, so ongoing monitoring is required. We were told that an upgrade to MegaMeeting had recently been rolled out.

It would be reassuring to be able to guarantee that MegaMeeting will work fine for whoever wants to use it. We may well be on our way to achieving this reassurance.

Since my previous post, I’ve had ‘host’ training from Carrie and a support call from James at Megameeting.

In theory (and in practice with other customers), the system should easily be able to handle the number of participants we tried to throw at it, all with simultaneous video feeds, so we discussed issues around:

• our equipment setup (confirmed ok for at least some participants e.g. me)
• available network bandwidth (again, should have been fine for at least most people)
• possible issues their end (nothing he’s aware of, but will check with the relevant peeps at MM)