Closed joelle-o-world closed 5 years ago
"The number of frames is less than the minimum bound."
I think its trying to create an audio buffer of length 0 samples
I notice that the browser isn't requesting audio, I strongly suspect this has something to do with it.
Yes, this issue occurs when the p5 Recorder.record() method is called, but no audio is written to the buffer, as is the case when the AudioContext has failed to initialize. We'll need to find a better place in Recorder interface.js or in a brief script tag in the main index.html to initialize the audio context, but in Chrome this needs to happen in response to a user gesture (e.g. upon clicking a button.) I think there's a method in p5 called "getAudioContext()" or something that re-prompts the browser to ask for audio permissions.
micRoberts.start()
is an asynchronous function using node-style callback. In other words, you need to pass it function(s) to tell it what to do if it fails to start (ie user declines to enable microphone, or microphone doesn't exist) or if it starts successfully. I'll fix this now..
Hmmmm, I've added asynchronous callback, but it doesn't fix the problem. I don't think this bug is in our code actually. Because I get the same error messages running p5's own demo (in safari & chrome)
There may well be a simpler way to do this that doesn't involve p5. I'll look into it..
Because I get the same error messages running p5's own demo (in safari & chrome)
Actually, it works in chrome if you reset the demo after it has failed once.
https://developer.mozilla.org/en-US/docs/Web/API/MediaStream_Recording_API
This is (probably) the underlying api which p5 is using. Probably the answer to our troubles lies within..
Because I get the same error messages running p5's own demo (in safari & chrome)
Actually, it works in chrome if you reset the demo after it has failed once.
Yeah the same thing was actually happening when I first got it working last night.
https://developer.mozilla.org/en-US/docs/Web/API/MediaStream_Recording_API
This is (probably) the underlying api which p5 is using. Probably the answer to our troubles lies within..
I think you're right. If we can manage to avoid using p5 at all, that'll probably simplify things significantly. I just went with p5 because it was a more comfortable transition for me. But now that we're using mostly native JavaScript (rather than all of the proprietary syntax that p5 uses) it might be better to stick with the Mozilla MediaStream. I probably won't be able to get into that until later this weekend, but I can try to get something going.
Actually just remembered that Jeremy specifically requested the waveform animation I had on the first version of the site, which was made using the p5 AudioIn and a p5 canvas. Maybe we can handle the essential audio functionalities (i.e. recording) with MediaStream and the auxiliary features (visual feedback via waveform animation) with p5
I see, another option would be to reimplement that using a simple canvas element and javascript. The advantage here is that p5 is a large library and takes a long time to load.
However I guess it's easier to use the code you've already written. I think it is best to put the code for the waveform animation in a seperate bundle (or two, keeping p5.bundle.js seperate). This way the browser can load the animation lazily after already displaying the main content and if p5 crashes it won't effect any of the other script.