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(a)linuxaudiosystems.com
To: nettings(a)folkwang-hochschule.de
CC: linux-audio-dev(a)lists.linuxaudio.org
Subject: Re: [LAD] Real-time plotting of audio/ oscilloscope.
2010/6/17 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>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(a)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