Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

5 participants
7515 discussions

[linux-audio-dev] interesting post from vst-plugins on float/int

by Paul Davis

i thought this was pretty insightful. vst-plugins has had a little debate over whether or not VST should provide an integer sample format. actually, not much of a debate. one person suggested it, everybody else jumped on him. this post, however, is the most detailed on why you should forget about thinking of float arithmetic as slower than integer ... --;p ------- Forwarded Message Date: Sun, 15 Sep 2002 14:21:52 -0700 From: Vesa Norilo <vnorilo(a)siba.fi> To: <vst-plugins(a)lists.steinberg.net> (VST PlugIns) Subject: [vst-plugins] Re: SDK buffers from host Ah, good ol' Mike Abrash. But do yourself a favour and update your knowledge: I'm pretty sure Mike has also done just that. BTW, I did learn a huge amount from his Zen of Code Optimization, but almost everything in it has become irrelevant by superscalar processing and vector engines. > > i think you are seriously and dramatically underestimating the > > incredible benefits provided by a standardized > I haven't count cpu instruction cycles recently. But last time > I did, the difference between floating point operations and > integer operation was from 15x to 100x speed difference. I > think though with the last few generation of cpu's they have > significantly narrowed the gap. On AMD 3DNow, all floating point instructions take 2 cycles, and two of them can be run in parallel, meaning that a total of 4 floating point additions or multiplies can be executed in 2 clock cycles. These also include sine, cosine, reciprocal and square approximations. Can you beat that with integer asm? > Again in my very limited audio processing experience so far > I'm finding that I can apply many of the same asm techniques. > And I know things are changing with new hardware I guess it's > possible in the future that floating with equal or, I don't know how, > but I suppose could even exceed int speeds. Since I have AMD, I'm fluent with 3DNow and not SSE. But from what I know, SSE is very similiar in functionality and power to 3DNow, and SSE2 offers even more capabilities. To beat the vector engines, you would have to go MMX. This is for two reasons: the saturating adds would eliminate the need of overflow checking, and due to its SIMD nature it can match or outdo 3DNow/SSE. Unless you are willing to drop to 16 bits (so that MMX can do 4 operations per instruction) it will not. > But when you get right down the heart of the matter, the > computer really is only doing bit manipulations anyway - > floating point or int. The difference with IEEE floating is the fact Which is why integer bit mask operations are still usable with floats, making many neat tricks possible. Such as really fast logarithms, which is again impossible with ints unless you use lookup tables (which you don't want to do for 32 bit resolution) > that the cpu has to decode the register to get at the exponent. > And that is going to add extra clock cycles. 2 sign bits have So, if an instruction that performs two floating point multiplies costs 2 cycles (and can run parallel with another such), each floating point multiply will consume 0.5 cycles. I don't really see any "extra cycles" here. Do you? > Still the ideal speed approach is a flat bit array with no decoding > and a big register, big enough to handle that largest number > you will ever have to deal with. That's very untrue. Consider how much memory speeds are limiting processing speed. Processing 32 bit floats is faster than 64 bit ints largely for that reason. The optimal speed approach is not simple. It has to do with optimizing memory for cost/benefit, optimizing cache and processor for speed, and trying to strike a balance. Consider floats as a hardware accelerated compression method that saves memory bandwidth. > What's wide enough for audio processing (64 bit???, 128 bit???). > At some point need for an exponent simply disappears. And the need for a 4GHz bus appears. > But you all are right. In reality it seems my lack of experience > has jump up and bit me in the ass. And I was only looking at > things from my self-absorbed world of the plug-in I'm trying > to build to do some specific things I personally would like to > accomplish. That's nice, but to recapitulate, don't really talk about optimization before you know several SIMD sets by heart. Nowadays, that's mandatory. > For the above reasons under optimized assembly language > conditions, I just don't see how float speeds can exceed int > speeds. But considering all of the other points you all have > brought up my suggestion seems to have been short-sited. If your most recent knowledge is of x87 floating point asm, I understand this perfectly. However, a speed and assembly enthusiast should keep himself updated. Best regards, Vesa ############################################################# This message is sent to you because you are subscribed to the mailing list <vst-plugins(a)lists.steinberg.net>. To unsubscribe, E-mail to: <vst-plugins-off(a)lists.steinberg.net> To switch to the DIGEST mode, E-mail to <vst-plugins-digest(a)lists.steinberg.net > To switch to the INDEX mode, E-mail to <vst-plugins-index(a)lists.steinberg.net> Send administrative queries to postmaster(a)steinberg.de ------- End of Forwarded Message

23 years

[linux-audio-dev] midi programming (bulk data on Yamaha TX81z)

by Will Benton

Howdy, all. I've sent a similar message to comp.music.midi and rec.music.makers.synth, but I don't think I'll get many replies. I hope this isn't OT for the list (and that someone here knows the answer!) In any case, I'm trying to write an application that "does stuff" (not necessarily an editor/librarian, but with a small feature overlap) with the user bank and performance data on my TX81z here, and I'm confused about the VMEM bulk data format. 1. Page 74 of the manual states that address 6 (and 16, 26, and 36) is occupied by AME (b6), EBS (b4-2), and KVS (b1-b0) data. However, it also states that KVS data ranges from 0-7, which is clearly impossible in 2 bits. Where's the mistake? Should EBS be bits 5-3 and then KVS as bits 2-0? 2. How would one compute VMEM checksums? Heck, as long as I'm at it, what's the method for computing all of the checksums (i.e. VMEM, PCED, PMEM, SYS, microtune, etc.)? I have looked at the sourcecode for JSynthLib (which, for some reason, doesn't run properly in my environment -- too bad, because it seems to be a good program), but the answers to these questions were not really clear to me from an examination of its TX81z driver. (In its defense, very little bit-twiddling Java code is particularly clear.) In particular, either their checksum implementation is wrong or the TX81z manual is wrong (my money's on the latter). In any case, I'd be glad to hear from anyone with experience doing this kind of junk to the TX81z. It seems that most of the TX81z sysex info available on the net is for real-time control. best, wb -- Will Benton | "Die richtige Methode der Philosophie wäre eigentlich willb(a)acm.org | die: Nichts zu sagen, als was sich sagen läßt...."

23 years

[linux-audio-dev] snd_pcm_playback_format

by shiva shankar

I have problem in getting the function snd_pcm_playback_format in 0.5.10 and my kernel is 2.4.18-6 . Thank you Shiva

23 years, 1 month

[linux-audio-dev] Autoconf macros for libsndfile

by Jeff Welty

Anyone made autoconf macros for libsndfile? Specifically ones that could test for the appropriate version of libsndfile? I have completed the initial integration of libsndfile into gwc and am working on the configure scripts, would rather use someone else's before I hack one together myself... Thanks, Jeff Welty

23 years, 1 month

[linux-audio-dev] hi

by Bety Lora

http://www.geocities.com/alikahomapage/alika http://www.lizaclub.da.ru http://www.sokarim.tk

23 years, 1 month

[linux-audio-dev] Ripping CD

by Lars Åslund

Hello, I´m new to this list and i´m not sure if i asking on right forum. I´m looking for information for Ripping a CD to a non compressed format into as good as possible format for audio-playback. Anyone have suggestion on thisone. I´m goona play from a Linux-box with a Semi pro Soundcard with external DAC. Best regards /Lasse - from Sweden

23 years, 1 month

[linux-audio-dev] GNOME multimedia mailing list

by Christian Fredrik Kalager Schaller

Hi everyone, I have now set up a new mailing list at gnome.org for discussing GNOME multimedia development. The list is meant to allow multimedia developers all across the GNOME and GTK+ world to come togheter to discuss issues of interoperability, library development, and general issues related to developing multimedia applications for GTK+ and GNOME. I hope as many as possible of you will join the list and the effort to bring multimedia support under GNOME 2 forward. You find details on the list at: http://mail.gnome.org/mailman/listinfo/gnome-multimedia Sincerely, Christian

23 years, 1 month

Re: [linux-audio-dev] more hdsp stuff

by D R Holsbeck

any new and updated info on the cardbus interface, for the HDSP. Mine should be in the post today, and I am chomping at the bit On Fri, 2002-07-05 at 17:03, Paul Davis wrote: > >Just unwrapped my new thinkpad, so I am thinking of ordering the cardbus > >interface for my hdsp. Has anyone gotten the cardbus to work with the > >digiface box? > > it works (orm has reported it working). it seems very dependent on the > kernel, cardbus utilities and possibly the underlying hardware. if > these 2 succeed with their task of making the pcmcia card appear like > a normal PCI device, then everything proceeds as normal. several > people have combinations of these 3 that fail at this goal. > > >As for the pci/digiface system I currently have, it seems that even > >with the latest cvs code, I still need to unload/reload the hdsp module, > >before Jack is able to use the device. I dont remember the exact > > i believe i have already told you that i fixed this, but have not yet > submitted the patch because i am trying to fix the lack of output issue. > > >message, but I can post it later if it would help. There is no audio > >output, until I load the rme modules, reboot, and reload the modules. > >After which everything seems to work fine. Any ideas on where to look > >for debug info would be greatly appreciated. > > orm did some great detective work. the cardbus/pcmcia version works, > but when it stops, it seems necessary to eject the card then reload it > again. this fixes the output problem. i am hoping to try out an > equivalent process (which you have outlined above), one way or > another, tonight. > > --p > -- drh(a)niptron.com Great spirits have always encountered violent opposition from mediocre minds. -- Albert Einstein They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- Carl Sagan

23 years, 1 month

[linux-audio-dev] liblrdf first release

by Steve Harris

http://plugin.org.uk/lrdf/ I had to bundle up libraptor with the LADSPA specific stuff for complicated reasons, so the auto* stuff is nasty. It builds OK on my RedHat and RedHat+Planet CCRMA machines though. There are no docs yet, but there are some fairly clean exmaples in the examples direcory. The API and subclass heirachy of plugins is far from fixed, so tell me what you think. - Steve

23 years, 1 month

Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)

by Stefan Kost

Paul Davis wrote: >> >>that doesn't solve the generic malloc problem (strings of arbitrary >>size) but it does look attractive for the common case of fixed-size >>events. > > > yes, and it would be less than a few hours to get it working. > > the problem is that many of the interesting data types are variable > sized. MIDI is the most obvious. > For midi: wouldn't it be possible to allocate block of the upper bound-size. I mean midi is constrained by the transfer-rate. Commands can be placed into the buffer at the point in time when they should occure. Ofcourse they need to check if the time-slot is still free and should use the next free one. Stefan -- \|/ Stefan Kost <@ @> private business +-oOO-(_)-OOo------------------------------------------------------ - - - - - | __ Address Zwenkauer Str. 24 HTWK Leipzig, Fb IMN, Postfach 300066 | /// 04277 Leipzig 04277 Leipzig | __ /// Germany Germany | \\\/// Phone +49341 3910483 +49341 30766101 | \__/ EMail st_kost(a)gmx.net kost(a)imn.htwk-leipzig.de | WWW www.sonicpulse.de www.imn.htwk-leipzig.de/~kost/about.html ===-=-=--=---=---------------------------------- - - - - -

23 years, 1 month

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