quisk and wsjt-x

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

quisk and wsjt-x

Nick
Quisk works fine with my softrock rxtx.

Now I want to try to get wsjt-x working with this combination.

The snag is that wsjt-x only understands pulseaudio; it cannot use alsa devices directly.  So it cannot use the alsa loopback device that works so well with fldigi.

I have got wsjt-x to work with 2 instances of dttsp and sdr-shell using jack and the pulseaudio-module-jack package to route the audio.

The quisk documentation says "you can use the ALSA loopback device, or use PortAudio, PulseAudio or Jack to route your audio."

Been playing around with this for a couple of days and it seems that quisk is _not_ jack aware.  I must be missing something.

I can virtualise the loopback devices using ~/.asoundrc and make them available to jack using alsa_in and alsa_out, but when jack is running Config, Sound only shows

Available devices for capture
     M Audio Delta 44 ICE 1712 multi (hw:0,0)
     Loopback Loopback pcm (hw:1,0)
     Loopback Loopback pcm (hw:1,1)

No jack device names are listed.

The ALSA devices are not available to quisk when jack is running, so I need to be able to route everything via jack...

1. IQ from the softrock via jack to name_of_sound_capt
2. Audio from digital_output_name to wsjt-x input
3. Audio from wsjt-x output to digital_input_name
4. IQ from name_of_mic_play to the softrock

Is there a jack plugin for quisk I can use to make this work?

73

Nick G3VNC

Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

ahlstromjc
Administrator
Hello Nick,

Philip G. Lee contributed code to provide native PulseAudio support for Quisk.  It was added to version 3.6.17.  Hopefully, if you use the PulseAudio device, you can connect to Jack.  I haven't tried this, however.

The PulseAudio devices have a name that starts with "pulse" instead of an ALSA name like "hw:0".  I do not know how PulseAudio device names work, but I will try to find out.  For now, just use the device name "pulse" and see what happens.

Quisk has device names for ALSA and PortAudio that start with "alsa:" and "portaudio:" as well as PulseAudio.  Surely at least one of these will work with Jack.

Jim
N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

Nick
Hi Jim

thank you for your reply.  I've done a few more tests.

Here's what works with the softrock rx connected to the Delta 44 Inputs 1 & 2...

1. hw:0,0 -> sound_capt -> quisk -> sound_play -> hw:0,0

2. hw:M44 -> sound_capt -> quisk -> sound_play -> hw:M44

These configurations only use alsa.

2. hw:M44 -> sound_capt -> quisk -> sound_play -> hw:M44
                                                              -> digital_output -> hw:Loopback,0,0 -> fldigi
Again this only uses alsa.

3.  hw:M44 -> sound_capt -> quisk -> sound_play -> pulse -> M44

This uses alsa and pulse.

4. hw:M44 -> sound_capt -> quisk -> sound_play -> pulse -> Loopback -> fldigi

This works once.  Then it needs a reboot to work again.


Here's what doesn't work...

5. hw:M44 -> sound_capt -> quisk -> sound_play -> hw:M44
                                                              -> digital_output -> pulse
Need to reboot to recover from this.

The pure alsa configurations are solid as a rock.  You can shutdown one or both applications in either order and it will recover when they are restarted.  Anything involving pulseaudio is flakey.

Sadly wsjt-x 1.3+ will not work on linux without going through pulseaudio.

This works fine with a PC connected to a hardware radio.
 
But the only way I have found to connect wsjt-x to a software radio i.e. via another process, is by using jack.

dttsp uses jack natively to connect it's inputs and outputs so happy days.  Unfortunately there are other problems with dttsp, hence my interest in using quisk as the software radio.

Portaudio can reputedly be used as a way to connect applications to jack, although I haven't tried it.  Mint 17 uses jack2 which no longer supports portaudio as a backend under linux.  I plan to uninstall jack2 and install jack1 to test this.

I realise this might be a lot of work, but would you consider extending quisk to be a jack client?

http://sourceforge.net/projects/py-jack/

Looking at the sample code from that project, jack would need to regularly callback a jack.process function in quisk.  This means that quisk must not block on writes or reads from PCM devices.  I don't know if quisk could operate that way.

73

Nick G3VNC
Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

ahlstromjc
Administrator
Hello Nick,

Thank you for the additional information.  I do not run JACK, so I need a little time to work on this.  I will keep you posted.

Jim
N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

ahlstromjc
Administrator
In reply to this post by Nick
Hello Nick,

Linux has four independent sound systems, ALSA, PortAudio, PulseAudio and Jack.  I have looked for documentation on how this all works, and have found nothing.  Even the author's description of their own sound system is lacking.  So I have tried to reverse engineer my own Linux system to get some insight.

I am running Ubuntu 14.04LTS 32-bit.  By default, it runs PulseAudio as a daemon.  The settings/sound dialog box shows a list of input and output devices, an effects tab, and a list of applications using audio.  I am using ALSA devices directly with Quisk.   PulseAudio does not interfere with this, but Quisk does not appear on the list of applications.  If I change Quisk to use PulseAudio devices, Quisk works fine and also appears on the application list.  So I guess that PulseAudio does not demand exclusive control of sound hardware, and can co-exist with  applications that use ALSA directly.

I installed wjst-x version 1.1 and found a list of ALSA devices on the sound menu.  It seemed to work.  But then I remembered you were running 1.3.  I then installed wsjt-x version 1.4.  The sound menu shows a list of alsa_input and alsa_output names, but I could not get wsjt-x to work at all.  Also, wsjt-x appears on the application list for PulseAudio.  You said that wsjt-x requires PulseAudio, and that seems to me to be correct.  I looked for documentation on the wsjt-x sound system and found nothing.

You discussed using Jack.  Both PulseAudio and Jack seem to be doing the same thing, namely routing sound among applications and hardware devices, and so are not compatible with each other.  The advice from the Internet is not to run both at the same time.  But this is Linux, so there is a complicated way to run both if you want.

Quisk is not aware of PulseAudio or Jack.  The list of audio devices from Config/Sound are the hardware device names and the ALSA devices.

If wsjt-x requires PulseAudio, running Jack seems to be a bad idea.  The solution seems to be fixing the Quisk PulseAudio system so it works with wsjt-x.  Do you agree, or is there some reason you think Jack is necessary?

Jim
N2ADR

Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

ahlstromjc
Administrator
In reply to this post by ahlstromjc
Hello Nick,

I think I have a way to get wsjt-x to work on receive with Quisk.  The quisk configuration is:
  name_of_sound_play = "pulse"
  digital_input_name = ""
  digital_output_name = ""
Other needed Quisk devices use the ALSA names.

In wsjt-x choose the input audio device to be the ".monitor" of the device that is playing radio sound; that is, the default PulseAudio output device equal to name_of_sound_play.

This should work because Quisk will use PulseAudio for radio sound, and each PulseAudio play device has a ".monitor" input that is equal to the output.  So radio sound goes to wsjt-x.

I looked at the PulseAudio code from Philip G. Lee, and found that the "pulse" device for capture or playback refers to the default PulseAudio device.  There is currently no way to specify a different device, but by adding this capability, Quisk could work with all PulseAudio devices.

Jim
N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

Nick
In reply to this post by ahlstromjc
Hi Jim

sorry for the delay.  Got your message then our phone line went down so
no internet.  Internet is sort of working today even though there's no
phone service; guess the ADSL is leaping across the broken twisted pair!

Anyway to reply to your various points...

On 02/10/14 16:05, ahlstromjc [via quisk] wrote:
>
> Hello Nick,
>
> Linux has four independent sound systems, ALSA, PortAudio, PulseAudio and
> Jack.

Not to mention OSS.

 > I have looked for documentation on how this all works, and have found
> nothing.  Even the author's description of their own sound system is
> lacking.

Yes it is hard to find, but there is some useful stuff out there.
Perhaps you have seen these...

http://alsa.opensrc.org/
http://www.volkerschatz.com/noise/alsa.html
http://www.portaudio.com/
https://wiki.archlinux.org/index.php/PulseAudio
http://jackaudio.org/

> So I have tried to reverse engineer my own Linux system to get
> some insight.
>

Yes.  But there are many variables, and keeping track of what works and
what doesn't is not easy.

> I am running Ubuntu 14.04LTS 32-bit.  By default, it runs PulseAudio as a
> daemon.

Yes.

 > The settings/sound dialog box shows a list of input and output
> devices, an effects tab, and a list of applications using audio.  I am using
> ALSA devices directly with Quisk.   PulseAudio does not interfere with this,
> but Quisk does not appear on the list of applications.

Because quisk uses ALSA by default.

 > If I change Quisk to
> use PulseAudio devices, Quisk works fine and also appears on the application
> list.  So I guess that PulseAudio does not demand exclusive control of sound
> hardware, and can co-exist with  applications that use ALSA directly.
>

Yes.  That is exactly what I have observed.

> I installed wjst-x version 1.1 and found a list of ALSA devices on the sound
> menu.  It seemed to work.  But then I remembered you were running 1.3.  I
> then installed wsjt-x version 1.4.  The sound menu shows a list of
> alsa_input and alsa_output names, but I could not get wsjt-x to work at all.
> Also, wsjt-x appears on the application list for PulseAudio.  You said that
> wsjt-x requires PulseAudio, and that seems to me to be correct.  I looked
> for documentation on the wsjt-x sound system and found nothing.

Same here.

wsjt-x 1.1 and 1.2 used ALSA.  The only snag was that the receive path
required 16-bit integer samples from the sound card at 12000 sps.  Few
sound card drivers for linux are able to supply samples at that rate.
One workaround was to use .asoundrc and the alsa "plug" plug-in to
convert the sampling rate.

This works if the alsa device you are trying to receive from is a sound
card, but I could not find a way to do this if the alsa device was the
output from another process i.e. a software radio like quisk.

The only way I could make it work was to downgrade the whole receive
chain to 12000 sps so that the baseband bandwidth was +/-6000Hz.  This
worked great for wsjt-x that only needs 4000Hz bandwidth.  The only
downside was my sound card supplied 24 bit samples and wsjt-x ignored
the 8 most significant bits resulting in an unwanted 48dB gain at baseband.

There is no problem on transmit where 16 bit integer samples are sent
out at 48000 sps which is generally supported by all sound cards under
linux.

Then from 1.3 onwards wsjt-x uses pulseaudio.  This works fine where the
receive source is a sound card connected to a hardware radio.

But the only way to get audio from a dttsp based software radio into
wsjt-x was by using jack with the pulseaudio-module-jack package.

>
> You discussed using Jack.  Both PulseAudio and Jack seem to be doing the
> same thing, namely routing sound among applications and hardware devices,

Yes.  There are both sound servers, although jack is designed for low
latency pro audio applications.

> and so are not compatible with each other.  The advice from the Internet is
> not to run both at the same time.  But this is Linux, so there is a
> complicated way to run both if you want.

With jack2 it's not complicated. The pulseaudio-module-jack package
makes pulse source and sink devices available to jack.

https://wiki.archlinux.org/index.php/PulseAudio

 > The > solution seems to be fixing the Quisk PulseAudio system so it
works with
> wsjt-x.  Do you agree, or is there some reason you think Jack is necessary?
>

Yes, I agree. jack reputedly has lower latency than pulse, but the only
real benefit I can point to so far is using Outputs 3&4 for the TX IQ
signals to the softrock is very easy to set up.  Without jack you need
to hack ice1712.conf and/or ~/.asoundrc to separate Outputs 3&4 from
1&2.  Or use another sound card of course.

> Jim
> N2ADR
>
>
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://quisk.973856.n3.nabble.com/quisk-and-wsjt-x-tp4023702p4023706.html
>
> To unsubscribe from quisk and wsjt-x, visit

Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

Nick
In reply to this post by ahlstromjc
Hi Jim

Yes, that works here.

digital_input_name and digital_output_name are set to "" in
quisk_conf_defaults.py so no need to set them in ~/.quisk_conf.py?

quisk 3.6.18, DGT-U, 4800Hz baseband
wsjt-x 1.4

It all looks pretty normal in the wsjt-x wide graph.  jt65 signals all
look good.  wsjt-x controls quisk via hamlib properly.

However there are a couple of issues

- there are no jt65 or jt9 decodes even though the wsjt-x level meter
shows plenty of signal;

- the wsjt-x wide graph shows signals about 200Hz LF.  Both wsjt-x and
quisk show the frequency as 10.138000 MHz (which is correct).

I'll try to fix these before I play with the transmit side.

Nick

On 03/10/14 00:01, ahlstromjc [via quisk] wrote:

>
>
> Hello Nick,
>
> I think I have a way to get wsjt-x to work on receive with Quisk.  The quisk
> configuration is:
>    name_of_sound_play = "pulse"
>    digital_input_name = ""
>    digital_output_name = ""
> Other needed Quisk devices use the ALSA names.
>
> In wsjt-x choose the input audio device to be the ".monitor" of the device
> that is playing radio sound; that is, the default PulseAudio output device
> equal to name_of_sound_play.
>
> This should work because Quisk will use PulseAudio for radio sound, and each
> PulseAudio play device has a ".monitor" input that is equal to the output.
> So radio sound goes to wsjt-x.
>
> I looked at the PulseAudio code from Philip G. Lee, and found that the
> "pulse" device for capture or playback refers to the default PulseAudio
> device.  There is currently no way to specify a different device, but by
> adding this capability, Quisk could work with all PulseAudio devices.
>
> Jim
> N2ADR
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://quisk.973856.n3.nabble.com/quisk-and-wsjt-x-tp4023702p4023707.html
>
> To unsubscribe from quisk and wsjt-x, visit

Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

ahlstromjc
Administrator
Hi Nick,

The PulseAudio code contributed by Philip G. Lee only supports the "default" device.  To really make this work, I am adding code to display the PulseAudio device names and to support multiple cards.  Quisk uses seven audio channels.  Phillip used the "simple" PulseAudio API, and I hope all this works without changing to async coding.

Jim
N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

Nick
Hi Jim,

that sounds good.  Presumably you would then be able to make wsjt-x work
on transmit by specifying the wsjt-x pulseaudio device name in quisk.

I have wsjt-x decoding properly on receive now.  pulse was defaulting to
44100 sps instead of 48000 sps.  Creating a new ~/.pulse/daemon.conf
with default-sample-rate = 48000 fixed it.

Setting si570_direct_control = True seems to have fixed the ~-200Hz
error on setting the softrock via USB.

Is there an offset set anywhere to get the baseband audio away from 0Hz?

It would be nice to be able to use Outputs 3&4 for the TX IQ output to
the softrock without having to use a second sound card.

I have modified the playback translation table in /usr/share/alsa/cards
/ICE1712.conf so that the left and right outputs sent to hw:M44 get sent
to outputs 3&4 as well as outputs 1&2.  Since wsjt-x is half duplex this
should work OK.

73

Nick G3VNC

On 04/10/14 19:27, ahlstromjc [via quisk] wrote:

>
>
> Hi Nick,
>
> The PulseAudio code contributed by Philip G. Lee only supports the "default"
> device.  To really make this work, I am adding code to display the
> PulseAudio device names and to support multiple cards.  Quisk uses seven
> audio channels.  Phillip used the "simple" PulseAudio API, and I hope all
> this works without changing to async coding.
>
> Jim
> N2ADR
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://quisk.973856.n3.nabble.com/quisk-and-wsjt-x-tp4023702p4023710.html
>
> To unsubscribe from quisk and wsjt-x, visit

Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

ahlstromjc
Administrator
<quote author="Nick">

>>I have wsjt-x decoding properly on receive now.  pulse was defaulting to
44100 sps instead of 48000 sps.  Creating a new ~/.pulse/daemon.conf
with default-sample-rate = 48000 fixed it.

That is odd.  The sample rate is correctly specified when the PulseAudio device is opened.

>>Is there an offset set anywhere to get the baseband audio away from 0Hz?

There is RIT, but just tuning the radio moves the audio up and down.  

Jim
N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: quisk and wsjt-x

ahlstromjc
Administrator
In reply to this post by ahlstromjc
Hello Nick,

Here is some more information:

You are right that digital_output_name doesn't work unless name_of_sound_play is also set.  This is because the audio must be tuned and demodulated before it is sent to digital_output_name.  Also, data is only sent to digital_output_name for the modes DGT-U, DGT-L, and DGT-IQ.  Push the DGT button repeatedly to cycle through these modes.

The raw I/Q data (before tuning and demodulation) is sent to sample_playback_name if it is set even if name_of sound_play is null.  But the rate is equal to the capture rate.  To avoid rate conflicts, you should try to get everything set to 48 ksps initially before trying other rates.

I don't think the loopback device should be necessary.  PulseAudio should be able to connect the apps itself.  The names shown in wsjt-x are also shown in Quisk.  So just setting a Quisk input/output name to the wsjt-x output/input name should work (maybe).

The transmit audio from wsjt-x must go to digital_input_name at 48 ksps, and then Quisk will tune it and send it to name_of_mic_play (or Ethernet); but only if one of the DGT modes is selected.  Remember that Quisk is expecting audio 300-3000 Hz, and replaces the mic audio with the digital audio.  For DGT-U it then transmits it on upper sideband.  For a soundcard, that means tuning it somewhere between -24 to + 24 kHz.  Be sure that wsjt-x does not tune it first, or it will be tuned twice.

Quisk duplicates and routes all this audio because it is able to work with hardware that uses Ethernet for the samples, and does not assume that everything is a soundcard.  Since you are using a soundcard, I wonder if you could send wsjt-x transmit samples to the sound card directly.  If you do, you would have to tune with wsjt-x directly.  If you go through Quisk, the audio is always 300-3000 Hz, and Quisk tunes it as required.

Jim
N2ADR