21 Dec
2011
21 Dec
'11
3:29 a.m.
Hey all,
I've been writing a scope the last while, and I'm intrested in how other
people have approached plotting the data.
Currently I'm taking every 50th sample, and drawing a line from the
previous sample to there, and so on. Not particulary neat.
So is there a resample, or smoothing of the samples, or how does one plot a
"smooth" waveform like Ardour / QTractor?
My other question is about RMS, is calculating it in its literal sense
best? Or perhaps only taking every 5th sample?
Resampling the signal from 44.1 or 48k to say 11025? I'm not really sure
which way to go.
Cheers, -Harry
21 Dec
21 Dec
3:34 a.m.
2011/12/20 Harry van Haaren <harryhaaren(a)gmail.com>
Hey all,
I've been writing a scope the last while, and I'm intrested in how other
people have approached plotting the data.
Currently I'm taking every 50th sample, and drawing a line from the
previous sample to there, and so on. Not particulary neat.
So is there a resample, or smoothing of the samples, or how does one plot
a "smooth" waveform like Ardour / QTractor?
You might find some inspiration in sndpeek:
http://soundlab.cs.princeton.edu/software/sndpeek/
Best,
Tristan
--
Tristan Matthews
web: http://tristanswork.blogspot.com
5:05 p.m.
On 12/21/2011 03:34 AM, Tristan Matthews wrote:
You might find some inspiration in sndpeek:
http://soundlab.cs.princeton.edu/software/sndpeek/
Wow. very neat! I did not know about this project.
Do you have contact w/ upstream?
It requires a few additional header includes (stdlib, stdio; for abs()
and sprintf()) to compile with recent gcc.
robin
6:15 p.m.
2011/12/21 Robin Gareus <robin(a)gareus.org>
On 12/21/2011 03:34 AM, Tristan Matthews wrote:
Unfortunately no, I'm not sure how actively developed it is.
You might find some inspiration in sndpeek:
http://soundlab.cs.princeton.edu/software/sndpeek/
Wow. very neat! I did not know about this project.
Do you have contact w/ upstream?
It requires a few additional header includes (stdlib,
stdio; for abs()
and sprintf()) to compile with recent gcc.
It's also using (included in the tarball) fairly old portions of Stk (
https://ccrma.stanford.edu/software/stk/). It would be a good idea to
update these, the biggest change being the RtAudio API. I wouldn't mind
taking a crack at it.
Best,
Tristan
--
Tristan Matthews
web: http://tristanswork.blogspot.com
24 Dec
24 Dec
6:54 a.m.
2011/12/21 Tristan Matthews <le.businessman(a)gmail.com>om>:
It's also using (included in the tarball) fairly old portions of Stk
(https://ccrma.stanford.edu/software/stk/). It would be a good idea to
update these, the biggest change being the RtAudio API. I wouldn't mind
taking a crack at it.
So I ended up updating the stk files and porting sndpeek to the new
API. It builds and runs fine with JACK and ALSA. The modifications are
in the master branch of this git repo:
https://gitorious.org/sndpeek/
I mailed the sndtools devs as well, hopefully this will be useful to
them. Patches welcome.
Best,
Tristan
--
Tristan Matthews
web: http://tristanswork.blogspot.com
10:54 a.m.
On 12/24/2011 06:54 AM, Tristan Matthews wrote:
2011/12/21 Tristan Matthews
<le.businessman(a)gmail.com>om>:
Thanks a lot. That's a very nice x-mas present! works as is.
two very minor things:
the INSTALL file could mention to `cd src/sndpeek` before running make.
and the documentation (printed on statup) could be updated:
'4' - toggle feature extraction (broken)
it does not seem to be broken. The annotations seem correct and can be
toggled. Though of course I don't know what was broken.
It's also using (included in the tarball) fairly old portions of Stk
(https://ccrma.stanford.edu/software/stk/). It would be a good idea to
update these, the biggest change being the RtAudio API. I wouldn't mind
taking a crack at it.
So I ended up updating the stk files and porting sndpeek to the new
API. It builds and runs fine with JACK and ALSA. The modifications are
in the master branch of this git repo:
https://gitorious.org/sndpeek/ I mailed the sndtools devs as well, hopefully this
will be useful to
them. Patches welcome.
Best,
Tristan
2:52 p.m.
2011/12/24 Robin Gareus <robin(a)gareus.org>rg>:
Thanks a lot. That's a very nice x-mas present! works as is.
two very minor things:
the INSTALL file could mention to `cd src/sndpeek` before running make.
and the documentation (printed on statup) could be updated:
'4' - toggle feature extraction (broken)
it does not seem to be broken. The annotations seem correct and can be
toggled. Though of course I don't know what was broken.
Done, I also removed some files that weren't being used.
Best,
Tristan
--
Tristan Matthews
web: http://tristanswork.blogspot.com
21 Dec
21 Dec
4:23 p.m.
(sorry Harry, I missed to CC the list)
On 12/21/2011 03:29 AM, Harry van Haaren wrote:
Hey all,
I've been writing a scope the last while, and I'm intrested in how other
people have approached plotting the data.
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/yass-0.0.2.tar.bz2
or http://xoscope.sourceforge.net/
Currently I'm taking every 50th sample, and
drawing a line from the
previous sample to there, and so on. Not particulary neat.
So is there a resample, or smoothing of the samples, or how does one plot a
"smooth" waveform like Ardour / QTractor?
IIRC ardour uses all audio samples and lets cairo do the scaling.
My other question is about RMS, is calculating it in
its literal sense
best?
It depends on the use-case. A traditional analog scope does that. Well,
it is not true RMS but a low-pass filter.
Or perhaps only taking every 5th sample?
Better take the min/max of all sample that fall on a single pixel on the
time-axis and draw a box (actually a vertical line if x is the time-axis).
Resampling the signal from 44.1 or 48k to say 11025?
I'm not really sure
which way to go.
11025?
25 (fps) (or actually: screen update-freq aka vblank-frequency)
multiplied by the width of display in pixels is more appropriate.
Cheers!
robin
4:30 p.m.
On Wed, Dec 21, 2011 at 10:22 AM, Robin Gareus <robin(a)gareus.org> wrote:
IIRC ardour uses all audio samples and lets cairo do
the scaling.
no. we have some fairly complex code. cairo plays no role (at
present). i'm not in the mood to explain all the details.
gtk2_ardour/canvas-waveview.c has most of the details. ardour rarely
draws waves directly from audio data.
4:38 p.m.
On , Paul Davis <paul(a)linuxaudiosystems.com> wrote:
gtk2_ardour/canvas-waveview.c
Thanks for the
pointer, indeed it seems quite complex to me :D
I was concidering doing all RMS calculation or max / min in a seperate
thread, and keep the results local in the GUI.
I'll guess thats roughly what all the cache operations are in the
canvas_waveview.c
@Robin: Thanks for the other scope examples, I'll look into them. The Max /
Min code is probably easiest, I'll try that :)
Cheers, -Harry
4:38 p.m.
On Wed, Dec 21, 2011 at 04:22:48PM +0100, Robin Gareus wrote:
If there are > 1 samples per pixel yass finds the min and max samples
for each pixel and draws a vertical line from min to max.
One refinement of this (not done in yass): to compute min and max
for the next pixel, don't reset the current values but just swap
them. This ensures that lines are connected in all cases.
If you have more than one pixel per sample, and your app is a scope
(rather than just a informative waveform display in a DAW or so) you
have to resample. In a scope you have to upsample and interpolate
anyway to find the right trigger point.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
4:44 p.m.
On Wed, Dec 21, 2011 at 7:38 AM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
If you have more than one pixel per sample, and your
app is a scope
(rather than just a informative waveform display in a DAW or so) you
have to resample.
Indeed its an informative display, so no need for resampling or such..
Thanks, -Harry
4501
days inactive
4504
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
6 participants
participants (6)
-
Fons Adriaensen -
Harry van Haaren -
harryhaaren＠gmail.com
-
Paul Davis -
Robin Gareus -
Tristan Matthews