Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

by Kjetil Matheussen

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

9 years, 11 months

[LAD] Realtime inter-thread communication

by Sebastian Gesemann

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

9 years, 11 months

Re: [LAD] Realtime inter-thread communication

by Kjetil Matheussen

> > Sebastian Gesemann: > @all: Thank you for your responses. I'm going to use my own ringbuffer > using C++11's std::atomics. > > Here are a couple of alternatives: http://portaudio.com/docs/v19-doxydocs-dev/pa__ringbuffer_8h.html http://www.boost.org/doc/libs/1_60_0/doc/html/lockfree.html

9 years, 11 months

Re: [LAD] Code reordering

by Kjetil Matheussen

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?

9 years, 11 months

Re: [LAD] Linux-audio-dev Digest, Vol 109, Issue 4

by Kjetil Matheussen

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

9 years, 11 months

[LAD] No sound after login

by Gene Heskett

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>

9 years, 11 months

[LAD] [ANN] Vee One Suite 0.7.4 - The Ninth-bis beta release

by Rui Nuno Capela

Hello again, The so called 'Vee One Suite' aka. 'the gang of three' old-school software instruments, respectively synthv1 [1] as a polyphonic subtractive synthesizer, samplv1 [2] a polyphonic sampler synthesizer and drumkv1 [3] as one drum-kit sampler, are released yet again in their ninth official beta second iteration (bis). Still available in dual form: - a pure stand-alone JACK [4] client with JACK-session, NSM [5] (Non Session management) and both JACK MIDI and ALSA [6] MIDI input support; - a LV2 [7] instrument plug-in. As simple as a change-log may go: - Fixed the DCF Formant filter voice initialization reset. - French translation updated (by Olivier Humbert, thanks). The Vee One Suite are free, open-source Linux Audio [9] software, distributed under the terms of the GNU General Public License (GPL) [8] version 2 or later. And here they are again! **synthv1 - an old-school polyphonic synthesizer [1]** synthv1 0.7.4 (ninth-bis official beta) is out! synthv1 is an old-school all-digital 4-oscillator subtractive polyphonic synthesizer with stereo fx. LV2 URI: http://synthv1.sourceforge.net/lv2 website: http://synthv1.sourceforge.net downloads: http://sourceforge.net/projects/synthv1/files - source tarball: http://download.sf.net/synthv1/synthv1-0.7.4.tar.gz - source package: http://download.sf.net/synthv1/synthv1-0.7.4-27.rncbc.suse.src.rpm - binary packages (openSUSE Tumbleweed): http://download.sf.net/synthv1/synthv1-0.7.4-27.rncbc.suse.i586.rpm http://download.sf.net/synthv1/synthv1-0.7.4-27.rncbc.suse.x86_84.rpm git repos: http://git.code.sf.net/p/synthv1/code https://github.com/rncbc/synthv1 **samplv1 - an old-school polyphonic sampler [2]** samplv1 0.7.4 (ninth-bis official beta) is out! samplv1 is an old-school polyphonic sampler synthesizer with stereo fx. LV2 URI: http://samplv1.sourceforge.net/lv2 website: http://samplv1.sourceforge.net downloads: http://sourceforge.net/projects/samplv1/files - source tarball: http://download.sf.net/samplv1/samplv1-0.7.4.tar.gz - source package: http://download.sf.net/samplv1/samplv1-0.7.4-27.rncbc.suse.src.rpm - binary packages (openSUSE Tumbleweed): http://download.sf.net/samplv1/samplv1-0.7.4-27.rncbc.suse.i586.rpm http://download.sf.net/samplv1/samplv1-0.7.4-27.rncbc.suse.x86_84.rpm git repos: http://git.code.sf.net/p/samplv1/code https://github.com/rncbc/samplv1 **drumkv1 - an old-school drum-kit sampler [3]** drumkv1 0.7.4 (ninth-bis official beta) is out! drumkv1 is an old-school drum-kit sampler synthesizer with stereo fx. LV2 URI: http://drumkv1.sourceforge.net/lv2 website: http://drumkv1.sourceforge.net downloads: http://sourceforge.net/projects/drumkv1/files - source tarball: http://download.sf.net/drumkv1/drumkv1-0.7.4.tar.gz - source package: http://download.sf.net/drumkv1/drumkv1-0.7.4-23.rncbc.suse.src.rpm - binary packages (openSUSE Tumbleweed): http://download.sf.net/drumkv1/drumkv1-0.7.4-23.rncbc.suse.i586.rpm http://download.sf.net/drumkv1/drumkv1-0.7.4-23.rncbc.suse.x86_84.rpm git repos: http://git.code.sf.net/p/drumkv1/code https://github.com/rncbc/drumkv1 References: [1] synthv1 - an old-school polyphonic synthesizer http://synthv1.sourceforge.net/ [2] samplv1 - an old-school polyphonic sampler http://samplv1.sourceforge.net/ [3] drumkv1 - an old-school drum-kit sampler http://drumkv1.sourceforge.net/ [4] JACK Audio Connection Kit http://jackaudio.org/ [5] NSM, Non Session Management http://non.tuxfamily.org/nsm/ [6] ALSA, Advanced Linux Sound Architecture http://www.alsa-project.org/ [7] LV2, Audio Plugin Standard, the extensible successor of LADSPA http://lv2plug.in/ [8] GNU General Public License http://www.gnu.org/copyleft/gpl.html [9] Linux Audio consortium of libre software for audio-related work http://linuxaudio.org See also: http://www.rncbc.org/drupal/node/1012 Enjoy && keep the fun ;) -- rncbc aka. Rui Nuno Capela

9 years, 11 months

[LAD] ALSA sequencer: Early delivery of events.

by Richard Cooper

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.

9 years, 11 months

[LAD] Realtime inter-thread communication

by Sebastian Gesemann

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!

9 years, 11 months

[LAD] miniLAC 2016 wiki updates and schedule

by David Runge

Dear Linux Audio Developers/ Users/ LAC organizers, the wiki has seen a major overhaul: http://minilac.linuxaudio.org/ Please head over, enjoy the first stage of the schedule and read updated information! As we're using the wiki to keep track, who is coming (and more importantly how many are coming), please also sign up, if you're only a guest and not explicitely doing an event! We hope you find all the required information. If you think something is missing, please add it to the wiki or contact us (in case you can't)! See you in Berlin in April! Best, David -- David Runge Schreinerstraße 11 10247 Berlin http://sleepmap.de

9 years, 11 months

Jump to page:

2026

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