Wednesday, September 18, 2024

GNURadio Audio Sink Block For Windows Users

 

The GNURadio Audio Sink Block for Windows works well right out of the box. Here we’ll explore some things that don’t work as advertised as well.

 

GNURadio Audio Sink Block

Figure 1 shows the basic GNURadio Companion Audio Sink Block for Windows. The defaults will usually produce excellent results for most voice applications and some data applications.

 Figure 1 - GNURadio Audio Sink Block & Parameters

 

Parameters

ID - This is the name that will be used in the compiled Flowgraph. The ID can be changed to any valid Python name.

Sample Rate - A Dropdown box showing all the valid sample rates. Usually they are: 192k, 48k, 44.1k, 32k, 22.05k, 16k. where: 48k = 48,000 Killo Samples Per Second (KSPS). The Sample Rate can be any value from the drop down box or may be a valid variable name or python expression. For instance the field may be the Python expression: “samp_rate/decimation” as long as the variables samp_rate and decimation are declared elsewhere in the Flowgraph. More information below.

Device Name - If this field is blank, then the Windows Default Audio Output Device will be used. Otherwise this field is an Integer specifying which device to use, with “0” specifying the default device. More information below.

OK to Block - This allows the Audio Sink to apply “Back Pressure” or block the rest of the Flowgraph, thus acting like a Throttle. Usually this should just be left to “Yes”.

Num Inputs - An integer specifying the number of inputs to the block. Specifying “1” (Default) will be a Mono input that is delivered to both stereo speakers equally. “2” will specify two inputs that will map to the Stereo Left and Right outputs independently. Specifying a value greater than “2” will result in an error for most PC Sound Devices.

 

Sample Rate In Depth

For CW and voice communications demodulation that has an audio bandwidth of 6 kHz or less, setting the sample rate all the way down to 16 KSPS will work fine. When decoding low rate digital data such as VHF ACARS [1] the sample rate should be 48 or 192 KSPS so that there are enough samples for the decoder to work properly.

The ideal is to use an audio sample rate that is an integer divisor of the RF Sample Rate so decimations can be used exclusively instead of irrational resampling. For example: With a RF Sampling Rate of 2.4 MSPS, an overall Flowgraph decimation factor of 50 will result in an audio rate of 48 KSPS.

Note: I have noticed that on some Flowgraphs the lower sample rates sometimes get clicks in the audio. I assume that this is because there is some sort of interpolation going on in the device driver and it appears to be over or under-flowing the audio buffer. Just keep this in mind and test rigorously.

 

Device Name In Depth

The GNURadio 3.10 documentation (as of September 2024) states that a device's friendly name, as a string, can be used to specify the audio output device. Unfortunately, this is incorrect.

The GNURadio code actually uses the Windows C++ API WAVE_MAPPER functionality.

WAVE_MAPPER is a dynamic list of all the possible devices that can be used for Audio Input (Source) and Output (Sink) functionality.

For instance my Laptop by itself has one audio IO device, the inbuilt sound card. And the WAVE_MAPPER list will have only one entry for device “0”, or the default device.

When I connect my Laptop to my Docking Station, three other sound devices become available. The Docking Station has a Sound Card in it, the external Monitor connected to the docking station has a Sound Card in it, and finally the external Webcam also has a Sound Card in it. All these devices, when connected, cause the WAVE_MAPPER list to be reconfigured on the fly.

The Windows Sound Control Panel App allows a different default device to be reconfigured when the Laptop is standalone and when connected to my Docking Station. In my case, I have it configured to the Docks’ sound card that drives some external speakers when the Docking Station is connected.

WAVE_MAPPER device “0” is always the default device as configured by Windows. The other integer specifiers: 1, 2, and 3 in my case when connected to my Dock, can direct the audio to those devices. Unfortunately there is no direct way to tell which device is what hardware ID without writing some sort of utility to explore the WAVE_MAPPER list in real time.

But what you do know is that for any given configuration leaving the device name blank or putting a “0” there will always specify the Windows configured default device.

By trial and error, I found that my Laptops speakers were Device Name “1” when connected to my Docking Station. Hence if I use a Device Name of “1” when connected to my Docking Station I will be using the Laptops speakers. When I remove the Laptop from the Docking Station device “1” will not exist and the GNURadio code will fallback to the Windows WAVE_MAPPER default device, or in this case the Laptop Speakers.

This will work as long as no other sound devices are added or deleted to the system, as the WAVE_MAPPER may map the added or removed devices differently.

All you know for sure is that “0” is the Device Name for the default sound card.

If you specify a Device Name that does not exist, then the GNURadio code will fallback to the WAVE_MAPPER default device. Hence, you should always get some audio output on the default device. That’s a good thing.

A lot of Radio Sleuths use a “Virtual Audio Cable” to route the radios audio output to a virtual cable that can be sent to a software decoder. These Virtual Cables will also show up in the WAVE_MAPPER list.

Note: Check the console window in GNURadio Companion when running a Flowgraph, if there are any audio issues, a warning will be issued there.

 

Bonus

By running this command at a Windows command prompt you can get a list of the “MEDIA” or sound devices that are currently connected to your PC. It will list the "Friendly Name" but unfortunately won't tell you the current WAVE_MAPPER list mapping.

pnputil /enum-devices /class “MEDIA”

 

References

[1] ACARS is a low rate HF/VHF aircraft reporting system that  is popular to decode with SDR radios because the modulation bandwidth fits within a normal radios audio channel bandwidth - https://en.wikipedia.org/wiki/ACARS

 

No comments:

Post a Comment