<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
How do the other scopes work? If you really want to get a good image of<br>a waveform on a screen then you might want to totally divorce the sampling<br>rate from the screen drawing:<br><br>To actually see a waveform and how it develops then you really need the scope<br>to sync to it. The way the oscilloscopes worked was a detection level at which <br>to start painting (positive edge zero crossing for example but other levels are<br>equally acceptable) and a delay time before searching again (blanking period,<br>more or less).<br><br>After that you have the scan rate at which the analogue signal was painted<br>over the tube but for your waveforms just scan at the sample rate. Forget<br>drawing every sample as a pixel/line, just scan through the audio data to find<br>your sync point then render the next (eg) 500 samples into your favorite kind <br>of bitmap and request it be displayed/flushed.<br><br>If you do this 20 times per second, ie, find your sync point every 50ms then<br>you will get a pretty good image of how a waveform develops over time. All<br>the rest of the audio data can be dumped unceremoniously to /dev/null. The<br>sample rate is not that relevent, making the rendered image have some form<br>of consistency is and you will not get that if you simply attempt to render every <br>sample.<br><br>Regards, nick.<br><br>"we have to make sure the old choice [Windows] doesn't disappear”.<br>Jim Wong, president of IT products, Acer<br><br><br><br><br>> Date: Thu, 17 Jun 2010 16:28:27 -0400<br>> From: paul@linuxaudiosystems.com<br>> To: nettings@folkwang-hochschule.de<br>> CC: linux-audio-dev@lists.linuxaudio.org<br>> Subject: Re: [LAD] Real-time plotting of audio/ oscilloscope.<br>> <br>> 2010/6/17 Jörn Nettingsmeier <nettings@folkwang-hochschule.de>:<br>> > On 06/17/2010 07:37 PM, Jeremy wrote:<br>> ><br>> >> Now, assuming a 60 Hz refresh rate (which is what I believe my monitor<br>> >> has),<br>> >> and a buffer size of 1024 pixels, that would be a throughput of 61440<br>> >> samples per second. More than the 48000 sampling rate. So it seems that<br>> >> drawing every sample *is* a reasonable request. But obviously a lower<br>> >> refresh rate would also satisfy my needs.<br>> ><br>> > drawing all the samples is not the issue. drawing each sample individually<br>> > (and the assorted overhead that goes with it) is.<br>> > you really don't want to call a graphics toolkit more than $refresh times<br>> > per second...<br>> <br>> to phrase it another way: its the difference between:<br>> <br>> a) oh good, a new sample has arrived, now i must plot it<br>> <br>> b) excellent, another 1/60th of a second has elapsed, how many<br>> samples are there for me to draw on the screen?<br>> _______________________________________________<br>> Linux-audio-dev mailing list<br>> Linux-audio-dev@lists.linuxaudio.org<br>> http://lists.linuxaudio.org/listinfo/linux-audio-dev<br> <br /><hr />Hotmail: Trusted email with powerful SPAM protection. <a href='https://signup.live.com/signup.aspx?id=60969' target='_new'>Sign up now.</a></body>
</html>