USB sound adapter for use with Tom's soundmodem?

USB sound adapter for use with Tom's soundmodem?

[Alan Crosswell]

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

Re: USB sound adapter for use with Tom's soundmodem?

[Dave Platt]

> 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.

Re: USB sound adapter for use with Tom's soundmodem?

[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
ZL3AME


On Sat, December 13, 2008 16:59, Dave Platt wrote:
>> 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 majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
>

Re: USB sound adapter for use with Tom's soundmodem?

[Dave Platt]

> 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

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.

> 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.

> 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.

Re: USB sound adapter for use with Tom's soundmodem?

[Andrew Errington]

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




On Sat, December 13, 2008 18:08, Dave Platt wrote:
>> 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
>>
>
> 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.
>
>> 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.
>
>> 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 majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
>

Re: USB sound adapter for use with Tom's soundmodem?

[Alan Crosswell]

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

Andrew Errington wrote:
> 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
>
>
> On Sat, December 13, 2008 16:59, Dave Platt wrote:
>   
>>> 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 majordomo@vger.kernel.org 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>   

Re: USB sound adapter for use with Tom's soundmodem?

[don]

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


On Fri, Dec 12, 2008 at 07:59:42PM -0800, Dave Platt wrote:
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB sound adapter for use with Tom's soundmodem?

[Dave Platt]

Alan Crosswell wrote:
> 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.

> 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.

Re: USB sound adapter for use with Tom's soundmodem?

[Dave Platt]

> 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?

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.

Re: USB sound adapter for use with Tom's soundmodem?

[don]

On Mon, Dec 15, 2008 at 03:47:00PM -0800, Dave Platt wrote:
> > 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?
> 
> 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.

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

Re: USB sound adapter for use with Tom's soundmodem?

[Dave Platt]

> 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?

ICOM PCR1000

[Geoff Bagley]

Hi.

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

Re: USB sound adapter for use with Tom's soundmodem?

[Andrew Errington]

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

[1] http://www.baycom.org/~tom/ham/soundmodem/