I have posted a code example that shows how to record audio from a microphone in a web browser using the Web Audio API.
Take a look a the demo and the code HERE
It turns out that the API does not support recording directly so you have to add consecutive samples of audio data to your own recording buffer. You need to grow the size of the buffer whenever you add a new sample. Once you have your recording you can use it as the source of a BufferSourceNode and play it back.
A collection of computer systems and programming tips that you may find useful.
Brought to you by Craic Computing LLC, a bioinformatics consulting company.
Showing posts with label html5. Show all posts
Showing posts with label html5. Show all posts
Tuesday, July 2, 2013
Friday, June 28, 2013
Vocabrio - a new way to learn a language
I am very pleased to announce the launch of Vocabrio - a new web service from Craic that helps you improve your vocabulary in a foreign language.
Vocabrio lets you read any web site in your target language and translate those words that are new to you. The words are added to your custom dictionary and you can test what you have learned with custom quizzes.
Unlike a general textbook, Vocabrio lets you build up a vocabulary of the words that are relevant to your interests, making it more useful than existing tools.
Vocabrio makes use of some amazing new web technologies.
You can listen to how any word is pronounced using Speech Synthesis and HTML5 Web Audio in your browser (no Flash or plugin required!)
You can test your own pronunciation using Web Audio and cutting edge Speech Recognition - all in your browser.
Vocabrio is free to use while it is in Beta release - over time it will shift to a paid subscription.
You can learn more and sign up for an account at http://vocabrio.com
Vocabrio lets you read any web site in your target language and translate those words that are new to you. The words are added to your custom dictionary and you can test what you have learned with custom quizzes.
Unlike a general textbook, Vocabrio lets you build up a vocabulary of the words that are relevant to your interests, making it more useful than existing tools.
Vocabrio makes use of some amazing new web technologies.
You can listen to how any word is pronounced using Speech Synthesis and HTML5 Web Audio in your browser (no Flash or plugin required!)
You can test your own pronunciation using Web Audio and cutting edge Speech Recognition - all in your browser.
Vocabrio is free to use while it is in Beta release - over time it will shift to a paid subscription.
You can learn more and sign up for an account at http://vocabrio.com
Wednesday, April 17, 2013
Gotchas when working with HTML5 Audio
I've run into a few issues while building a demo web app that plays audio files, so I wanted to post my experiences...
1: Firefox does NOT play MP3 files (as of 2013-04-17)
This is because the MPEG format is proprietary and the Firefox/Mozilla folks insist on only open source formats. You need to use .wav, .ogg or .webm. See https://developer.mozilla.org/en-US/docs/HTML/Supported_media_formats for the allowed options.
Unfortunately they do not seem to produce a useful error message if you try and play an MP3 file.
Google Chrome plays anything - so your application may appear to work fine but may fail on Firefox.
2: Firefox is VERY strict in regard to Cross-Origin Resource Sharing (CORS)
Firefox will refuse to play an audio file on a host other than the one that served the original web page. So you can't store an audio file on, say, Amazon S3, and play it on your web site. The same goes for Ajax requests to another site. The Firefox console will, or may, display an error but this is not necessarily clear.
Google Chrome doesn't seem to care about this restriction.
See this page for more details https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
To work around this you can specify a header for the audio file which means that as the owner of the audio file you allow it to be referenced from any other site.
"Access-Control-Allow-Origin" = "*"
To work around the problem with Ajax requests you can use JSONP instead of JSON as I have described.
The special header ought to work with AWS S3... except....
3: AWS S3 does NOT allow the Access-Control-Allow-Origin header
You can set metadata headers with S3 files but not this one. The Amazon support forums are full of requests/complaints about this but it does not seem to have been resolved.
There does seem to be a way round this on Amazon Cloudfront, which pretty much exists to server assets for other sites, but from what I've seen this is pretty ugly.
My workaround for this was to add a proxy method to my server. The client requests a file that resides on S3 from the proxy. It fetches it from S3 and echoes it to the client, which sees it as coming from the originating server. This introduces an unnecessary delay but works file. Here is a snippet of code in Ruby for a Sinatra server. It uses the aws-sdk gem and leaves out set up for that.
get '/proxy' do
s3obj = bucket.objects[params['file']]
response["Access-Control-Allow-Origin"] = "*"
content_type 'audio/wav'
s3obj.read
end
Apparently Google's equivalent of S3 does not have this issue - I've not tried it.
4: You cannot play audio files from localhost
This makes testing a pain. Your audio files must be hosted on a server other than localhost. I recommend Heroku as a way to get development servers up and running quickly and at no initial cost.
If you don't realize this, then there is no error message in the browser console - it simply doesn't work and you are left scratching your head until you figure it out. I hate stuff like that...
1: Firefox does NOT play MP3 files (as of 2013-04-17)
This is because the MPEG format is proprietary and the Firefox/Mozilla folks insist on only open source formats. You need to use .wav, .ogg or .webm. See https://developer.mozilla.org/en-US/docs/HTML/Supported_media_formats for the allowed options.
Unfortunately they do not seem to produce a useful error message if you try and play an MP3 file.
Google Chrome plays anything - so your application may appear to work fine but may fail on Firefox.
2: Firefox is VERY strict in regard to Cross-Origin Resource Sharing (CORS)
Firefox will refuse to play an audio file on a host other than the one that served the original web page. So you can't store an audio file on, say, Amazon S3, and play it on your web site. The same goes for Ajax requests to another site. The Firefox console will, or may, display an error but this is not necessarily clear.
Google Chrome doesn't seem to care about this restriction.
See this page for more details https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
To work around this you can specify a header for the audio file which means that as the owner of the audio file you allow it to be referenced from any other site.
"Access-Control-Allow-Origin" = "*"
To work around the problem with Ajax requests you can use JSONP instead of JSON as I have described.
The special header ought to work with AWS S3... except....
3: AWS S3 does NOT allow the Access-Control-Allow-Origin header
You can set metadata headers with S3 files but not this one. The Amazon support forums are full of requests/complaints about this but it does not seem to have been resolved.
There does seem to be a way round this on Amazon Cloudfront, which pretty much exists to server assets for other sites, but from what I've seen this is pretty ugly.
My workaround for this was to add a proxy method to my server. The client requests a file that resides on S3 from the proxy. It fetches it from S3 and echoes it to the client, which sees it as coming from the originating server. This introduces an unnecessary delay but works file. Here is a snippet of code in Ruby for a Sinatra server. It uses the aws-sdk gem and leaves out set up for that.
get '/proxy' do
s3obj = bucket.objects[params['file']]
response["Access-Control-Allow-Origin"] = "*"
content_type 'audio/wav'
s3obj.read
end
Apparently Google's equivalent of S3 does not have this issue - I've not tried it.
4: You cannot play audio files from localhost
This makes testing a pain. Your audio files must be hosted on a server other than localhost. I recommend Heroku as a way to get development servers up and running quickly and at no initial cost.
If you don't realize this, then there is no error message in the browser console - it simply doesn't work and you are left scratching your head until you figure it out. I hate stuff like that...
Labels:
AWS S3,
CORS,
firefox,
google chrome,
html5,
javascript
Friday, March 8, 2013
HTML5 and web API code examples
Whenever I am learning a new feature of HTML5, JavaScript/Jquery or a new API, such as Google Maps, I always look for example code that I can learn from.
In many cases the examples are great, but in others they can be too clever and too heavily styled, such that it can be hard to understand the core of the feature that they are demonstrating.
So in writing my own example code I try and strip things down to the bare minimum - very little styling and code that tries to do one, and only one, thing.
I've been collecting examples that I think have some substance and that can help others learn about a feature with the minimum of confusion.
Take a look at http://html5-examples.craic.com
This site has working examples of a number of HTML5-related features, including Data Attributes, Geolocation, Web Audio and Speech Recognition.
Look at the Source for each of these pages to see annotated JavaScript, etc. which illustrates the target feature of each page.
All the code is distributed freely under the terms of the MIT license and you are encouraged to build your own applications using it.
Note that some of the examples involve new web technologies, so they may not work in some browsers and what does work now may not work in the future as the APIs mature.
In many cases the examples are great, but in others they can be too clever and too heavily styled, such that it can be hard to understand the core of the feature that they are demonstrating.
So in writing my own example code I try and strip things down to the bare minimum - very little styling and code that tries to do one, and only one, thing.
I've been collecting examples that I think have some substance and that can help others learn about a feature with the minimum of confusion.
Take a look at http://html5-examples.craic.com
This site has working examples of a number of HTML5-related features, including Data Attributes, Geolocation, Web Audio and Speech Recognition.
Look at the Source for each of these pages to see annotated JavaScript, etc. which illustrates the target feature of each page.
All the code is distributed freely under the terms of the MIT license and you are encouraged to build your own applications using it.
Note that some of the examples involve new web technologies, so they may not work in some browsers and what does work now may not work in the future as the APIs mature.
Labels:
google chrome,
google maps,
html5,
javascript,
web audio,
web speech
Tuesday, July 26, 2011
Default Auto Capitalization in HTML Forms with Safari on iPad2
Ran into a nasty gotcha testing out one of my web sites on an iPad2 with Safari.
By default the iPad will capitalize the first letter in a sentence. But with my application the login page requires an email address and these are typically in al lower case.
Safari forces the first letter of the email address into upper case, e.g. Jones@example.com - but this does not match the text in the application's databases (jones@example.com).
My app doesn't force text into lower case on its end (and it shouldn't !), which means that I could not login to my site. And in this case using the SHIFT key on the keyboard does not let you enter the first letter in lower case.
The solution is for the User of the iPad to go to Settings -> General -> Keyboard and set Auto-Capitalization to Off.
This is a really bad default setting - yes, it can be useful if you are entering regular text - but it's not that useful...
I can't expect my users to deal with this on their end. I could force all email address into lower case in my application and that is probably what I'll end up doing.
HTML5 forms can define that a text entry box represents an email address. This adds convenience when entering from a mobile device (the keyboard can display a '.com' key, for example). Whether or not using this has any effect on auto-capitalization I have yet to test.
Subscribe to:
Posts (Atom)