SoftwarePractice.org: Home | Courseware | Wiki | Archive

T4 : Accesible MP3 Player

From SoftwarePractice.org

Contents

Project brief

Some severely physically disabled people lack the use of their limbs, but still have control of their head movements. A need has been identified for a device that can allow a person with only control of their head to interact with a sound system for playing recorded music.

The vision is for this device to consist of a small, wearable accelerometer that measures the direction, tilt and acceleration of the person’s head in order to derive input control commands.

The wearable device communicates over wireless with the sound system to control the selection, playback, volume, and so forth, of music. The sound system contains a graphical user interface that displays the current track, a playlist, duration of track, etc. The system can play tracks in .wav and .mp3 format.

The graphical user interface also contains a separate panel that shows a visual indication of the user’s head movements, and associated commands. You need to explore what kinds of head movements make sense for this application, and what commands they will represent. For this project you will develop a software prototype for this system. You will need to use the Java Sound API. It is up to you how you design the graphical user interface and what features you provide. It is envisaged that future applications may want to reuse the head movement monitoring part of the program, and provide different mappings from head movements to commands. You will need to simulate the accelerometer inputs (unless you happen to have an accelerometer! Although interfacing to the physical device is beyond the scope of this subject.) – you can do this by providing a mouse-operated GUI that mimics the head movements with some combination of mouse actions.

Given references

This is a specification for a two-axis accelerometer. It can measure acceleration in two orthogonal directions (X and Y). This means that you can easily derive parameters like tilt, direction and speed. http://www.freescale.com/files/sensors/doc/data_sheet/MMA6271QT.pdf

Here is a description of how an accelerometer works: http://www.dimensionengineering.com/accelerometers.htm This publication describes the application of artificial neural networks for processing and recognising head movement commands. What is useful for this project is their set of head movements such as "forward nod" and "forward hold".

P.B. Taylor, H.T. Nguyen, “Performance of a head-movement interface for wheelchair control”, Engineering in Medicine and Biology Society, 2003. Proceedings of the 25th Annual International Conference of the IEEE, Vol.2, 17-21 Sept. 2003, p. 1590-1593 http://ieeexplore.ieee.org/iel5/9009/28599/01279669.pdf

This publication describes the use of infrared sensors for detecting head movements to control a wheelchair. It is useful for their approach to understanding the possible range and mapping of head movements. H.V. Christensen, J.C. Garcia, “Infrared Non-Contact Head Sensor, for Control of Wheelchair Movements”, IOS Press, 2003 http://vbn.aau.dk/fbspretrieve/529548/aaate_article.pdf


The Team

Team 4 is composed by (*):

  • Farshad Babaiee
  • Scott Rowlandson
  • Daniel Sánchez

(*) Victor García has withdrawn the subject.

Analysis of The Project

The project has been divided into four separate modules, with one member of the group inicially in charge for each of the modules.

Simulator

(Responsible: Scott)

Designing the simulator is more a an engineering process than a software-based problem. The potential users of the system must be identified and analysed, and the head movements mapped. BOTH head position (related to gravity) and head movement (instantaneous) matter, since they are of similar order of magnitude.

The simulator will be based on the traditional X and Y axis accelerometers. These accelerometers output a voltage which varies around a mid point voltage at 0G. The simulator will output samples of these X and Y voltage readings at defined time intervals. The signal processing module will then be able to determine both the direction of movement, and also, through calculation the speed of movement.

A graphical user interface (mouse or keyboard controlled) must be implemented to simulate the movements of the head. It should have the image of a head that could be moved, showing also the placement of the sensor.

Different neutral positions should be considered.

Signal processing

(Responsible: Dani)

This module could be used in any other program controlled by head movements. It takes as inputs the X and Y signals from the simulator and converts them into signals: nod, move up, move down, move left and move right.

It should be possible to turn the movement capture system on/off with head movements, and to set up different neutral positions, and maybe different sensibilities.

GUI

(Responsible: Victor)

The player should provide a stable, attractive and friendly interface for the user, and also should be intuitive on the commands, that includes visual understanding on the main functions and options. The system can be controlled either by mouse or by full head-movements, and it would be advisable to include a mode controlled by very simple movements (like nods) for people with hard disabilities.

The system will use the functions provided by the layer 4 - audio player.

Audio player

(Responsible: Farshaad) The audio player in this case is a device to play songs in either wave or mp3 format. It also provides the ability to control the selection, playback (play, stop, pause, rewind and FF), volume. It also enable the user to create a play list and add songs to it. The user would also be able to sort the songs in play list in terms of four options (song name, name of artist, size and date) It also must provide the GUI with above functions.

Stakeholders

The Stakeholders in this project and a brief list of their key concerns are as follows:

Disabled Users

  • Accomodates for limited movement.
  • User friendly/easy to use interface.
  • Instructions and usage guides.
  • Software support.

Non-disabled Users/Carers

  • Easy to use interface.
  • Ability to fix problems with accelerometer input.
  • Ability to use program with normal inputs (mouse/keyboard).

Support Staff

  • Modular code.
  • Ability to release patches and updates easily.
  • Good documentation and instructions.

Distributors

  • Small file size
  • Ability to be distributed via the internet and cd easily

Sales Staff

  • Innovative product.
  • Software correctly produced for the target market.

Investors

  • Cheap to produce.
  • High volume of sales.
  • Minimal support and long term issues.


Usage Scenarios

  • Tom is a music lover. He always knows the latest songs and loves to carry them in his MP3 portable player, but, he is lately getting tired of asking for people's help to turn the player on and operate it because he can't use his hands.
  • Tom already knows the order of the songs in his MP3 player, and he is getting a little bit bored with them. He asks his friend Paul to shuffle the playlist (random mode).
  • Sean likes to hear music while is running, so he always carries his MP3 player when going out. Sometimes he needs to turn it down when he is approaching a crossroads, because he doesn't want to be hit by a car. Since he is running, he doesn't want to stop to do so.
  • Sally likes to listen to music when she is driving her car, but she finds quite annoying having to control the music player with her hands, because she gets distracted from the road. So she would love to use the head-controlled mp3 player.
  • Pedro uses the Accessible MP3 player to listen to music and love the head movement control because he can't use his hands and feels it very comfortable. The only problem is that sometimes he moves his head and the mp3 player accidentally changes the song. He wants to put the player on hold.
  • Peter, Michael's father, always makes playlists for his son, but he wants Micheal to do it for himself because he wants Michael to be more independent and learn to live with his disability. Peter would like Michael to do it himself.

Use-Cases diagrams

Use case diagram: Image:T4-Usecases.jpg

Essential use cases:

Open song

Main flow

User action System action
1. Selects "Add Song" under the Playlist menu -
- 2. Displays dialog box to choose file
3. Selects a song -
- 4. A new playlist is created with the selected song.
- 5. PL is played. Song information displayed on the screen.

Branches

User action System action
3a. Cancels the process -
- 4a. Back to the main screen without any changes.

Configure accelerometer neutral position

Main flow

User action System action
1. Selects "Capture NP" under the Configuration menu -
- 2. Program displays message "Put head in neutral position it will be captured in 5 seconds"
3. User holds in neutral position -
- 5. Program saves configuration

Configure accelerometer sensitivity

Main flow

User action System action
1. Selects "Sensitivity Up" or "Sensitivity Down" under the Configuration menu -
- 2. Program displays message "new Sensitivity x/6"
- 3. Sensitivity changed (6 sensitivity levels available)
- 4. Program saves configuration

Add song to PL

Main flow

User action System action
1. Selects "Add song to PL" -
- 2. Displays dialog box to choose file
3. Selects a song -
- 4. New song is added in the end of playlist.

Branches

User action System action
3a. Cancels the process -
- 4a. Back to the main screen without any changes.

Erase song from PL

Main flow

User action System action
1. User selects "Remove song" under the playlist menu item -
- 2. System erases the last song in the playlist
- 3. If song is currently playing, player stops
- 4. System updates GUI with new playlist

Shuffle PL

Main flow

User action System action
1. User commands the "Shuffle" option -
- 2. System stops playing songs.
- 3. System shuffles the playlist
- 4. System starts playing the first song in the list.

Preconditions

Some songs exist in the Playlist

Play song from PL

Main flow

User action System action
- 1.Currently selected song highlighted in playlist.
2. User selects "Play" under the playback menu -
- 3. System plays song
- 4. Clock and song time information starts displaying

Branches

User action System action
2a. User selects "Next" under playback menu. -
- 3a. Next song in playlist highlighted and played.

If no more songs in the playlist

User action System action
2a(i). User selects "Next" under playback menu. -
- 3a(i). No action

Increase Volume

Main flow

User action System action
1.User selects "up" in the volume control menu -
- 2. System increases volume 1 level per second to a maximum of 10
3. User stops selection when volume at desired level -

Decrease Volume

Main flow

User action System action
1.User selects "down" in the volume control menu -
- 2. System decreases volume 1 level per second to a minimum of 0 (muted)
3. User stops selection when volume at desired level -

Control playback

Main flow

User action System action
1. User selects prev/pause/next -
- 2. System performs chosen operation

Branches

User action System action
1.a User selects next and there are no more songs -
- 2.a No action taken
1.b User selects pause and there is no song being played -
- 2.b No action is taken

Proposed GUI/ initial drafts

Image:draft11.jpg

How to use it

Considering the person's ergonomics while using the player is very important. Reducing the number of tilts and movements to use the MP3 Player is the main consideration when developing the GUI. So modular stages are proposed: Lock, Volume Control, Playback control, Playlist and Configuration. This modules must be clearly displayed by the GUI, making it easy to recognize the commands and operate them.

Note: This draft was developed for the Project Presentation and does not reflect the actual effort of the team for the desing; but an example of how the functionalities would be integrated in the GUI.

Class Diagrams

This is a first draft of the class diagram.

Image:T4-classdiagram.jpg

After doing the implementation phase, some changes were done to the class diagram.

  • Each of the modules was implemented in a separate class, without further need for classes such as Song, Playlist or ConfigMode.
  • A new class was needed to filter files in the openFile() dialog box.

The final class diagram for the system is:

Image:T4-finalclassdiagram.jpg

Sequence Diagrams

Some use cases were developed to test the feasibility of the class diagram. These sequence diagrams are the result.

AddSongtoPlaylist

Image:Addsong2.jpg

IncreaseVolume

Image:Increasevolume2.jpg

EraseSongfromPlaylist

Image:Erasesong2.jpg

PlaySong

Image:playsong2.jpg

Unit Tests

Testing will be performed in two steps in the Accesible MP3 Player. First, individual units will be tested independently (using stubs, drivers, and the BlueJ environment features), and finally, some acceptance tests will be run to the system as a black box.

Below are shown the patterns for the unit tests, and their expected results.

Simulator

Description: These unit tests focus on the Simulator

Requirements tested:

  • Tests correct functionality of simulator methods.
  • Signals are output from the simulator correctly within their bounds.

Environment: Simulator object created and GUI is displayed

Step number Description Expected result Pass/Fail
1. Call simulator constructor Simulator window displayed -
2. Call get_x{) whilst in neutral (initialised) position int 0 returned -
3. Call get_x() in far right position integer 10 returned -
4. Call get_x() in far left position integer -10 returned -
5. Call get_y{) whilst in neutral (initialised) position int 0 returned -
6. Call get_y() in far up position integer 10 returned -
7. Call get_y() in far down position integer -10 returned

Interpreter

Description: Unit test to thoroughly test Interpreter module.

Requirements tested:

  • Tests correct functionality of Interpreter methods.


Environment: Simulator and GUI (or appripriate stubs).

Step number Description Expected result Pass/Fail
1. Call constructor Interpreter initialised with neutral position set at (0,0) and sensitivity at 4/6. -
2. Call run() Thread starts. -
3. Call capture_NP() Sets the Simulator's current position as neutral position, and returns true if success -
4. Call sens_up() with sens < 6 Sensitivity up by one unit, and limit points adjusted in accordance. -
5. Call sens_up() with sens = 6 no action -
6. Call sens_down() with sens > 6 Sensitivity down by one unit, and limit points adjusted in accordance. -
7. Call sens_down() with sens = 0 no action -
8. Call get_x_sens() Returns sensitivity in X axis (integer) -
9. Call get_y_sens() Returns sensitivity in Y axis (integer) -
10. Call get_neutral_x() Returns X neutral position -
11. Call get_neutral_y() Returns Y neutral position -
12. Call set_x_sens(int a) X sensitivity set to "a" and X limit point set to 2^(3-a) -
13. Call set_y_sens(int a) Y sensitivity set to "a" and Y limit point set to 2^(3-a) -
14. Call set_x_sens(int a) X sensitivity set to "a" and X limit point set to 2^(3-a) -
15. Call set_neutral_x(double a) X neutral position set to "a" -
16. Call set_neutral_y(double a) Y neutral position set to "a" -
17. Call set_config(int lpx, int lpy, double nx, double ny) New configuration is saved -
18. x-neutral_x| > |y-neutral_y| && |x-neutral_x| > x_limit_point && (x-neutral_x) > 0 Signal 4 (right) is sent to the GUI -
19. x-neutral_x| > |y-neutral_y| && |x-neutral_x| > x_limit_point && (x-neutral_x) < 0 Signal 3 (left) is sent to the GUI -
20. x-neutral_x| > |y-neutral_y| && |x-neutral_x| <= x_limit_point Signal 0 (neutral) is sent to the GUI -
21. x-neutral_x| <= |y-neutral_y| && |y-neutral_y| > y_limit_point && (y-neutral_y) > 0 Signal 1 (up) is sent to the GUI -
22. x-neutral_x| <= |y-neutral_y| && |y-neutral_y| > y_limit_point && (y-neutral_y) < 0 Signal 2 (down) is sent to the GUI -
23. x-neutral_x| <= |y-neutral_y| && |y-neutral_y| <= y_limit_point Signal 0 (neutral) is sent to the GUI -

GUI

Description: These unit tests focus on the GUI

Requirements tested:

  • Tests correct functionality of GUI methods.


Environment: MediaPlayer and Interpreter objects are valid and intialised

Step number Description Expected result Pass/Fail
1. call GUI() Window displayed, interpretere and media player objects intialised -
2. set_visible(int i) where i< total menu items Single menu item displayed -
3. set_visible(int i) where i> total menu items null pointer error -
4. set_visible(int i), menu item i already visible no action -
5. set_invisible(int i) where i< total menu items Single menu item removed from gui -
6. set_invisible(int i) where i> total menu items null pointer error -
7. set_invisible(int i), menu item i already invisible no action -
8. highlight(int i) where i< total menu items Single menu item highlighted -
9. highlight(int i) where i> total menu items null pointer error -
10. highlight(int i), menu item i already highlighted no action -
11. Vector <string> convertPL() - Playlist exists String of filenames placed in vector -
12. Vector <string> convertPL() - Playlist doesn't exist no action -
13. update_playlist () playlist refreshed on screen -
14. intialize_component() GUI redrawn -
15. signal(int i) - i=1 Up arrow displayed, up() called -
16. signal(int i) - i=2 Down arrow displayed, down() called -
17. signal(int i) - i=3 Left arrow displayed, left() called -
18. signal(int i) - i=4 Right arrow displayed, right() called -
19. signal(int i) - i<1, i>4 Neutral displayed, no action -
20. right() - at top level menu Cycle through top level menu items in right direction (No action at bounds) -
21. right() - on menu item Menu item executed -
22. left() - at top level menu Cycle through top level menu items in left direction (No action at bounds) -
23. left() - on menu item Cycle through top level menu items in left direction (No action at bounds) -
24. down() Cycle through the drop down menu in downwards direction (No action at bounds) -
25. up() Cycle through the drop down menu in upwards direction (No action at bounds) -
26. main(String args[]) executes complete program -

Media Player

Description: These unit tests focus on the Media Player.

Requirements tested:

  • Tests correct functionality of Media Player methods.

Environment: MediaPlayer and GUI objects are valid and intialised .

Step number Description Expected result Pass/Fail
1. Call "openFile" (cancel option) The URL returned is NULL
2. Call "openFile" (play list file chosen) The URL of the chosen play lit is returned
3. Call "playCurrentSong" Create a player for the current song
4. Call "stopPlayer" To stop the current player & close the current instance of the player
5. Call "pausePlayer" To stop the current player
6. Call "restartPlayer" To continue the stopped player
7. Call "removePreviousPlayer" To close the current instance of the player
8. Call "previousSong" (current file is not the first fle) To change the pointer to previous of the current file & start a new instance of a player
9. Call "nextSong" (current file is not the last file) To change the pointer to head of the current file & start a new instance of a player
10. Call "randomSong" To choose a random song in the list & create an instance of the player
11. Call "decreaseVolume" (when the volume is not less than or equall to zero) To decrease the volume by 0.1
12. Call "decreaseVolume" (when the volume is less than or equal to zero) N/A
13. Call "increaseVolume" (when the volume is greater then or equall to 1.0) N/A
14. Call increaseVolume (when the volume is not greater then or equall to 1.0) To increase the volume by 0.1
15. Call "get_PL" Returns list of URLs
16. Call "addSong" To add song to the play list
17. Call "getCurrentFile" To return the current file in the play list
18. Call "removeSong" (when current file is not the last file remained in the play list) To remove the last file in the play list
19. Call "removeSong" (when current file is the last file remained in the play list) To close the player
20. Call "clearPL" To close the current player & remove all the files from the play list
21. Call "getStopTime" To return the player stop time
22. Call "getCurrentTime" To return the player media time

Acceptance Tests

Template to use to develop test cases:

Test case name

Description: This is the description.

Requirements tested: ...

Environment: (preconditions, eg. user exists and is logged in)

System setup: Any extra equipment needed (I think it wont apply to our project)

Step number Description Expected result Pass/Fail
1. Action the USER has to do Expected result here leave this column blank
2. - - -

We have developed three test cases, to give a quick overview of the functionalities of the system in a customer presentation, treating the system as a black box.

Test case 1

Description: This Test Case focuses on the configuration features.

Requirements tested:

  • Simulator can input correct X and Y data.
  • The MP3 Player can be locked and it does not execute any actions.
  • The MP3 Player can be unlocked.
  • The sensitivity of the MP3 Player can be adjusted.
  • A new neutral position distinct than (0,0) can be specified.
  • Signals appear on the screen when inputted.

Environment: Neutral position set to (0,0), Sensitivity set to 4/6 (initial condions at program start)

Step number Description Expected result Pass/Fail
1. Set the input to (1, 0) in the simulator RIGHT signals are sent every second
2. Set the input to (0, 0) in the simulator No signals are sent
3. Set the input to (0, -1) in the simulator DOWN signals are sent every second
4. Navigate through the menus to "Sensitivity down" Sensitivity is set to 3/6
5. Set the input to (0, 1) in the simulator No signals are sent
6. Set the input to (0, 2) in the simulator UP signals are sent every second
7. Navigate through the menus to "Add lock" Player is locked
8. Navigate through the menus to "Capture NP" No action taken
9. Navigate through the menus to "Remove lock" Player is unlocked
10. Navigate through the menus to "Capture NP" Message is displayed
11. Before 5 seconds, set the simulator in position (2, 3). New NP is captured
12. Set the input to (2,3) No signals are sent
13. Set the input to (0, 0) DOWN signals are sent
14. Set the input to (0, 3) LEFT signals are sent

Test case 2

Description: This Test Case focuses on the playback features.

Requirements tested:

  • Simulator can input correct X and Y data which are translated into correct signals.
  • The user can add songs to the playlist.
  • Player can play both MP3 and WAV files.
  • The "Add song" dialog box only shows playable files.
  • Playback can be paused and resumed.
  • User can skip a song and go to a previous song.
  • Playlist functions correctly: It forwards to the next song once a song is over, and it stops when there are no more songs to play.

Environment: Empty playlist at start.

Step number Description Expected result Pass/Fail
1. Navigate through the menus to "Add song" Add song dialog box is displayed
2. Choose song "Gypsy Kings - Hotel California.mp3" from the testsongs folder Song added to playlist and highlighted. Player starts to play song, song time is displayed in the GUI
3. Navigate through the menus to "Pause" Song is paused.
4. Navigate through the menus to "Add song" Add song dialog box is displayed
5. Choose song "loopymusic.wav" from the testsongs folder Song is added at the end of the playlist
6. Navigate through the menus to "Add song" Add song dialog box is displayed
7. Choose song "The Police - Every Breath you take.mp3" from the testsongs folder Song is added at the end of the playlist
8. Navigate through the menus to "Play" Song 1 is restarted.
9. Wait until first song ends Second song starts to play.
10. Navigate through the menus to "Previous Song" Song 1 starts to play
11. Navigate through the menus to "Next Song" Song 2 starts to play
12. Navigate through the menus to "Next Song" again No action is taken

Test case 3

Description: This Test Case focuses on the playlist control features.

Requirements tested:

  • Simulator can input correct X and Y data which are translated into correct signals.
  • The user can add songs to the playlist.
  • The user can control the volume of the player.
  • The user can shuffle the playlist.
  • The user can remove the last song of the playlist, and if it is being played, the player will stop.
  • The user can clear the playlist and stop the player.

Environment: Empty playlist at start.

Step number Description Expected result Pass/Fail
1. Navigate through the menus to "Add song" Add song dialog box is displayed
2. Choose song "Alphaville - Forever Young.wav" from the testsongs folder Song added to playlist and highlighted. Player starts to play song, song time is displayed in the GUI
3. Navigate through the menus to "Add song" Add song dialog box is displayed
4. Choose song "The Police - Every Breath you take.mp3" from the testsongs folder Song is added at the end of the playlist
5. Navigate through the menus to "Add song" Add song dialog box is displayed
6. Choose song "The Fray - How to save a life.mp3" from the testsongs folder Song is added at the end of the playlist
7. Navigate through the menus to "Add song" Add song dialog box is displayed
8. Choose song "Gypsy Kings - Hotel California.mp3" from the testsongs folder Song is added at the end of the playlist
9. Navigate through the menus to "Volume down" New volume is set to 9/10
10. Repeat step 9 until volume is mute Volume reaches 0
11. Select "Volume up" until volume is 5/10 Volume goes up by one to 5
12. Navigate through the menus to "Shuffle Playlist" Playlist is shuffled and starts playing again
13. Navigate through the menus to "Remove song" Last song in PL is removed, player keeps playing.
14. Navigate through the menus to "Clear Playlist" Playlist is empty and player stops


Screenshots

The following are snapshots of the finished application:

Layout of elements in the player:

Image:T4-player.jpg

Simulator control:

Image:T4-simulator.jpg

Using the player:

Image:T4-player2.jpg

Library and Package Requirements

This program requires the following packages:

  • Java Media Framework 2.1.1
  • JDK 1.5.x or higher

Instructor comments

Excellent start! Only point to make is to beef up your usage scenarios. Write them using a persona -- give the user a name and some particulars about who they are that are meaningful to the design. Scenarios should give the context of use for that persona. Lian 21st March

Post presentation session milestone: Excellent work. Stakeholders are well done. Usage scenarios include identification of extensions of use outside original vision, and high empathy with disabled users. Good modularisation and division of work. Very good choice of classes. Good use of aggregation and inheritance on class diagram. Excellent thinking around design and situations of use, eg. configuration and neutral position of user. Good GUI layout and thinking through usability for disabled user. Sequence diagrams - reasonable logic, but notation is not always correct (eg. Play song). Lian 4th April

Personal tools