Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Fri, Jun 18, 2010 at 1:10 PM, Johannes Kroll jkr...@lavabit.com wrote: On Thu, 17 Jun 2010 00:29:44 -0400 Jeremy jeremyb...@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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thu, 17 Jun 2010 00:29:44 -0400 Jeremy jeremyb...@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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
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 :(. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
Ralf Mardorf 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 :(. 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
Ralf Mardorf wrote: Ralf Mardorf 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 :(. 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev Sorry, here's the link: http://www.64studio.com/node/69 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thu, Jun 17, 2010 at 2:25 AM, Ralf Mardorf ralf.mard...@alice-dsl.netwrote: 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
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 3 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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
Jeremy wrote: On Thu, Jun 17, 2010 at 2:25 AM, Ralf Mardorf ralf.mard...@alice-dsl.net mailto:ralf.mard...@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-s...@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-s...@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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
Ralf Mardorf wrote: Jeremy wrote: On Thu, Jun 17, 2010 at 2:25 AM, Ralf Mardorf ralf.mard...@alice-dsl.net mailto:ralf.mard...@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-s...@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-s...@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. Correction, frequency scaling was ondemand, I changed to performance now: spinymouse-s...@64studio:~$ hwinfo --cpu [snip] Clock: 2100 MHz [snip] ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On 17 June 2010 08:20, Peter Nelson pe...@fuzzle.org wrote: 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 3 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thu, Jun 17, 2010 at 3:20 AM, Peter Nelson pe...@fuzzle.org wrote: 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 3 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev 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? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thu, Jun 17, 2010 at 4:04 AM, Mike Cookson cook60020...@mail.ru wrote: 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? 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@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
Excerpts from James Morris's message of 2010-06-17 09:57:26 +0200: On 17 June 2010 08:20, Peter Nelson pe...@fuzzle.org wrote: 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 3 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. 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 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thu, Jun 17, 2010 at 3:26 AM, Ralf Mardorf ralf.mard...@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 . ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On 06/17/2010 10:11 AM, Philipp Überbacher wrote: Excerpts from James Morris's message of 2010-06-17 09:57:26 +0200: On 17 June 2010 08:20, Peter Nelson pe...@fuzzle.org wrote: 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 3 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. 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 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 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
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 3 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thursday 17 June 2010, Ralf Mardorf wrote: Ralf Mardorf 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 :(. 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.. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thursday 17 June 2010, Jeremy wrote: On Thu, Jun 17, 2010 at 2:25 AM, Ralf Mardorf ralf.mard...@alice- dsl.netwrote: 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 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
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 ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thursday 17 June 2010, Paul Davis wrote: On Thu, Jun 17, 2010 at 3:26 AM, Ralf Mardorf ralf.mard...@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 . 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thu, Jun 17, 2010 at 10:41 AM, f...@kokkinizita.net wrote: 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 ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
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... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
2010/6/17 Jörn Nettingsmeier netti...@folkwang-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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
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: p...@linuxaudiosystems.com To: netti...@folkwang-hochschule.de CC: linux-audio-dev@lists.linuxaudio.org Subject: Re: [LAD] Real-time plotting of audio/ oscilloscope. 2010/6/17 Jörn Nettingsmeier netti...@folkwang-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@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___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
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 ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thu, Jun 17, 2010 at 5:06 PM, f...@kokkinizita.net wrote: 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 ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
On Thu, Jun 17, 2010 at 8:05 PM, Jeremy jeremyb...@gmail.com wrote: On Thu, Jun 17, 2010 at 5:06 PM, f...@kokkinizita.net wrote: 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 ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev 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 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Real-time plotting of audio/ oscilloscope.
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Real-time plotting of audio/ oscilloscope.
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 3 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
