discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]