It’s now 2024-
Is there or will there ever be any way to use more “generic” audio interfaces for a radio interface?
I was asking this back in 2010.
I’ve always thought it would be fun or cool to use the built in audio on a laptop or PC motherboard that is already there.
In that case COS and PTT would be on a serial port or parallel port (also built in to thePC).
you never want to use the built in sound chip for an audio interface or you will have windows keying up your repeater or node. always use a 2nd audio fob modified for it. Lots of plans all over the internet for this.
many more interfaces that have an attached radio or separately. Shari node, clear nodes, Allscan.info nodes.
Rim Devices, DMK URI. if you have been asking since 2010 you moight want to figure out how to use google cause the information is all around
How is Windows going to key your node when ASL runs on Linux, and has exclusive access to the audio device?
FWIW, there is an old ALSA module for ASL from 2010, called chan_alsaradio, which theoretically does exactly this, using any generic I/O for audio, and serial for COR/COS. I tried using it a few years ago to implement a highly nonstandard configuration, but never got too far with it.
https://yo3iiu.ro/blog/?p=324
Creating another radio interface is “simply” a matter of a channel driver being written that does what you want it to do. There’s RTCMs and USRP devices out there and others could be created.
Any new channel driver that wants to use the native soundcard would have to be combined with some other kind of analog hardware to execute radio control. Any radio interface needs to be able to receive COR/COS and CTCSS as well as be able to send PTT. The CM1xx chipset provides on-chip GPIO pins for everything needed. One could add some sort of general GPIO module to the device and do it, but now we’re back to needing external hardware so why not just use one of the myriad of CM1xx-based devices?
1 Like
The cm108 audio usb interfaces are easy to find on aliexpress and cheaper online is not posible…
But both cm108 and cm119 are obsolete…so this means eventually we have to convert. But as long as the stocks are not depleated its our only choice.
I believe the CM108B and CM119B are still in production from CMedia?
This is a clever pending thought. If using a Raspberry, COS and PTT are easily addressed on ports. The problem is the hook to the variables in Asterisk.
Since it is Pi, a variety of audio is available. Managing levels can be a challenge.
Keep the thought process going.
OK same kind of response I got back in 2009.
“you can go write your own driver, we’re not interested”.
LOL.
And I’ve not learned how to write my own stuff yet. And this is a good reason to learn for sure.
I get it it’s not easy.
Also I NEVER ever mentioned Windows here so I do not know where those responses are coming from.
It sounds like new stuff would have to be “written” to make this work.
I’m also not asking, and never have asked or expected mainstream “support”.
It’s just that it would be cool to be able to use built in audio on some computers as well as be able to use the onboard hardware (serial and/or parallel ports) already on present within that hardware.
I never mentioned having to use any kind of external or USB hardware for PTT in this case.
If you get it you get it, if you don’t you don’t.
I personally think it would be cool and a worthwhile thing to try/do.
I also get it that the channel drivers as they are (are) expecting the PTT and COR to be within the same hardware being use for the audio, So this may be complicated in that way or because of this.
And I also get it if we have something that works and is available why have to re-write everything to work a different way if we don’t need to.
I get that and understand that part.
But would still be cool.
Well, I agree that something else needs to appear.
But to take you back to 2010, on a PC, you could have. And still can.
Using the parallel port (not a usb parallel adapter) to obtain cos /ptt , the sound unit is much less critical. For the software addresses for extracting those lines change with other adaptors and likely other things that are specific to that sound dongle.
My 1st private node back then actually did this with the built-in sound on a PC with a parallel port. But there is only one built-in sound and I had 3 private nodes then, so I just used the cm108’s and disabled the built-in as the motherboard was giving me issues with the shared IRQ supporting that built-in sound and I never looked back.
Of course this is no help with a Pi unless you separate the hardware interfacing with some other means. Every couple of years I load a Pi up and experiment with something on this.
The best results came from the I2C interface. And one can generate enough I/O to serve up 4 nodes+ and still have plenty of switches/inputs to play with.
Then I come to find out there was an attempt to do this already and has been buried in the code and not released since the passing of it’s author.
I did take some notes for others to follow.
But the framework is in there in the source to extract the code just for the i2c interfacing.
But I am looking in one other direction now and I am not sure when I will have time to sit with it again. I really don’t use the Pi for anything in Ham Radio/ASL, but I might.
I am using Pi’s with a i2c for other utility purposes.
So will anyone pick it up and run with it… I doubt it.
I may after retirement. No incentive at present.
This discussion comes around at least once a year for over the last decade.
Yeah, I get the desire but that’d be another snake’s nest of code along with the fact that almost no system today has a serial port or - most definitely - not an old parallel port. Even if it did, you’d have to co-opt the RS232 and hack into something like the CTS, RTS, DSR, DTR, etc. and line that up timing-wise with the audio.
I would be interested in hacking on a chan_raspi since at least the GPIO pins already exist natively. But the chan_simpleusb code is 1200+ lines long. I don’t know how much surgery it would take to clone it and replace the CM1xx semantics with the other audio semantics.
What would be really interesting is if you could somehow leverage PipeWire to do it but I’m not certain you could leverage the low-level GPIO items you’d need to make it viable.
In short, it’s a really tricky situation that would need someone who really wants to get it done and really knows the Linux sound stack inside and out.
I wonder if we could apply for an ARDC grant for it…
I’d like to see a Bluetooth option. Think about pairing your node with a BT URI 
or, possibly to your favorite hands-free headset ?
Cool stuff, and I have always “wanted” to learn how to do some of this stuff and still do.
Stuff like this can make it worthwhile and fun (to me).
I was more thinking of all the old FREE laptops and desktops out there that could make great nodes.
I have a pile of such desktops and laptops there have simply been discarded, but can run Debian12/amd64 and have all of this hardware built in.
It would be cool to use some of it as-is.
I’m also interested in all of the learning that would be involved to make that work.
Probably going to take me awhile! But I’ll come out of it a lot better than I am now.