Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

1 participants
7500 discussions

by Andrew W. Schmeder

<quote who="Mark Knecht"> > I do not see how a company could afford to invest in this area, short of > staying closed-source. Very difficult for them, so no wonder there are few companies calling Linux developers. Another difficulty with the GPL its somewhat sketchy legal basis. (OT for LAD... Google if you want to know more). I've noticed that Dual licencing GPL/Commercial seems to fit in with the corporate mindset, however. (e.g. Mysql). Ardour/Libardour could go this route if all the developers desired it. --- Andrew W. Schmeder

22 years, 6 months

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

by Kai Vehmanen

On Wed, 13 Nov 2002, Paul Davis wrote: >>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. > this is true unless the pointer/index isn't atomic. since on SMP sparc > systems, the arrangement of the cache lines means that you can't > guarantee better than 24 bit atomic values, you do have to be careful > about the potential size and memory position of the pointer/index > variables. I've browsed through the sparc arch manuals and couldn't find anything that would limit atomic access to 24 bits nor any directly related cache line limitations. The Linux asm-sparc/atomic.h provides only 24bits as it uses the lower 8bits to implement a low-overhead spinlock. Spinlock is required to guarantee memory ordering (also with mixed usage of various atomic_* ops). If you just read/write 32bit ints, this is atomic even on SMP-sparcs. >>in handling the l-f buffer indices. In the worst case >>reported write-space is larger, or read-space smaller, >>than the actual situation. > actually, the worst case for both metrics is that they are *smaller* > than they should be. this happens on two occasions: Ugh, true, my mistake. > its not so much "atomicity" as "ordered" that is needed here. because > read/write will only use that part of the buffer indicated as > available by the r/w pointers, all we have to know is that the writes > to the buffer complete before the write pointer is updated. it would > be good to use a so-called "memory barrier" somewhere there to make > sure this is true. Ok, this is a real problem, but I don't think using asm-arch/atomic.h (which can guarantee ordered access to the buffer indices) helps to solve this issue, so you might just as well use regular ints as the atomic indices. And this really is a corner case as the buffer would have to be close to empty (something has already gone wrong!) to read old data from the buffer, even on a SMP sparc or s390. -- http://www.eca.cx Audio software for Linux!

22 years, 6 months

[linux-audio-dev] Who maintains vkeybd?

by Mario Lang

Hi. Yesterday I hacked a bit on vkeybd, and managed to turn the vkb.c into tclkvb.so, such that I now can do $ tcl tcl% load "./tclkvb.so" and use the tcl commands like SetDevice midi set mididev 0 SeqOn ... and so on. This basicly means we could write tcl scripts which use the vkeybd backend, without having to use tk. Or even write different frontends... So I'd like to get this mod out there somehow, but the authors email of vkeybd does no longer work... -- CYa, Mario | Debian Developer <URL:http://debian.org/> | Get my public key via finger mlang(a)db.debian.org | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

22 years, 6 months

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]

by Patrick Shirkey

Len wrote: >> >If you will be making money from a Linux-based product, then you >> >*should* be investing your own money for promotion. >> >> I am. What's your point? >Other people (people who are not in business) need not and likely won't >invest money to promote Linux Audio. >People here invest their time and effort (but usually not money for >promotion), mostly because they're techies who want to to build >something that they really need/want. Businesses invest money for >another reason, because they want to develop and promote commercial >products. They're mostly two different worlds (though there is >crossover). Would you agree that the commercial side of Linux Audio development is not currently showing much support for the community then? Would you consider it to be partly (if not largely) because there is an image problem. >> I have a small business and there are others out there in similar >> positions. We don't have the financial resources to fund large scale >>ad campaigns on our own. But we do if we work together. >Perhaps there's no need to promote Linux Audio; perhaps instead there >is a need to promote useful products. If those products happen to need >Linux (and ALSA & Jack) as a foundation, then Linux will get promoted >as a side effect of successful products. Much like MacOS. >So if you want Linux Audio to be promoted, either make broadly useful >products or assist the companies that want to turn your work into >broadly useful products. Are you making an offer? ;) While trawling then net today looking at the google search on the word "sound". I saw your site was listed in the first few pages. That's some tough competition there. If we had a community run organisation that lead by example do you think it would make you feel more motivated to promote Linux as a platform to your customers? Esp. If you could show them that your company has an active part in supporting the community? Eg. Official status in the form of certification or advertising space, naming rights, awards in your honour... BTW. Would you like to add your Company to the Tech Support database? http://www.djcj.org -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

22 years, 6 months

[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!

22 years, 6 months

[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

22 years, 6 months

[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

22 years, 6 months

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==

22 years, 6 months

[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)

22 years, 6 months

[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.

22 years, 6 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