Topics

flamp closes when using the file ... audio capture RX save dialog


we1u.david@...
 

When I try to save "Capture RX" audio file in fldigi; flamp opens a dialog box with the message "fldigi off line" and a "close" button.

I started to notice this with fldigi-4.1.01 and flamp 2.2.0x something

running fldigi from terminal show the following error
 

(fldigi:16184): Gtk-WARNING **: 17:17:03.821: Unable to locate theme engine in module_path: "adwaita",
 
(fldigi:16184): GLib-GIO-CRITICAL **: 17:17:03.946: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
I: [17:17:27] misc/arq_io.cxx : 697 : test_arq_clients
    socket 58 timed out, error 32, send: Broken pipe
I: [17:17:27] network/socket.cxx : 688 : close
 


John Rabold KS6M
 

I am confirming this behavior under certain specific circumstances, and I agree that it has been around for a while. I am using fldigi 4.1.11, flmsg 4.0.14, and flamp 2.2.05 on Windows 10. When launching "File|Audio|RX capture" OR "File|Audio|Playback" in fldigi, and the dialog box opens to specify the capture or playback file, with flmsg and flamp running, flamp will crash with the "fldigi off line" error message. Further, though flmsg does not display an error message at that point, it does not close cleanly; it is "not responding" for a few seconds. However, this happens on my system ONLY with flmsg executing. If flmsg is NOT executing, flamp continues to run and there is no error message. If flmsg is not launched or if it is closed manually before invoking "File|Audio|RX capture" OR "File|Audio|Playback" in fldigi, flamp remains executing and there is no error message.

Once capture or playback has begun, flmsg can be safely launched without causing flamp to crash.

In case this behavior is related to the settings at Misc|NBEMS interface (I have not tested this), my settings are: NBEMS data file interface checked, Open message folder NOT checked, Transfer direct to executing flmsg NOT checked, Open with flmsg checked, Open in browser checked, and the correct full path to the flmsg executable specified in the text box: C:\Program Files (x86)\flmsg-4.0.14\flmsg.exe

On a slightly-related note, when using "File|Audio|Playback" with the dialog box filter at "Waveform Audio Format (*.mp3;*.wav)", any *.wav files in the specified folder are invisible. They become visible only with the filter set at "All Files (*.*)".

John / KS6M


Dave
 

John,

Thank you for your comprehensive report.

David, W1HKJ

On 4/3/20 6:46 PM, John Rabold wrote:
I am confirming this behavior under certain specific circumstances, and I agree that it has been around for a while. I am using fldigi 4.1.11, flmsg 4.0.14, and flamp 2.2.05 on Windows 10. When launching "File|Audio|RX capture" OR "File|Audio|Playback" in fldigi, and the dialog box opens to specify the capture or playback file, with flmsg and flamp running, flamp will crash with the "fldigi off line" error message. Further, though flmsg does not display an error message at that point, it does not close cleanly; it is "not responding" for a few seconds. However, this happens on my system ONLY with flmsg executing. If flmsg is NOT executing, flamp continues to run and there is no error message. If flmsg is not launched or if it is closed manually before invoking "File|Audio|RX capture" OR "File|Audio|Playback" in fldigi, flamp remains executing and there is no error message.

Once capture or playback has begun, flmsg can be safely launched without causing flamp to crash.

In case this behavior is related to the settings at Misc|NBEMS interface (I have not tested this), my settings are: NBEMS data file interface checked, Open message folder NOT checked, Transfer direct to executing flmsg NOT checked, Open with flmsg checked, Open in browser checked, and the correct full path to the flmsg executable specified in the text box: C:\Program Files (x86)\flmsg-4.0.14\flmsg.exe

On a slightly-related note, when using "File|Audio|Playback" with the dialog box filter at "Waveform Audio Format (*.mp3;*.wav)", any *.wav files in the specified folder are invisible. They become visible only with the filter set at "All Files (*.*)".

John / KS6M


Dave
 

Easy ones first.

The files are visible on Linux, so this is a Windows interface issue.  I can confirm that the mp3 and wav files are not visible until "All files" are selected.

For now, list this as a "known bug" with a work-around.  I'll refrain from advising to move to a Linux OS.

David


On 4/3/20 6:46 PM, John Rabold wrote:


On a slightly-related note, when using "File|Audio|Playback" with the dialog box filter at "Waveform Audio Format (*.mp3;*.wav)", any *.wav files in the specified folder are invisible. They become visible only with the filter set at "All Files (*.*)".

John / KS6M


Dave
 

Strange behavior on Windows 7.  The same dialog correctly discovers the wav and mp3 files when opened from either the <AUDIO:...> macro tag creation, or when setting up the configuration items for audio alarms.

Dave

On 4/3/20 7:16 PM, Dave wrote:

Easy ones first.

The files are visible on Linux, so this is a Windows interface issue.  I can confirm that the mp3 and wav files are not visible until "All files" are selected.

For now, list this as a "known bug" with a work-around.  I'll refrain from advising to move to a Linux OS.

David


On 4/3/20 6:46 PM, John Rabold wrote:


On a slightly-related note, when using "File|Audio|Playback" with the dialog box filter at "Waveform Audio Format (*.mp3;*.wav)", any *.wav files in the specified folder are invisible. They become visible only with the filter set at "All Files (*.*)".

John / KS6M


John Rabold KS6M
 

Alpha 4.1.11.06 does not fix the flamp problem for me. Using Windows 10. The flamp crash behavior remains as before.

However, I do now see *.wav files when using File|Audio|whatever with the Audio Format filter on.

John / KS6M


Dave
 

Did you install both the fldigi and the flamp alpha ?

On 4/5/20 9:40 PM, John Rabold wrote:
Alpha 4.1.11.06 does not fix the flamp problem for me. Using Windows 10. The flamp crash behavior remains as before.

However, I do now see *.wav files when using File|Audio|whatever with the Audio Format filter on.

John / KS6M


Dave
 

BTW, this is not an flamp "crash", but a controlled shutdown of the program.

Dave

On 4/6/20 5:58 AM, Dave wrote:

Did you install both the fldigi and the flamp alpha ?

On 4/5/20 9:40 PM, John Rabold wrote:
Alpha 4.1.11.06 does not fix the flamp problem for me. Using Windows 10. The flamp crash behavior remains as before.

However, I do now see *.wav files when using File|Audio|whatever with the Audio Format filter on.

John / KS6M


Dave
 

Please make sure that you have installed and are using these versions (alpha postings have frequent updates):

http://www.w1hkj.com/alpha/fldigi/

http://www.w1hkj.com/alpha/flamp/

Shown executing on a Windows 10 - Home/64 bit OS running on a vintage Lenovo i5 notebook computer.

This flamp transmission file was created on the Win10 system and then played back on my Linux development machine:

epa-ares.wav

It is an html information document published by the Eastern Pennsylvania ARES group.  The mode is 8PSK-1200F.  There is an RsID signal at the beginning of the transmission, so enable RxID.  I tested by stopping wav file playback in the middle of the transmission and then restarting playback from the beginning to emulate signal loss and retransmission block capture.

I tested File/Audio/ capture, generate, and playback, leaving the Windows finder dialog open for extensive periods with no shutdown in flamp.

There are a few undocumented macro tags that are used by developers during tests.  One set is for high speed wav file playback:

<HS:on>  - turn on high speed playback
<HS:off> - turn off high speed playback
<HS:toggle> - toggle high speed playback
<HS:t> - toggle high speed playback

During HS playback the file will be read and decoded at the maximum possible rate.  That is usually about 10x the normal playback speed.  HS playback speed is dependent on the processor and other system cpu loading.

73, David, W1HKJ



Dave
 

OK.  I can force that to occur on the Win10 machine.

Dave

On 4/6/20 8:54 AM, John Rabold wrote:
Thanks, Dave. I had not installed the flamp alpha, but now I have. The problem persists. See the screen shot.

As before, though, it's a problem only if flmsg is also running.

John / KS6M


John Rabold KS6M
 

Thanks, Dave. I think you've reproduced this already, but here's a new screen shot using what I hope are still the current alphas. The error persists.

John / KS6M