4 October 2012

Sample rates, Signalink USBs, wspr and transmit audio issues

Well, wspr has been running and seemingly working ok on my Ubuntu 12.04 x86_64 machine for a few days, but I still have an unresolved issue that causes me some concern.  Whilst this issue doesn't prevent wspr from working, it does cause a crackling, popping noise to be added to my transmitted audio.

To be honest, I'd noticed this once before, when transmitting pks31 though my Signalink USB  and on out through the new KX3.  I heard the noise on the KX3's sidetone, but then forgot about it after reducing the monitor volume.

I heard it again when monitoring the wspr transmission on another radio, and resolved to track down the cause.  I've also been having other issues with Pulse Audio on Ubuntu 12.04 x86_64 so had a strong bias towards an assumption that the problem lay in the OS itself (or some part of the sound system).

However, I was using PortAudio for both wspr and fldigi, so it seemed unlikely that Pulse was the direct cause. Restarting the pulse audio daemon didn't seem to help.

I wondered if the slightly unconventional wiring arrangement between the KX3 and the Signalink USB might be allowing RF feedback into the audio circuits in the Signalink, so I disconnected it completely from the radio and switched the speaker I've been using from the Aux output of the Signalink to the Moni output, so I could monitor the TX audio.  Sure enough, the popping noise was still present when wspr transmitted. Not an RF issue then.

Someone on the LHS podcast forum asked if the popping noise was present on other audio outputs.  I reconfigured wspr to use the laptop's speakers as an output and the signal sounded clean.  They also suggested checking sample rates for the soundcard configuration. I found that wspr seemed to have no method for setting the samplerate, but after some googling discovered that it 'expected' a sample rate of 48kHz.  I wondered what sample rate fldigi had been using and noted that it was using the default sample rate for the soundcard (the Signalink USB), which I then determined to be 44.1kHz.  I then confirmed that I still got the popping noise on TX audio from fldigi by invoking the Tune function.  Switching fldigi to use a 48kHz sampling rate cured the popping noise.

Wanting to be sure that this wasn't a fluke, I fired up gnuradio-companion and sketched out an AF signal generator that could run at different sample rates (see image below).



Using this as an audio signal generator with the Signalink USB device, I confirmed that with a sample rate of 44.1kHz the popping was present, but at 32kHz and 48kHz it was OK.

I thought it weird that wspr required a 48kHz sample rate but seemingly didn't use one.  I took a look through the wspr code and it seemed to request 12kHz for transmit and 48kHz for receive audio streams.  I tried to debug it, but gdb wasn't having any of it.  Being a mixture of python, fortran  and C I wan't surprised.  I wasn't that keen on it myself, but each to their own :P

I confirmed though that  the signalink did in fact seem to be set to 48kHz during transmission:

darren@len:~/src/wspr$ cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 48000 (48000/1)
period_size: 8192
buffer_size: 16384
darren@len:~/src/wspr$ cat /proc/asound/cards
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xf1600000 irq 45
 1 [CODEC          ]: USB-Audio - USB Audio CODEC
                      Burr-Brown from TI USB Audio CODEC at     usb-0000:00:1d.0-1.2.4, full speed
darren@len:~/src/wspr$ cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 48000 (48000/1)
period_size: 8192
buffer_size: 16384

During reception, it was also set to 48kHz:

darren@len:~/src/wspr$ cat /proc/asound/card1/pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 48000 (48000/1)
period_size: 8192
buffer_size: 1638
Note that checking the TX settings reads the pcm0p (playback) values and the RX settings are from pcm0c (capture), both from card1 in my case.  If you check the settings for the playback stream whilst wspr is receiving (and vice versa) the streams are reported as closed.

Currently I'm stumped.  Whilst wspr seems to work OK, transmitting a noisy signal is something I'm not keen on, so I think I'm done with it for now, until the issue is resolved, somehow.


No comments: