On Mon, March 7, 2016 7:49 pm, Adrian Knoth wrote:
> On Sun, Mar 06, 2016 at 07:12:25PM -0600, Jonathan E. Brickman wrote:
>
>> Greetings, everyone. Since I am using 85% of JACK DSP in my primary
production box, while using 14% of the CPU and 1/8 of the RAM
>> according to htop, it appears that I need to develop a way to move
forward :-) It is very clear from the excellent Patrick Shirkey's
input that one can use netjack to chain any combination of
>> motherboards each running JACK; I would like to use the power of my box
to do the same internally.
>
> I so don't get what you're trying to achieve. Use multiple soundcards?
Use multiple CPUs? Parallelize the client graph?
>
>
IIUC, it seems that Jonathan has encountered an issue with JACK DSP not
being consistent with cpu load so he is trying to find a way to use
multiple instances of JACK (> 2) on the same machine.
--
Patrick Shirkey
Boost Hardware Ltd
--
Patrick Shirkey
Boost Hardware Ltd
>
> Control of memory ordering and atomics are officially part of the C
>
and C++ languages since 2011. GCC already supported this when the ISO
> standards was finalized. Microsoft and Clang started supporting it in
> 2012. So, it's been pretty much portable since 2012. This is 2016.
> IMHO, it's time to make use of it. :)
Well, atomics are not an official part of the C standard, only the C++
standard. For the jack ringbuffer, Paul could wrap std::atomic into
a C interface in order to follow a langauge standard, but for all practical
purposes, the __atomic_ functions are probably fine to use directly.
On Tue, Mar 1, 2016 at 4:54 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
> On Tue, Mar 1, 2016 at 10:12 AM, Sebastian Gesemann <s.gesemann(a)gmail.com>
> wrote:
>>
>> Thank you all for the responses!
>>
>> On Mon, Feb 29, 2016 at 9:05 PM, Harry van Haaren <harryhaaren(a)gmail.com>
>> wrote:
>> > On Mon, Feb 29, 2016 at 7:52 PM, Spencer Jackson <ssjackson71(a)gmail.com>
>> > wrote:
>> >> > The generic solution for cases like this is a lock-free ringbuffer.
>> >> I've also used the jack ringbuffer for this and it was easy enough.
>> >
>> > Simple tutorial on using JACK ringbuffer and C++ event class here:
>> > https://github.com/harryhaaren/realtimeAudioThreading
>>
>> I've looked into JACK's ringbuffer implementation. It doesn't look too
>> complicated. Thank you all for suggesting it! But I'm a little bit
>> concerned about ISO standard compliance. According to the
>> multi-threading-aware update to the C11 and C++11 memory models, the
>> access to the ringbuffer's data (*buf) is technically a data race and
>> therefore invokes undefined behaviour. Only read_ptr/write_ptr are
>> somewhat protected (volatile). From what I understand, given the
>> C11/C++11 memory model, one is supposed to use "atomics" for all
>> read/write accesses in such situations (including *buf). But so far, I
>> havn't gathered much experience in this kind of lock-free programming.
>
> Sadly, you still don't understand how a lock-free ringbuffer works.
Oh, don't be sad. I'm sure you're underestimating my understanding of the topic.
> The key insight to have is this:
>
> * the calculation of what can be read and what can be written may, in
> fact
> be incorrect due to threading
>
> BUT
>
> they are ALWAYS wrong in the "safe" direction. if the calculation is
> wrong
> it will ALWAYS underestimate data-to-be-read and space-to-be-written.
I understand that.
> that is: you will never attempt to read data that should not be read, and
> you will never attempt to write to space that should not be written. This is
> true of ALL lock-free ringbuffer designs, not just JACK's. The property
> arises from the requirement that they are single-reader/single-writer. If
> you violate this (e.g. attempt to move the read-ptr from the write thread or
> vice versa), then all bets are off unless you use some higher level mutual
> exclusion logic (which has no place in the ringbuffer itself. The design
> works because in audio contexts, when you use a ringbuffer, you are more or
> less guaranteed to be using a design where you keep reading and keep writing
> to the ringbuffer over and over. The design cannot work for single-shot
> communication where you must always collect ALL possible data in a
> thread-synchronous fashion. This is not the case for audio work.
I understand that. So far, nothing you said was new to me.
> Now, that said, there are some under-the-hood issues with the actual JACK
> ringbuffer code, but they have absolutely nothing to do with the high level
> semantics, and that is what you're relying on. Those issues concern the use
> of memory barriers, and are thus related to code-reordering not to
> atomicity.
It depends on what meanings you attach to the words "atomics" and
"atomicity". I was trying to use the term "atomic" in a way consistent
with the C11/C++11 memory model. In this context, atomicity is not
only about having logically multiple operations done as a single one
(fetch-and-add, compare-and-swap, etc) but it also involves memory
ordering hints (defaulting to sequential constistency but weaker
models are possible). So, it seems to me that you were not familiar
with this. I said I have little experience with lock-free programming
but that does not mean I'm completely unaware of the theoretical
aspects.
> Although a clean fix/patch for this would still be a good thing,
> the ringbuffer's are used widely and they function as intended in almost all
> situations.
Sure. I'm not surprized that it works in practice. If the compiler
emits a memory barrier for the volatile memory access, it's all you
need. But technically, it's still undefined behaviour.
> You need not concern yourself with this issue if you are just
> starting out.
Well, for me, that's part of the fun -- figuring out how it's supposed
to be written without invoking U.B.
sg
On Fri, Mar 4, 2016 at 1:22 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com>
wrote:
> You are right. There was even a discussion about how broken it was
> in 2008, and it was fixed, at least in practice.
>
> http://lists.linuxaudio.org/pipermail/linux-audio-user/2008-October/056000.…
>
> Theoretically (and not unlikely also in practice), it seems to be still
> broken.
> This can also confirmed by compiling with -fsanitize=thread:
>
>
I made a quick fix: http://folk.uio.no/ksvalast/ringbuffer.diff
It can probably be optimized by relaxing some of the barrier
strenghtnessness though,
but it probably makes no practical difference in execution time.
Perhaps apply this to jack, at least to avoid uncertainty about whether it
will really
always work?
On Fri, Mar 4, 2016 at 1:00 PM, <
linux-audio-dev-request(a)lists.linuxaudio.org> wrote:
> Send Linux-audio-dev mailing list submissions to
> linux-audio-dev(a)lists.linuxaudio.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
> or, via email, send a message with subject or body 'help' to
> linux-audio-dev-request(a)lists.linuxaudio.org
>
> You can reach the person managing the list at
> linux-audio-dev-owner(a)lists.linuxaudio.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-audio-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Code reordering (Sebastian Gesemann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 4 Mar 2016 10:16:02 +0100
> From: Sebastian Gesemann <s.gesemann(a)gmail.com>
> To: Jonathan Brickman <jeb(a)ponderworthy.com>
> Cc: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
> Subject: Re: [LAD] Code reordering
> Message-ID:
> <
> CAGdQazeKzU1ZOyHrnZLoQnXgm2ca4yZ36+-+xT1MupZMfjTpPg(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Mar 2, 2016 at 5:55 PM, Jonathan Brickman <jeb(a)ponderworthy.com>
> wrote:
> > On 3/1/2016 11:40 AM, Paul Davis wrote:
> >
> > > the JACK implementation relies on two things to work:
> > >
> > > * pointer and integer operations are (weakly) atomic on all
> platforms
> > > that JACK runs on
> > > * code reordering will either not happen or will be prevented by the
> > > compiler
> >
> > Does #2 mean that -O3 should always be avoided when compiling JACK
> clients?
>
> As I said, I consider JACK's ringbuffer implementation to be broken.
> According to the C11/C++11 memory model there is nothing in the code
> that prevents reordering the update to write_ptr and the update to
> *buf in jack_ringbuffer_write. The use of volatile only makes sure
> that read/write accesses to the volatile variables are not reordered
> or "optimized out" by caching. Specificaly, a volatile write is not a
> release barrier. It does not constrain reordering with respect to
> other memory locations (*buf). This makes the access to the buffer's
> content unordered and invokes undefined behaviour.
>
> Having said that, if you can be sure that the compiler does not
> reorder this (by checking the assembly code, for example) then you
> will be fine on an x86/x64 platform because this platform makes an
> extra guarantee: writes in one thread are never seen out of order from
> another thread's perspective.
>
>
You are right. There was even a discussion about how broken it was
in 2008, and it was fixed, at least in practice.
http://lists.linuxaudio.org/pipermail/linux-audio-user/2008-October/056000.…
Theoretically (and not unlikely also in practice), it seems to be still
broken.
This can also confirmed by compiling with -fsanitize=thread:
WARNING: ThreadSanitizer: data race (pid=24978)
Write of size 8 at 0x7d0c0000efd8 by thread T2:
#0 jack_ringbuffer_write jack/ringbuffer.c:247
(test-int-array-jack+0x000000401a30)
#1 writer_start /home/ksvalast/rbtest/test-int-array.c:85
(test-int-array-jack+0x000000400f4d)
#2 <null> <null> (libtsan.so.0+0x0000000235b9)
Previous read of size 8 at 0x7d0c0000efd8 by thread T1:
#0 jack_ringbuffer_read_space jack/ringbuffer.c:108
(test-int-array-jack+0x000000401346)
#1 reader_start /home/ksvalast/rbtest/test-int-array.c:48
(test-int-array-jack+0x000000400df2)
#2 <null> <null> (libtsan.so.0+0x0000000235b9)
Location is heap block of size 48 at 0x7d0c0000efd0 allocated by main
thread:
#0 malloc <null> (libtsan.so.0+0x000000025993)
#1 jack_ringbuffer_create jack/ringbuffer.c:41
(test-int-array-jack+0x0000004010ab)
#2 main /home/ksvalast/rbtest/test-int-array.c:102
(test-int-array-jack+0x00000040100c)
Thread T2 (tid=24981, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:105
(test-int-array-jack+0x000000401056)
Thread T1 (tid=24980, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:104
(test-int-array-jack+0x00000040103b)
SUMMARY: ThreadSanitizer: data race jack/ringbuffer.c:247
jack_ringbuffer_write
==================
==================
WARNING: ThreadSanitizer: data race (pid=24978)
Read of size 8 at 0x7d500000fe00 by thread T1:
#0 memcpy <null> (libtsan.so.0+0x00000002666a)
#1 jack_ringbuffer_read jack/ringbuffer.c:166
(test-int-array-jack+0x0000004015fc)
#2 reader_start /home/ksvalast/rbtest/test-int-array.c:50
(test-int-array-jack+0x000000400e22)
#3 <null> <null> (libtsan.so.0+0x0000000235b9)
Previous write of size 8 at 0x7d500000fe00 by thread T2:
#0 memcpy <null> (libtsan.so.0+0x00000002666a)
#1 jack_ringbuffer_write jack/ringbuffer.c:246
(test-int-array-jack+0x0000004019e5)
#2 writer_start /home/ksvalast/rbtest/test-int-array.c:85
(test-int-array-jack+0x000000400f4d)
#3 <null> <null> (libtsan.so.0+0x0000000235b9)
Location is heap block of size 512 at 0x7d500000fe00 allocated by main
thread:
#0 malloc <null> (libtsan.so.0+0x000000025993)
#1 jack_ringbuffer_create jack/ringbuffer.c:52
(test-int-array-jack+0x0000004011c8)
#2 main /home/ksvalast/rbtest/test-int-array.c:102
(test-int-array-jack+0x00000040100c)
Thread T1 (tid=24980, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:104
(test-int-array-jack+0x00000040103b)
Thread T2 (tid=24981, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:105
(test-int-array-jack+0x000000401056)
SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_memcpy
==================
==================
WARNING: ThreadSanitizer: data race (pid=24978)
Write of size 8 at 0x7d0c0000efe0 by thread T1:
#0 jack_ringbuffer_read jack/ringbuffer.c:167
(test-int-array-jack+0x000000401647)
#1 reader_start /home/ksvalast/rbtest/test-int-array.c:50
(test-int-array-jack+0x000000400e22)
#2 <null> <null> (libtsan.so.0+0x0000000235b9)
Previous read of size 8 at 0x7d0c0000efe0 by thread T2:
#0 jack_ringbuffer_write_space jack/ringbuffer.c:128
(test-int-array-jack+0x00000040141a)
#1 writer_start /home/ksvalast/rbtest/test-int-array.c:83
(test-int-array-jack+0x000000400f1d)
#2 <null> <null> (libtsan.so.0+0x0000000235b9)
Location is heap block of size 48 at 0x7d0c0000efd0 allocated by main
thread:
#0 malloc <null> (libtsan.so.0+0x000000025993)
#1 jack_ringbuffer_create jack/ringbuffer.c:41
(test-int-array-jack+0x0000004010ab)
#2 main /home/ksvalast/rbtest/test-int-array.c:102
(test-int-array-jack+0x00000040100c)
Thread T1 (tid=24980, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:104
(test-int-array-jack+0x00000040103b)
Thread T2 (tid=24981, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:105
(test-int-array-jack+0x000000401056)
SUMMARY: ThreadSanitizer: data race jack/ringbuffer.c:167
jack_ringbuffer_read
==================
Greetings;
This has been a PIMA here for a couple years, surviving at least one full
fresh install to a new HD.
I hear a very strong thump during the bootup at about the time the
modules are loaded, which tells me the audio is alive and well.
However, when I have initially logged in and the system is ready to be
used for whatever my urges want to, if I want to hear the sound on a web
site as a news story is played, I must first call up a terminal and
issue:
alsactl restore
Now it seems to me there ought to be someplace in the junk that runs
after the login, to put a "/usr/sbin/alsactl restore", where it will be
executed as me, and this problem then should be fixed, at least until a
new install is done.
The question is where?
Thank you.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
I know it's possible for a sequencer to send MIDI events to ALSA early with a timestamp and ALSA will wait until the specified time to deliver the event. Is it possible to ask ALSA to also deliver these events early along with that timestamp? I've looked all over the ALSA documentation but I can't find any evidence that this is an option.
Hello fellow audio developers,
I've started writing a software synthesizer in C++ (using SDL2 for
now) for kicks and giggles and ran into the problem of having the
event loop thread that listens for keyboard events communicate with
the audio callback.
Are there any recommendations for how to pass real-time events (note
on, note off, etc) to such an audio callback? I figured, this is
already a solved problem and that I could benefit from your
experiences. Maybe you know of some nice open-source C++ queue
implementation that is suitable in such a situation.
I could use some kind of "channel" (thread-safe bounded buffer
implemented using mutexes and condition variables) but I'm not sure
whether this is a good idea in this situation since the audio callback
function should avoid unnecessary delays.
I've also looked into LV2. If I implemented the synthesizer as LV2
plugin, I would get around having to solve the inter-thread
communication problem because it's the plugin host's responsibility.
But to be honest I've found this API to be a bit intimidating and I'm
not familiar with any LV2 host that would allow me to test such a
plugin. Any recommendations? Ardour?
Thanks in advance!
