Re: [Jamin] Re: [linux-audio-user] good spectrum analyser

From: Jan Depner ^lt;eviltwin69_at_cableone.net>
Date: 02/22/04 08:26 EST
Message-Id: <1077456376.24174.14.camel@eviltwin>
Steve,

	Is there anything I can do to help with this one (will there be any
graphics)?

Jan


On Sun, 2004-02-22 at 07:14, Steve Harris wrote:
> On Sat, Feb 21, 2004 at 10:00:32 -0600, Jack O'Quin wrote:
> > > It just needs the threading and HDEQ spectrum code.
> > 
> > If it's in the same CVS tree, it might as well be built as an
> > additional command in the same src directory.  Then, it could probably
> > share several some common .c files.  That reuse could help reduce
> > maintenance later on, perhaps.
> 
> I was thinking of a different top level directory, I thought the code
> would diverge quite a bit. Having it as a sepersate command is a good idea
> if we can factor out the bits that will be common across both programs.
> 
> <mode="thinking-out-loud">
> 
> >From a DSP persepective the code would be quite different - the oversample
> would only be x2, so the current helper thread would be needed at < 1024
> samples/block, and I'd like to use it as a testbed for the idea I had
> earlier of decimating the input data a couple of times and FFTing the
> decimated data in parallel streams.
> 
>         .------------.
> in --+--| 2048pt FFT |----------------------------> top 3 octaves of display
>      |  '------------'
>      |  .-------------.   .------------.
>      '--| 4x decimate |-+-| 2048pt FFT |---------------> next 3 octaves down
>         '-------------' | '------------'
>                         |  .-------------. .------------.
>                         '--| 4x decimate |-| 2048pt FFT |----> lower octaves
>                            '-------------' '------------'
> 
> So if the input is 96k the most accurate bottom bins will be only 3 Hz
> wide (rather than the 47Hz they are in JAMin), though they will also only
> be calculated 6 times a second and will be quite latent (500ms ish at
> 48k), but thats the tradeoff.
> 
> Hmm... as it doesnt really matter wether the graph shown at any time is
> self-consistent (infact it never will be) we should also be able to do
> away with some of the double buffering and just scrible directly on the
> vector that the UI code reads to get amplitude values. That vector
> probalbly should be linear with pitch too - 100, 50 or 25 cent intervals I
> guess.
> 
> - Steve
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jamin-devel mailing list
> Jamin-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jamin-devel




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Jamin-devel mailing list
Jamin-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jamin-devel
Received on Sun Feb 22 08:24:49 2004

This archive was generated by hypermail 2.1.8 : 02/22/04 08:24 EST