Safari decoding issue...
sinewave440hz opened this issue · 10 comments
Hi...I've just released an e.p. on cassette with videos on the b-side, thanks to this project :) Works great in chrome. I added the following replacement code to get the code running in Safari:
var AudioContext = window.AudioContext // Default
|| window.webkitAudioContext
|| false;
if(AudioContext) {
this.audioCtx = new AudioContext();
} else {
alert("Web Audio API is not supported in your browser...");
}
This makes the canvas visible, but when I try running audio through it the scan lines turn green and nothing is really visible. Nothing like the working decoder in Chrome. Do you have any idea where to start fixing this? I see no errors in the page in Safari, unfortunately.
Hmm, it's surprising that safari would require the old webkitAudioContext. According to caniuse it's been supporting the proper AudioContext for quite a while now. Is your version of safari current? As far as the image decoding goes I'd start with looking at the lSamples and cSamples arrays in the process function to see if the data that comes in makes sense.
I don't have access to a machine running safari, so I can't really do any testing myself.
It is fully supported yeah, but in the small print on caniuse it actually points out that it still has to be prefixed with webkit to work. This is why my fix worked in getting the canvas up and running. My guess is that there is another compatibility issue in one of the AudioContext methods/properties. I'll take a look and PR if I get something fixed :)
Can't find any incompatibilities in the rest of the WebAudio-related code. On further testing I established that I can actually see the image, but with very low contrast and the green tint I mentioned. So it would seem that it's related to the canvas code, although I haven't found anything more specific yet. I noticed that the generated audio files are detected as being 96khz sample rate, but converting to 44100 didn't solve the issue. Also confirmed working on Firefox as well as Chrome...
Ahh, right, sorry, missed that part about the prefix!
Low contrast and green tint could be a number of things. Maybe some kind of offset or scaling in the audio signal (even though that should be taken care of in the code), or maybe the point where the color gradient for the line gets constructed. It seems strange that any one of these would result in these specific problems though.
Is the static that shows up during silence also tinted green, or just once the video plays?
Only while playing. The video in question has a strong red tint - maybe there’s a clue there? Wonder if it could be related to the input device. So far I’ve only tested with Soundflower looping back the output to the input. I’ll try another device...
Ohhhh, that could indicate that maybe the phase of the signal is flipped!
Nothing's really leaping out at me here, I suppose I'll have to dig deeper when I have the time. For reference here are screenshots of a video at more or less the same point in time on Safari and Chrome.
OK, I was able to reproduce your issue by mixing down audio of a similar picture to mono. So it looks like Safari only provides a mono input when using getUserMedia. Might need some experimentation to see if there is a workaround by specifying the right constraints.
Nice catch! Thought it must be something “simple” like that. Hoping the solution is too...!
I've tried all the audio constraints options (such as defining min or exact for channelCount) and see no indication that this option is anything but ignored in Safari. So it looks like I'll have to leave it there until it's updated to meet the Web Audio standard (if that happens!).