New Audio Recorder button in WYSIWYG editor requires testing

[JohnSmith-LT]

Hi @ronm123, @torinfo, @FayCross this has been a long time idea and I've finally got something up and running and committed this morning. This relates to several issues #23 #24 #25 #447 #525

The functionality isn't finalised yet - I just wanted to get it up there so that it can be tested in practice and can get some feedback but it seems pretty robust to my testing (in Chrome only at present)

I also still need to do some work on the language file and the sources dropdown - at present it might only record from the default audio source. I need to get a few other devices hooked up to my laptop so that I have some to choose from but if anyone else has multiple things populated in that dropdown then i'd welcome any feedback on whether it works or not.

The button is after the Audio icon in the editor:

It transcodes into mp3 by default but can also do ogg and wav if required. Possibly I can have it write out the default Opus/.webm format also, if anyone thinks that is a good idea.

Any suggestions greatly received!

[ingedonke]

Hi @JohnSmith-LT Great!! I'm going to test this today :)

[ingedonke]

Hi @JohnSmith-LT When I press recording nothing happens. I tried it in Chrome and Edge. Do I have to do something else in the configuration before it works?

[ronm123]

Hi @JohnSmith-LT @ingedonke it works great for me! ;-)

In Chrome I can also go to the settings menu and choose my different input sources and they all show and work correctly. While I was at it I tested in Firefox too and with that the recording works but that is using the built-in laptop mic and the settings menu just shows Microphone 1 three times rather than the different named microphones that I see in Chrome.

[JohnSmith-LT]

Not sure @ingedonke, perhaps it's a caching issue? Try clearing your cache and try again.

Thank @ronm123, i'll look into the sources issue in Firefox later but great that is works for you in Chrome at least - the sources update as you hotswap devices and I have some extra code that is commented out which I haven't implemented yet which, from memory, keeps the selected source selected after the devices refresh, but it may also do some clearup or something else.

[JohnSmith-LT]

So @ronm123 I've tested in Edge (latest) and I suspect the same may be the case in Firefox - but Edge doesn't return a deviceID which is used to identify and choose the audio context for the recording so I will have to investigate if there is a way to use the groupId somehow (although it suggests that it may be the same for a group of devices, perhaps where you have a webcam with audio and video source)...

That is obviously a dealbreaker in Edge and Firefox just now so please do any testing in Chrome and feedback any bugs found there and they can then be checked in the other browsers once I get a chance to look into the source issue a bit...

Chrome:

Edge:

[JohnSmith-LT]

Ok @ronm123 @ingedonke I just committed a small change that made the device selection less specific and tested in latest Edge and it's working there now too, as well as Chrome.

I'm on work laptop and don't have Firefox installed so can't test there but will test later there but if either of you get the chance to test in FF before me then that would be great.

Regarding the Microphone names @ronm123 It should have said Microphone 1, 2, 3 so I will look to see why it isn't doing that but in some browsers they simply don't return the name of the device. Even Edge which is Chromium based returns different settings from Chrome and no device labels...

[torinfo]

@JohnSmith-LT In xot310beta.dlearning.nl (which automatically pulls every 10 minutes) I can record a fragment and place it in a text page. However, I only see 1 microphone in chrome.

When I use my own develop install (also on a linux box and on the same PC) I see my two microphone, and they have proper device names. But upload and place player gives a console error on parsing a json file. It triggers the lock file message somehow.

[ronm123]

@JohnSmith-LT @torinfo I've only been testing locally but after Tom's last message I'll do a quick test on xot310beta too.

On my local machine I get the following: Chrome works fine and displays my different devices correctly names in the settings menu and I can slect a device and then switch to record and record via that device. Edge works the same as Chrome. Firefox only displays two options both saying Microphone 1 and don't seem to make a difference when selecting one or the other. However after hitting record I get a browser pop up that allows me to choose which input I want to use and works for each input. The only drawback of this is that as soon I select Allow the recording begins whereas being able to choose via settings with Chrome and Edge means that I can choose before starting record.

[ronm123]

@JohnSmith-LT @torinfo I just tested via xot310 beta and initially there was a difference but I think I had this locally too...

Testing with Chrome first time I tried it under the settings menu I only saw Microphone 1 and when clicking record I got a browser pop-up asking me to allow xot310beta to use my microphone. Options were Allow or Block but no mic selection menu like I had locally with Firefox. Selecting allow and recording worked and used my default mic. When I then hit the record icon again and visit settings I see my list of devices and can choose which to use, switch to record and record without seeing the browser pop-up. So @torinfo it might be worth trying record for a second time after allowing and see if your settings menu now shows your devices? I'm not getting a console json error either locally or via xot310beta.

[ronm123]

@JohnSmith-LT @torinfo just tested in each browser on xot310beta and works exactly the same as local develop e.g.

after clicking allow in the pop-up both Chrome and Edge show the list of devices in settings when testing again. Firefox prompts to allow every time and doesn't show the devices under settings but does show the devices correctly in the pop-up and can choose and record via each one.

[JohnSmith-LT]

Thanks @ronm123 and @torinfo for your feedback. I had a hunch that it might be a permissions thing - I will see if I can figure out how to get the permissions and devices to persist in FF. They all say that they adhere to standards, and they have improved greatly, but the number of hoops you have to jump through just to get this stuff to where it is now is ridiculous!!

If @ronm123 can't find a way to break it though (in Chrome at least) then I'm quite happy with that :-)

One thing that I know might be an issue is spaces and quotes in the filename - I need to strip them out still because that will definitely break things...

[torinfo]

@JohnSmith-LT I revisited xot310beta, and it shows the names of the mics, and I can insert the player in the content :-)

[JohnSmith-LT]

Brilliant @torinfo, thanks for confirming. I also see that the deviceIDs come through in Edge now so I must've had a permission issue there too. I will try to detect and possibly do a test/practice recording to trigger the permissions and then stop and discard and see if I can figure something out...

Just a caveat, if you select a Audio widget entered by the Recorder or by the HTML5 Audio plugin and then click the editor then it will detect it and replace the audio in that player instead of creating a new one...

[JohnSmith-LT]

I've made some changes to the interface, made the Timestamp option look a lot nicer and added a filename cleanser and popup if any are entered -

• allows letters, numbers, underscore _ and hyphen - (can be changed easily enough)
• replaces multiple spaces and underscores with single underscore
• removes leading and trailing underscores before adding timestamp

Will work on the sources issue over weekend... have a good one!!

[ronm123]

@JohnSmith-LT just had a quick meeting with Alistair who is delivering an accessibility session with Xerte today. I quickly demoed the recorder you have added which he thought was great but instantly asked "is there an option to add a transcript?"

In discussing that we wondered about two options:

1. add a tip/reminder about including a transcript e.g. the record pane already includes a tip so perhaps just add a prompt/reminder there?
2. ideally add a textbox in the recorder for typing/pasting a transcript and include a link to that automatically.

Both possible future enhancements?

[JohnSmith-LT]

Yes @ronm123 I can probably work in both, once I sort out the sources issue - I had it mostly working at the weekend but started messing with it to make it better and inevitably made it worse! Questions regarding the above:

What tip text would you suggest? Would you want the transcript functionality as a separate box? I think the transcript would be added as a < track> within the < audio> < /audio> tags and would therefore be a url so a textbox would have to generate an upload request, get back a filename from the server and insert that - that could get messy - i.e. what happens if you edit?

For example we re-populate the textbox but then what does edit do? Upload a new file or overwrite the old file, etc.

Alternatively a file upload box for a transcript file would probably be easiest and most robust but would that then be an extra step that would discourage users - if they had to generate the transcript elsewhere and then save as a file and then upload...?

[ronm123]

@JohnSmith-LT any tip/prompt would obviously vary depending on whether there is a transcript option or not. Simplest as it is now would be to just add something like: Reminder - for accessibility purposes you should include a transcript of your recording(s) especially if your recordings contain information that isn't already displayed as text on screen.

I can see what you mean about the possibility to get messy, especially as this now provides the potential for multiple recordings on the same screen and we've had the html5 audio option for quite a while without adding a similar thing for that. Perhaps for now, the text tip is sufficient? The best solution would probably be something like we have with the graphic and sound page where there is a textbox and a toggle button that gets added below the audio player if a transcript has been added. But with these smaller audio players and possibly multiples of them I'm not sure that would be a very neat solution.

[JohnSmith-LT]

Hi @ronm123 @ingedonke I've made an update to the recorder. I've fixed a few bugs and now the record button turns red when it is recording. More importantly it checks the permissions and alerts the user to the fact that they need to enable permissions. Have only tested really in Chrome and Edge but seems to work ok..

[JohnSmith-LT]

Is everyone happy that this is working well enough for the release? I'm going to close this issue now but will revisit once the dust settles. If there are any glaring issues then please reopen and let me know and I may get a chance to take a look...

[FayCross]

@JohnSmith-LT sorry for only testing this now - it works really well! I have one comment but won't reopen the issue - I'll leave it to you to decide whether it's necessary or not. After you have added a new recording to the page, if you double click the player then it reopens the record audio dialog. I think it would be nice if instead it opened the HTML5 audio dialog instead (the one you get when you insert audio in the normal way without recording in Xerte). Then you could edit the align options etc.

Edit: I've just realised it does do this if you move away from the page and back!

[JohnSmith-LT]

HI @FayCross , no problem at all, I know you are busy...

I've reopened this and taken a look at it. It seems that if you insert the audio and then double click on it then yes it does open the recorder again but if you insert the recording and navigate to a different page and then come back again and then double click on it then it does indeed open the HTML5 Audio box and allow you to change the alignment etc...

Not really sure why that is but i'll take a look in the morning again and see if I can do something to make the recorder widget no longer recognise the player it's just inserted so that the HTML5 player takes over handling double click...