USB sound adapter for use with Tom's soundmodem?
Can anyone recommend a USB sound adapter for use with Tom's soundmodem? I'm building an aprsdigi with a newer server I was given that has no motherboard sound and no PCI slots (and no parallel port to do an easy PTT with either:-( I see there's a few choices out there and was hoping one of you had already found one that you could recommend. Thanks.
73 de Alan N2YGK
Quoted 5 lines
Can anyone recommend a USB sound adapter for use with Tom's soundmodem? I'm building an aprsdigi with a newer server I was given that has no motherboard sound and no PCI slots (and no parallel port to do an easy PTT with either:-( I see there's a few choices out there and was hoping one of you had already found one that you could recommend. Thanks.
I've just been spending some time trying to get the SignaLink USB to work with the soundmodem. Have run into a few problems, think I understand their cause, and am working on fixes.
First problem noted: the AFSK modem would not even start to receive when using soundmodemconfig. The ALSA audio glue complained about the RX and TX sample rates being different (and the code has a comment in it to the effect of "Make different-rate configurations work, or take them out.")
The cause: apparently, the TI USB sound chip in this device publishes a different set of sample rates as being available for its input and output endpoints. When the device is opened using the "hw:" ALSA specifier (as is suggested by the setup dialog), only the actual adapter sample rates are available, and since none of them happens to match the sample rate that the Soundmodem asks for, the closest-available rates are offered to the soundmodem. These offered rates are different and the Soundmodem balks.
Workaround: type in "plughw:1,0" as the device to use. The "plughw:" module will do software sample-rate conversion when necessary, and in this case it allows the Soundmodem to use the sample rate it wants. The same rate is used for both the RX and TX channels, and all is well.
At this point, incoming AFSK packets started being decoded reliably (as long as the receiver squelch was opened).
[Possible alternative - use the ALSA/OSS emulation module, the
SoundModem OSS interface, and open /dev/dsp1. I don't recommend this, as I've observed numerous problems and data glitches in the OSS emulation sample rate converter.]
Second problem noted: the soundmodem app would either stop receiving and transmitting, or exit abruptly with a "closed pipe" error.
The cause: the ALSA drivers will report a "closed pipe" any time the internal audio state machine goes into the XRUN state, which occurs if there's a buffer overflow (on receive) or underflow (on transmit). This apparently can occur due to timing / race conditions during TX/RX turnaround. It's necessary to restart the TX or RX channel with a "prepare" call, and it appears that the Soundmodem code doesn't do this if an EPIPE error occurs... instead, it bails out and dies.
I haven't yet modified the Soundmodem code to do what's necessary but I don't think it'll be difficult.
I've had good results with the SignaLink USB using other sound packages, for PSK31 and other digital modes, and I believe it'll work well for AFSK packet once the driver-interface glitches are dealt with.
Hi,
Spookily enough I have been thinking exactly the same thing.
The real cheap USB audio devices seem to work in Linux. They're less than NZ$10 in New Zealand, but I don't actually have one yet.
Here's a report of someone successfully using one in Linux, with a picture to show the particular model (there are many USB audio adaptors, but that particular plastic moulding style seems common):
http://www.hermann-uwe.de/photoblog/3d-sound-usb-audio-device
Here's some further information on actually getting the driver running:
http://www.hermann-uwe.de/blog/playing-audio-on-the-nslu2
And here's some general discussion of some different USB audio devices and issues:
http://www.nslu2-linux.org/wiki/HowTo/SlugAsAudioPlayer
Maybe the sampling rate mismatch will be an issue with these devices too.
:(
The discussion is targeted at the LinkSys NSLU2 device, but I think the information can be extrapolated to Linux in general.
My particular interest is in the LEDs on the USB thingummybob. If they can be programmed easily then the audio adapter could become a self contained audio in/out/PTT device (with the LED line controlling a transistor or something for PTT). I don't yet have a unit to experiment with (despite them being very cheap) but I think the idea has merit. If someone else wants to dabble...
73,
Andrew
ZL3AME
Quoted 67 lines · Dave Platt
Quoted 7 lines
Can anyone recommend a USB sound adapter for use with Tom's soundmodem?
I'm building an aprsdigi with a newer server I was given that has no
motherboard sound and no PCI slots (and no parallel port to do an easy PTT with either:-( I see there's a few choices out there and was hoping one of you had already found one that you could recommend. Thanks.I've just been spending some time trying to get the SignaLink USB to work with the soundmodem. Have run into a few problems, think I understand their cause, and am working on fixes.
First problem noted: the AFSK modem would not even start to receive when using soundmodemconfig. The ALSA audio glue complained about the RX and TX sample rates being different (and the code has a comment in it to the effect of "Make different-rate configurations work, or take them out.")
The cause: apparently, the TI USB sound chip in this device publishes a different set of sample rates as being available for its input and output endpoints. When the device is opened using the "hw:" ALSA specifier (as is suggested by the setup dialog), only the actual adapter sample rates are available, and since none of them happens to match the sample rate that the Soundmodem asks for, the closest-available rates are offered to the soundmodem. These offered rates are different and the Soundmodem balks.
Workaround: type in "plughw:1,0" as the device to use. The "plughw:" module will do software sample-rate conversion when necessary, and in this case it allows the Soundmodem to use the sample rate it wants. The same rate is used for both the RX and TX channels, and all is well.
At this point, incoming AFSK packets started being decoded reliably (as long as the receiver squelch was opened).
[Possible alternative - use the ALSA/OSS emulation module, the SoundModem OSS interface, and open
/dev/dsp1. I don't recommend this, as I've observed numerous problems and data glitches in the OSS emulation sample rate converter.]Second problem noted: the soundmodem app would either stop receiving and transmitting, or exit abruptly with a "closed pipe" error.
The cause: the ALSA drivers will report a "closed pipe" any time the internal audio state machine goes into the XRUN state, which occurs if there's a buffer overflow (on receive) or underflow (on transmit). This apparently can occur due to timing / race conditions during TX/RX turnaround. It's necessary to restart the TX or RX channel with a "prepare" call, and it appears that the Soundmodem code doesn't do this if an EPIPE error occurs... instead, it bails out and dies.
I haven't yet modified the Soundmodem code to do what's necessary but I don't think it'll be difficult.
I've had good results with the SignaLink USB using other sound packages, for PSK31 and other digital modes, and I believe it'll work well for AFSK packet once the driver-interface glitches are dealt with.
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html
Quoted 9 lines
Here's a report of someone successfully using one in Linux, with a picture to show the particular model (there are many USB audio adaptors, but that particular plastic moulding style seems common):
http://www.hermann-uwe.de/photoblog/3d-sound-usb-audio-device
Here's some further information on actually getting the driver running:
A lot of these inexpensive USB audio dongles seem to use chipset by CMI. The one I tried (around $7, mail-order from Taiwan) works fine iwht the Linux USB audio driver, at least for simple functions.
Quoted 3 lines
Maybe the sampling rate mismatch will be an issue with these devices too.
:(
Could be. The same remedy should apply - plughw will work on top of pretty much any hardware implementation.
I think I'll add plughw: entries to the ALSA glue code's dialog, as a hint to users that there might be a reason to use this feature.
Quoted 6 lines
My particular interest is in the LEDs on the USB thingummybob. If they can be programmed easily then the audio adapter could become a self contained audio in/out/PTT device (with the LED line controlling a transistor or something for PTT). I don't yet have a unit to experiment with (despite them being very cheap) but I think the idea has merit. If someone else wants to dabble...
Unfortunately, in the case of the CMI-chipset devices I've looked at, the LED functionality is hardwired by the chip. Open the audio endpoints and start doing reads or writes, and the LED starts blinking. I couldn't see any way in the chipset register documentation to control the LEDs directly, or change their behavior (e.g. non-blinking, illuminate-on-output-only, etc.). So, I'm afraid that either a separate serial/parallel-port PTT, or a vox-like PTT circuit (such as I believe the SignaLink USB uses) will be necessary.
On a related subject - has anyone come across any modern, usable, halfway-readable sample code for doing Linux USB I/O to HID endpoints? A fair number of chips seem to have one or more GPIO pins, addressible via HID endpoints, but I've been quite unable to make any sense of the various Linux documentation on how one might actually read/write these sorts of endpoint entities.
Hmm.
According to the nslu2-linux wiki these are two common chips found in the USB audio adapters:
http://www.cmedia.com.tw/?q=en/USB/CM102
http://www.cmedia.com.tw/?q=en/USB/CM103
(There was a CM106, but the link didn't work). The 102 chip is output only, but the 108 has audio input and output. I looked at the bullet points for the 108 chip and found this:
* 4 GPIO pins with read/write via HID
(The 102 has one GPIO pin).
How exciting! Of course, it's hit and miss as to whether you get this chip in any particular adaptor, but it's possible that the LEDs are hooked up to some fixed function (as you have discovered) but that the GPIO pins are free. It's also possible that the vendor has chosen to disable this function as the chips are highly customisable.
Wishful thinking perhaps, especially as I haven't looked for a datasheet yet (more to the point, I don't actually have one of these doodads either.)
Actually, reading your email again, are these the GPIO endpoints that you can't yet work out how to write to?
73,
Andrew
ZL3AME
Quoted 57 lines · Dave Platt
Quoted 4 lines
Here's a report of someone successfully using one in Linux, with a picture to show the particular model (there are many USB audio adaptors, but that particular plastic moulding style seems common):
Quoted 8 lines
http://www.hermann-uwe.de/photoblog/3d-sound-usb-audio-device
Here's some further information on actually getting the driver running:
A lot of these inexpensive USB audio dongles seem to use chipset by CMI. The one I tried (around $7, mail-order from Taiwan) works fine iwht the Linux USB audio driver, at least for simple functions.
Quoted 5 lines
Maybe the sampling rate mismatch will be an issue with these devices too.
:(
Could be. The same remedy should apply - plughw will work on top of pretty much any hardware implementation.
I think I'll add plughw: entries to the ALSA glue code's dialog, as a hint to users that there might be a reason to use this feature.
Quoted 6 lines
My particular interest is in the LEDs on the USB thingummybob. If they
can be programmed easily then the audio adapter could become a self
contained audio in/out/PTT device (with the LED line controlling a transistor or something for PTT). I don't yet have a unit to experiment with (despite them being very cheap) but I think the idea has merit. If someone else wants to dabble...Unfortunately, in the case of the CMI-chipset devices I've looked at, the LED functionality is hardwired by the chip. Open the audio endpoints and start doing reads or writes, and the LED starts blinking. I couldn't see any way in the chipset register documentation to control the LEDs directly, or change their behavior (e.g. non-blinking, illuminate-on-output-only, etc.). So, I'm afraid that either a separate serial/parallel-port PTT, or a vox-like PTT circuit (such as I believe the SignaLink USB uses) will be necessary.
On a related subject - has anyone come across any modern, usable, halfway-readable sample code for doing Linux USB I/O to HID endpoints? A fair number of chips seem to have one or more GPIO pins, addressible via HID endpoints, but I've been quite unable to make any sense of the various Linux documentation on how one might actually read/write these sorts of endpoint entities. --
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html
Quoted 6 lines
How exciting! Of course, it's hit and miss as to whether you get this chip in any particular adaptor, but it's possible that the LEDs are hooked up to some fixed function (as you have discovered) but that the GPIO pins are free. It's also possible that the vendor has chosen to disable this function as the chips are highly customisable.
Quoted 6 lines
Wishful thinking perhaps, especially as I haven't looked for a datasheet yet (more to the point, I don't actually have one of these doodads either.)
Actually, reading your email again, are these the GPIO endpoints that you can't yet work out how to write to?
Yup. Those are the ones.
There may be some light a'glimmering, though. In another discussion today I ran across an open-source project for a general-purpose programmer board for PIC and AVR and I2C and SPI devices, which uses a USB-enabled PIC as its basis. The PIC presents a 64-byte HID packet interface, and the developer has provided source code for the Linux software needed to communicate with it and send the packets that its firmware expects.
By studying this I hope to be able to figure out the magic involved in accessing one of the CMedia chips' HID endpoints and twizzling its GPIOs.
If that succeeeds, then it might be possible to gut one of these cheap dongles. hook it up to a couple of isolation transformers and an optocoupler, and drive a transceiver with it... a homebrew near- equivalent to the SignaLink USB.
Doing so would require that the packet software (or whatever) know how to tell the GPIOs to go up and down. I'm not sure that the usual approach of opening a kernel device and using ioctl() calls would be appropriate... a change to the software to run an external application to assert and deassert PTT might be preferable.
Quoted 23 lines · Dave Platt
Quoted 6 lines
How exciting! Of course, it's hit and miss as to whether you get this chip in any particular adaptor, but it's possible that the LEDs are hooked up to some fixed function (as you have discovered) but that the GPIO pins are free. It's also possible that the vendor has chosen to disable this function as the chips are highly customisable.
Quoted 6 lines
Wishful thinking perhaps, especially as I haven't looked for a datasheet yet (more to the point, I don't actually have one of these doodads either.)
Actually, reading your email again, are these the GPIO endpoints that you can't yet work out how to write to?
Yup. Those are the ones.
There may be some light a'glimmering, though. In another discussion today I ran across an open-source project for a general-purpose programmer board for PIC and AVR and I2C and SPI devices, which uses a USB-enabled PIC as its basis. The PIC presents a 64-byte HID packet interface, and the developer has provided source code for the Linux software needed to communicate with it and send the packets that its firmware expects.
Quoted 3 lines
By studying this I hope to be able to figure out the magic involved in accessing one of the CMedia chips' HID endpoints and twizzling its GPIOs.
Another source of info on HID might be the AVR-USB project (which does USB in firmware), and its HIDKeys example
http://www.obdev.at/products/avrusb/index.html
http://www.obdev.at/products/avrusb/hidkeys.html
73
Don - W7DMR
Quoted 4 lines
By studying this I hope to be able to figure out the magic involved in accessing one of the CMedia chips' HID endpoints and twizzling its GPIOs.
Well, phooey.
I did some digging last night and determined a few things:
- The USB audio dongle I have doesn't use a CMedia chip. Rather, its chip is from TenX Technologies.
- The TenX chip is, basically, a USB-enabled 8051 micro with some analog capabilities: a single-channel ADC with differential inputs, and a pair of PWM outputs that are filtered down to create a continuous analog signal for headphones or speakers.
- The USB endpoints appear to be managed via the 8051 firmware, which is in OTP.
- The sample rates supported by the audio-in and audio-out streaming endpoints are different, and disjoint - there doesn't not appear to be a common sound rate for the two interfaces! This is unlike the TI chip used in the SignaLink USB, whose input sample rates are a superset of the output sample rates. Use of the plughw: ALSA sample rate converter would be required.
- The chip has plenty of GPIO pins, two of which appear to be wired up to the power and activity LEDs on the dongle.
- Some GPIO pins are intended to be hooked up a keyboard scanning matrix. The HID input-report descriptor provided by this version of the chip identifies features like VOLUME UP, MUTE, and so forth. There's also a second HID input report which seems to have a bunch of unspecified input flags in it.
- There is no HID output endpoint, and no output HID reports defined... and thus no ability to control any of the GPIO pins from the USB host.
Hence, no PTT control in software. This particular brand of chip doesn't appear to be suitable for a simple "all in one" packet audio USB interface, unless chips can be sourced directly from the manufacturer and some different firmware programmed into them... seems excessive.
The CMedia chips might be a better choice... I'll have to see if I can find a local cheap source for a USB dongle with one of these in it.
A third alternative would be a USB audio interface which uses one of the TI streaming audio controller chips... these are also 8051-core micros, but it appears that the main code is located from an external EPROM rather than from OTP within the chip. The SignaLink USB uses one of these chips - I'll try interrogating its HID report structure and see whether there are any output reports which might control one of the GPIO pins.
If so, there may be a very interesting prospect for homebrewers:
the Behringer UCA202. This is a stereo USB/audio adapter which (from what I've read) uses one of these TI chips internally... and it's available for $25-$30 from numerous online sources. If there's a way to write its GPIO pins, then a board scavenged from a UCA202, plus a couple of isolation transformers and an optoisolator for PTT, might make a very nice packet interface. And, what's more, it has stereo-audio goesintas and goesoutas, which means that it could be used with an I/Q modulator/demodulator front end... software DSP single sideband or OFDM, anyone?
Hi everyone,
A long time ago I wrote in this mailing list about using the GPIO lines which are present on some USB sound card chips to control PTT. This would make a self-contained radio interface which would not need a separate wire to a parallel or serial port. I said that if this would work with soundmodem then it would be a Good Thing.
Well, I haven't had the chance to do anything for a long time, but recently I started dabbling again and I finally got around to doing it.
I have discovered that the CM108 chip has become scarce, and also the packaged version of the chip is not so common as these days the chips are often epoxy blobbed. They can still be found however, and there are now successors to this chip: CM109 and CM119 for example; and alternatives: SSS1620/1/3. There are also many examples of using the GPIO pins for PTT for Asterisk (app_rpt), TheLinkBox and the pcrepeatercontroller projects. Inspired by these I have implemented USB GPIO PTT control in soundmodem and submitted a patch to Thomas Sailer and he has incorporated it into soundmodem v0.16.
Please note, it has not been extensively tested. I don't have a CM108, but I have had my modified code working with SSS1621 and SSS1623. I have a CM119, but Linux does not create a /dev/hidrawX node for it (the audio function works, but not the HID for buttons etc., so GPIO can't be controlled).
If anyone is interested, please download the source[1] and take a look. It should work with C-Media chips (e.g. CM108), but the vendor and product IDs for SSS1621 and SSS1623 must be added if you have these chips. Actually, I have a patch for this if you need it. On the hardware side, amongst other things you have to solder a tiny pin on the chip and connect it to a transistor to drive PTT.
73,
Andrew
ZL3AME
Do these cheapo USB things with only a Mic input have enough impedance matching to handle a line level input?
The reviews seem to be focused on playback. I'm willing to invest the $5 to find out but would rather not waste a week to find out....
73
/a
Quoted 121 lines · Andrew Errington
Hi,
Spookily enough I have been thinking exactly the same thing.
The real cheap USB audio devices seem to work in Linux. They're less than NZ$10 in New Zealand, but I don't actually have one yet.
Here's a report of someone successfully using one in Linux, with a picture to show the particular model (there are many USB audio adaptors, but that particular plastic moulding style seems common):
http://www.hermann-uwe.de/photoblog/3d-sound-usb-audio-device
Here's some further information on actually getting the driver running:
http://www.hermann-uwe.de/blog/playing-audio-on-the-nslu2
And here's some general discussion of some different USB audio devices and issues:
http://www.nslu2-linux.org/wiki/HowTo/SlugAsAudioPlayer
Maybe the sampling rate mismatch will be an issue with these devices too.
:(
The discussion is targeted at the LinkSys NSLU2 device, but I think the information can be extrapolated to Linux in general.
My particular interest is in the LEDs on the USB thingummybob. If they can be programmed easily then the audio adapter could become a self contained audio in/out/PTT device (with the LED line controlling a transistor or something for PTT). I don't yet have a unit to experiment with (despite them being very cheap) but I think the idea has merit. If someone else wants to dabble...
73,
Andrew
ZL3AMEQuoted 61 lines · Dave Platt
Quoted 8 lines
Can anyone recommend a USB sound adapter for use with Tom's soundmodem?
I'm building an aprsdigi with a newer server I was given that has no
motherboard sound and no PCI slots (and no parallel port to do an easy PTT with either:-( I see there's a few choices out there and was hoping one of you had already found one that you could recommend. Thanks.I've just been spending some time trying to get the SignaLink USB to work with the soundmodem. Have run into a few problems, think I understand their cause, and am working on fixes.
First problem noted: the AFSK modem would not even start to receive when using soundmodemconfig. The ALSA audio glue complained about the RX and TX sample rates being different (and the code has a comment in it to the effect of "Make different-rate configurations work, or take them out.")
The cause: apparently, the TI USB sound chip in this device publishes a different set of sample rates as being available for its input and output endpoints. When the device is opened using the "hw:" ALSA specifier (as is suggested by the setup dialog), only the actual adapter sample rates are available, and since none of them happens to match the sample rate that the Soundmodem asks for, the closest-available rates are offered to the soundmodem. These offered rates are different and the Soundmodem balks.
Workaround: type in "plughw:1,0" as the device to use. The "plughw:" module will do software sample-rate conversion when necessary, and in this case it allows the Soundmodem to use the sample rate it wants. The same rate is used for both the RX and TX channels, and all is well.
At this point, incoming AFSK packets started being decoded reliably (as long as the receiver squelch was opened).
[Possible alternative - use the ALSA/OSS emulation module, the SoundModem OSS interface, and open
/dev/dsp1. I don't recommend this, as I've observed numerous problems and data glitches in the OSS emulation sample rate converter.]Second problem noted: the soundmodem app would either stop receiving and transmitting, or exit abruptly with a "closed pipe" error.
The cause: the ALSA drivers will report a "closed pipe" any time the internal audio state machine goes into the XRUN state, which occurs if there's a buffer overflow (on receive) or underflow (on transmit). This apparently can occur due to timing / race conditions during TX/RX turnaround. It's necessary to restart the TX or RX channel with a "prepare" call, and it appears that the Soundmodem code doesn't do this if an EPIPE error occurs... instead, it bails out and dies.
I haven't yet modified the Soundmodem code to do what's necessary but I don't think it'll be difficult.
I've had good results with the SignaLink USB using other sound packages, for PSK31 and other digital modes, and I believe it'll work well for AFSK packet once the driver-interface glitches are dealt with.
Quoted 7 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Alan Crosswell
Do these cheapo USB things with only a Mic input have enough impedance matching to handle a line level input?
A line-level signal is at a substantially higher voltage level... it's usually 1 to 2 volts peak-to-peak. Microphone level is lower... perhaps 100 millivolts peak-to-peak.
Driving a microphone input with a line-level signal may overdrive it into serious distortion. On some devices, the input is switchable between line and microphone levels (this is usually done via the software mixer). On others, the additional gain in the mic path cannot be defeated, and it's necessary to "turn down" the input signal to avoid overdriving.
This "turn-down" can be done with a couple of resistors, or (if you want adjustable gain) via a potentiometer.
There's a disadvantage to "padding" down the signal level and going in the higher-gain mic input - the resulting noise level will probably be somewhat higher than if you went into a properly- level-matched line input.
Impedance matching per se is very probably not a problem in this case. Line-level drive circuits usually have a fairly low output impedance (a few tens or hundreds of ohms), and both mic and line-level inputs have relatively high input impedances (tens of thousands of ohms). The input impedance is so high that it does not load down the driving circuit by any significant amount.
Quoted 2 lines
The reviews seem to be focused on playback. I'm willing to invest the $5 to find out but would rather not waste a week to find out....
My guess is that this approach would probably work just fine for AFSK packet, with most cheap USB audio dongles (plus a padding resistor or two), due to the characteristic of the signal... high audio level, lots of gain in the FM signal path, and no close-in interferers within the audio bandwidth.
I'm not sure they'd work as well in (for example) weak-signal I/Q demodulation applications - their dynamic range might not be adequate.
Thank you very much for finding this. I have been struggling with this for a long time. I had to revert my laptop back to an older OS release to get my portable system working again.
I was using the OSS emulation mode, /dev/dsp* and never saw a message about sampling rates. After much effort and several false trails I had just found that sometimes there was a group of zeros in the incoming data. Using alsa and "plughw" makes it work!.
Perhaps it is time to include a sample config file that uses alsa.
73
Don - W7DMR
Quoted 61 lines · Dave Platt
Quoted 5 lines
Can anyone recommend a USB sound adapter for use with Tom's soundmodem? I'm building an aprsdigi with a newer server I was given that has no motherboard sound and no PCI slots (and no parallel port to do an easy PTT with either:-( I see there's a few choices out there and was hoping one of you had already found one that you could recommend. Thanks.
I've just been spending some time trying to get the SignaLink USB to work with the soundmodem. Have run into a few problems, think I understand their cause, and am working on fixes.
First problem noted: the AFSK modem would not even start to receive when using soundmodemconfig. The ALSA audio glue complained about the RX and TX sample rates being different (and the code has a comment in it to the effect of "Make different-rate configurations work, or take them out.")
The cause: apparently, the TI USB sound chip in this device publishes a different set of sample rates as being available for its input and output endpoints. When the device is opened using the "hw:" ALSA specifier (as is suggested by the setup dialog), only the actual adapter sample rates are available, and since none of them happens to match the sample rate that the Soundmodem asks for, the closest-available rates are offered to the soundmodem. These offered rates are different and the Soundmodem balks.
Workaround: type in "plughw:1,0" as the device to use. The "plughw:" module will do software sample-rate conversion when necessary, and in this case it allows the Soundmodem to use the sample rate it wants. The same rate is used for both the RX and TX channels, and all is well.
At this point, incoming AFSK packets started being decoded reliably (as long as the receiver squelch was opened).
[Possible alternative - use the ALSA/OSS emulation module, the
SoundModem OSS interface, and open/dev/dsp1. I don't recommend this, as I've observed numerous problems and data glitches in the OSS emulation sample rate converter.]Second problem noted: the soundmodem app would either stop receiving and transmitting, or exit abruptly with a "closed pipe" error.
The cause: the ALSA drivers will report a "closed pipe" any time the internal audio state machine goes into the XRUN state, which occurs if there's a buffer overflow (on receive) or underflow (on transmit). This apparently can occur due to timing / race conditions during TX/RX turnaround. It's necessary to restart the TX or RX channel with a "prepare" call, and it appears that the Soundmodem code doesn't do this if an EPIPE error occurs... instead, it bails out and dies.
I haven't yet modified the Soundmodem code to do what's necessary but I don't think it'll be difficult.
I've had good results with the SignaLink USB using other sound packages, for PSK31 and other digital modes, and I believe it'll work well for AFSK packet once the driver-interface glitches are dealt with.
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ICOM PCR1000
In reply to Dave PlattHi.
I have just revives my old ICOM PCR1000 after a period of rest.
It used to be contrlled with Windo$e in the bad old days, but now I have put away childish things and am using Debian Lennie.
I have qpcr1k which controls it well from the command-line. Can anyone recommend a spectrum display that runs well with the PCR1000 ?
73
Geoff G3FHL