Transmit audio not making it to mic_play device

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

Transmit audio not making it to mic_play device

mcody
Looks like nothing is going to be easy with getting my SDR system set up running under Quisk. While reception appears to be working great now, output of transmit audio is not working.  I know that the transmit capability of the AVALA-01 does work because I have used it with a Windows XP computer running GSDR (a variant of FlexRadio PowerSDR software).

Here is my set-up again:
Computer: Toshiba Satellite L355D-S7825 laptop with AMD Turion 64 X2 Dual-Core, 2.0 GHz, 1 MB L2 Cache, 2 GB RAM, Running Kubuntu Linux 10.04 LTS and with Alsa sound system.
External Sound Card: Creative Soundblaster X-Fi Surround 5.1 Pro USB Audio System with THX (model SB1095), which is capable of 96,000 sps and 24-bit resolution
SDR "front end" AVALA-01 (similar to Genesis G40) with QRP2000 USB frequency generator with key line control

My current .quisk_conf.py file is listed at the end of this post.

When the PTT button is depressed, the AVALA-01 keys up but no audio is generated by the Creative SB1095 device. I have verified that the microphone and the laptop's internal sound card are working by using arecord and aplay. I attached a second headphone to both the headphone output and speaker output on the SB1095. Nothing is heard during transmit. I discovered, though, that when not transmitting, the tone generated by the TEST1 button is heard from both the headphone output and speaker output on the SB1095.  This does not occur when the PTT is depressed.

I did quite a bit of searching through Google, but with no luck. I did find a thread on the Peaberry Support Forum that looked promising, but it didn't provide any enlightenment towards a solution. Hopefully someone will show me the obvious solution that I apparently don't see.

73,

Mac / AE5PH

<Start of quisk_conf.py file>
# -*- coding: utf-8 -*-
# The default hardware module was already imported.  Import a different one here.
# import quisk_hardware_fixed as quisk_hardware

#import sys

# Import the default Hardware module.  You can import a different module in
# your .quisk_conf.py.
from softrock import hardware_usb as quisk_hardware
from softrock import widgets_tx   as quisk_widgets

# AVALA-01 SDR sound device (Sound Blaster X-Fi Surround 5.1 Pro USB) configuration.
name_of_sound_capt="hw:1" # Connects to AVALA-01 baseband RX audio output.
name_of_mic_play="hw:1" # Connects to AVALA-01 baseband TX audio input.
#sample_rate = 48000 # As noted above, 48 ksps works well.
sample_rate = 96000 # Audio output does not want to work at 96 ksps.
mic_playback_rate = sample_rate # Playback rate must be a multiple 1, 2, ... of mic_sample_rate
mic_out_volume = 1.0 # This value may need to be lowered.
channel_i = 1 # Soundcard index of in-phase channel:  0, 1, 2, ...
channel_q = 0 # Soundcard index of quadrature channel:  0, 1, 2, ...

# Operator audio (internal sound device) configuration.
name_of_sound_play="portaudio:(hw:0,0)" # Speaker/headphone for operator.
microphone_name="portaudio:(hw:0,0)" # Microphone for operator.
mic_sample_rate = 48000 # Can this be decreased to 8 ksps? No!
playback_rate = mic_sample_rate
mic_channel_I = 0 # Soundcard index of mic capture audio channel
mic_channel_Q = 0 # Soundcard index of ignored capture channel
mic_out_volume = 0.7 # Microphone output volume (after all processing) as a fraction 0.0 to 0.7
# Microphone audio processing:
# The original audio processing used mic_clip = 4.0; mic_preemphasis = -1.0
# For no mic audio processing, use mic_clip = 1.0; mic_preemphasis = 0.0
mic_clip = 3.0 # Mic amplitude clipping; larger numbers give more clipping
mic_preemphasis = 0.6 # Mic pre-emphasis 0.0 (none) to 1.0; or -1.0 for a Butterworth filter
# These parameters control the microphone gain adjustment.
#mic_avg_gain = 75.0 # Typical gain for the microphone in use
mic_max_gain = 100.0 # Do not increase gain over this value

# The program polls the soundcard or SDR-IQ for data every data_poll_usec microseconds.
# A lower time reduces latency; a higher time is less taxing on the hardware.
if sys.platform == "win32":
  data_poll_usec = 20000 # poll time in microseconds
else:
  data_poll_usec = 7000 # poll time in microseconds (originally 7050)

# latency_millisecs determines how many samples are in the soundcard play buffer.
# A larger number makes it less likely that you will run out of samples to play,
# but increases latency.  It is OK to suffer a certain number of play buffer
# underruns in order to get lower latency.
latency_millisecs = 200 # latency time in milliseconds

# Vendor and product ID's for the QRP2000
usb_vendor_id = 0x16c0
usb_product_id = 0x05dc
# Thanks to Ethan Blanton, KB8OJH, for this patch for the Si570 (many SoftRock's):
# If you are using a DG8SAQ interface to set a Si570 clock directly, set
# this to True.  Complex controllers which have their own internal
# crystal calibration do not require this.
si570_direct_control = True
# This is the Si570 startup frequency in Hz.  114.285MHz is the typical
# value from the data sheet; you can use 'usbsoftrock calibrate' to find
# the value for your device.
#si570_xtal_freq = 114285000
si570_xtal_freq = 114257943

# The "DGTL" mode mostly acts like USB, but it sends received audio to an external
# program that can decode digital modes, and receives audio to transmit.
# The only program currently supported is Fldigi.  Set Fldigi to USB, XML-RPC control.
digital_xmlrpc_url = "http://localhost:7362" # URL for control by XML-RPC
# Input audio from an external program for use with mode DGTL.  The input must be
# stereo at 48000 sps, and you must set mic_sample_rate to 48000 also.
digital_input_name = "" # device name for transmit audio
# digital_input_name = 'hw:Loopback,0'
# Output audio to an external program for use with mode DGTL.  The output is
# stereo at the same sample rate as the radio sound playback.
digital_output_name = "" # device name for received audio
# digital_output_name = digital_input_name
<End of quisk_conf.py file>
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

magun
For testing the output of the SB1095 I used the following setup, which is more easy for testing:

name_of_sound_capt = "alsa:SB X-Fi"
name_of_sound_play = "alsa:SB X-Fi"
sample_rate = 48000        

With this setup I obtained the radio spectrum on the screen as expected and could hear a very weak audio signal for maximum volume on the quisk screen. I also could change the audio level with the volume slider but could not change the audio level through alsamixer, as no slider controls are available. This is consistent with the fact, that the SB1095 has no hardware mixer, and thererfore the audio output level cannot be changed manually.

According to the ALSA documentation and other internet sources softvol and dmix plugins must be used to control the output volume of the SB1095. I tried this following the documentation and was able to generate an output volume slider for the SB1095 but could not change the output volume when running quisk.

My guess is, that either quisk cannot recognize the device which is governed by dmix and softvol, or that softvol and dmix do not work with the SB1905.

It probably would be possible to implement a second volume slider in quisk for the mic_play device that controls the output I/Q levels manually.

Cheers
Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

ahlstromjc
Administrator
In reply to this post by mcody
Hello Mac,

Here are some more things to try.  Try replacing your config file with one modeled from my n2adr/conf3.py file.  The idea is to send mic audio to your normal radio play device as a test.  This is:

name_of_mic_play="portaudio:(hw:0,0)"
name_of_sound_play=""
mic_playback_rate = 48000

This is a test of just the mic, and the AVALA-01 is not involved.

Take a look at the config screen and look for audio device errors.

I see you have both mic channels set to 0:
mic_channel_I = 0 # Soundcard index of mic capture audio channel
mic_channel_Q = 0 # Soundcard index of ignored capture channel

Perhaps the mic is monophonic on a different channel, like 1.

There may be a mixer setting missing, either to enable the mic or to set its volume.  The test using conf3.py should settle that.

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

Re: Transmit audio not making it to mic_play device

ahlstromjc
Administrator
In reply to this post by mcody
Hi Mac,

I forgot to say that this:

 >>I discovered, though, that when not transmitting, the tone generated by the TEST1 button is heard from both the headphone >>output and speaker output on the SB1095.

is completely unexpected, and indicates some kind of problem.

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

Re: Transmit audio not making it to mic_play device

mcody
In reply to this post by magun
Andreas,

Thanks for replying.

I'll give that alternate configuration a try. I suspect that I'll get similar results, as using alsamixer indicated that the SB1095 has no mixer functionality. Some Google searching lead to this thread on the Gentoo Forums. This, in turn, lead me to this thread, where the second post lists an .asoundrc file that provides some support for SB1095 surround sound, and this web page, which provides a basic .asoundrc file for the SB1095. Both use the softvol and dmix plugins.

I'd have to figure out how to implement the second volume control you describe. I have not done programming in either Python or WX GUI programming, so there will be a bit of a learning curve there. Perhaps I can learn by example through studying the Quisk source code.

73,

Mac / AE5PH
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

mcody
In reply to this post by ahlstromjc
Jim,

Thanks for replying.  I'll give your suggestions a shot and let you know what happens. Regarding your follow-up post: Yeah, I found the presence of the test tone on the output of the SB1095 during reception to be quite odd as well. I don't know why that is happening. Perhaps an inspection of Quisk source code is in order, but I suspect that the cause is probably external to  Quisk.

73,

Mac / AE5PH
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

mcody
In reply to this post by ahlstromjc
Jim,

There's not much good news to come out of my experimentations today.  I followed your suggestion regarding sending the mic audio to the radio play device. I could never hear any mic sound on this "loop back" test. All possible combinations of "0" and "1" settings for mic_channel_I and mic_channel_Q failed to yield sound coming from the microphone.  The config screen didn't show any errors out of the ordinary.

I was finally able to use aplay to output a short recording of my voice on the SB1095, as recorded from my mic using arecord. I think I may have successfully set up a proper .asoundrc file, but I'm not sure.  My .asoundrc file is as follows:

pcm.hw:1 {
    type            plug
    slave.pcm  "softvol"   #make use of softvol
}

pcm.softvol {
    type            softvol
    slave {
        pcm        "dmix"      #redirect the output to dmix (instead of "hw:0,0")
    }
    control {
        name        "Master"       #override the PCM slider to set the softvol volume level globally
        card        "1"
    }
}

I don't have a  whole lot of confidence in this file, though, as I find the examples for .asoundrc files a bit confusing.

Any more ideas you might have are appreciated.

Mac / AE5PH
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

ahlstromjc
Administrator
Hello,

I am afraid I am running out of ideas.  I tested on my PC at 96000 sps play and it worked.  I was afraid my interpolation was broken.  Since it works on my hardware and I don't have your hardware I am at a loss.

You could try the sound test at 48000 sps instead of 96000.  That eliminates some complications.

The experience of Flex Radio is interesting.  Their first hardware was based on a switching mixer with output to the sound card.  After confronting sound card hell, they started including the sound card within their hardware, but spent a lot of time and software eliminating images.  Now they direct sample at the antenna, and no analog mixers or sound cards are used.

My station uses direct sampling at the antenna too.  An amateur project using this is HiQSDR.  BTW, SDR is my only station.  I don't own a commercial transceiver, so Quisk either works or I am QRT.

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

Re: Transmit audio not making it to mic_play device

mcody
This post was updated on .
Jim,

What puzzles me is that the "loopback" test, which doesn't even involve the SB1095 did not work. Yet, I am able to record sound with the mike and then play the sound file through the laptop's sound card. I have also been able to play that same sound file out on the SB1095. That sort of tells me that both sound cards are working. I am wondering if the problem is in the ALSA name that I am using for microphone_name.  Maybe it needs to be something other than "portaudio:(hw:0,0)". This is my next course of investigation. Also, if I recall correctly, Quisk can be compiled in a "debug" mode, which may provide some additional information.  Do you think that doing that is worth a shot? Digging into someone else's code can be very enlightening.

!!!UPDATE!!!

Progress is finally being made! I spent some time studying ALSA and PortAudio. One of the things I discovered was that in alsamixer, there is a CAPTURE volume control, which was set to zero. I'm not sure that this was really a factor, but I set its level to about 80% of full scale.

I decided to take a step back and take a mental reset on the configuration of .quisk_conf.py. I tried the "loopback" test again, but used hw:0,0 rather than portaudio(hw:0,0). I also made sure that the sample rate was set to 48000 sps. Suddenly, I could hear the sound of my voice, but it was distorted. I went back to alsamixer and adjusted the input sound level to where the distortion was gone. I decided to switch the "loopback" test back to using portaudio(hw:0,0). Now there was no sound, so I switched it back to using hw:0,0. I was surprised by this.

Deciding to be bold, I adjusted .quisk_conf.py for "normal" operation SB1095 using hw:1,0 and voice audio on hw:0,0. When I pressed PTT, no transmit audio came out on SB1095.  I switched back to "loopback" test and then my voice could be heard on my headphones. Out of curiosity, I switched back to "normal" operation and tried setting the SB1095 sample rate to 96000 sps.  Quisk would then have latency errors on radio sound play and eventually segfault. This does not occur when portaudio(hw:0,0) is used instead of hw:0,0.

It appears that part of the problem is with using PortAudio to read the mic.  I don't understand why that is the case. Of course I still can't get transmit audio our on the SB1095. Well, one step at a time.

Mac / AE5PH
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

ahlstromjc
Administrator
Hello,

One point to be careful: when transmitting, your audio is mixed up to your transmit frequency.  That is, if you are tuned 10 kHz above the center, your audio is sent to the sound card at 0-3 kHz + 10 kHz.

For the audio test we are discussing, set the transmit frequency to the center of the display.  There is a small center mar there.  Then it should appear at the output at an offset of zero Hertz and sound normal.

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

Re: Transmit audio not making it to mic_play device

mcody
Jim,

Not exactly sure what you mean by "There is a small center mar there." (unless you mean small center bar), but I have been setting the transmit frequency to the center of the display.  There is no audio output (transmit audio) whatsoever coming from the SB1095 from Quisk. This is strange, as I can get audio output when I use the ALSA aplay utility.  As Andreas pointed out in his earlier post, "My guess is, that either quisk cannot recognize the device which is governed by dmix and softvol, or that softvol and dmix do not work with the SB1095.". I think I have set up my .asoundrc file properly to use dmix and softvol with the SB1095. That being said, the alsamixer "Master" volume control for the SB1095 does not appear to have any affect on changing that sound device's output volume.

Is there any way to verify that Quisk is actually sending audio data to the SB1095?

Any thoughts about why "portaudio(hw:0,0)" does not appear to work on the "loopback" test while "hw:0,0" does work?

Mac / AE5PH
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

ahlstromjc
Administrator
I don't know why alsa and portaudio are different.  They should both work.

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

Re: Transmit audio not making it to mic_play device

mcody
This post was updated on .
Jim,

It appears that there are a number of debug defines in the Quisk C source code (DEBUG, DEBUG_IO, and NOTCH_DEBUG). Would enabling any of them provide any enlightenment to my predicament? Perhaps some debug statements might indicate something that is wrong, not necessarily with the Quisk code, but with Quisk's interfacing to my laptop's sound system.

Another thing I'll try (tomorrow) is to use the SB1095 for name_of_sound_capt and name_of_sound_play.  I'll try it at both 48 ksps and 96 ksps. The success or failure of this test might tell me something about Quisk's ability talk though a virtual mixer.

Mac / AE5PH
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

mcody
Jim,

Yesterday, I set up .quisk_conf.py to use the SB1095 for name_of_sound_capt and name_of_sound_play. I discovered, to my surprise, that I could hear the received audio. The audio volume control on the left hand side of the Quisk control panel could control the sound level, but the sound was faint, but discernible at full volume. I don't know why the volume is so low, but I suspected that the problem is in the volume control of the SB1095, not in Quisk itself.

I still have not found a way to externally control the output audio volume of the SB1095 using softvol and dmix in the .asoundrc file. Everything on the net appears to have the same solution for the .asoundrc configuration, more or less. The configuration assumes that the SB1095 is hw0, not hw1, as in my situation. Modifying the configuration to "suggest" using hw:1 does not appear to work for me. Most attempts resulted in all sound support being turned off.

I'm in a bit of a quandary as to what to do next.

Mac / AE5PH
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

magun
Hi All

I was close giving up using the SB1095I under Linux but out of curiosity did some further tests.

My setup uses Ubuntu 12.04 LTS, alsa1.025+dfsg-0ubuntu1.1 and libportaudio2: 19+svn20111121-1
no pulseaudio (which did not matter)
quisk-3.6.10
SDR TRX from Funkamateur

When using Alsa I had the same results as Mac. However, using Portaudio brought some progress:

With
name_of_sound_capt  = "portaudio:X-Fi"  or  name_of_sound_capt  = "alsa:X-Fi"
name_of_sound_play  = "alsa:Xonar"
name_of_mic_play      = "portaudio:X-Fi"
microphone_name       = ""

With PTT 'on' and 'CW' or 'IMD'  on I obtained I and Q output peak to peak voltages of 2 V (with 90 deg phase shif).
This is more enough to drive my PA into saturation. External attenuators at the output of the SB1905 could be used for adjusting the audio I and Q levels. It would be nice, to have instead a Quisk volume control for the mic_play device.

With
name_of_sound_capt  = "portaudio:X-Fi"  or  name_of_sound_capt  = "alsa:X-Fi"
name_of_sound_play  = "portaudio:X-Fi"

a strong audio output signal appeared at the SB1095 output and could be leveled with the volume slider.

It seems that at least with my setup and by using portaudio a strong audio output can be obtained with the SB1095.

I will check this on my Laptop under Mint and test dmix and softvol again.

Andreas (HB9EHI)
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

magun
Hi All

On my Laptop Lenovo S12 with Mint same behaviour as above.
When using portaudio SB1095 output is 2 V peak to peak. With alsa there is no output voltage to speak of..

No success with softvol. I give up on that and might learn Python and try to understand Quisk for implementing a variable output for mic_play.

Cheers
Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

mcody
In reply to this post by magun
Andreas,

Thanks for your insights into the SB1095.  In my investigations, I have found where the SB1095 volume can be controlled via softvol and dmix. The examples of configuring .asoundrc file to support this take the following form, which I'm sure you have already seen:

pcm.!default {
    type            plug
    slave.pcm       "softvol"   #make use of softvol
}

pcm.softvol {
    type            softvol
    slave {
        pcm        "dmix"      #redirect the output to dmix (instead of "hw:0,0")
    }
    control {
        name        "Master"       #override the PCM slider to set the softvol volume level globally
        card        0
    }
}


I have tried a similar version, which I listed in my second post from May 31. It apparently does not work, as alsamixer does not display the mixer control, as shown in this picture:


The problem I have is that my SB1095 is not the default device (hw:0,0), it is hw(1,0) and hw(1,1).  I have not figured out the details of ALSA's naming conventions. I have yet to figure out how to set up .asoundrc to use softvol and dmix with a non-default sound card.

In your post you mention sound card names like "portaudio:X-Fi", "alsa:X-Fi", and "alsa:Xonar". I havn't even been successful in using these "names" or "aliases" for cards, especially in the .asoundrc file. Perhaps you could present your .asoundrc, if that might help me understand.

Mac / AE5PH
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

ahlstromjc
Administrator
Hello,

The names like "portaudio:X-Fi" or "alsa:X-Fi" are used within Quisk, not the .asoundrc file.  They cause Quisk to search for a device with the given string in its name "X-Fi" and are an alternative to a hardware name.  The names that Quisk knows about are on the config screen.  You can look at the names and pick a substring to search for.

I can't help with .asoundrc as I don't use it and don't understand it.

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

Re: Transmit audio not making it to mic_play device

magun
In reply to this post by mcody
Hi Mac

The names "portaudio:X-Fi" and "alsa:Xonar" are used in the .quisk_conf.py configuration file and define a Xonar D1 PCI-soundcard (Xonar) and the SB1905 (X-Fi) to quisk. They have nothing to do with with the .asoundrc file. At one stage I defined alias names in .asoundrc. But they did not appear in quisk (Config->Sound).

As mentioned by Jim .asoundrc is not needed at all for Quisk. During my test under Mint, also mentioned above, no .asoundrc or /etc/asoundrc files were present.

My conclusion from what I read on the internet is that softvol and dmix can be used by programs, that have an audio interface different from quisk.

Quisk runs nicely under Windows7 on my Lenovo S12 Laptop. And as software volume control is included in the driver the output level of the SB1095 can be changed manually.

Cheers
Andreas

Just a side remark regarding the SB1095 noise performance. There is a report by IW3AUT how to lower its noise. Search in Google for    SB_Creative_XFi_Pro_USB.pdf
Reply | Threaded
Open this post in threaded view
|

Re: Transmit audio not making it to mic_play device

mcody
In reply to this post by ahlstromjc
Jim,

So what you are saying is that if I do not configure the relevant variables in quisk_conf.py, the config screen will still list the names that Quisk knows about? I'm tired and I'm forgetting what the config screen displays. If it weren't so late, I'd go check this out right now. It will have to  wait until  tomorrow, though.

Mac / AE5PH
12