[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-audio-dev
Subject: Re: [LAD] Real-time plotting of audio/ oscilloscope.
From: Jeremy <jeremybubs () gmail ! com>
Date: 2010-06-20 4:59:20
Message-ID: AANLkTinOxubr_QJ-0XPNZK_JVjiR9RrKGR1lnhnASj9y () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jun 18, 2010 at 1:10 PM, Johannes Kroll <jkroll@lavabit.com> wrote:
> On Thu, 17 Jun 2010 00:29:44 -0400
> Jeremy <jeremybubs@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
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Fri, Jun 18, 2010 at 1:10 PM, Johannes Kroll \
<span dir="ltr"><<a \
href="mailto:jkroll@lavabit.com">jkroll@lavabit.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">
On Thu, 17 Jun 2010 00:29:44 -0400<br>
<div class="im">Jeremy <<a \
href="mailto:jeremybubs@gmail.com">jeremybubs@gmail.com</a>> wrote:<br> <br>
</div><div class="im">> Hi,<br>
><br>
> When I'm programming, I find it immensely helpful to be able to plot \
audio<br> > data at different points in its processing, for debugging, and to test \
new<br> > ideas.<br>
><br>
> Essentially I want an oscilloscope, which plots each chunk of 1024 samples.<br>
><br>
> I've tried using libplot, but it seems too slow. It's causing \
constant<br> > xruns, even when I only plot every 5th sample.<br>
><br>
> I thought that maybe libplot was too abstract, and that I needed to draw the<br>
> pixels on the screen directly. I tried using SDL, but it caused excessive<br>
> xruns also. Simply setting 48000 pixels per second was enough to cause the<br>
> flow of xruns. This is *not* erasing the screen, just drawing the points.<br>
> I'd expect that erasing the screen is the slow part, but apparently \
not.<br> <br>
</div>How did you write your SDL program? Don't use any Setpixel functions.<br>
Draw your pixels to a memory buffer/surface with the same pixel format<br>
as the screen and flip that to the screen. Or try OpenGL. Use GL Arrays<br>
if glBegin()/glEnd() is too slow.<br>
<br>
The hardware shouldn't be a bottleneck if you don't use a system<br>
older than 10 years or so. If you use OpenGL, you need an accelerated<br>
driver of course, else it's useless.<br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" \
target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br> \
</div></div></blockquote></div><br><div>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.</div>
<div><br></div><div>Jeremy</div>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic