Re: [Discuss-gnuradio] VRAudioSource question (was Parallel Port Interface)

['Eric Blossom']

On Mon, Mar 03, 2003 at 05:40:23PM -0800, Ettus, Matt wrote:
> > I think that the entire AudioSource / AudioSink issue needs to be
> > revisited (again).  My general thought is to have them produce or
> > consume streams of floats or complexes, scaled to a maximum range of
> > +/- 1.0
> 
> What if you actually want ints?
>  
> > It would also remove additional bogus template code.
> 
> Right now it works with any simple numeric type.

OK, but see template commentary below.

> I can add a scale factor pretty easily, and default it to do +/-1.0.

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.

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.


> That's fine, but we also need to consider cards with >2 channels

Good point.

> I propose 

>       GrAudioSink<simple numeric type>(range)
>               accepts any number of streams (limited by soundcard)
>       GrAudioSinkC(range)
>               accepts any number of Complex streams (limited by soundcard)

OK.  (but I still don't like the template)

If you're going to have a range argument, I think the source needs it too.

>       GrAudioSource<simple numeric type>(sample_rate, range, number of 
> streams)
>       GrAudioSourceC(sample_rate, range, number of streams)

Aside to those who aren't that familiar with the GNU Radio code: In
the current implementation, a module may have a variable number of
inputs, but it must be told ahead of time how many outputs it will
have.  Hence the "number_of_streams" parameter.

> I'll work on this tonight.

Thanks!

> Anybody know ALSA and auto* well enough to get those integrated?  We'll want
> ALSA for multichannel soundcards.

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.

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.

> Matt

Eric