Audio Streaming

A4: Audio Streaming  
 1/16  
A4: Audio Streaming  
Due Sunday by 11:59p.m.  
Points 200  
Available after Mar 13 at 12a.m.  
Last updated Apr. 2  
WARNING: Please define any additional macros or functions using libas.h (.c), we may need to  
override your particular as_*.h files for the automated testing, thank you!  
Table of Contents  
1. Introduction  
1.1. Background  
2. Basic Outline  
2.1. Setup  
3. Implementation  
3.1. Passive Application Architecture  
3.2. Active Application Architecture  
3.3. Request Format  
3.4. Dynamic buffering  
4. Tasks  
4.1 Server Tasks  
4.2 Client Tasks  
5. Grading scheme  
6. Software you’ll probably need and some tips about how to proceed  
6.1. Debugging the server or the client separately  
6.2. Ensuring files received by the client match the server  
6.3. Playing audio data (and how to install mpv)  
6.3.1. Listening in the labs  
6.3.2. Using real files  
7. Updates and clarifications (check back here as needed)  
8. Concluding remarks  
1. Introduction  
In this assignment, we will endeavor to develop a system of interconnected applications in one of the  
most often-used and fundamental configurations: a server and accompanying client(s) connected  
through sockets. This particular server will serve a small music (media file) library such that compatible  
clients will be able stream the files on the server’s library, save the files locally, or both.  
 A4: Audio Streaming  
 2/16  
In essence, streaming means that files can be requested from the server, and they are sent  
progressively and intermittently in chunks. Your implementation will be able to support many different  
media file types, including wav , mp3 , ogg , flac , etc.. The clients will use a dynamic buffer to receive  
as many packets as are available, as they become available, before redirecting them to their appropriate  
destination.  
1.1. Background  
For this assignment, multiple clients will be able to simultaneously stream available audio files from the  
server. The client and the server will be using sockets to communicate with each other while transferring  
text or binary data.  
Roughly speaking, the server is responsible for 2 things:  
1. Scanning and maintaining a “music library” –写Audio Streaming which for this assignment, will simply be maintaining a  
list of files with correct extensions from a specified library directory (default: library/ ). See Section  
6.3.2 to download a sample library that you may use to complete the assignment.  
2. Listen for clients and handle clients in their own child process. The server will wait and retrieve the  
exit status of all children under normal operation. Part of handling, is receiving and responding to  
requests.  
The client, on the other hand, will be responsible for:  
1. Making requests and receiving responses  
2. Managing an accompanying media player process named mpv (https://mpv.io/) , which is a free,  
open source, and cross-platform media player. For installation information, please see Section 6.3  
(https://q.utoronto.ca/#org2f62d44) .  
2. Basic Outline  
The majority of the design is provided to you in the starter code, and you are tasked with completing:  
1. Server side processing of received requests and associated responses, for:  
1. Listing all files  
2. Streaming particular files  
3. Setting up the server to listen on the specified port number  
2. Client-side sending of requests and receiving responses, for:  
1. Creating requests to list or stream files  
2. Receiving files with dynamic buffering  
3. Storing files as they are received  
4. (Separately from local storing) Piping files to an accompanying audio (media) player process  
The challenge in this assignment is ensuring that no bytes are lost, all bytes are transferred and received  
in the right order, and this is done without memory errors, as well as feeling comfortable working with an  
 A4: Audio Streaming  
 3/16  
already developed, and somewhat larger codebase. Throughout the starter code there are TODOs that  
must be completed. The functions and structs defined in the three header files as_client.h as_server.h  
and libas.h should not change, but you may add to these headers as you need, and change the values  
of different macros.  
2.1. Setup  
Follow the instructions carefully, so that we receive your work correctly.  
Your first step should be to log into MarkUs (https://markus.teach.cs.toronto.edu/2024-01/courses/16/) and  
navigate to the A4 assignment. Then, at the bottom of the assignment page, click on the button labelled  
"Add Starter Files to Repository".  
Then, open a terminal on your computer and do a git pull in your existing CSC209 MarkUs repository.  
Inside the repository, you should see a new folder name A4 containing the starter files for this  
assignment.  
Starter Files  
as_server.c: contains code that implements the audio streaming server. You should modify this  
file to complete the missing server features.  
as_server.h: the header file for functions and structs that are defined and used in as_server.c. Do  
not change.  
as_client.c: contains code that implements the audio streaming client. You should modify this file  
to complete the missing client features.  
as_client.h: the header file for functions that are defined in as_client.c. Do not change.  
libas.c: contains common code that are used by both the server and client. Do not change.  
libas.h: contains the function prototypes and structs that are used by both the server and client. Do  
not change.  
stream_debugger.c: a simple debugging program that can help you with debugging your streaming  
service. Do not change.  
Makefile: a script that is used to simplify compilation of your program. Do not change.  
Compilation  
You should use the following command in your A4 folder to compile your source code:  
make  
If your submission does not compile, you will receive a mark of 0. If the compilation displays warning  
messages, you will lose 10% of the total mark. It is your responsibility to ensure that your submission  
works on teach.cs.  
 A4: Audio Streaming  
 4/16  
Note that the Makefile will generate a file named port.mk which randomly assigns a default port number  
for you. This is to minimize the chance where you and another classmate accidentally use the same port  
number on teach.cs and negatively affect each other's work, e.g., if someone else is using your port  
number, you won't be able to start the server.  
After compilation, you can simply run the server as follows:  
./as_server  
Once the server is up and running, you can run the client to connect to the server:  
./as_client  
Note: while the starter code compiles, you will not be able to start the server until you complete the  
following:  
1. See Section 6.3.2 to set up your media library. Note: your server code does not need to handle an  
empty library, so you need to make sure your library has at least one valid audio file.  
2. The initialize_server_socket function.  
If at any point, you are tired of the excessive debug output, you may re-compile your code in release  
mode.  
make clean  
make release  
Remember that debugger symbols are not available in release mode, so you will not be able to gdb your  
program. Note that you will also need to run make clean before running make again to go back to debug  
mode.  
3. Implementation  
A passive process is on a machine known as the “server”, somewhere on the network. This process is  
bound to a particular port accompanying the network address for the machine.  
3.1. Passive Application Architecture  
The passive process’s main/original process sets up a socket for incoming connections and uses  
select to manage whether clients are connecting, or if it locally receives 'q' on stdin , implying the  
application should shut down. This is managed through the run_server function, which also re-scans the  
library after a certain amount of iterations of it’s main loop. It also passively checks for the termination of  
any existing child processes.  
Each new connection is managed in a child process by (immediately calling) handle_client , which  
receives the current layout of the library for the duration of the connection. It is responsible for receiving  
 A4: Audio Streaming  
 5/16  
and responding to requests from the client.  
Any requests to stream a file are written to the connected client in chunks of a maximum size:  
STREAM_CHUNK_SIZE .  
3.2. Active Application Architecture  
The “client” application is a single active process anywhere on the same network as the “server”,  
including the same machine. It features a small shell; see the client_shell function, featuring the  
following commands:  
1. list – to list the available files in the server’s library  
2. get <index> – to save a particular file to client’s library directory  
3. stream <index> – to stream a particular file without saving it  
4. stream+ <index> – to stream a particular file and save it to the client’s library  
5. help – to list the available commands  
6. quit – to quit the application  
These boil down to two types of requests:  
1. listing the available files.  
2. streaming a particular file.  
The client will receive the library list and then be able to request a file to be streamed by it’s library index.  
Commands 2-4 ultimately leverage stream_and_get_request with different arguments. This function will  
also use select to accomplish interleaved and non-blocking: reading from the socket connection, writing  
to the file-system and playing audio through the audio player. See Section 6.3, for more information on  
how to stream the received files. The client must successfully wait for this process to terminate as  
appropriate.  
3.3. Request Format  
List Request  
To send a list request to the server, the client would send the following text data:  
"LIST\r\n"  
The server will respond with a list of files in the format index:filename, one file per line, in text format.  
The list is returned as a single string with each file starting with an integer corresponding to it's index in  
the library, in reverse order. A colon separates the index and the file's name. Each entry is separated by  
a network newline "\r\n" (2 chars). For example, if the library contains the files "file1.wav",  
"artist/file2.wav", and "artist/album/file3.wav" in this order, the data sent to the client will be the following  
characters:  
 A4: Audio Streaming  
 6/16  
For example:  
"2:artist/album/file3.wav\r\n1:artist/file2.wav\r\n0:file1.wav\r\n"  
Stream Request  
To send a stream request to the server, the client would send a mixture of text and binary data. The text  
data is exactly the following:  
"STREAM\r\n"  
and a 4-byte binary data should follow, that represents the requested file index. For example, to stream  
file index 3, a full packet will look like this in hex:  
5354 5245 414d 0d0a 0000 0003  
S T R E A M \r\n |-- 3* -|  
*3 is in 32-bit big endian byte order.  
Note that the file index needs to be in network byte order, i.e., big endian byte order.  
If the file index exists, the server will respond by first sending the size of the file in network byte order,  
then sending a series of data chunks in the following format:  
[-- size of file --][ ----- data chunk 1 -----][ ----- data chunk 2 -----][ -- last data chunk -- ]  
<---- 4 bytes -----><------ 1024 bytes -------><------ 1024 bytes -------><-- up to 1024 bytes --->  
Note that the last chunk of data is can be less than 1024 bytes. For example, suppose the you send a  
text file with the content "hello world" using this protocol, the server response will look like this in hex:  
0000 000b 6865 6c6c 6f20 776f 726c 64  
|- 11 --| h e l l o _ w o r l d  
Hint: 0x0000000b is the decimal 11 in big endian, which is the size of the file.  
3.4. Dynamic buffering (client-side)  
First thing that you’ll need to take a look at is the realloc function documentation. Have a quick read of  
man realloc .  
The intended dynamic buffer is as follows, and shall receive full marks if successfully accomplished.  
Marks for alternative solutions will be subject to TA discretion. The simplest of which is a fixed size array  
on the stack (or the heap*), and this will receive 1/3 of the buffering grade, even if everything else is  
perfect. The keyword here is dynamic, so the realloc function will probably be your friend. Any solution  
that does not implement dynamically changing buffer sizes on the client can achieve a maximum grade,  
of at most, 90% on this assignment overall (only a third of the 15% awarded for dynamic buffering,  
because technically any non-static buffer is kind of dynamic).  
 A4: Audio Streaming  
 7/16  
The intended/aspirational implementation features two buffers: one to read directly from the socket --  
which will be of a fixed size ( NETWORK_PRE_DYNAMIC_BUFF_SIZE ) allowing at most this many bytes to be read  
from the socket each time select indicates it is ready. Then, a second and dynamic buffer to hold all the  
bytes that have been received by the client, but not yet been written to (both) the audio process pipe and  
library file (as needed). This includes what was read into the first buffer, and any bytes that you have no  
managed to write to the other targets yet. If the byte hasn’t been written out to each fd (or one of them if  
not doing stream+) yet, it should be held in this second buffer that dynamically grows, so that the first  
can read from the network again. All bytes from the first fixed buffer move through the second dynamic  
one.  
The first bytes of the dynamic buffer shall contain the next bytes that need to be written. So, upon  
reading the first, say, four bytes from the server, in your first fixed buffer, you then make your dynamic  
buffer 4 bytes in size and move those bytes into the second buffer in the order they were received.  
As more bytes are received from the network, your second buffer should expand to contain the additional  
bytes. “Simultaneously”, you should be writing to one or both of the audio and file destinations, starting  
from the beginning of the buffer. It is sufficient to simply try to write the entire contents of the buffer to  
either stream when they are ready for writing. But, this doesn't guarantee that they well all be, in fact,  
written. Use the return value of write to get the number of bytes actually written, to update which byte  
each stream (audio or file) will need next for an unbroken stream of data.  
Once you’ve finished writing data out of the second buffer, you can look to see how many of the first  
bytes in the buffer are no longer needed, as in, ones that have already been written to both (for stream+ ,  
otherwise it is either) the audio and file streams. You should then resize your buffer so that it no longer is  
taking up memory for those bytes. So if your dynamic buffer had 100 bytes in it, and you wrote 20 bytes  
to the audio process and 15 bytes to the local library file, you can remove 15 bytes from the buffer,  
making a new buffer of 85 bytes in length. Somehow, the audio process must still start from the correct  
byte offset in this example, so it will be "ahead" of the local file.  
Note that the server should be sending the file’s bytes starting with the first byte in the file, and  
ending with the last, even though network-byte-order is big-endian. Endianess pertains to  
contiguous data-types, not files or streams of bytes.  
How do you accomplish this “simultaneously”? Well we will use select , and read from the network if  
select indicates that the connected socket has bytes to be read, and write to either file descriptor if it  
indicates that either file descriptor can be written to. Then use select again in a loop.  
*Allocated once and free'd once. Allocating and freeing multiple times for one file transfer/stream will be  
considered dynamic, but only the described solution is guaranteed full marks. Any other dynamic  
solutions will receive at least 50% (7.5/15) and up to 100% (15/15) for this portion of the work.  
4. Tasks  
 A4: Audio Streaming  
 8/16  
For each function listed below, there are descriptions of the expected functionality above the function  
signature in the header files, or above the function body for helper functions. You should consult them for  
more information on how to implement each function. Hint: there are some helper functions that have  
already been implemented for you to simplify some tasks. Please take some time to understand how  
they work.  
For each function, there is a list of errors that you must handle. If any of the listed error occurred,  
print a relevant error message (not tested but the TA will look at it) then return -1 (tested). If you  
have temporarily-allocated resources (e.g., heap memory, file descriptors), you need to free/close  
them before returning.  
General set of errors you must always handle for all functions:  
Reading or writing to socket failed.  
Memory allocation, e.g., malloc , failed.  
4.1. Server Tasks  
For the server, you are responsible for implementing the following functions:  
initialize_server_socket  
int initialize_server_socket(int port)  
The purpose of this function is to initialize a server socket up to the point of listening for connections. You  
should use the existing helper functions to complete this task. On success, return the file descriptor used  
for listening to connections.  
Hints:  
You should be calling init_server_addr and set_up_server_socket to complete this function. Take  
some time to learn what they do.  
For set_up_server_socket , use MAX_PENDING for the num_queue argument.  
list_request_response  
int list_request_response(const ClientSocket * client, Library *library)  
The purpose of this function is to respond to the client request for listing the files in your media library.  
See Section 3.3 for more information. You should take a look at the Library struct definition in libas.h ,  
and understand the purpose and format of each member variable.  
Advices:  
Take a look at _free_library in libas.c and make sure you understand the data structure. Then,  
take a look at scan_library in as_server.c and make sure you understand how the object is  
initialized.  
Use the write_precisely function to simplify writing to socket.  
You may assume filenames do not include newline characters.  
 A4: Audio Streaming  
 9/16  
You may assume the media library is never empty.  
Hence, you need to ensure there is at least one audio file in your library folder, otherwise the  
server will not send any response and the client will hang.  
stream_request_response  
int stream_request_response(const ClientSocket * client, Library *library, uint8_t  
*post_req, int num_pr_bytes)  
The purpose of this function is to respond to the client request for streaming a particular file.  
The file is streamed in chunks of maximum STREAM_CHUNK_SIZE bytes. The client will be able to request a  
specific file by its index in the library. Please see Section 3.3 for more information.  
It is important to understand the post_req and num_pr_bytes parameters, because there is no guarantee  
whether the file_index data from the client is included in the request packet, or would come afterwards.  
This could happen:  
# only 1 byte out of the 4 bytes for file_index came with the stream request  
"STREAM\r\n" + 0x00  
The post_req parameter is a pointer to the end of the stream request data (after the \r\n ), and  
num_pr_bytes tells you how many bytes of data are available in post_req . In the above example,  
num_pr_bytes would be 1.  
To successfully complete this function, you must look at num_pr_bytes and determine how many more  
bytes you need to read from client_socket . If num_pr_bytes is 4, then you don't need read anymore.  
After you have the 4-bytes of data, you need to convert it from network byte order back to native byte  
order so that the value is correct. Hint: use ntohl .  
Errror Handling:  
If any of the following error occurred, print a relevant error message (not tested but the TA will look at it)  
then return -1 (tested). If you have temporarily-allocated heap memory, you need to free it before  
returning.  
The file index does not correspond to a valid media file, i.e., index out of range. (unfortunately, this  
will cause the client to hang, but it indicates that you sent an invalid request).  
Requested file does not exist (this can happen if someone deleted the file and your server hasn't  
realized it yet).  
num_pr_bytes is greater than 4 (think time: why is this an error?)  
4.2. Client Tasks  
For the client, you are responsible for implementing the following functions:  
get_library_dir_permission  
 A4: Audio Streaming  
 10/16  
int get_library_dir_permission(const char *library_dir, mode_t * perpt)  
Given the name of the library folder library_dir , return its permission through the output parameter  
perpt . If library_dir does not exist, create it with the permission 0700 . On success, return 0. You may  
assume perpt is never NULL .  
Hint: you will need to use the stat system call and mkdir system system call.  
Error Handling:  
Any of the system calls you made failed.  
Except in the case where the first time you call stat , the library folder does not exist.  
list_request  
int list_request(int sockfd, Library *library)  
Send a list request (please see Section 3.3) to the server and store the list of available audio files in the  
library object. Upon success, print the list of audio files by their file_index in ascending order, and return  
the number of files available in the library, e.g.:  
0: flac/teenage-ant-marching-band.flac  
1: m4a/atmospheric-eerie-song.m4a  
2: m4a/night-sessions.m4a  
3: mp3/dark-evil-piano.mp3  
4: mp3/encryption.mp3  
5: mp3/im-your-dj.mp3  
6: ogg/permsound.ogg  
7: ogg/rainbow-disco-bears.ogg  
8: wav/ac-guitar.wav  
9: wav/afx-study.wav  
10: wav/cha-cha-ender.wav  
11: wav/magic-harp.wav  
12: wav/wedidit.wav  
13: wav/weird-synth.wav  
Use the following format specifier to print each line to standard output: "%d: %s\n" .  
Advices:  
Take a look at _free_library in libas.c and make sure you understand what is heap-allocated and  
what isn't. Then, take a look at scan_library in as_server.c and make sure you understand how the  
object is initialized. You can re-use some of the logic to implement this function, e.g., instead of  
reading from the file system, you are reading and parsing the response packet from the server.  
Most of the response packet parsing is done for you in the function get_next_filename . Learn how to  
use the function.  
Error Handling:  
get_next_filename failed.  
start_audio_process  
 A4: Audio Streaming  
 11/16  
int start_audio_player_process(int *audio_out_fd)  
Create the audio player process, and redirect standard input to it. Use the AUDIO_PLAYER and  
AUDIO_PLAYER_ARGS macro constants for setting up arguments to exec .  
Notes:  
Because the audio player process sometimes takes a while to boot up, you should sleep for  
AUDIO_PLAYER_BOOT_DELAY seconds.  
If you are using WSL, the executable name will be "mpv.exe" instead of just "mpv". You can deal with  
this discrepancy by temporarily changing the macro AUDIO_PLAYER (defined in as_client.h ) from  
"mpv" to "mpv.exe". However, do not check this change in.  
Error Handling:  
Any of the system calls you made in the parent process failed.  
send_and_process_stream_request  
int send_and_process_stream_request(int sockfd, uint32_t file_index, int audio_out_fd, int  
file_dest_fd)  
This is the meat of this assignment. The purpose of this function is to simultaneously receive data from  
the server, save data to a file, and steam data to the audio process. You are required to use select to  
accomplish this feat. Failure to use select will result in 0 for this function.  
Please see Section 3.3 for information on how to send a stream request packet, and what the server  
response looks like.  
Before returning from this function (failure or success), you must close the two file descriptors,  
audio_out_fd and int file_dest_fd .  
Advices:  
Because an audio file can be extremely large (e.g., 4GB), it would be infeasible to preallocate a  
buffer for the entire incoming file. Therefore, you need create a dynamic buffer for receiving data and  
writing data to one or both file descriptors. Please see Section 3.4 for more information on how to  
implement this. However, you may create the entire buffer in memory just as a intermediate step to  
get things working, before attempting dynamic buffering.  
Use the timeout macro constants for setting up select 's timeout argument: SELECT_TIMEOUT_SEC and  
SELECT_TIMEOUT_USEC .  
Error Handling:  
Both file descriptors, audio_out_fd and int file_dest_fd , are invalid, i.e., -1.  
If you receive more data than what the specified file size is, print an error message (not auto-tested,  
but we will look at your code) and disregard the extra bytes (do not return -1).  
 A4: Audio Streaming  
 12/16  
5. Grading scheme  
The following is a breakdown of the grading scheme for this assignment:  
10% style  
30% memory management (valgrind testing)  
15% server/client each  
20% server functionality  
25% client functionality (independent of dynamic buffer)  
15% Implementation (TA inspection) of client-side buffering  
Max 5% if not dynamic  
6. Software you’ll probably need and some tips about  
how to proceed  
6.1. Debugging the server or the client separately  
The basic utility known as netcat or nc (see man nc ) is ideal for sending or receiving raw text  
(amongst other things with some work). You can use nc to setup a dummy server that you can view  
requests with, and type back responses to your client (locally on your machine, bound to port 3456) like  
this:  
nc -v -C -l -p 3456  
This sets up verbose printing, network newlines to be sent everytime you hit enter ( \r\n not just \n ,  
notice that our requests make use of this), and listening – essentially a passive network process.  
You can configure an active netcat process as follows, more commonly referred to as a client to connect  
to this server with:  
nc -v -C localhost 3456  
Try running both, in seperate terminals, side-by-side and start entering data into either side. Notice how it  
pops up in the other terminal. Once you get your client or server implementations working, you can swap  
out one of these netcat programs for your solution, e.g. connect your as_client to an nc server.  
Note, you can also run the server on teach.cs, and then connect by replacing localhost with  
teach.cs.utoronto.ca, then you can run the server after ssh'ing into teach.cs, and the client locally or on  
teach.cs, and connect to the server that is running on teach.cs!  
I recommend implementing the server first, since a lot of heavy lifting has already been done for you in  
this application. Then you can try running something like this before implementing the client, to see that it  
is possible:  
 A4: Audio Streaming  
 13/16  
echo -e "STREAM\r\n\x00\x00\x00\x02" | nc -C <server-address> <port> | dd bs=1 skip=4 | tee filenam  
e.wav | mpv -  
This should allow you to retrieve the file with index 2 (notice the last of 4 hex bytes is 0x02 in the echo  
message) from the server, skip the first 4 bytes of response (the file’s size as an unsigned int sent by the  
server), save it to filename.wav and play it through mpv . This solution may not produce a perfect  
filename.wav depending on how you kill the line of commands. But, in effect, the client’s most difficult  
task can be accomplished through this line of shell script with fairly standard programs. Nonetheless we  
are going to do the dynamic buffering as an exercise and a demonstration of how one might buffer  
media. The portion of \x00\x00\x00\0x02 above, indicates 4 hexadecimal numbers. Network byte order  
is big-endian, so the above is the number two, expressed as a 32-bit big-endian integer.  
6.2. Ensuring files received by the client match the server  
The command line utility diff will report when two files differ, so use this to check that the received file  
is the same as the one on the server. If they are identical, it will print nothing! Alternatively cmp also  
provides good output. These are sufficient tools, but are hard to use for binary files. Remember that you  
can send and recieve (though not actually play anything through mpv) any file data you like, as long as  
the extension is compatible (see libas.h). This means you can debug with files containing only ASCII text  
in them, and use diff tools like diff or cmp, or diff within your IDE to see where things went wrong.  
While you are working on receiving files, changing the size of buffers, or more specifically, the number of  
bytes you read or write at once, will help debug the process of sending and receiving data. Stepping  
through your code with smaller buffers and test files will really help.  
As a starting point, it may be helpful to create a dummy file in text format to test that file transfer is  
working. You will need to rename the file to have the extension .wav , otherwise the server will not pick it  
up. You should use the get command on the client to attempt transferring the file.  
6.3. Playing audio data  
To actually hear the output of the audio files (video files were not tested, I suspect you might need to  
enlarge some of the buffers for performance reasons, but it should probably work too, see  
SUPPORTED_FILE_EXTS and let me know on Piazza if you looked into it), you’ll be piping data into software  
that can decode any compression used to store the file and then relay the correct data to the audio driver  
system. The driver system is not consistent between Linux, Mac and Windows, so we will use the mpv  
(https://mpv.io/) project to do all this work in a cross-platform way, and allow us to experiment using  
files with arbitrary compressions/encodings/extensions (not all of which are compatible with streaming,  
but .mp3 and .mp4 containers should represent stuff that will work if you get this far). Note that you can  
use mpv's controls when you've exec'd the process (try using the arrow keys while music is playing).  
tldr: A good first step overall is installing mpv . You can use mpv to play media files directly through  
stdin by giving it the argument - , as in mpv -  
 A4: Audio Streaming  
 14/16  
On the teach.cs machines, the basic command aplay is sufficient to process .wav files, and is a good  
starting place if you need to limit output, but you should have access to mpv on the teach.cs machines  
as well, and this will give you some consistency across platforms. Install mpv on your local machine,  
make sure it is accessible “via command line” (i.e. it’s on your PATH ) and then switch to the mpv -specific  
macros in as_client.h .  
Most linux package managers provide mpv e.g. sudo apt install mpv but note if you're using the  
windows linux subsystem (WSL), you're probably better off installing mpv outside of the linux subsystem  
and linking to the executable (the application called mpv in the installation) on a correct path to be  
accessible to a bash terminal in WSL. It will take some digging to figure out. This github repo  
(https://github.com/jnozsc/mpv-nightly-build) hosts mac builds, and is linked to from mpv's main  
installation page. You'll still need to be able to access mpv from your shell's path.  
While this will be great when everything is working, we’ve also included the code for something called  
stream_debugger , which will help you debug what you are sending to the external process and when.  
6.3.1. Listening in the labs  
Please avoid disturbing others with playing any audio out of the speakers in the lab. There are  
headphone jacks on the lab machines, on the front of the desktop box (top jack is only microphone,  
bottom is headphones with optionally connected mic, use this with standard headphones):  
As well as an audio out (green; largely equivalent to the headphones, but perhaps slightly different  
voltages for additional amplification) on the back of the desktop box:  
 A4: Audio Streaming  
 15/16  
6.3.2. Using real files  
We have made a small library of free sounds for your testing (downloaded from https://freesound.org/  
(https://freesound.org/) ). You can get a zipped copy here  
(https://q.utoronto.ca/courses/337029/files/31062827?wrap=1)  
(https://q.utoronto.ca/courses/337029/files/31062827/download?download_frd=1) . You should unzip this file  
in the A4 folder. Make sure the library folder is created after unzipping. WARNING: do not check in  
the audio files into your repository. We have add a .gitignore file to make sure you do not  
accidentally make this mistake.  
If you are working on the teach.cs machine, you can also make a copy of the audio library from our  
course directory:  
# you should be in your A4 folder  
cp -R /u/csc209h/winter/pub/a4/library .  
You can also check out this article (https://creativecommons.org/about/arts-culture/arts-culture?resources/legalmusicforremixing/) for a bunch of free choices to add to your library, ccMixter had some  
fun things.  
7. Updates and clarifications (check back here as  
needed)  
Mar 20, 5:31pm PST (jsun): updated starter code and solution to be more const-correct. Removed  
the need to implement get_file_request , stream_request , and stream_and_get_request for the starter  
code.  
Mar 24, 7:47pm PST (jsun): updated handout to clarify that you may assume the server's media  
library is never empty.  
 A4: Audio Streaming  
 16/16  
Apr 1, 12:45pm EST (dee): Warning pertaining to avoiding adding to as_client.h and as_server.h.  
Use libas.h and libas.c for any macros or additional functions that need to be accessible across  
multiple .c files.  
Apr 2, 1:28pm EST (dee): There was some concern that the above meant that you could not change  
macro values, particularly AUDIO_PLAYER and/or AUDIO_PLAYER_ARGS in as_client.h. You can and should  
have fun changing all the macros as you like, but your solution will be tested using the values from  
the starter, as well as some additional values of AUDIO_PLAYER and AUDIO_PLAYER_ARGS to use a  
testing executable for testing the bytes going to the audio player process.  
Apr 2, 1:46pm EST (dee): I've made a variety of references to our dynamic buffer being a circular  
buffer. This is not a conventional use of this term bizzare use of a term I frankly have been otherwise  
familiar with: circular buffers tend to refer to buffers of a fixed size that write over the beginning of a  
buffer when they are filled (and then write in a circle). My usage of the term is based in circles being  
a useful expression of a line with infinite length and multiple entry/exit points and a general  
disposition towards using circular models over more linear dimensions.  
8. Concluding remarks  
This has been one of the most impressive instances of CSC209 in my memory, all things considered.  
This is understood to be a difficult course, and even making it through to the point of reading the end of  
this document should be understood as an accomplishment.  
As you complete this assignment savour your new knowledge and pat yourself on WX：codinghelp