[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] VRAudioSource question (was Parallel Port Interfa
From: |
Matthew Ettus |
Subject: |
Re: [Discuss-gnuradio] VRAudioSource question (was Parallel Port Interface) |
Date: |
Tue, 4 Mar 2003 23:39:54 -0800 |
User-agent: |
Internet Messaging Program (IMP) 4.0-cvs |
Quoting 'Eric Blossom' <address@hidden>:
> When you say, "scale factor", do you mean the maximum value that you
> expect to read or write? E.g., scale_factor == 1 means my i/o shall
> be in the range [-1,+1] while scale_factor == 32768 means my i/o
> shall be in the range [-32768, 32768]. If so, let's give it another
> name, say "range". I think of "scale_factor" as the number I
> have to multiply by to convert into the appropriate range.
I was thinking of scale factor the same way you were. However, I changed it to
be I/O range, and generate the scale factor internally. It picks no scaling if
the user doesn't specify a scale factor.
> The Sink/Source can query the card to figure out what it can do, and
> then it can pick the correct scale factor, possibly based on a user
> provided "range". I'm trying to bury the hardware dependencies
> and simplify the interface at the same time.
Right now the default is 16 bits. When we do ALSA, we can extend that to handle
24 and 32 bit cards.
> > GrAudioSink<simple numeric type>(range)
> > accepts any number of streams (limited by soundcard)
> > GrAudioSinkC(range)
> > accepts any number of Complex streams (limited by soundcard)
Turns out that I already had the code in there to handle the complex case in the
template, so I didn't take it out.
> OK. (but I still don't like the template)
> Possible strategy: assume two implementations: GrAudioSource_oss.h and
> GrAudioSource_alsa.h and imagine that configure (somehow) creates
> GrAudioSource.h as a link to the appropriate one.
Good idea.
> For the record, I still think that this is a bad use of templates. It
> totally pollutes the namespace of everybody who includes the template
> header with all the include file cruft needed for the implementation.
> And note that the cruft included is going to to depend on which
> version is selected at configure time. This leads to hard to find
> include file problems, which are not contained to a single file (the
> actual implmentation file (non-existent in the template case)), but
> rather spread like cancer throughout the project. This is not good.
You forgot to add that templates cause Pestilence, Famine, War, and Death, and
in so doing hasten the Apocalypse. :)
It's all checked in now.
Matt