inputting_20real-time_20audio
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
inputting_20real-time_20audio [2024/01/05 00:22] – external edit 127.0.0.1 | inputting_20real-time_20audio [2024/04/19 17:43] (current) – richardrussell | ||
---|---|---|---|
Line 1: | Line 1: | ||
=====Inputting real-time audio===== | =====Inputting real-time audio===== | ||
- | //by Richard Russell, November 2006//\\ \\ | + | Most PCs provide the capability of inputting audio, typically either from a microphone or from a line-level input. This article describes how a //BBC BASIC for SDL 2.0// or //BBC BASIC for Windows// program can read and process audio data from this source in real-time (i.e. without it having to be recorded to a file first). |
+ | |||
+ | ===== BBC BASIC for SDL 2.0 ===== | ||
+ | |||
+ | //by Richard Russell, April 2024// | ||
+ | |||
+ | ==== Preliminaries ==== | ||
+ | |||
+ | As is usual for programs accessing the SDL 2.0 API, it may be important to trap errors, or closing the window, so that the necessary ' | ||
+ | |||
+ | <code bb4w> | ||
+ | ON ERROR PROCcleanup : MODE 7 : PRINT REPORT$ : END | ||
+ | ON CLOSE PROCcleanup : QUIT | ||
+ | </ | ||
+ | |||
+ | The **PROCcleanup** routine is listed later. You may want to change the error reporting to a different method. | ||
+ | |||
+ | ==== Selecting the input device ==== | ||
+ | |||
+ | Typically the host system will have multiple audio input devices, which may include a **microphone** or a **line input** or a **Stereo Mix** etc. Your program must select which of these devices it wishes to input audio from, and the easiest way is probably to present a list to the user to choose from: | ||
+ | |||
+ | <code bb4w> | ||
+ | REM. Find number of audio capture devices: | ||
+ | SYS " | ||
+ | IF numDevices% = 0 ERROR 100, "No audio capture devices are available" | ||
+ | |||
+ | REM. List the capture device names and put them into an array: | ||
+ | DIM deviceName$(numDevices%) | ||
+ | PRINT " | ||
+ | FOR index% = 1 TO numDevices% | ||
+ | SYS " | ||
+ | IF @platform% AND &40 ELSE pname%% = !^pname%% | ||
+ | deviceName$(index%) = $$pname%% | ||
+ | PRINT ;index% ": " deviceName$(index%) | ||
+ | NEXT | ||
+ | |||
+ | |||
+ | REM. Get selected device from user: | ||
+ | REPEAT | ||
+ | INPUT "Enter device number: " index% | ||
+ | UNTIL index% >= 1 AND index% <= numDevices% | ||
+ | </ | ||
+ | |||
+ | You could of course present the choices and accept the selection in different ways, for example a dialogue box containing a list box plus OK and Cancel buttons. | ||
+ | |||
+ | ==== Choosing the buffer size ==== | ||
+ | |||
+ | The first step is to decide how large the audio buffer should be. To some extent this is an arbitrary decision, but it will depend on things like //latency// (how much time elapses between the audio arriving and it being processed by your program) and the amount of work needed to process the received audio data.\\ \\ It is vitally important that your program can process the audio data quickly enough, otherwise data will be lost, with undesirable results. If there is any variability in the rate at which you can process the data (for example it depends on disk or network accesses) then you may need to use a larger buffer to 'iron out' the fluctuation. In the example below the length of the buffer is 1024 samples; at 44100 Hz stereo that implies a latency of at least 24 milliseconds. | ||
+ | |||
+ | <code bb4w> | ||
+ | SamplesPerBuffer% = 1024 | ||
+ | </ | ||
+ | |||
+ | ==== Selecting the audio format ==== | ||
+ | |||
+ | The next step is to decide the audio //format// you will use: the principal choices being of sampling rate (the main ones being 11025 Hz, 22050 Hz and 44100 Hz) and number of channels (mono, 1 channel, or stereo, 2 channels). The higher the sampling rate the higher the audio frequency that can be received, but the more work your software needs to do. Normally you should choose the lowest sampling rate suitable for your application, | ||
+ | |||
+ | You set up the required audio format and open the audio capture device as follows: | ||
+ | |||
+ | <code bb4w> | ||
+ | DIM want{freq%, format{l&, | ||
+ | DIM have{} = want{} | ||
+ | want.freq% = 22050 | ||
+ | want.format.h& | ||
+ | want.format.l& | ||
+ | want.channels& | ||
+ | want.samples% = SamplesPerBuffer% | ||
+ | </ | ||
+ | |||
+ | ==== Opening the audio device and creating the buffer ==== | ||
+ | |||
+ | Now the audio capture device can be opened and the buffer created: | ||
+ | |||
+ | <code bb4w> | ||
+ | SYS " | ||
+ | IF Device% = 0 ERROR 100, " | ||
+ | |||
+ | BytesPerBuffer% = have.size% | ||
+ | WordsPerBuffer% = BytesPerBuffer% DIV 4 | ||
+ | |||
+ | DIM Buffer%(WordsPerBuffer% - 1) | ||
+ | </ | ||
+ | |||
+ | This code allows for the possibility that the capture device doesn' | ||
+ | |||
+ | ==== Starting audio capture ==== | ||
+ | |||
+ | Once you have initialised the audio device using the above code, you can start the real-time capture as follows: | ||
+ | |||
+ | <code bb4w> | ||
+ | SYS " | ||
+ | </ | ||
+ | |||
+ | ==== Inputting in real-time ==== | ||
+ | |||
+ | Once the above code has been executed you need to process the received audio buffers fast enough to keep up with the incoming data. The following code constantly cycles, filling the buffer and calling the **PROCprocessbuffer** routine: | ||
+ | |||
+ | <code bb4w> | ||
+ | REPEAT | ||
+ | p%% = ^Buffer%(0) | ||
+ | R% = BytesPerBuffer% | ||
+ | PROCprocessbuffer(p%%, | ||
+ | REPEAT | ||
+ | SYS " | ||
+ | p%% += I% : R% -= I% | ||
+ | UNTIL R% <= 0 | ||
+ | UNTIL FALSE | ||
+ | END | ||
+ | </ | ||
+ | |||
+ | In this example the audio processing continues indefinitely, | ||
+ | |||
+ | ==== Processing the audio data ==== | ||
+ | |||
+ | Obviously it's only possible to describe this aspect in general terms, because precisely what audio processing takes place will depend on what the program is designed to do. The code below simply calculates the RMS (Root Mean Square) value of the incoming audio: | ||
+ | |||
+ | <code bb4w> | ||
+ | DEF PROCprocessbuffer(B%%, | ||
+ | LOCAL I%, V%, sumsq | ||
+ | FOR I% = 0 TO N%*2-2 STEP 2 | ||
+ | V% = B%%!I% AND &FFFF : IF V% >= &8000 V% -= 65536 | ||
+ | sumsq += V%^2 | ||
+ | NEXT | ||
+ | RMS = SQR(sumsq / N%) | ||
+ | ENDPROC | ||
+ | </ | ||
+ | |||
+ | This code is appropriate for monaural input (one channel) where each audio sample consists of a signed 16-bit value in the range -32768 to +32767. | ||
+ | |||
+ | ==== Cleaning up ==== | ||
+ | |||
+ | When you stop the sound capture, or exit the program, you need to shut down the audio input in a controlled fashion: | ||
+ | |||
+ | <code bb4w> | ||
+ | DEF PROCcleanup | ||
+ | Device% += 0 | ||
+ | IF Device% THEN | ||
+ | SYS " | ||
+ | SYS " | ||
+ | Device% = 0 | ||
+ | ENDIF | ||
+ | ENDPROC | ||
+ | </ | ||
+ | |||
+ | This code might form part of a larger routine, if there are other things that need to be shut down. | ||
+ | |||
+ | |||
+ | |||
+ | ===== BBC BASIC for Windows ===== | ||
+ | //by Richard Russell, November 2006// | ||
+ | |||
==== Preliminaries ==== | ==== Preliminaries ==== | ||
inputting_20real-time_20audio.1704414125.txt.gz · Last modified: 2024/01/05 00:22 by 127.0.0.1