I need to do it asap.
# Homework 1 - CSE 320 - Fall 2020 #### Professor Eugene Stark ### **Due Date: Friday 09/18/2020 @ 11:59pm** **Read the entire doc before you start** ## Introduction In this assignment, you will write a command line utility to synthesize audio data containing Dual-Tone Multi-Frequency (DTMF) signals and to detect DTMF signals in audio data. The goal of this homework is to familiarize yourself with C programming, with a focus on input/output, bitwise manipulations, and the use of pointers. For all assignments in this course, you **MUST NOT** put any of the functions that you write into the `main.c` file. The file `main.c` **MUST ONLY** contain `#include`s, local `#define`s and the `main` function (you may of course modify the `main` function body). The reason for this restriction has to do with our use of the Criterion library to test your code. Beyond this, you may have as many or as few additional `.c` files in the `src` directory as you wish. Also, you may declare as many or as few headers as you wish. Note, however, that header and `.c` files distributed with the assignment base code often contain a comment at the beginning which states that they are not to be modified. **PLEASE** take note of these comments and do not modify any such files, as they will be replaced by the original versions during grading. > :scream: Array indexing (**'A[]'**) is not allowed in this assignment. You > **MUST USE** pointer arithmetic instead. All necessary arrays are declared in > the `const.h` header file. You **MUST USE** these arrays. **DO NOT** create > your own arrays. We **WILL** check for this. > :nerd: Reference for pointers: [https://beej.us/guide/bgc/html/multi/pointers.html](https://beej.us/guide/bgc/html/multi/pointers.html). # Getting Started Fetch base code for `hw1` as described in `hw0`. You can find it at this link: [https://gitlab02.cs.stonybrook.edu/cse320/hw1](https://gitlab02.cs.stonybrook.edu/cse320/hw1). **IMPORTANT: 'FETCH', DO NOT 'CLONE'.** Both repos will probably have a file named `.gitlab-ci.yml` with different contents. Simply merging these files will cause a merge conflict. To avoid this, we will merge the repos using a flag so that the `.gitlab-ci.yml` found in the `hw1` repo will replace the `hw0` version. To merge, use this command: ``` git merge -m "Merging HW1_CODE" HW1_CODE/master --strategy-option=theirs ``` > :scream: Based on past experience, many students will either ignore the above command or forget > to use it. The result will be a **merge conflict**, which will be reported by git. > Once a merge conflict has been reported, it is essential to correct it before committing > (or to abort the merge without committing -- use `git merge --abort` and go back and try again), > because git will have inserted markers into the files involved indicating the locations of the > conflicts, and if you ignore this and commit anyway, you will end up with corrupted files. > You should consider it important to read up at an early stage on merge conflicts with git and > how to resolve them properly. Here is the structure of the base code:
. ├── .gitlab-ci.yml └── hw1 ├── hw1.sublime-project ├── include │ ├── audio.h │ ├── const.h │ ├── debug.h │ ├── dtmf.h │ ├── dtmf_static.h │ └── goertzel.h ├── Makefile ├── rsrc │ ├── 941Hz_1sec.au │ ├── dtmf_0_500ms.au │ ├── dtmf_0_500ms.txt │ ├── dtmf_all.au │ ├── dtmf_all.txt │ └── white_noise_10s.au ├── src │ ├── audio.c │ ├── dtmf.c │ ├── goertzel.c │ └── main.c └── tests └── hw1_tests.c
- The `.gitlab-ci.yml` file is a file that specifies "continuous integration" testing to be performed by the GitLab server each time you push a commit. Usually it will be configured to check that your code builds and runs, and that any provided unit tests are passed. You are free to change this file if you like. > :scream: The CI testing is for your own information; it does not directly have > anything to do with assignment grading or whether your commit has been properly > pushed to the server. If some part of the testing fails, you will see the somewhat > misleading message "commit failed" on the GitLab web interface. > This does not mean that "your attempt to commit has failed" or that "your commit > didn't get pushed to the server"; the very fact that the testing was triggered at > all means that you successfully pushed a commit. Rather, it means that the CI tests > performed on a commit that you pushed did not succeed". The purpose of the tests are > to alert you to possible problems with your code; if you see that testing has failed > it is worth investigating why that has happened. However, the tests can sometimes > fail for reasons that are not your fault; for example, the entire CI "runner" system > may fail if someone submits code that fills up the system disk. You should definitely > try to understand why the tests have failed if they do, but it is not necessary to be > overly obsessive about them. - The `hw1.sublime-project` file is a "project file" for use by the Sublime Text editor. It is included to try to help Sublime understand the organization of the project so that it can properly identify errors as you edit your code. - The `Makefile` is a configuration file for the `make` build utility, which is what you should use to compile your code. In brief, `make` or `make all` will compile anything that needs to be, `make debug` does the same except that it compiles the code with options suitable for debugging, and `make clean` removes files that resulted from a previous compilation. These "targets" can be combined; for example, you would use `make clean debug` to ensure a complete clean and rebuild of everything for debugging. - The `include` directory contains C header files (with extension `.h`) that are used by the code. Note that these files contain `DO NOT MODIFY` instructions at the beginning. You should observe these notices carefully where they appear. - The `src` directory contains C source files (with extension `.c`). - The `tests` directory contains C source code (and sometimes headers and other files) that are used by the Criterion tests. - The `rsrc` directory contains some samples of audio files that you can use for testing purposes. ## A Note about Program Output What a program does and does not print is VERY important. In the UNIX world stringing together programs with piping and scripting is commonplace. Although combining programs in this way is extremely powerful, it means that each program must not print extraneous output. For example, you would expect `ls` to output a list of files in a directory and nothing else. Similarly, your program must follow the specifications for normal operation. One part of our grading of this assignment will be to check whether your program produces EXACTLY the specified output. If your program produces output that deviates from the specifications, even in a minor way, or if it produces extraneous output that was not part of the specifications, it will adversely impact your grade in a significant way, so pay close attention. **Use the debug macro `debug` (described in the 320 reference document in the Piazza resources section) for any other program output or messages you many need while coding (e.g. debugging output).** # Part 1: Program Operation and Argument Validation In this part, you will write a function to validate the arguments passed to your program via the command line. Your program will treat arguments as follows: - If no flags are provided, you will display the usage and return with an `EXIT_FAILURE` return code - If the `-h` flag is provided, you will display the usage for the program and exit with an `EXIT_SUCCESS` return code. - If the `-g` flag is provided, you will generate audio data containing DTMF signals; reading "DTMF events" from `stdin` and writing audio data to `stdout`, exiting with `EXIT_SUCCESS` on success and `EXIT_FAILURE` on any error. - If the `-d` flag is provided, you will perform DTMF detection; reading audio data from `stdin` and writing DTMF events to `stdout`, exiting with `EXIT_SUCCESS` on success and `EXIT_FAILURE` on any error. > :nerd: `EXIT_SUCCESS` and `EXIT_FAILURE` are macros defined in `
` which > represent success and failure return codes respectively. > :nerd: `stdin`, `stdout`, and `stderr` are special I/O "streams", defined > in ``, which are automatically opened at the start of execution > for all programs and do not need to be reopened. Some of these operations will also need other command line arguments which are described in each part of the assignment. The usage scenarios for this program are described by the following message, which is printed by the program when it is invoked without any arguments:
USAGE: bin/dtmf [-h] -g|-d [-t MSEC] [-n NOISE_FILE] [-l LEVEL] [-b BLOCKSIZE] -h Help: displays this help menu. -g Generate: read DTMF events from standard input, output audio data to standard output. -d Detect: read audio data from standard input, output DTMF events to standard output. Optional additional parameters for -g (not permitted with -d): -t MSEC Time duration (in milliseconds, default 1000) of the audio output. -n NOISE_FILE specifies the name of an audio file containing "noise" to be combined with the synthesized DTMF tones. -l LEVEL specifies the loudness ratio (in dB, positive or negative) of the