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!
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
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.comHttp://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
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!
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
>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==
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)
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.
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)