gmfsk

Hi all
System here
Mandriva 2007 Gnome 2.16
GMFSK 0.7 pre1
sound cards M-audio delta 66
on board VIA 8253

Problem:-

Cant seem to get audio routed to GMFSK , it compiled OK as far as I know, no errors .
In settings , selecting device /dev/dsp /dev/dsp1 /dev/dsp2 doesn't route audio to the program.
I've determined that /dev/dsp2 is the mic input off the webcam, so that can be ignored.
There never seems to be any input directed from /dev/dsp, bur /dev/dsp1 has an input even when everything has been muted.
I've had problems trying to get the sound from the TV card which is hard wired to AUX i/p on the mobo to route through the digital mixer to get routed out of the delta 66 breakout box to a diddy little hifi system in the shack. So I'm aware that the two cards don't talk to each other very well.

Is this behaviour I'm seeing on GMFSK normal , ie displaying garbage on /dev/dsp1 ??

Yet I can run winrad using wine to use the delta66 card as the input and the VIA 8253 as the output device

the output from lspci -v below
00:0d.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)

       Subsystem: VIA Technologies Inc. M-Audio Delta 66
       Flags: bus master, medium devsel, latency 32, IRQ 17
       I/O ports at d800 [size=32]
       I/O ports at d400 [size=16]
       I/O ports at d000 [size=16]
       I/O ports at b800 [size=64]
       Capabilities: [80] Power Management version 1

00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
Subsystem: ASUSTeK Computer Inc. A7V8X-X Motherboard
Flags: medium devsel, IRQ 18
I/O ports at e000 [size=256]
Capabilities: [c0] Power Management version 2

I'm using the envy24 patch bay as well as the alsa control thing.
It used to be easy to determine which dsp was in use by selecting them with other software like skype, which now lists devices not by which dsp they are connected to, but by a list of device types.

Any help appreciated
73
Richard g8jvm

Is /dev/dsp actually the ALSA emulation, ie you are using ALSA natively? Can you send the results of "aplay -l" so we can see how ALSA has detected your devices?

There's no way that sound can get from one card to the other via the mixer alone. Either you need a cable from a line-out to a line-in, or you need a program to copy samples from one card to the other. I think this is irrelevant to your use of gMFSK though.

Not sure what you mean by garbage?

Is that the configuration you want? I don't think there is any support in gMFSK for input and output on different devices. Your setup sounds unusual (perhaps unusually complicated?).

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

I've got the internal card disabled in the bios now.
[ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: M66 [M Audio Delta 66], device 0: ICE1712 multi [ICE1712 multi]
Subdevices: 1/1
Subdevice #0: subdevice #0
<snip>

If I leave the mode in MSK16 or CW there is always a waveform shown, even when there is no input.
With all the connections to the inputs on the break out box disconnected, the waterfall is plain grey, yet there
is a noisy waveform and the percentage indicator is showing 10% . I've had a look at the noise floor in winrad and I cant see anything which would cause this.

I've noted /dev/dsp is busy if put in transmit mode.
ps ax showed artsd running, but killing it makes no difference to the device busy message..

Connecting an audio source with a 1KHz tone ,shows a line in the right place on the waterfall display

<another snip>

No I don't need input and out on different cards, just something that decodes

It could also be I'm at the bottom of the learning curve with this package.

TIA
73 Richard

<Humungus snip>

I'm gradually getting hold of whats happening, I have managed to decode bpsk31, rtty looks garbidge still, and cw is much the same. What is giving me a real problem is that if I go to TX I get the box up with:-
"sound_open_for_write:opensnd: /dev/dsp: Deviceor resource busy"
If I then click on the RX box the waterfall display speed increases 2 to 3 times faster than the previous working RX session, and the RX window gets gradually filled with random letters.
The only way to get back to a working RX session is to shutdown GMFSK and restart it.
I've checked to see if and other processes are usingh /dev/dsp and its permissions are :-
ls -la /dev/dsp
crw-rw---- 1 richard-g8jvm audio 14, 3 Oct 30 09:29 /dev/dsp

Any ideas ??????????????????????????????????????????????????????????????????????????????????

TIA
Richard g8jvm

If RTTY is garbage you might have it reversed. You need to be on LSB with the "REV" box unchecked, or USB with the "REV" box checked.

I don't think there is a CW decoder anyway.

I had more success when I set the sampling rate to 48000. My sound card doesn't really have the lower rates and the sample rate converter inside gMFSK seems to do a better job than the ALSA one which is providing /dev/dsp.

Could be that gMFSK requires (inadvertently?) a full duplex sound card which yours is not? Unlikely though.

At any command prompt, can you output to the device? just cat /dev/random > /dev/dsp

You should hear garbage.

That sounds like a bug.

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

0.7pre1 has one.

This is a good suggestion. I've heard lots of complaints about the sample rate conversion stuff in ALSA.

It shouldn't. I've tried to make gMFSK as simple as possible here:

- open card for reading
- listen and decode
- close card
- open card for writing
- send
- close card

... and so on.

That should be pretty fool proof, but I guess anything is possible.

Tomi Manninen / OH2BNS / KP20JF74

I have luck with alsa using the following script

#!/bin/sh
#
# Configure alsa oss emulation for soundapps
#

# Configuration

PLAYBACK=/proc/asound/card0/pcm0p/oss CAPTURE=/proc/asound/card0/pcm0p/oss
SOUNDAPPS="qsstv twpsk gpsk31 multimon p3dtelem xdemorse xdemorse-fft"

# Check if root is performing the operation

id | grep "(root)" > /dev/null
if [ "$?" != "0" ]
then
echo "You must be root or super-user to run $0." exit 1
fi

# Erase current configuration

echo "erase" > $PLAYBACK
echo "erase" > $CAPTURE

# Configure

for app in $SOUNDAPPS
do
echo "$app 0 0 direct" > $PLAYBACK
echo "$app 0 0 direct" > $CAPTURE
done
#cat $PLAYBACK
#cat $CAPTURE

--

Al - ka1as

# Al Bolduc - [email protected] - [email protected]

Neat!

ISTR that I could hear clicking in the Tx audio until I changed the sample rate. No problem with gMFSK's internal converter.

It also seems unlikely to me that Richard's M-Audio card is half duplex. More likely something is using the playback device already.

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

Some of the X Window desktop systems these days make use of the audio playback device for sound effects. Some of them will automatically close the audio device (un-busying it) if there's no UI activity requiring sound for some number of seconds; possibly, others do not.

There are a number of ways around this sort of problem. The simplest is to disable the desktop (e.g. KDE or Gnome) sound feature entirely, so that it never opens the audio driver. This is probably the best approach to use if you're going to be using the sound card for ham radio purposes, since transmitting UI feedback sounds over the air would be Bad.

Good idea. Richard's run lsof and not found anything else using /dev/dsp, but maybe the sound server is using the ALSA device directly and that's preventing playback on /dev/dsp.

A good reason not to use VOX..

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

Now I know about the permissions problem, I've noticed it decodes well at 38wpm. Not that many can read at that speed, definitely not me :)

Is'nt the delta 66 capable of full duplex ?

It might be foolproof, but not quite proof against me.
Another thing I've found, after loading FFTW Wisdom it now allows two failure in TX mode to write to /dev/dsp before the waterfall goes extra fast and no input signal is seen or decoded..
That could be a bug as Hamish suggested

If I can get the permissions sorted, its working, but at the moment only if run by root..

Richard