17 Jun
2010
17 Jun
'10
6:30 a.m.
Hi,
When I'm programming, I find it immensely helpful to be able to plot audio
data at different points in its processing, for debugging, and to test new
ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024 samples.
I've tried using libplot, but it seems too slow. It's causing constant
xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to draw the
pixels on the screen directly. I tried using SDL, but it caused excessive
xruns also. Simply setting 48000 pixels per second was enough to cause the
flow of xruns. This is *not* erasing the screen, just drawing the points.
I'd expect that erasing the screen is the slow part, but apparently not.
At this point I'm not sure if it's even possible to plot the audio data in
realtime. I did a rough calculation, that on my 2 Ghz cpu, it should have
roughly 40,000 cycles to process each sample. It seems to me that
considering running the whole plugin only uses 1/4 of my cpu, the other
30000 cycles should be plenty to put a pixel on the screen.
So I would guess that something else is the bottleneck, like my video chip,
or maybe the libraries I'm using.
So basically my question is: Has anyone else had any luck with plotting
audio data in real time, and if so, how? Is it not possible to plot every
sample, but only a certain percentage of them? Is there a fundamental
restriction on doing so, or is my problem in software?
Jeremy
8:41 a.m.
Ralf Mardorf wrote:
Jeremy wrote:
A blacklist (greylist) was started here, but it's a forum. We should do
a real 'list' (table) with printable short informations about no-go chip
sets etc..
Is there a fundamental restriction on doing so,
or is my problem in
software?
Jeremy
Hardware ;)!
We should start a black- and whitelist for hardware used for Linux
real-time. Unfortunately I could add my two machines to the blacklist :(.
8:43 a.m.
Ralf Mardorf wrote:
Ralf Mardorf wrote:
Sorry, here's the link: http://www.64studio.com/node/69
Jeremy wrote:
A blacklist (greylist) was started here, but it's a forum. We should
do a real 'list' (table) with printable short informations about no-go
chip sets etc..
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev Is there a fundamental restriction on doing so,
or is my problem in
software?
Jeremy
Hardware ;)!
We should start a black- and whitelist for hardware used for Linux
real-time. Unfortunately I could add my two machines to the blacklist
:(. 
4:27 p.m.
On Thursday 17 June 2010, Ralf Mardorf wrote:
Ralf Mardorf wrote:
And you could possibly borrow some of the worst hardware from our wiki's
list to start yours. ;-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
An intellectual is someone whose mind watches itself.
-- Albert Camus
Jeremy wrote:
A blacklist (greylist) was started here, but it's a forum. We should do
a real 'list' (table) with printable short informations about no-go chip
sets etc.. Is there a fundamental restriction on doing so,
or is my problem in
software?
Jeremy
Hardware ;)!
We should start a black- and whitelist for hardware used for Linux
real-time. Unfortunately I could add my two machines to the blacklist
:(.
9:01 a.m.
On Thu, Jun 17, 2010 at 2:25 AM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>wrote;wrote:
Jeremy wrote:
Which hardware is "bad"? The cpu? The video chip? The motherboard?
Jeremy
Is there a fundamental restriction on doing so,
or is my problem in
software?
Jeremy
Hardware ;)!
We should start a black- and whitelist for hardware used for Linux
real-time. Unfortunately I could add my two machines to the blacklist :(.
9:26 a.m.
Jeremy wrote:
On Thu, Jun 17, 2010 at 2:25 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net <mailto:ralf.mardorf@alice-dsl.net>> wrote:
Jeremy wrote:
Is there a fundamental restriction on doing so, or is my
problem in software?
Jeremy
Hardware ;)!
We should start a black- and whitelist for hardware used for Linux
real-time. Unfortunately I could add my two machines to the
blacklist :(.
Which hardware is "bad"? The cpu? The video chip? The motherboard?
Jeremy
Dunno. I could post $ hwinfo > hwinfo.txt for a combination of hardware
that will cause MIDI jitter when controlling external MIDI equipment.
My mobo is a M2A-VM HDMI with an onboard graphics 'ATI Radeon
X1250-based'. Currently I'm using this mobo with a 'NVIDIA GeForce 7200
GS'. Jitter and jitter free moments did shift a little bit when changing
the graphics. I guess it's minimal better when using the integrated
graphics, but the NVIDIA, anyway, I prefer the NVIDIA, because I'm now
able to do 3D stuff.
My CPU is a
spinymouse-sudo@64studio:~$ hwinfo --cpu
01: None 00.0: 10103 CPU
[Created at cpu.304]
Unique ID: rdCR.j8NaKXDZtZ6
Hardware Class: cpu
Arch: X86-64
Vendor: "AuthenticAMD"
Model: 15.107.2 "AMD Athlon(tm) X2 Dual Core Processor BE-2350"
Features:
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,rdtscp,lm,3dnowext,3dnow,rep_good,extd_apicid,pni,cx16,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,3dnowprefetch
Clock: 1000 MHz
BogoMips: 2000.04
Cache: 512 kb
Units/Processor: 2
Config Status: cfg=new, avail=yes, need=no, active=unknown
02: None 01.0: 10103 CPU
[Created at cpu.304]
Unique ID: wkFv.j8NaKXDZtZ6
Hardware Class: cpu
Arch: X86-64
Vendor: "AuthenticAMD"
Model: 15.107.2 "AMD Athlon(tm) X2 Dual Core Processor BE-2350"
Features:
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,rdtscp,lm,3dnowext,3dnow,rep_good,extd_apicid,pni,cx16,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,3dnowprefetch
Clock: 1000 MHz
BogoMips: 2000.04
Cache: 512 kb
Units/Processor: 2
Config Status: cfg=new, avail=yes, need=no, active=unknown
spinymouse-sudo@64studio:~$
My other machine currently is dismantled. The mobo is an ASRock K7VT2
and the CPU is an 32-bit 800 MHz AMD Athlon + NVIDIA GeForce Blabla 440.
9:33 a.m.
Ralf Mardorf wrote:
Jeremy wrote:
Correction, frequency scaling was ondemand, I changed to performance now:
spinymouse-sudo@64studio:~$ hwinfo --cpu
[snip]
Clock: 2100 MHz
[snip]
On Thu, Jun 17, 2010 at 2:25 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net <mailto:ralf.mardorf@alice-dsl.net>> wrote:
Jeremy wrote:
Is there a fundamental restriction on doing so, or is my
problem in software?
Jeremy
Hardware ;)!
We should start a black- and whitelist for hardware used for Linux
real-time. Unfortunately I could add my two machines to the
blacklist :(.
Which hardware is "bad"? The cpu? The video chip? The motherboard?
Jeremy
Dunno. I could post $ hwinfo > hwinfo.txt for a combination of
hardware that will cause MIDI jitter when controlling external MIDI
equipment.
My mobo is a M2A-VM HDMI with an onboard graphics 'ATI Radeon
X1250-based'. Currently I'm using this mobo with a 'NVIDIA GeForce
7200 GS'. Jitter and jitter free moments did shift a little bit when
changing the graphics. I guess it's minimal better when using the
integrated graphics, but the NVIDIA, anyway, I prefer the NVIDIA,
because I'm now able to do 3D stuff.
My CPU is a
spinymouse-sudo@64studio:~$ hwinfo --cpu
01: None 00.0: 10103 CPU
[Created at cpu.304]
Unique ID: rdCR.j8NaKXDZtZ6
Hardware Class: cpu
Arch: X86-64
Vendor: "AuthenticAMD"
Model: 15.107.2 "AMD Athlon(tm) X2 Dual Core Processor BE-2350"
Features:
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,rdtscp,lm,3dnowext,3dnow,rep_good,extd_apicid,pni,cx16,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,3dnowprefetch
Clock: 1000 MHz
BogoMips: 2000.04
Cache: 512 kb
Units/Processor: 2
Config Status: cfg=new, avail=yes, need=no, active=unknown
02: None 01.0: 10103 CPU
[Created at cpu.304]
Unique ID: wkFv.j8NaKXDZtZ6
Hardware Class: cpu
Arch: X86-64
Vendor: "AuthenticAMD"
Model: 15.107.2 "AMD Athlon(tm) X2 Dual Core Processor BE-2350"
Features:
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,rdtscp,lm,3dnowext,3dnow,rep_good,extd_apicid,pni,cx16,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,3dnowprefetch
Clock: 1000 MHz
BogoMips: 2000.04
Cache: 512 kb
Units/Processor: 2
Config Status: cfg=new, avail=yes, need=no, active=unknown
spinymouse-sudo@64studio:~$
My other machine currently is dismantled. The mobo is an ASRock K7VT2
and the CPU is an 32-bit 800 MHz AMD Athlon + NVIDIA GeForce Blabla 440. 
12:40 p.m.
On Thu, Jun 17, 2010 at 3:26 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
Dunno. I could post $ hwinfo > hwinfo.txt for a
combination of hardware that
will cause MIDI jitter when controlling external MIDI equipment.
which would produce a basically useless list.
most of the hardware that most people have is fine when considered by
itself. its the combination of different devices *and* device drivers
*and* BIOSes that cause the issues. although there are cases where
"chip X is bad for foobar" can be said without any ambiguity, most of
the time its much more like "chip X on mobo Y with BIOS foo and
version 3.14519 of the diddly driver ....."
4:48 p.m.
On Thursday 17 June 2010, Paul Davis wrote:
On Thu, Jun 17, 2010 at 3:26 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
Very very true Paul, and its something I didn't expound on. Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"Spare no expense to save money on this one."
-- Samuel Goldwyn
Dunno. I could post $ hwinfo > hwinfo.txt for
a combination of hardware
that will cause MIDI jitter when controlling external MIDI equipment.
which would produce a basically useless list.
most of the hardware that most people have is fine when considered by
itself. its the combination of different devices *and* device drivers
*and* BIOSes that cause the issues. although there are cases where
"chip X is bad for foobar" can be said without any ambiguity, most of
the time its much more like "chip X on mobo Y with BIOS foo and
version 3.14519 of the diddly driver ....." 
10:04 a.m.
New subject: [LAD] Real-time plotting of audio/ oscilloscope.
We should
start a black- and whitelist for hardware used for Linux
real-time. Unfortunately I could add my two machines to the blacklist .
Which hardware is "bad"? The cpu? The video chip? The motherboard?
10:11 a.m.
On Thu, Jun 17, 2010 at 4:04 AM, Mike Cookson <cook60020tmp(a)mail.ru> wrote:
Is your output was accelerated? I looked to list of backends at plotutils
documentation and could not find any with accelerated output to screen.
May be, you should try OpenGL/GLU?
Also, I found:
http://www.visualizationlibrary.com/
And by playing with synaptic: libmgl5 ( http://mathgl.sourceforge.net/ )
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
I don't think it's accelerated. But I'm only drawing simple pixels, it
doesn't seem like I need to do any "acceleration"
Jeremy
We should start a black- and whitelist for hardware
used for Linux
real-time. Unfortunately I could add my two machines to the blacklist .
Which hardware is "bad"? The cpu? The video chip? The motherboard?
4:30 p.m.
On Thursday 17 June 2010, Jeremy wrote:
Video hardware seems to be the biggest offender.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
An intellectual is someone whose mind watches itself.
-- Albert Camus
On Thu, Jun 17, 2010 at 2:25 AM, Ralf Mardorf
<ralf.mardorf@alice-
dsl.net>wrote:
Jeremy wrote:
Which hardware is "bad"? The cpu? The video chip? The motherboard?
Jeremy
Is there a fundamental restriction on doing so,
or is my problem in
software?
Jeremy
Hardware ;)!
We should start a black- and whitelist for hardware used for Linux
real-time. Unfortunately I could add my two machines to the blacklist
:(. 
9:21 a.m.
On Thu, 2010-06-17 at 00:29 -0400, Jeremy wrote:
Hi,
When I'm programming, I find it immensely helpful to be able to plot
audio data at different points in its processing, for debugging, and
to test new ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024
samples.
I've tried using libplot, but it seems too slow. It's causing
constant xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to
draw the pixels on the screen directly. I tried using SDL, but it
caused excessive xruns also. Simply setting 48000 pixels per second
was enough to cause the flow of xruns. This is *not* erasing the
screen, just drawing the points. I'd expect that erasing the screen
is the slow part, but apparently not.
At this point I'm not sure if it's even possible to plot the audio
data in realtime. I did a rough calculation, that on my 2 Ghz cpu, it
should have roughly 40,000 cycles to process each sample. It seems to
me that considering running the whole plugin only uses 1/4 of my cpu,
the other 30000 cycles should be plenty to put a pixel on the screen.
So I would guess that something else is the bottleneck, like my video
chip, or maybe the libraries I'm using.
So basically my question is: Has anyone else had any luck with
plotting audio data in real time, and if so, how? Is it not possible
to plot every sample, but only a certain percentage of them? Is there
a fundamental restriction on doing so, or is my problem in software?
I'm going to assume you're plotting directly within the realtime process
thread, which will never work. Push the audio data in a ring buffer,
then do the plotting in your main thread.
--
Peter
9:57 a.m.
On 17 June 2010 08:20, Peter Nelson <peter(a)fuzzle.org> wrote:
On Thu, 2010-06-17 at 00:29 -0400, Jeremy wrote:
How about taking a look at some of the sound editors, snd, mhwaveedit,
etc? Or perhaps Freqtweak?
I seem to recall seeing a reference somewhere recently, to
oscilloscope type software, which also might be useful to read the
code of, but can't remember where.
James
Hi,
When I'm programming, I find it immensely helpful to be able to plot
audio data at different points in its processing, for debugging, and
to test new ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024
samples.
I've tried using libplot, but it seems too slow. It's causing
constant xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to
draw the pixels on the screen directly. I tried using SDL, but it
caused excessive xruns also. Simply setting 48000 pixels per second
was enough to cause the flow of xruns. This is *not* erasing the
screen, just drawing the points. I'd expect that erasing the screen
is the slow part, but apparently not.
At this point I'm not sure if it's even possible to plot the audio
data in realtime. I did a rough calculation, that on my 2 Ghz cpu, it
should have roughly 40,000 cycles to process each sample. It seems to
me that considering running the whole plugin only uses 1/4 of my cpu,
the other 30000 cycles should be plenty to put a pixel on the screen.
So I would guess that something else is the bottleneck, like my video
chip, or maybe the libraries I'm using.
So basically my question is: Has anyone else had any luck with
plotting audio data in real time, and if so, how? Is it not possible
to plot every sample, but only a certain percentage of them? Is there
a fundamental restriction on doing so, or is my problem in software?
I'm going to assume you're plotting directly within the realtime process
thread, which will never work. Push the audio data in a ring buffer,
then do the plotting in your main thread.
10:11 a.m.
Excerpts from James Morris's message of 2010-06-17 09:57:26 +0200:
On 17 June 2010 08:20, Peter Nelson
<peter(a)fuzzle.org> wrote:
Well, there's ll-scope, but no idea how close it is to what you want:
http://www.student.nada.kth.se/~d00-llu/music_dssi.php?lang=en
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
On Thu, 2010-06-17 at 00:29 -0400, Jeremy wrote:
How about taking a look at some of the sound editors, snd, mhwaveedit,
etc? Or perhaps Freqtweak?
I seem to recall seeing a reference somewhere recently, to
oscilloscope type software, which also might be useful to read the
code of, but can't remember where.
James Hi,
When I'm programming, I find it immensely helpful to be able to plot
audio data at different points in its processing, for debugging, and
to test new ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024
samples.
I've tried using libplot, but it seems too slow. It's causing
constant xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to
draw the pixels on the screen directly. I tried using SDL, but it
caused excessive xruns also. Simply setting 48000 pixels per second
was enough to cause the flow of xruns. This is *not* erasing the
screen, just drawing the points. I'd expect that erasing the screen
is the slow part, but apparently not.
At this point I'm not sure if it's even possible to plot the audio
data in realtime. I did a rough calculation, that on my 2 Ghz cpu, it
should have roughly 40,000 cycles to process each sample. It seems to
me that considering running the whole plugin only uses 1/4 of my cpu,
the other 30000 cycles should be plenty to put a pixel on the screen.
So I would guess that something else is the bottleneck, like my video
chip, or maybe the libraries I'm using.
So basically my question is: Has anyone else had any luck with
plotting audio data in real time, and if so, how? Is it not possible
to plot every sample, but only a certain percentage of them? Is there
a fundamental restriction on doing so, or is my problem in software?
I'm going to assume you're plotting directly within the realtime process
thread, which will never work. Push the audio data in a ring buffer,
then do the plotting in your main thread.
3:36 p.m.
On 06/17/2010 10:11 AM, Philipp Überbacher wrote:
Excerpts from James Morris's message of 2010-06-17
09:57:26 +0200:
jack_oscrolloscope: http://das.nasophon.de/jack_oscrolloscope/
Sonogram: http://www.christoph-lauer.de/Homepage/Sonogram.html
MeterBridge has an oscilloscope plugin too
And then there's jack.scope, but that one chokes on my computer
Maybe the above links provide some useful info.
Best,
Jeremy
On 17 June 2010 08:20, Peter Nelson
<peter(a)fuzzle.org> wrote:
Well, there's ll-scope, but no idea how close it is to what you want:
http://www.student.nada.kth.se/~d00-llu/music_dssi.php?lang=en On Thu, 2010-06-17 at 00:29 -0400, Jeremy wrote:
How about taking a look at some of the sound editors, snd, mhwaveedit,
etc? Or perhaps Freqtweak?
I seem to recall seeing a reference somewhere recently, to
oscilloscope type software, which also might be useful to read the
code of, but can't remember where.
James Hi,
When I'm programming, I find it immensely helpful to be able to plot
audio data at different points in its processing, for debugging, and
to test new ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024
samples.
I've tried using libplot, but it seems too slow. It's causing
constant xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to
draw the pixels on the screen directly. I tried using SDL, but it
caused excessive xruns also. Simply setting 48000 pixels per second
was enough to cause the flow of xruns. This is *not* erasing the
screen, just drawing the points. I'd expect that erasing the screen
is the slow part, but apparently not.
At this point I'm not sure if it's even possible to plot the audio
data in realtime. I did a rough calculation, that on my 2 Ghz cpu, it
should have roughly 40,000 cycles to process each sample. It seems to
me that considering running the whole plugin only uses 1/4 of my cpu,
the other 30000 cycles should be plenty to put a pixel on the screen.
So I would guess that something else is the bottleneck, like my video
chip, or maybe the libraries I'm using.
So basically my question is: Has anyone else had any luck with
plotting audio data in real time, and if so, how? Is it not possible
to plot every sample, but only a certain percentage of them? Is there
a fundamental restriction on doing so, or is my problem in software?
I'm going to assume you're plotting directly within the realtime process
thread, which will never work. Push the audio data in a ring buffer,
then do the plotting in your main thread.
10:09 a.m.
On Thu, Jun 17, 2010 at 3:20 AM, Peter Nelson <peter(a)fuzzle.org> wrote:
On Thu, 2010-06-17 at 00:29 -0400, Jeremy wrote:
Yes, I'll bet that's my problem. Is it because writing to the screen is
high
bandwidth but high latency? Or is it just not possible to draw anywhere
near every sample?
Hi,
When I'm programming, I find it immensely helpful to be able to plot
audio data at different points in its processing, for debugging, and
to test new ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024
samples.
I've tried using libplot, but it seems too slow. It's causing
constant xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to
draw the pixels on the screen directly. I tried using SDL, but it
caused excessive xruns also. Simply setting 48000 pixels per second
was enough to cause the flow of xruns. This is *not* erasing the
screen, just drawing the points. I'd expect that erasing the screen
is the slow part, but apparently not.
At this point I'm not sure if it's even possible to plot the audio
data in realtime. I did a rough calculation, that on my 2 Ghz cpu, it
should have roughly 40,000 cycles to process each sample. It seems to
me that considering running the whole plugin only uses 1/4 of my cpu,
the other 30000 cycles should be plenty to put a pixel on the screen.
So I would guess that something else is the bottleneck, like my video
chip, or maybe the libraries I'm using.
So basically my question is: Has anyone else had any luck with
plotting audio data in real time, and if so, how? Is it not possible
to plot every sample, but only a certain percentage of them? Is there
a fundamental restriction on doing so, or is my problem in software?
I'm going to assume you're plotting directly within the realtime process
thread, which will never work. Push the audio data in a ring buffer,
then do the plotting in your main thread.
--
Peter
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
4:41 p.m.
On Thu, Jun 17, 2010 at 04:09:08AM -0400, Jeremy wrote:
Yes, I'll bet that's my problem. Is it because
writing to the screen is high
bandwidth but high latency? Or is it just not possible to draw anywhere
near every sample?
Plotting a waveform with 48kHz samples per second is not that
difficult and it doesn't require HW acceleration or esoteric
hardware.
But *what* do you want to see ? Of one thing you can be sure:
the information contained in 48k samples per second will
overload the visual parts of your brain. If the waveform
is more or less cyclic for some time, you can set a trigger
level and display small fragments - that is what a scope
is doing. In the other case the only thing that makes much
sense is display longer fragments, and then the only info
you get from this the amplitude envelope.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
7:37 p.m.
On Thu, Jun 17, 2010 at 10:41 AM, <fons(a)kokkinizita.net> wrote:
On Thu, Jun 17, 2010 at 04:09:08AM -0400, Jeremy
wrote:
Well I'm interested in plotting two things:
1. A single buffer of the audio
2. The autocorrelation (and selected peak) of that same buffer.
This means about a thousand samples per window (although the goal is to
increase it). I'm only looking at periodic signals, or at least that's all
I care about, so I can change the frequency until it's a harmonic of the
buffer size. On the other hand, the autocorrelation is almost constant, so
that is also interpretable by me, even when refresh rate.
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.
Thanks everyone for the suggestions of programs to look at. It looks like
I'm going to separate the drawing into another thread, although I am a
little bit confused as to why that is necessary. I'll probably copy
something from jack.scope or meterscape, as they seem closest to what I
want.
Jeremy
Yes, I'll bet that's my problem. Is it
because writing to the screen is
high
bandwidth but high latency? Or is it just not
possible to draw anywhere
near every sample?
Plotting a waveform with 48kHz samples per second is not that
difficult and it doesn't require HW acceleration or esoteric
hardware.
But *what* do you want to see ? Of one thing you can be sure:
the information contained in 48k samples per second will
overload the visual parts of your brain. If the waveform
is more or less cyclic for some time, you can set a trigger
level and display small fragments - that is what a scope
is doing. In the other case the only thing that makes much
sense is display longer fragments, and then the only info
you get from this the amplitude envelope.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
7:59 p.m.
you could also do something with openGL that would be fairly
efficient...I know a fellow who implemented something very similar to
this for an iPhone oscilloscope.
you'll most certainly want to copy the samples into a
ringbuffer...doing the GUI work from the realtime thread is just
asking for trouble. off in the GUI thread, read the samples from the
ringbuffer and push them to the graphics card as a vertex buffer
object. should keep things pretty speedy...
-w
9:29 p.m.
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...
10:28 p.m.
2010/6/17 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
On 06/17/2010 07:37 PM, Jeremy wrote:
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?
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... 
10:53 p.m.
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>:
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
On 06/17/2010 07:37 PM, Jeremy wrote:
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 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...
11:06 p.m.
On Thu, Jun 17, 2010 at 10:53:31PM +0200, Nick Copeland wrote:
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:
Yes. For a soft scope you have two options: a horizontal scale
caibrated in 'samples' (a pixel corresponds to an integer number
of samples), or one that maps to time (in ms or us).
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).
In a digital scope finding the sync point requires upsampling by a least
a factor of four, then you can interpolate linearly. After that, to
display the actual waveform correctly aligned to the sync point you may
have to interpolate even to a finer level. It's not at all a simple
thing.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
18 Jun
18 Jun
2:05 a.m.
On Thu, Jun 17, 2010 at 5:06 PM, <fons(a)kokkinizita.net> wrote:
On Thu, Jun 17, 2010 at 10:53:31PM +0200, Nick
Copeland wrote:
I don't need to sync the oscilloscope. I don't need to interpolate. I
don't need to get a good image of the waveform. I just need to draw a few
pixels on the screen. I had it working fine with libplot, and I would have
been more than happy with how it displayed, except it caused xruns.
I thought that something like SDL was direct memory access. The pixel
setting method I used only called one SDL function, to map RGB to an
integer. The rest of it was just some basic arithmetic to figure out where
to point to, and then dereferencing a pointer.
Anyway, is there any library that provides me with an array to write to, and
it handles refreshing the screen? That way I would essentially just be
writing to an array, which should be really fast inside the realtime loop.
I thought that is what SDL does, but I guess not.
Jeremy
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:
Yes. For a soft scope you have two options: a horizontal scale
caibrated in 'samples' (a pixel corresponds to an integer number
of samples), or one that maps to time (in ms or us).
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).
In a digital scope finding the sync point requires upsampling by a least
a factor of four, then you can interpolate linearly. After that, to
display the actual waveform correctly aligned to the sync point you may
have to interpolate even to a finer level. It's not at all a simple
thing.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
2:10 a.m.
On Thu, Jun 17, 2010 at 8:05 PM, Jeremy <jeremybubs(a)gmail.com> wrote:
On Thu, Jun 17, 2010 at 5:06 PM, <fons(a)kokkinizita.net> wrote:
After doing some more experimenting, I realize that SDL does not in fact
cause any xruns if I don't ask it to refresh.
Jeremy
On Thu, Jun 17, 2010 at 10:53:31PM +0200, Nick
Copeland wrote:
I don't need to sync the oscilloscope. I don't need to interpolate. I
don't need to get a good image of the waveform. I just need to draw a few
pixels on the screen. I had it working fine with libplot, and I would have
been more than happy with how it displayed, except it caused xruns.
I thought that something like SDL was direct memory access. The pixel
setting method I used only called one SDL function, to map RGB to an
integer. The rest of it was just some basic arithmetic to figure out where
to point to, and then dereferencing a pointer.
Anyway, is there any library that provides me with an array to write to,
and it handles refreshing the screen? That way I would essentially just be
writing to an array, which should be really fast inside the realtime loop.
I thought that is what SDL does, but I guess not.
Jeremy
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:
Yes. For a soft scope you have two options: a horizontal scale
caibrated in 'samples' (a pixel corresponds to an integer number
of samples), or one that maps to time (in ms or us).
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).
In a digital scope finding the sync point requires upsampling by a least
a factor of four, then you can interpolate linearly. After that, to
display the actual waveform correctly aligned to the sync point you may
have to interpolate even to a finer level. It's not at all a simple
thing.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
2:37 a.m.
On Friday 18 June 2010, at 02.09.43, Jeremy <jeremybubs(a)gmail.com> wrote:
[...]
After doing some more experimenting, I realize that
SDL does not in fact
cause any xruns if I don't ask it to refresh.
Of course. Depending on how you set up the SDL display, the pixel plotting may
actually just be raw memory access in a system RAM shadow buffer. No
scheduling/xrun issues with that, obviously. Refreshing, however, is where the
real work is done. Whether you're using SDL or the underlying APIs directly is
of no relevance here.
Realistically, for reliable operation in your average environment (X11,
Windows GDI, whatever...), there is only one solution: You need to move the
plotting into a separate thread. Could be a global GUI thread. What's critical
is that it's NOT the audio thread.
You may get away with just passing the coordinates (or raw samples) from the
audio thread to the rendering thread via a shared buffer, but the proper,
solid solution is to pass it in some synchronized manner, preferably lock-
free.
--
//David Olofson - Developer, Artist, Open Source Advocate
.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
'---------------------------------------------------------------------'
3:13 a.m.
On 06/18/2010 02:05 AM, Jeremy wrote:
[..]
Anyway, is there any library that provides me with an
array to write to, and
it handles refreshing the screen? That way I would essentially just be
writing to an array, which should be really fast inside the realtime loop.
I thought that is what SDL does, but I guess not.
Jeremy
Not sure where this is going. You started by saying you only needed a
simple debug tool.. but of course it's fun to tinker with SDL. :)
For drawing array-data on screen, pure-data would be a good choice.
Should not take more than 1 min: just open the Pd help for "tabwrite~"
and replace the "phasor~" with "adc~" to feed it with real-time
audio-data.
If you want to stick with SDL, use a jack-ringbuffer (which is basically
an array); the jack-process callback writes into it
and in the main SDL thread: you read from the ring-buffer, plot it,
sleep for 40ms, repeat.
http://das.nasophon.de/jack_oscrolloscope/ is using SDL.
UTSL,
robin
17 Jun
17 Jun
4:23 p.m.
On 06/17/2010 06:29 AM, Jeremy wrote:
Hi,
When I'm programming, I find it immensely helpful to be able to plot audio
data at different points in its processing, for debugging, and to test new
ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024 samples.
I've tried using libplot, but it seems too slow. It's causing constant
xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to draw the
pixels on the screen directly. I tried using SDL, but it caused excessive
xruns also. Simply setting 48000 pixels per second was enough to cause the
flow of xruns. This is *not* erasing the screen, just drawing the points.
I'd expect that erasing the screen is the slow part, but apparently not.
At this point I'm not sure if it's even possible to plot the audio data in
realtime. I did a rough calculation, that on my 2 Ghz cpu, it should have
roughly 40,000 cycles to process each sample. It seems to me that
considering running the whole plugin only uses 1/4 of my cpu, the other
30000 cycles should be plenty to put a pixel on the screen.
So I would guess that something else is the bottleneck, like my video chip,
or maybe the libraries I'm using.
So basically my question is: Has anyone else had any luck with plotting
audio data in real time, and if so, how? Is it not possible to plot every
sample, but only a certain percentage of them? Is there a fundamental
restriction on doing so, or is my problem in software?
Jeremy
There's jack.scope that comes with jackd, jack_oscrolloscope[1] and
QoscC[2] which display the wave-form in realtime on-screen (but IIRC
won't save the graphic to file).
"bitscope" is nice for detecting value-range issues (sticky bits,
Nan..); "baudline" has a waveform option.. and a more generic
Oscilloscope: "xoscope"
As for "plotting" the signal: most audio-editors will do. just fire up
ardour or any sound-editor, record the signal & take a screenshot :)
Well, there's a couple of utilities to render wave-forms but all tools I
know there operate on files and not real-time.
http://apps.linuxaudio.org/apps/categories/scopes_and_realtime_visualizers
[1] http://das.nasophon.de/jack_oscrolloscope/
[2] http://flup.homelinux.org/qoscc.html
18 Jun
18 Jun
2:53 a.m.
On Thu, Jun 17, 2010 at 2:29 PM, Jeremy <jeremybubs(a)gmail.com> wrote:
Essentially I want an oscilloscope, which plots each chunk of 1024 samples.
From memory, try jack-oscrolloscope. You can modify the source code to
update the
refresh quicker than the allowed values.
Damien
7:10 p.m.
On Thu, 17 Jun 2010 00:29:44 -0400
Jeremy <jeremybubs(a)gmail.com> wrote:
Hi,
When I'm programming, I find it immensely helpful to be able to plot audio
data at different points in its processing, for debugging, and to test new
ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024 samples.
I've tried using libplot, but it seems too slow. It's causing constant
xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to draw the
pixels on the screen directly. I tried using SDL, but it caused excessive
xruns also. Simply setting 48000 pixels per second was enough to cause the
flow of xruns. This is *not* erasing the screen, just drawing the points.
I'd expect that erasing the screen is the slow part, but apparently not.
How did you write your SDL program? Don't use any Setpixel functions.
Draw your pixels to a memory buffer/surface with the same pixel format
as the screen and flip that to the screen. Or try OpenGL. Use GL Arrays
if glBegin()/glEnd() is too slow.
The hardware shouldn't be a bottleneck if you don't use a system
older than 10 years or so. If you use OpenGL, you need an accelerated
driver of course, else it's useless.
20 Jun
20 Jun
6:59 a.m.
On Fri, Jun 18, 2010 at 1:10 PM, Johannes Kroll <jkroll(a)lavabit.com> wrote:
On Thu, 17 Jun 2010 00:29:44 -0400
Jeremy <jeremybubs(a)gmail.com> wrote:
I used a setpixel function, but it was quite simply a pointer dereferencer.
I believe I am doing exactly what you are suggesting, but with SDL.
Writing directly to the array, and then calling flip. I think I realize
why I'm having this problem. I'm using moderately old hardware, which
doesn't have any linux acceleration driver (even 2d), so everything is
written to main memory and then copied on flip (I believe). This is why
it's slow. Even with this, I only get xruns when I click another window, or
try to drag or resize a window. Basically, it's good enough that if I put
the flip() call in another thread it probably should run perfectly.
Jeremy
Hi,
When I'm programming, I find it immensely helpful to be able to plot
audio
data at different points in its processing, for
debugging, and to test
new
ideas.
Essentially I want an oscilloscope, which plots each chunk of 1024
samples.
I've tried using libplot, but it seems too slow. It's causing constant
xruns, even when I only plot every 5th sample.
I thought that maybe libplot was too abstract, and that I needed to draw
the
pixels on the screen directly. I tried using
SDL, but it caused
excessive
xruns also. Simply setting 48000 pixels per
second was enough to cause
the
flow of xruns. This is *not* erasing the
screen, just drawing the
points.
I'd expect that erasing the screen is the
slow part, but apparently not.
How did you write your SDL program? Don't use any Setpixel functions.
Draw your pixels to a memory buffer/surface with the same pixel format
as the screen and flip that to the screen. Or try OpenGL. Use GL Arrays
if glBegin()/glEnd() is too slow.
The hardware shouldn't be a bottleneck if you don't use a system
older than 10 years or so. If you use OpenGL, you need an accelerated
driver of course, else it's useless.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5070
days inactive
5073
days old
linux-audio-dev@lists.linuxaudio.org
32 comments
17 participants
participants (17)
-
Damien Zammit -
David Olofson -
fons＠kokkinizita.net -
Gene Heskett -
James Morris -
Jeremy -
Jeremy Jongepier -
Johannes Kroll -
Jörn Nettingsmeier -
Mike Cookson -
Nick Copeland -
Paul Davis -
Peter Nelson -
Philipp Überbacher -
Ralf Mardorf -
Robin Gareus -
Will Light