An update and some good and bad news.
First the bad.
I've distilled the failure mode to the following:
1. If aplay is used to send to the rig, it's successful.
aplay -D CARD=Device,DEV=0 /usr/share/sounds/alsa/Noise.wav
2. If one of the uart devices is opened, aplay fails.
cat /dev/ttyUSB0
Some more info:
1. The USB controller on the RPi 4/5 is the Via VL805. It has had
firmware updates for various isochronous problems in the past. I'll try
the RPi list and see if anybody is interested.
2. The RPi 3B+ uses the Microchip LAN7515 controller and wsjtx works FB
with the FT-710. I got l
I did some further testing.
I have pipewire disabled and am only using alsa. If I use aplay to send
to the FT-710 sound device, it succeeds. If I open any one of the two
serial ports with something like "cat /dev/ttyUSB0", aplay shows reset
errors in syslog.
So, this is not pipewire, wsjtx or ham
Hi Mike,
Thanks for the suggestion. I tried it, but I still get errors at 48000
on my RPi 5.
On my amd64 platform, the 48000 rate gives me 100's of flags on
pskreporter. If I change the output rate to 44100 in soundoutput, I get
zip. Is there an assumption of a 48k sample rate for the output? If
Sending sound is only 50% of the sound I/O -- it's the sound reading that is
being done most the time.
You can minimize hamlib overhead with this data in hamlib_settings.json which
would go in the same directory as WSJT-X.ini
{
"config": {
"multicast_data_addr": "0.0.0.0
I changed the sample rate in Audio/soundout.cpp from 48000 to 44100.
There are no errors logged and the oscilloscope shows data during
transmit.
It looks like the RPi can't handle the higher rate.
I'm still running to a dummy load, so I don't know yet if I'm getting
out.
What is interesting is
As a side note, when having problems like this it can be nice to compile
and run wsjt-x in an isolated container, with known and controlled
system environment:
https://sm6vfz.wordpress.com/2023/07/10/building-and-running-wsjt-x-in-a-docker-container/
This is tested by me on RPi 5 as well.
/Dani
Hi Kari,
What's the length of the IC-7300 output device name?
There doesn't seem to be much consistency in the size of card_name in
the pipewire alsa plugin. But, if the name gets truncated, wsjtx should
fail on the amd64 as well and doesn't. I'll ask on the pipewire-devel
list.
spa/plugins/alsa
FWIW I am finding the same thing here.
Ft-710
Pi5
Ubuntu 24.04 stock pipewire but using x11 not wayland
Wsjtx 2.7.0-rc3 set to pipewire
Pressing tune or enable tx would not produce any audio drive on the 710
I then installed pavucontrol.
When trying to tx audio output in pavucontrol would cycle bet
Hi Kari,
It's installed on both systems.
Some more evidence:
I can run aplay and output to the fig's sound output device without
error. However, if I run wsjtx with the audio output set to the hdmi
device, when I run aplay, I get the same "no such device" error.
I don't this is a wsjtx issue, r
Yes.
> On Jun 29, 2024, at 2:31 PM, Kari Sillanmäki via wsjt-devel
> wrote:
>
> Hi Steve,
>
> Do you have "libqt5multimedia5-plugins" installed?
>
> 73's de Kari, oh2gqc
>
>> On 6/29/24 22:04, Steve Brown via wsjt-devel wrote:
>> Hi,
>>
>> No problem on Ubuntu 24.04 on an amd64, but no au
Hi Steve,
Do you have "libqt5multimedia5-plugins" installed?
73's de Kari, oh2gqc
On 6/29/24 22:04, Steve Brown via wsjt-devel wrote:
Hi,
No problem on Ubuntu 24.04 on an amd64, but no audio on RPi 5 with the
same OS. Receive works on both.
I rebuilt wsjtx so the images are identical on bot
Hi,
No problem on Ubuntu 24.04 on an amd64, but no audio on RPi 5 with the
same OS. Receive works on both.
I rebuilt wsjtx so the images are identical on both (2b9d65).
The settings are identical.
The sound output name is
"alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-
st
13 matches
Mail list logo
