piper-audio / ugly-duckling

Technology demo for Piper components using Waves-UI
4 stars 0 forks source link

Request microphone access when trying to record, not on construction. #35

Closed LucasThompson closed 7 years ago

LucasThompson commented 7 years ago

This addresses #2.

It doesn't ask the user for permission to use the microphone until recording is attempted. Once recording permission has been obtained, browsers have a warning icon so the user knows that a page has access to the microphone. In Chrome this is the canonical recording icon to the right of the page title in the tab section. I don't believe it is possible to remove this icon without cleaning everything up in such a way that the user would need to give permission again to access the microphone. Browsers can however remember your choice, which chrome seems to by default.

Requesting media devices from the browser navigator returns a MediaStream object. MediaStreams have tracks, representing a microphone for example. So requesting an audio media device returns a MediaStream with one live MediaStreamTrack. When a MediaStream has no tracks, or contains only ended (the MediaStreamTrack has had its end method called), it is considered inactive (its active property is false).

I had assumed that if a MediaStream is not active, the recording icon in the browser is removed. This doesn't seem to always be the case. If there is any reference to a live audio MediaStreamTrack, the icon is active (even if the only MediaStream object has no tracks or inactive tracks).

This is a security feature of browsers I guess, to notify the user that the page has access to the microphone.

So, assuming I am correct, we have two choices:

This PR takes the first option. The second option involves a little re-jigging of the code to keep some references around.

cannam commented 7 years ago

Testing on Android phone:

In Chrome, it behaves pretty well. In fact, the browser actually never asked for my permission at all. I guess it must have remembered from last time, which I guess also implies that this issue wasn't such a big deal in Chrome in the first place... except that, as we were speculating, this also appears to fix #27 - if you just play the audio, you now get the Media volume control, with the In-Call volume used only when you are actually recording. So it's all pretty fine there.

In Firefox, the browser doesn't seem to remember the permission and asks me again every time I ask to record. Not so good, but still better than asking me every time I start the app regardless of whether I want to record.

This introduces a minor problem with the record button icon, which is now a crossed-out microphone until you first press it - presumably it should be a normal mic until you press it and then become crossed-out only if you refuse permission. Also it's not obvious enough when you are recording and there's no progress update. But I'm sure you know about those.

LucasThompson commented 7 years ago

Your experiences with mobile Chrome and Firefox align with what I've seen on my mac whilst developing this.

This introduces a minor problem with the record button icon, which is now a crossed-out microphone until you first press it - presumably it should be a normal mic until you press it and then become crossed-out only if you refuse permission

Wasn't sure what to do about this, so left it. I think your suggestion is better than leaving it. It does mean that in Safari it is going to initially look like recording is supported, until the user tries (without some additional restructuring).

Also it's not obvious enough when you are recording

This could perhaps be made more obvious by using different icons. However I realise that is a reasonably crap solution. Ideally some kind of level meter or accumulating waveform would be better. Or, a better interim solution could be the addition of a card before the recording has finished. Either way, perhaps we should open another issue about this.

..and there's no progress update

Could you clarify what you mean by this?

You mentioned #27 being fixed as a result of this, I think this may break again if I go with the second option above. If this is indeed the case, does this change your thinking about the best option?

cannam commented 7 years ago

That definitely would change my view of the best option. #27 is pretty serious. I didn't give it a priority label because (i) there was a chance this one might fix it without our having to do anything else and (ii) if it didn't, we probably wouldn't be able to do so anyway.

By "progress update" I just meant that it might be good to have a display showing, for example, how long you've been recording for, or how much space you've used up.

cannam commented 7 years ago

I should add, this fix already works better than I'd expected, so I might have changed my mind about the best option anyway.

LucasThompson commented 7 years ago

I'll merge this for now then, and close the issue. We can re-open it again if we change our minds.