Monday, June 4, 2012

Troy: GSoC 2012 Pronunciation Evaluation Week 2

Following are things done in the second week of GSoC 2012:

1. Setup the server rtmplite to automatically check whether the process is still running or not. If it is stopped, restart it. 

To accomplish this, first of all, create a .process file under my home folder and put the current rtmplite process id as the only content of this .process file. You can use 'top' or 'ps' to find out the current process id of your application. 

Then I created following script file to do the status checking:

if [ -e "$pidfile" ]  then	  	# check whether the process is running  	rtmppid=`/usr/bin/head -n 1 ${pidfile} | /usr/bin/awk '{print $1}'`;  	  	# restart the process if not running  	if [ ! -d /proc/${rtmppid} ]  	then  		/usr/bin/python ${exefile} -r ${dataroot} &  		rtmppid=$!  		echo "${rtmppid}" > ${pidfile}  		echo `/bin/date` "### rtmp process restarted with pid: ${rtmppid}"  	fi  fi
In this script, first we will check whether the .process files ( i.e. the $pidfile) exists or not. If we don't want the server to check for this process for now (maybe when we apply patches to the program), we could simply delete this file and it won't check the process again. And after the maintenance, recreate the file with the new process id. The checking will automatically going on.
The checking itself is quite simple: getting the process id from the file and see whether the process exists by looking into the /proc system folder where each running process will have a folder. Goolge the '/proc linux' you will get more information about this mystery folder which contains quite a lot information about your system. 

2. Implement the login and registration pages using HTML5.
First for user information storage, we use MySQL database, thus a user table is designed and created in the server's mysql database:

FieldType Comments
userid INTEGERCompulsory, automatically increased, primary key
email VARCHAR(200) Compulsory, users are identified by emails
passwordVARCHAR(50) Compulsory, encrypted using SHA1, at least 8 alphanumeric characters
name VARCHAR(100) Not compulsory, default 'NULL'
ageINTEGER Not compulsory, default 'NULL', accepted values [0,150]
sex CHAR(1) Not compulsory, default 'NULL', accepted values {'M', 'F'}
nativeCHAR(1) Not compulsory, default 'NULL', accepted values {'Y', 'N'}. Indicating the user is a native English speaker or not.
place VARCHAR(1000) Not compulsory, default 'NULL'. Indicating the place when the user lived at the age between 6 and 8.
accent CHAR(1)Not compulsory, default 'NULL', accepted values {'Y', 'N'}. Indicating the user has a self-reported accent or not.
The creation of the database:
CREATE TABLE users   (  	userid INTEGER NOT NULL AUTO_INCREMENT,  	email VARCHAR(200) NOT NULL,  	password VARCHAR(50) NOT NULL,  	name VARCHAR(100),  	age INTEGER,  	sex SET('M', 'F'),  	native SET('Y', 'N') DEFAULT 'N',  	place VARCHAR(1000),  	accent SET('Y', 'N'),  	CONSTRAINT PRIMARY KEY (userid),  	CONSTRAINT chk_age CHECK (age>=0 AND age<=150)  );
Secondly, the login and simple registration pages are implemented in HTML5 which I have to learn in practice. Follows are the screenshots of the pages:

Also if you are interested, you can go to this page to help us test the system: . On the server side we use PHP to retrive information from the page and do the query in mysql database and finally sending the data back to the page. 
The recording interface, has also been ported to use HTML instead of pure Flex as I did before. The page current shows up OK but no event interaction between HTML and Flash yet. 

3. Database design for the whole project. 
A bunch of tables are designed to store various information for this project. Detailed table information could be found on our wiki page: . Here I will give a brief discussion. First the user table created in the previous step will be augmented to keep two kind of user information: one for normal student user and one for exemplar recordings. The reason to put them into one table instead of two is that student users, when they can do an excellent job in pronunciation, should also be allowed to contribute to the exemplar recording. Also for exemplar recorders, if they register through the website, they have to show they are proficient enough to contribute a qualified exemplar recording. 
Beside the user table, there are several other tables to for necessary information such as languages for list of languages defined by ISO in case we may extend our project to other languages; region table to have an idea of the user's accent; prompts table for the list of text resources will be used for pronunciation evaluation. 
Then are the tables to log the recordings the users do and tables for set of tests designed in the system. 

Things to do in the coming week:
1. Discuss more regarding the game part to finish the last part of schema design. 
2. Figure out how to integrated the Flash audio recorder nicely with the HTML5 interface. 
3. Implement the student recording interface.
4. Further tasks could be found on this list:

No comments:

Post a Comment