[LAD] Real-time plotting of audio/ oscilloscope.

[Nick Copeland]

How do the other scopes work? If you really want to get a good image of
a waveform on a screen then you might want to totally divorce the sampling
rate from the screen drawing:

To actually see a waveform and how it develops then you really need the scope
to sync to it. The way the oscilloscopes worked was a detection level at which 
to start painting (positive edge zero crossing for example but other levels are
equally acceptable) and a delay time before searching again (blanking period,
more or less).

After that you have the scan rate at which the analogue signal was painted
over the tube but for your waveforms just scan at the sample rate. Forget
drawing every sample as a pixel/line, just scan through the audio data to find
your sync point then render the next (eg) 500 samples into your favorite kind 
of bitmap and request it be displayed/flushed.

If you do this 20 times per second, ie, find your sync point every 50ms then
you will get a pretty good image of how a waveform develops over time. All
the rest of the audio data can be dumped unceremoniously to /dev/null. The
sample rate is not that relevent, making the rendered image have some form
of consistency is and you will not get that if you simply attempt to render every 
sample.

Regards, nick.

"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer




> Date: Thu, 17 Jun 2010 16:28:27 -0400
> From: paul at linuxaudiosystems.com
> To: nettings at folkwang-hochschule.de
> CC: linux-audio-dev at lists.linuxaudio.org
> Subject: Re: [LAD] Real-time plotting of audio/ oscilloscope.
> 
> 2010/6/17 Jörn Nettingsmeier <nettings at folkwang-hochschule.de>:
> > On 06/17/2010 07:37 PM, Jeremy wrote:
> >
> >> Now, assuming a 60 Hz refresh rate (which is what I believe my monitor
> >> has),
> >> and a buffer size of 1024 pixels, that would be  a throughput of 61440
> >> samples per second.  More than the 48000 sampling rate.  So it seems that
> >> drawing every sample *is* a reasonable request.  But obviously a lower
> >> refresh rate would also satisfy my needs.
> >
> > drawing all the samples is not the issue. drawing each sample individually
> > (and the assorted overhead that goes with it) is.
> > you really don't want to call a graphics toolkit more than $refresh times
> > per second...
> 
> to phrase it another way: its the difference between:
> 
>   a) oh good, a new sample has arrived, now i must plot it
> 
>   b) excellent, another 1/60th of a second has elapsed, how many
>         samples are there for me to draw on the screen?
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100617/86c27b96/attachment.html>