[ntp:questions] New to group: radio/audio interest

Harlan Stenn stenn at ntp.org
Wed May 9 06:18:32 UTC 2012

Alan wrote:
> Harlan wrote:
>> What you are doing is pretty much what I did when I worked on it
>> years ago.  The trick is that what works for some folks seems to
>> break the driver for others, and vice-versa.
> I realize that, especially with so many platorms involved.  I'm just
> trying to get mine working, but I wonder when was the last time
> anybody tried this under OpenBSD and what OpenBSD version that might
> have been?

No idea...

? I tried it a few years ago and it didn't work then either,
> but now I have more time.

That's what happened with me when I decided I was going "make it go"
with FreeBSD.  At the time, the "balance" I had was Prof. Mills, who has
some of these running in his shop.  If I made a change that caused him
trouble, I heard about it :)

>> Most folks only run 1 audio source so using 1 channel is fine.  Some
>> folks do run multiple audio sources and want the ability to feed one
>> signal into the L channel and the other signal into the R channel.
> Hmm.  I thought from somewhere in the documentation you could only have 
> one audio refclock program running at a time.

Not to my recollection.  I was doing my testing with the IRIG output
from first a Zyfer refclock, and then from a Meinberg device.

> I'd love to have chu and wwv on different channels, but that would
> leave me a little short on radios.

The joy of audio is that you can split the signal pretty easily, if that
is an option.

> Maybe 2 radios on different antennas could be used into the same audio
> refclock to provide diversity reception.  The same way many WiFi setups have
> 2 antennas.

Not sure... I tend to avoid outside antennae as I have seen too much
trouble from lightning.

>> I do find it strange that you need the O_NDELAY and to a lesser
>> extent the O_NOCTTY flags for that open.  It may be that most folks
>> who use an ICOM who would otherwise have this problem hard-wire
>> something to avoid issues with DCD or DTR, not sure.
> Frankly I stole the flags from Fldigi, which is working.  It drives my radio
> fine without fixing anything.  Sometimes (under Linux) wxtoimg will leave
> the port in such a mess that it can't connect anymore so I use Fldigi then
> go back to wxtoimg.  Fldigi is open source, wxtoimg isn't.
> It probably doesn't matter, but I'm driving the radio with a Prolific
> USB/serial adapter that somebody made into a CI_V converter then sold on
> eBay.  The main difference is that the computer doesn't have direct access
> to the normal RS-232 handshaking lines like RTS, DTR, etc.

USB serial has a *lot* of jitter.

>> What happens if you flat-out enable all of the info.{play,record}.*
>> initializations?
> I found it in my notes finally: "invalid control device parameters".  If you
> look at what the AUDIO_INITINFO macro in sys/audioio.h does, it's pretty
> crude: (void)memset((void *)(p), 0xff, sizeof(struct audio_info)) so it
> fills everything with 0xff.  I can't imagine why play settings would matter
> anyway except that they were so far wrong that they caused an error.  Maybe
> with some sound cards it wouldn't, this is an Intel chipset on the
> motherboard.

I know I have a URL to example audio code somewhere...

It uses a call to AUDIO_INITINFO followed by the explicit setting of a
handful of fields.

> In the pages for the refclocks he's very specific about an 8 KHz sampling
> rate so each sample is 1/8000 second (an "epoch").  Also the ulaw or mulaw
> encoding, and I was getting slinear_le.  It doesn't say whether 1 or 2
> channels is right, but I imagine it makes a difference of looking at every
> value or every other value.  It talks about being what was used for
> telephones, so that wouldn't be stereo.  My next step, if I could get
> wwv_receive() to be called, would be to do a hex dump of a bufferful of
> audio data.

There is a task on-hand to "improve" audio support for NTP.  For
example, we have a flag bit (at least in the IRIG driver) to specfy the
microphone port v. the line-in port.  I *thought* we also had a bit that
said right or left channel...

I'm not aware of any reason in the code one could not have multiple
instances of each audio driver, as long as one had the hardware to
handle the signals.

If this is a project you are up for working on I'm happy to help.

I would like to see this problem fixed, and fixed well.


More information about the questions mailing list