Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization

by Kai Vehmanen

Btw; I'll cc'd this to lad, as this is a topic that has been discussed there _many_ times. More specifically the SMP-sparc case has been mentioned quite a few times but without specific details. For lad-only readers, see the jackit-devel archives for the whole thread. On Wed, 13 Nov 2002, Tim Goetze wrote: > it should be noted that this relies on accesses to the > r/w buffer indices to be atomic. that's no problem on > common workstation hardware, though. [...] > /usr/src/linux/include/asm-<target>/atomic.h gives more > info. Actually I've spent some time studying this issue and my conclusion is that the level of atomicity provided by linux asm-arch/atomic.h is not needed to implement single-reader-single-writer lock-free buffers. More specifically, asm/atomic.h provides guaranteed ordering of reads and writes. This is not really needed in handling the l-f buffer indices. In the worst case reported write-space is larger, or read-space smaller, than the actual situation. The only problematic scenarios are that a) read returns an invalid value, and b) write stores an invalid value. These could possibly happen if reads/writes were not atomic. But so far I haven't found any platforms (with publically available specs) which don't guarantee this level of atomicity (even in the case of complex processor cache arrangements). The two architectures for which asm-xxx/atomic.h contains special code even for plain reads and writes are SMP-sparc and s390. I haven't studied s390, but at least in the case of sparcs (ref: sparc v8 arch manual), reads and writes are atomic even in a SMP configuration, although ordering is not guaranteed. More specifically, if TSO (Total Store Ordering) memory mode is selected, loads do not necessarily appear in order. If using PSO (Partial SO), stores as seen by the issuing processor can be executed out-of-order. But these restrictions aren't really a problem for l-f buffers. If I've interpreted the situation incorrectly, or someone has better information, I'd be very interested to know! Even better, example code that demonstrates atomicity problems... I have currenly access to both IA32 and Sparc-v8 multi-processor machines. -- http://www.eca.cx Audio software for Linux!

23 years

[linux-audio-dev] [ann] preamp.so

by Tim Goetze

pleased to announce another ladspa unit - 'preamp'. this plugin implements an amplitude response that has been obtained from a spice simulation of the preamp stage of a modified fender 5F4 instrument amplifier. http://quitte.de/dsp/preamp.html tim

23 years

[linux-audio-dev] [ANN] ALSA Patch Bay 0.3

by Bob Ham

Hi all, I'm in a hacking mood :) I added an fltk (1.1) interface to alsa patch bay, and also updated the gtkmm interface to use 2.0.0. It can use both, or just one. Tarball here: http://pkl.net/~node/software/alsa-patch-bay-0.3.tar.gz (214KB) I also made a spiffy (if sparse) page for it here: http://pkl.net/~node/alsa-patch-bay.html Have fun, Bob

23 years

Re: [linux-audio-dev] Gigasampler vs Halion PR war

by Juhana Sadeharju

>From: Paul Davis <paul(a)linuxaudiosystems.com> > >idea, wrapped it up in patent language that restricts it to a specific >problem domain (playback of audio data in response to triggers), and >filed. There has been "instant play" devices prior gigasampler. I also found following from Usenet archives. I also have a product adv which can be used as directly-from-disk MIDI sampler with fades; I will scan and place this adv available soon. Year is 1990. Juhana ==cut== >> Forum: rec.audio.opinion Subject: Re: Why buy a digital transport? Date: 04/12/1995 Author: Mark Brindle <brindle(a)lf.hp.com> [ cut ] : a totaly error free transport system which would alow random play and : near ( sub 10ms ) access to any audio on the cd-rom ?? You've just described a hard-disk recorder. But, if you want to save some money, and you don't plan to edit the music, you could get by without the hard drive. Substitute a few megs of RAM; and if you need *INSTANT* access, cache the first second of every "cut" in memory -- then, you could start playing any track with only a few microseconds delay. Of course, anything quicker than about 50ms seems instantaneous to mere mortals. ...it's "only" software, Mark ==end==

23 years

[linux-audio-dev] RH8 mods

by jfm3

Has anyone put together a patch for the RH8 kernel that does better low latency, yet is compatible with the zillions of kernel patches RH puts in? A lot of these patches are good, and not cool to discard, but it is getting tedious trying to make a compatible patch. Has anyone done a similar patch for making ALSA part of the kernel RPM build? Has anyone measured what the latency on a RH8 system is without the full ll patches? Plugging away... -- (jfm3 2838 BCBA 93BA 3058 ED95 A42C 37DB 66D1 B43C 9FD0)

23 years

[linux-audio-dev] Intel C Compiler & RedHat 8.0 , Pentium 4 FPU performance

by Benno Senoner

Hi, does anyone know if it is possible to make the Free Intel C Compiler work on Red Hat 8.0 ? It used to work on RH7.3 but Jussi L. reported failure on RH8.0 too. I would just be courious about Intel compiler's efficiency since I am currently performing some resampling / mixing benchmarks using linear and cubic interpolation and for example with cubic interpolation which involves a few MULs/ADDs per sample, I get something like: Celeron (PII-class) 71 cycles/sample , Athlon 61 cycles/sample, Pentium 4 80 cycles / sample. (using gcc 3.2) It seems the P4's FPU sucks quite since for some ops it needs more cycles per instruction than the old Celeron. I heard Intel's compiler is able to use SIMD to speed up FPU ops so I would just be curious to see what is achievable given good quality code that is targeted for the P4. The innermost resampling/mixing loop is very short anyway so in that case one could probably use a P4-specific asm version (or importing the asm generated by icc) in order to achieve maximum performance. But first tests seems to indicate (at least to me) that the Athlon is 20-30% faster for doing resampling/mixing stuff thus I guess an Athlon machine will deliver more voices than a P4 running at the same frequency ( or Pentium-frequency-equivalence-index). Currently I am working only in the floating point domain, but Juan L. is telling me about the wonders of integer math and pointed me to the routines found in http://modplug-xmms.sourceforge.net/ but I am unable to compile the package on RedHat 8.0 (am I a masochist insisting on that distro ? :-) ) On the other hand Steve Harris says that in modern CPUs floating point ops are more accelerated than integer ones and since integer involves a lot of shifting, you might end up with longer execution times than the integer version. (FISTL takes 6 cycles but it is not that much compared to 70-80 cycles in the case of cubic interpolation plus doing all in the FP domain saves you from lots of hassles) I will publish the benchmark and the results when I will have implemented more test cases. Anyway it is interesting to learn how sucky the x86 architecture can be (the hard way of course :-) ). PS: regarding the optimization options Steve H. suggested -O6 -fomit-frame-pointer -fstrength-reduce -funroll-loops -fmove-all-movables -ffast-math -mcpu=i686 -march=i686 Can gcc 3.2 target archtitectures higher than the PII ? (I mean generating P3/P4 specific code ?) thoughts ? Benno -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

23 years

[linux-audio-dev] Re: [music-dsp] XBOX as an audio DSP? (fwd)

by CK

hi, anyone around who ran audio stuff on the xbox/linux yet ? Forwarded message: > From owner-music-dsp(a)shoko.calarts.edu Tue Nov 12 05:34:54 2002 > Date: Mon, 18 Nov 2002 12:22:30 +0800 > Subject: Re: [music-dsp] XBOX as an audio DSP? > From: Stewart Greenhill <sgreenhill(a)iprimus.com.au> > To: music-dsp(a)shoko.calarts.edu > > On Tuesday, November 12, 2002, at 11:38 AM, Russell Borogove wrote: [irrelevant parts snipped] . . > > Ultimately, it may be possible to run Linux (for example) without > modding the box. An anonymous donor has offered $US 200,000 towards the > development of such a "fix" so presumably if it is technically possible > it will be eventually done. Therefore, I guess one could eventually make > a CD image that boots the OS _and_ the application without requiring > mods or installs. > > But its really not an "unfinished" OS. Its just unix with X11 and ALSA. > A single API targets both environments, so the extra work required to > make an app run on the xbox may not be great. > > Personally, I doubt that I would pursue this route. However, it does > give an interesting "mass market" for linux audio applications. > > Cheers, > Stewart > > > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp/ > -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

23 years

Re: [linux-audio-dev] Re: OSX

by Bill Schottstaedt

> This is a bit off-topic, but did you use CoreAudio when porting to OSX? yes -- the code is in Snd's (sndlib's) audio.c. > You mean, there is now a Snd for OS-X? Wow, at work, I'll have to > choose between Win-XP and OS-X in the near future, and this is a very > important argument pro OS-X. You've considerably brightened up my morning!

23 years

[linux-audio-dev] [ANN] JACK Rack 1.0

by Bob Ham

Hi all, I just uploaded the first version of JACK Rack, a stereo LADSPA effects "rack" for JACK and GTK+ 2. Tarball is here: http://pkl.net/~node/software/jack-rack-1.0.tar.gz (96k) screenshot is here: http://pkl.net/~node/images/jack-rack-shot.png Enjoy :) Bob

23 years

Re: [linux-audio-dev] Gigasampler vs Halion PR war

by Benno Senoner

Don't worry David, I think we are wasting our precious time with these talks (but it is interesting anyway :-) ) Regarding source and binary code: Being or app opensource, we have the advantage that the source code does not constitute a runnable application and this provides several legal advantages. Just to cite an example: The freetype library http://www.freetype.org/ contains a bytecode interpreter for font hinting on which Apple holds a patent. But they can distribute the source because it is disabled in the default Makefile. This makes me think that opensource software that might contain "controversial" code can always be shipped in sourceform since it is not the final product since only a "description of it". (where the compiler turns this description into the final product). back to coding .... (guess what ? :-) ) cheers, Benno David Burrows wrote: > Send the source code to me and I will release it. Why? Because > I believe what I said in the above paragraph is true. It is immoral to > have software patents, not violate them. Especially ones as > absurdly simple as this. How could they proove that you did not > come up with the idea yourself? Whatever happened to innocent until >proven guilty -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

23 years

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