#!/bin/bash## 1KHz.sh## A very simple DEMO crude sinewave generator using the device /dev/audio.# It is an eight second burst and generates an approximation of a pure sinewave using linear interpolation.# The "sinewave.raw" file length is 65536 bytes in size...

# Zero the raw file...> sinewave.raw

# This is the b byte data list for the crude sinewave.data="\\x0f\\x2d\\x3f\\x2d\\x0f\\x03\\x00\\x03"

# Generate the file as an eight second burst...for waveform in {0..8191}do printf "$data" >> sinewave.rawdone

# Now play back a single run of the raw data for about eight seconds.cat sinewave.raw > /dev/audio

# End of 1KHz.sh DEMO...# Enjoy finding simple solutions to often very simple problems... ;o)

Scratch that one...
You might like this one instead, 8 second burst 1KHz pure
sinewave as a .WAV file that uses ALSA aplay command...

The one you have tried uses a logarithmic approach because it
uses /dev/audio, /dev/dsp is much better and this a much more
advanced variant.

It is still 8 bit depth, mono, unsigned integer at 8KHz sampling
and the the header can be used for literally ANY 65536 byte
RAW file you care to generate.

/dev/audio and /dev/dsp have linear interpolation, which is what
I prefer as external single or double pole filtering is simple to do.
OTOH the .WAV file generated is a very pure sinewave due to
DSP filtering.

Once run the sinewave.wav file can be saved anywhere and used
on other devices like my 'phone which is now my signal source
for AudioScope.sh

Try a triangular waveform using linear related HEX values in
place of the sine values for 8 points...

Be well aware of word wrapping, copy and paste errors, etc...

Enjoy...

EDIT:
This is the basis for an arbitrary LF Audio Function Generator
although the one I am starting to work on will sample at 48HKz,
stereo, 16 bit depth, etc...

Since posting my original question, I have subsequently worked out how to modify the hex values of the look-up table to get other frequencies and also modified your script so as not to write to a file but rather a variable and then printf the variable to /dev/dsp.

The reasons I prefer not to use any audio players is that they require the audio to be played from a file (which I'm not doing) and also I need to play the tone for as long as a key is pressed thus it's easier to play from a variable than a fixed length file containing the audio samples.

For my application, super accurate or low distorion tones are not required so both /dev/audio and /dev/dsp will suffice.

If I need to save the samples as a wav, I can always append a header to a file then add the audio samples after it.

Thanks for that Bazza.
What would be nice is to add a small AM/SW transmitter and modulator to your morse script so that the tones can be heard on a nearby radio.
The youngsters should enjoy that.

Below a schematic for a simple low power transmitter that shouldn't break any laws.
One could decrease range by using an AC coupled dummy load (several Kilo-ohms).
Keep in mind that the self contained xtal osc has a TTL output.

Glad you liked it.
The transformer type is not critical.
The headphone output of sound cards are pretty tolerant of loads in the 32 to 1000 ohm range so as long as the primary of the transformer has an impedance in this range you're fine.

For the secondary, the only real important thing is for it not to have too high a DC resistance else the volt drop to the osc will be too high.

You can use a LT700 if you have one lying about.
Small 100V line to 4/8 ohm transformers (as used on public address systems) would also work and so would a small mains transformer (mains side to computer, low voltage side to osc).
Mains transformers don't have a good frequency response but for this application, they're just fine.

For the osc module, they are widely available (loads of different freqs), cheap as chips and easy to solder to even with no PCB.

Herewith preliminary script and test circuit.
Note that both a still work in progress.

The application is to be able to control four small DC motors (the type often used in toys) using no special ports (such as LPT, Serial or USB) thus eliminating all the complexities associated with the code required to access these ports.
This leaves only the audio output.
What the script does is monitor the "w", "a", "s" and "z" keys and whilst any one is pressed, it outputs a corresponding tone.
The circuit uses four tone decoders to receive these tones and convert them to a high or low to drive the motors.
The "t" key terminates the script.

Note that the tones are a bit rough still and there are "clicks" whilst looping.
The circuit also still needs some refinement.

# ================================================# Generate the 4 lookup tables to give aprox# 1/2 sec tones.# Note that the tones have "clicks" when looping# this is due to the sample values not being# optimized, however since the audio output will# be driving PLL tone decoders (1 per tone), these# "clicks" are not a problem.# Needs dedicated hardware interface.# ================================================

for waveform in {0..511}doData1K=$Data1K$Table1KData2K=$Data2K$Table2KData3K=$Data3K$Table3KData4K=$Data4K$Table4Kdone

Just one point.
Sound cards are usually output inverted, i.e. \x00 is maximum output \xFF is minimum output. With a sinewave or squarewave this is immaterial but if you want, say, a pulse then be aware.

/dev/dsp and /dev/audio are 8 bit unsigned integer so the DSP __zero_offset__ point is \x7F or \x80 allowing for any bit error in the DSP device...

Glad you enjoying this as much as I am, after all this is exactly what makes Linux so nice, having the freedom to experiment without the constraints imposed by a corporation that decides what we should be able to do and how.

It's only a pity one can't change the sample rate and number of bits for /dev/dsp or /dev/audio without resorting to IOCTL, which then necessitates using something like C which would need compiling and have a bunch of lib dependencies which would no doubt cause a few problems across different OS' like Linux and Mac.
Assuming of course that all /dev/dsp and audio can actually support higher resolutions.