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

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@email-addr-hidden
> To: nettings@email-addr-hidden-hochschule.de
> CC: linux-audio-dev@email-addr-hidden
> Subject: Re: [LAD] Real-time plotting of audio/ oscilloscope.
>
> 2010/6/17 Jörn Nettingsmeier <nettings@email-addr-hidden-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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
                                               
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Jun 18 00:15:03 2010