Recently on this list, Paul referred to an "atomic integer
swap" and an "atomic pointer swap." This was a new concept
to me (and possibly others), and this e-mail shares what
I've learned.
If you access a variable from multiple threads -- even a
built-in variable like 'int', it is important to control
access to the variable with a mutex, semaphore, or an atomic
operation.
Alexander Sandler, on his blog, wrote a couple of good
articles on the subject:
"Do you need a mutex to protect an int?"
http://www.alexonlinux.com/do-you-need-mutex-to-protect-int
"Multithreaded simple data type access and atomic
variables"
http://www.alexonlinux.com/multithreaded-simple-data-type-access-and-atomic…
The first article contains code that calculates a wrong
answer on multiprocessor machines. I've attached a similar
example that will even fail on a single-processor machine.
There is a wealth of reading material on using Mutexes and
Semaphores. However, information on atomic operations
appears to be sparse and hard-to-follow. So, here's what
I've found:
+ At the moment, there is no built-in support in
C/C++ for atomic operations. You will need to use
a library, compiler extension, or write your own
in assembly code.
+ The GCC compiler has the built-in __sync_*()
functions[1] that provide atomic operations.
Note that the attached example is using this.
+ glib provides the g_atomic_*() functions[2].
+ Qt 4 has the q_atomic_*() functions.[3] While
they are accessible, they are /not/ a part of
their stable, public API.
+ The next version of ISO C++ (code name c++0x)
is expected to have support for atomic operations
(E.g. the std::atomic<T> template) and memory
barriers. It may even require that all built-in
types be atomic.
+ In the x86 instruction set, these are usually
implemented using the 'LOCK' instruction prefix.[5]
When using atomic operations, perhaps the best advice I
found is near the end of Sandler's second article:
"When using atomic variables, some extra
precautions have to be taken.... There is nothing
that prevents you from incrementing value of the
atomic variable with __sync_fetch_and_add() as I
just demonstrated and later in the code doing same
thing with regular ++ operator.
"To address this problem, I strongly suggest
wrapping around atomic functions and variables with
either ADT in C or C++ class."[4]
Peace,
Gabriel
[1] http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
[2] http://www.gtk.org/api/2.6/glib/glib-Atomic-Operations.html
[3] http://doc.trolltech.com/4.3/atomic-operations.html
See also the Qt header file QtCore/qatomic_i386.h, and
its brothers.
[4] http://www.alexonlinux.com/multithreaded-simple-data-type-access-and-atomic…
[5] http://siyobik.info/index.php?module=x86&id=159
All ladspavst users/contributors,
A ladspavst visitor has brought to my attention that the ladspavst.linuxaudio.org has been spammed for quite some time, rendering a page into useless goop of spam. This is mainly due to lack of moderation. As a result, I've no other choice than to take the site offline until further notice. If you or someone you know is supposed to take care of this site, please contact me and we'll figure out the best way to bring this site back online. Until that happens, the site will remain offline.
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
Hi,
I'm wondering what the size limit is for SysEx messages in the JACK MIDI
and ALSA sequencer APIs. My observations so far:
In JACK MIDI, a SysEx message can be as large as the MIDI port buffer,
which in turn has the same size as an audio buffer for one period. This
is assuming that there are no other events transmitted on the same port
during the same period.
Is this correct? Or are applications somehow expected to handle larger
SysEx messages split over multiple periods?
In the documentation of the ALSA sequencer API, I couldn't find any
mention of an upper limit. Some sources suggest that ALSA splits SysEx
messages into chunks of 256 bytes, but from my own attempts at sending
larger messages, it seems the limit is actually somewhere around 5500
bytes. Unfortunately ALSA doesn't seem to report an error when I try to
send larger chunks, instead the messages just disappear. Can anyone shed
some light on how to handle larger SysEx messages correctly?
Thanks,
Dominic
Hi all,
Yesterday I released version 1.0.21 of libsndfile. Its available here:
http://www.mega-nerd.com/libsndfile/#Download
Main changes for this version are:
* Add a couple of new binary programs to programs/ dir.
* Remove sndfile-jackplay (now in sndfile-tools package).
* Add windows only function sf_wchar_open().
* Bunch of minor bug fixes.
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
Hi.
I just happened to stumble about a (what I call) pretty subtle
bug in typical ALSA PCM code:
root@fzidpc73:/tmp# cat test.c
#include <stdio.h>
int main() {
int period = 1024;
int nperiods = 3;
int rate = 96000;
unsigned buffer_time = 1000000*period*nperiods/rate;
printf("%d\n", buffer_time);
}
root@fzidpc73:/tmp# ./test
-12739
root@fzidpc73:/tmp# sed -i -e 's/int rate/unsigned int rate/' test.c
root@fzidpc73:/tmp# gcc -o test test.c
root@fzidpc73:/tmp# ./test
32000
I.e., don't trust this boilerplate formula blindly.
--
CYa,
⡍⠁⠗⠊⠕
Dear fellow FOSS enthusiasts,
Last week's L2Ork debut was a great success with the performance hall packed and people standing in the back. We've had a tremendous amount of positive feedback and it has been truly hart-touching to learn that people genuinely cared about and were moved by what we had to share. As some of you may be already aware, our story also made the Slashdot and our server has received close to a half a million hits since its posting. Likewise, we've been featured on regional TV channels as well as various international news outlets.
As our thanks to all who have so generously supported us both in person and through the endless corners of the internet, we've posted a track from our weekend recording session. "Citadel" is a piece for soprano and L2Ork that uses a poem by Ivan Gundulic, a famous Croatian poet from the Baroque era. The piece was recorded in a beautifully reverberant Burruss rotunda on the Virginia Tech campus. No post-processing has been applied to the recording beyond a minor eq to soften lows.
To listen please visit http://l2ork.music.vt.edu/main/ and click on the Media->Jukebox, or simply click on the link in what is currently the top post on the L2Ork blog.
Once again, thank you all for your kind support. We will be starting a public l2ork-dev list soon, so if you wish to contribute, participate, or start your own L2Ork, please do not hesitate to join in on the discussion. Likewise, should you feel compelled to leave a comment, please feel free to do so on our jukebox page (no registration required).
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
Thanks for pointing that out to me.
I've started a version which uses atomic pointer exchange,
and this is something I wasn't aware of.
I think it shouldn't be a problem right now, as I keep
the objects I use in memory, and I don't need the reaction
of the program to the pointer swap to be a realtime operation.
thanks again for your reply,
lieven
On 11/29/2009 03:36 PM, Ken Restivo wrote:
> On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote:
>
>> Nick Copeland:
>>
>>> Adrian Knoth:
>>>
>>>> I'm also somewhat interested in the network part, I feel IPv6 could help
>>>> a lot. It supports autoconfiguration and it has decent multicast
>>>> support, so it would be possible to broadcast/multicast the streams on
>>>> the net (LAN). This could be useful if you want to access the stream at
>>>> a mixing console for a life setup and simultaneously record it on a
>>>> computer.
>>>>
>>> Put another way, it would be far more compatible if this were done over
>>> an IP stream rather than any native ethernet stream, not least it could use
>>> any ethernet driver that linux supports rather than a small subset of them.
>>>
>> Ack, a standard ip-stream is a sensible first choise.
>>
>>
>>> Perhaps the project needs to be specified with regards to its goals?
>>>
>> ...
>>
>> My goals is "just" to extend another project (industrial i/o).
>> What would your goals be ?
>>
>> Shall we decide on a single mailing list ?
>>
>>
> IIRC the motivation for this was:
>
> 1) Firewire is going away on laptops
> 2) USB 2.0 is proprietary and non-standard
> 3) Because of (1) and (2), Linux Audio users will soon be left without any way to do multichannel recording on laptops.
>
> The original thread converged on a goal pretty quickly: an inexpensive, multi-channel audio interface which is open hardware and software, and uses Gig Ethernet as its physical connection method.
>
> So, if I were going to put the goal simply: I'd like a Focusrite Saffire (or equivalent) that runs over Ethernet, please :-) Price-wise, it'd be nice if it cost the same or less than equivalent USB 2.0 product. Latency-wise, comparable with USB 2.0.
>
> In terms of how many I/O, I think that was still being calculated and experimentation was going to be required. Obviously options for 4, 8, or 16 I/O would be nice.
>
>
Did anyone have a good reason for not including support for a
usb-1.0/2.0/3.0 interface seeing as we can write the driver ourselves
and adhere to the standard?
Most chipsets these days have support for both port types. It would be
very useful if the schematic provided tracks for both ootb.
BTW, I will be able to contribute development funds towards this project
if required once we have a BoM.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
