Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time toomany

by eviltwin69＠cableone.net

On Thu, 9 Jun 2005 10:05 , 'Chris Cannam' <chris.cannam(a)ferventsoftware.com> sent: >N Smethurst: >> Since a vector is a wrapped C array (i.e. contigous), the [] operator >> compiles to the C equivalent when optimisation is turned on. > >I was thinking of iterator operations, having vaguely recalled that the vector iterator in the gcc library had at some point changed from an actual pointer to a wrapper class. Looking at the code, though, the wrapper is so thin that it probably isn't an issue with optimization on. > > I was under the impression that there was bounds checking going on with vectors. Is this not the case? Jan

20 years, 3 months

[linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

by Tim Goetze

Frailty, thy name is GCC A Modern Drama in Three Scenes. Dramatis Personae: An ardent programmer and a popular C++ compiler -*- Prologue: Appalled by the rat race commonly known as the proprietary software business, our young and gifted hero joins the light side, deeply inspired by the manifold yet subtle qualities of free software. Scene I: Our hero in day-and-night-long sessions optimizes the hell out of a SSE2-based n*4-band IIR equalizer. Of course in assembly, and mixed with C++ templating. The final code is about 10% faster than floats on AMD, probably a fair bit quicker yet on P4 systems. Enter gcc version 3, which drops multi-line inline assembly support. Said assembly code becomes effectively unusable and dies a quick and unsung death. Scene II: Our hero puts years of work into an all-round realtime audio and MIDI library that expands the Python programming language. While having its flaws, it's a versatile, surprisingly stable and immensely capable system, partly thanks to a very clever (according to our hero) design that subclasses Python's C types in C++. Enter gcc version 3, moving the vtable member to memory offset 0 of a derived type even if the base type is in C which doesn't know about vtables. As a result, the very foundation of said library's type system is rendered nonfunctional since Python expects its type header to reside in the very same memory location. With no precautions for such an abrupt change taken and the implications requiring a manual review and substantial rewrite of a good 50.000 lines of source code, said library dies a slow and painful but equally unsung death. Scene III: Our hero bundles his DSP efforts into a free plugin library, once again saving himself much work and improving code readability by using C++ templates, resulting in quite an elegant object system and source code, hethinks. Enter gcc version 4, which requires the templated types' constructor code be rewritten in the most nonsensical, misleading and ugly fashion possibly imaginable this side of Hungary and Redmond, WA, according to our (now not so very young anymore) hero. Epilogue: Our hero has completely and permanently lost his faith in the popular compiler. Disillusioned and indecisive, he resigns himself to henceforth reluctantly write C++ only to support his miserable life. His plight is so bad he downright refuses to support the latest follies of the popular compiler in his free software efforts. -*- Will this be the end? To be continued, hopefully. Cheers, Tim

20 years, 3 months

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time toomany

by eviltwin69＠cableone.net

On Thu, 9 Jun 2005 23:41 , David Cournapeau <cournape(a)gmail.com> sent: >On 6/9/05, stefan kersten steve(a)k-hornz.de> wrote: >> On Thu, Jun 09, 2005 at 10:31:35PM +0900, David Cournapeau wrote: >> > _Z6vectorSt6vectorIiSaIiEE: >> > .LFB539: >> > .L2: >> > .L7: >> > pushl %ebp >> > .LCFI0: >> > movl %esp, %ebp >> > .LCFI1: >> > popl %ebp >> > ret >> > >Well, that's what happens when one post some code after some heavy >coding all day long, and when one tries to answer two questions at the >same time....That's why I would have prefered to find the relevant >part instead in the C++FAQ :) > > Anyway, for the question "is there bound checking with operator[]", >the answer of Bjarne Stroustrup is no :). > The other problem "is [] as efficient for vector and plain c array >?", well, people who know better than me asm/gcc can test and answer. > Yeah, it really needs to be tested to tell. I remember taking a course in VAX Macro asm back in the days of dinosaur eggs and phonograph needles. The book, DEC, and the teacher all said you could turn off the VAX debugging mode when you compiled. I wrote some self-modifying code for one of the exercises (I wouldn't do that in real life ;-) The compiler still slapped in some debugging stuff and it wouldn't work. It was a real simple program though so the instructor checked it and passed it anyway ;-) Jan

20 years, 3 months

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time toomany

by Chris Cannam

Jan Depner: > I was under the impression that there was bounds checking going on with > vectors. Is this not the case? Nope. Chris

20 years, 3 months

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time toomany

by Chris Cannam

N Smethurst: > Since a vector is a wrapped C array (i.e. contigous), the [] operator > compiles to the C equivalent when optimisation is turned on. I was thinking of iterator operations, having vaguely recalled that the vector iterator in the gcc library had at some point changed from an actual pointer to a wrapper class. Looking at the code, though, the wrapper is so thin that it probably isn't an issue with optimization on. Chris

20 years, 3 months

[linux-audio-dev] Re: Software controller for homemade edrums

by Kevin Sookocheff

>Could anyone point me toward a document explaining the >technical/mathematical details of convolution, especially about audio? I've used convolution/correlation/fourier analysis for school projects. The standard text for Fourier analysis is Bracewell, "The Fourier Transform and its Applications". Also check out "Numerical Recipes in C" (available on-line) by Press, Teukolsky, Vetterling and Flannery, Cambridge Press, for code on performing convolution and correlation with the fast fourier transform. As for audio, I've dealt mostly with images but the same principals apply. Audio is a 1D signal and most texts spend a considerable time covering these . Look for any book on digital signal processing and it will most certainly contain what you need. Kevin

20 years, 3 months

Re: [linux-audio-dev] Re: Software controller for homemade edrums

by Ben Loftis

> And, as I said above, it did work better with some samples than with > others, but: it works :-) > > Here are three example of what it sounds like, using a modified guitar > chord sample as response file : > > 1 - For this one I softly hit the edge of the pad continuously, and the > middle of the edge harder once at the beginning of the measure : > http://samalyse.com/labs/edrum/audio/beat.ogg > > 2 - Playing faster ("rolling") with this one : > http://samalyse.com/labs/edrum/audio/roll.ogg > > 3 - Using a pen to hit and scratch the surface. The rubber surface, made of > several layers of bike tube makes it possible to obtain an interesting > sound (the input level was not high enough for this one, so I normalized it > afterward, it could sounds much better I think) : > http://samalyse.com/labs/edrum/audio/scratch.ogg > > As you may see, scratching seems to work fine in here :-) > This is so incredibly cool! Is this technique already in wide use somewhere that I missed? Because if not, it should be. This means that all you need for an electronic drum set is a multichannel sound card and some homemade piezo-triggered pads! And I think with some further experimentation with pad materials and response files, you can probably come up with all kinds of permutations on the sound. I'd like to hear what this sounds like using some traditional drum samples ( like a snare or an 808-style kick ). I'm assuming that the current samples lack "punch" only because they are from a piano chord response file. > By the way, Ben, what do you think of my idea of coupling triggering with > convolution, as stated in my previous mail (above, third paragraph) ? > Here's a diagram to further describe this idea : > > pad signal ----> trigger detection ----> sample playback ----- > | | > | | > -------------------------------------> convolution <---- > | > | > +--> output > > Would this be possible ? You essentially _have_ the drawing, above. You just can't change the sample on every hit. I don't know what you expect to achieve. Trust me, what you've got now is much cooler than a triggered playback (although it does not sound the same) It is possible that using a triggered sample or some sort of envelope follower will be required to get the attack of a traditional drum sound. I'm sure there are lots of ways to improve this simple system beyond jack_convolve. I think you've stumbled across a really cool synthesis technique! -Ben

20 years, 3 months

Re: [linux-audio-dev] [ot] [rant] gcc,you let me down one time too many

by Taybin Rutkin

I believe the C++ standard specifies that vector<> uses contigous memory and that &v[0] returns a valid pointer to an array. Taybin -----Original Message----- From: Chris Cannam <cannam(a)all-day-breakfast.com> Sent: Jun 8, 2005 4:41 PM To: linux-audio-dev(a)music.columbia.edu Cc: Jussi Laako <jussi.laako(a)pp.inet.fi> Subject: Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many On Wednesday 08 Jun 2005 21:35, Jussi Laako wrote: > You can derive a new class from the template and overload the [] > operator to perform exactly same as in C. After compilation the > result is the same no matter if the template or C array is used. Are you sure this is still true in the gcc world, after they changed vector from an array to a real class in gcc 3.3 or whenever it was? Chris

20 years, 3 months

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

by eviltwin69＠cableone.net

On Wed, 08 Jun 2005 22:19 , Jussi Laako <jussi.laako(a)pp.inet.fi> sent: >On Wed, 2005-06-08 at 05:47 -0700, eviltwin69(a)cableone.net wrote: > >> I'm working with multibeam sonar, airborne topographic and hydrographic >> LIDAR, and airborne hyperspectral imagery data. > >Sonar and radar applications are very familiar to me. There is no reason >why those couldn't be very efficient, yet written in C++. My opensource >HASAS passive sonar signal analysis suite, and the libDSP signal >processing library it uses, has been written using C++ and asm. I think >it's still very efficient. > >And for example in these kinds of applications the most valuable feature >is how well it performs it's tasks and reliability. Execution speed is >secondary. You can buy more CPU power if required. Most large array >beamformers are heavy SMP systems anyway. > We're talking apples and oranges here. You're talking about the real-time collection of multibeam. That is a piece of cake. I don't mean in terms of the actual beamforming but in the amount of data per second you have to deal with. The beamforming is really complicated. I'm talking about post-processing the data from 7 ships with dual multibeams plus 8 or so hydro survey launches running dual head multibeams plus a significant number of high-end sidescan systems plus a plane running hydro and topo LIDAR and hyperspectral. The ships collect data 24/7, the HSLs 10 hours per day. All of these approximately 300 days per year. The plane collects about 150 days per year, 5 to 6 hours per day. We're post-processing for hydrographic (and other) types of use. When you're dealing with tens to hundreds of billions of data points execution speed makes a huge difference. >In C/C++ case the performance is more about how you write the code, not >the language you use. > Yes, part of it is about how you write the code but if someone dumps a few billion data points on you and says "here, check these" then processing speed becomes extremely important. There have been some very good points made in this discussion and I will definitely investigate some of them. My problem here is that I've heard the same type of thing from companies and universities for way too long. Something along the lines of - "Really, you don't need to write your own processing code. We collected sonar data for a whole week and we didn't have any problem processing it with (fill in your favorite GIS or sonar processing package here)". Although this thread has about run its course, I would like to continue the discussion on sonar systems with you off-line if you are interested. Jan

20 years, 3 months

[linux-audio-dev] disaster day #3

by Dave Phillips

Greetings: While waiting for another box I decided to pull the RAM and test each stick (256 MB each). The problem occurred with either stick. I'm able to log in, work for a few minutes, then the box just freezes. I can hear the disk drive make a little activity noise first, then everything's just gone. Btw, it'll die in X or at the console, it's not an X problem (I think). And since the problem occurs whether I'm on /dev/hda or /dev/hdb I doubt if both disk drives are bad. Anyway, Ivy's bringing over the other machine in another day or so, I'll switch drives into that machine and see what happens next. Best, dp

20 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev