Nothern Utah WebSDR Logo - A skep with a Yagi Northern Utah WebSDR
Creating "fplay" - a version of the Linux
"aplay" utility, but without the speed limit

What is "aplay"

"aplay" is a command-line utility found in many Linux distributions that is most often used to play audio files into audio devices, but it has other useful capabilities, including conversion between different types of audio files (sample rate, encoding format to name but a few) - but it also has the ability to take raw data being emitted by another program via "STDOUT" and send it, with appropriate handling of sample format and data buffering, into an audio device.

Why is this important?

If you found this page, you probably know that it's part of a series about getting raw 16 bit I/Q data from a receiver into the ALSA sound system - and the "aplay" utility is an important part of that signal path.  Consider the following:

Suppose you have a receiver of some sort that can produce raw 16 bit I/Q data and you want to get it into the WebSDR program.  One way to do this would be to have a program/driver that interfaced with that receiver hardware via its API and from this you simply need to spew out the data.  Using the "STDOUT" interface, this "raw" data may be emitted by the driver and "caught" by "aplay" and put into an ALSA device.

Comment:

In development, we experimented briefly with using "netcat" to convey receiver data in a similar manner, having the receiver's driver send data via the network interface to a (real or virtual) network device.  This worked fine, but it introduced about 100 msec of extra latency in the stream and consumed more CPU resources than "STDOUT".  The latter is of less importance than the former as it's desired that the latency between the received signal and its appearing on the user's computer should be kept as low as possible.

Having said that, sending data via a network interface is still a useful tool as it allows raw I/Q data to be shared with other computers on the LAN for other purposes (decoding of digital signals, CW skimmer, logging/recording, operation of an "OpenWebRX" server) - something also facilitated by the use of the "loopback" device mentioned in a related article.

While the Linux ALSA kernel was patched a few years ago to permit sample rates to through 768 kHz, many of the ancillary programs were not modified accordingly - this is true of the "loopback" module (the modification of which was discussed in a related article) and "aplay".  To mitigate this oversight, a version of this utility, called "fplay" was created by patching the code for "aplay" to make it agnostic to the data rate:  In other words it should be able to operate at any rate that can be fed to it, as long as the underlying ALSA kernel can also support it.

Making "fplay"

Important:

What follows has been tested ONLY on Ubuntu 18.x and 20.04.  Building "fplay" should be possible on other Linux distributions and versions, but the steps below may fail do to the lack of certain dependencies and/or differences in syntax.

The steps are as follows:
  1. Your system must have installed on it "make", "gcc" and "alsa-lib".  Use "sudo apt-get install libasound2-dev" and similar to get these dependencies as required.  (Google may be your friend here!)
  2. Created a directory called "fplay-source" (md fplay-source)
  3. Download the "fplay" source from HERE and place it in "fplay-source".
  4. Go to "fplay-source" and unpack the file:  "tar xf fplay.tar.gz".   If you are paranoid about using other people's source code, I suggest that you look at it yourself to make sure that it's not harboring anything untoward.
  5. Go to the newly-created "fplay" directory (cd fplay)
  6. Make the file by typing "make"
  7. If all goes well, you will now have a binary called "fplay".  The size of this binary should be 80-90 kbytes.  Note:  You won't be able to copy this binary into the "fplay-source" directory as it and the "fplay" directory will conflict due to their having the same name.


This drop-in replacement for "aplay" may be placed in whatever directory your script requires it to be invoked.  Note that you may need to use "chmod" as appropriate to give it the needed permissions to be run.  Remember that this version is missing a few of the features of "aplay" (such as the -t option).

Example:

A sample invocation is as follows:
./sdrplayalsa -r 768000 -f 3750000 | ./fplay -D plug:f_loop0_in -r 768000 -c 2 -f s16_le --disable-softvol -B 30000

In this example:
Conclusion:

The "fplay" utility is just one part of the system to take the raw 16 bit I/Q data from a receiver - in this case, an SDRPlay RSP1a - but it could be any receiver hardware capable of producing a suitable sample type and rate - and make it available to the PA3FWM WebSDR server as an ALSA device at up to 768 kHz.

The above has been tested and found to work on Ubuntu 18.x and 20.04, but it is not known if this same procedure will work for other Linux distributions like Debian.  If you try it on another distribution, please let us know if it works - and what it took to make it work if it didn't do so "out of the box".  At the time of writing, we don't have a Debian system on which to try/troubleshoot this installation.

Please understand that we don't have the time or inclination to try the above procedure on OSes other than Ubuntu 18 and 20 (there are so many!) so again, please let us know about your successes or failures so that we can let others know.


Acknowledgment:  I would like to thank Gary Wong, AB1IP, for taking the time to produce and test the patch to make the "fplay" utility, and for his help in writing the procedure for doing so.


STILL TO DO:  Write the article on the "sdrplayalsa" utility. 



Additional information:
 Back to the Northern Utah WebSDR landing page