Re: [LAD] Feature requests: add JackSession support
On 07/11/2011 12:16 AM, Fons Adriaensen wrote: On Sun, Jul 10, 2011 at 05:08:32PM +0200, rosea grammostola wrote: After spending a week using JackSession, I don't think a quit-without-save option should be a 'showstopper' here Fons. Especially because JackSession makes working with JACK so much easier. Better to have JackSession without a quit-without-save option, then no JackSession at all. In other circumstances I'd call that a pragmatic tradeoff. But since you're not offered the choice it's not even that. There is no good reason to omit quit-without-save. I regard any app that doesn't offer it as fundamentally broken, and the same applies to whatever higher level system controlling apps. I use fluxbox, and this shortcut closes all windows for me (having qjackctl in the system tray) ;) Mod4 Shift a :CloseAllWindows Sorry, but I can't dive in the technical discussion. The only thing I can say as a user is that I think Torben did a good job so far. JackSession kills a lot of disadvantages when it comes to working with JACK, especially when creating music. I do understand that people might have good reasons for not working on / supporting something they think is wrong. The question is whether this missing quit-without-save function makes JackSession wrong enough to not support it, also considering the obvious benefits Linuxaudio users have when applications support JackSession. It might be good if Torben joins the discussion about the good and the bad and the missing things of JackSession at the moment (see also message by Emanuel). Kind regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
We have a variable 'int xval' that is being modified
I notice I have mixed up (switched) x and xval in my previous reply...
extern int xval;
void f(void)
{
int a, b, c, ... x, y, z;
x = xval;
// lots of code using a ... z;
}
Well, if you are content with any old possible value of xval (i.e. you
have no synchronization on it anywhere), you are right; but then you
might as well make xval a constant -- just use the first value it ever
had. You have no guarantees that the thread calling f() will EVER have
its hardware cache synchronized to whoever is producing xval. Cache
coherency again...
Otherwise, I bet you *do* have some synchronization, somewhere, for
xval in the thread that calls f. Wherever that place is, save the
cached value, i.e.
mutex_lock()
x = xval
mutex_unlock()
f (x)
... and now there is no need for volatile, data flow becomes clear etc.
So you are right, the way you have structured your short snippet of
code you might be preventing an optimization -- but there is still too
little context, and I bet structuring the code differently will
obviate the need for volatile, plus provide predictable data flow.
A. If xval is being modified by an interrupt handler
then clearly you can't use the mutex - you can't risk
to block the interrupt handler.
Let's say a signal handler, not an interrupt handler. Let's stick with
userspace (C89 + Posix) -- kernels have different rules, different
primitives etc.
*there is no difference* between xval being modified by
an interrupt handler, or by another thread. The difference
There is a difference. A signal will modify x immediately. A different
thread running on a different cache might never propagate the update
the to hardware cache used by f()'s thread.
A few more things, for the sake of completeness:
In the signal case, you should of course make sure the signal is
caught by the thread who reads x, by using pthread_sigmask()
appropriately. Or make the program non-threaded. Otherwise, you now
have two problems...
Also, strictly speaking if you're using a sighandler plus volatile,
you should also declare xval as sig_atomic_t.
-- Dan
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a small jack-session extension, proposal - was: Feature requests: add JackSession support
2011/7/11 Renato renn...@gmail.com: On Sun, 10 Jul 2011 19:43:53 +0200 rosea grammostola wrote: On 07/10/2011 06:33 PM, Emanuel Rumpf wrote: http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft Good job. I added some comments. Thank you. just wanted to notify that one of the additional ideas is asking support for multiple sessions, while one of Emanuel's conclusions (first bulleted list, third item) says that this is now possible but should actually not be, as it could be an error-source. I am for/pro multi-session, IF it is completely reliable, works without hassle (including user-handling) and doesn't complicate implementation too much. That might be possible. Eventually. The current behavior, to me, feels strange and unexpected, though: Opening a running session (twice) opens another set of windows. What's that ? Do I have a doubled session now ? It is very opaque, unclear, which window belongs to which session. Is that how it should be, is that what we'd want ? I'm adding a new section to the wiki page, (Multi-) Session Handling. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On 07/11/2011 03:45 AM, Sean Bolton wrote: On Jul 10, 2011, at 6:34 PM, Sean Bolton wrote: On Jul 10, 2011, at 2:41 PM, Paul Davis wrote: do we have SMP systems these days that do not guarantee cache coherency? Yes. PowerPC and Alpha do not. UltraSPARC v9 and ARMv6/ARM11 and later have modes where they do not (and linux on a SPARC v9 runs in that mode.) And how about the iPad 2?: http://wanderingcoder.net/2011/04/01/arm-memory-ordering/ Good catch... Multi-core ARM devices are actually arriving massively. With Android, there's the Motorola Atrix, the Samsung Galaxy S II, etc.. I think it wouldn't hurt to run the ringbuffer tests again.. -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On 11 July 2011 20:19, Olivier Guilyardi l...@samalyse.com wrote:
Good catch... Multi-core ARM devices are actually arriving massively. With
Android, there's the Motorola Atrix, the Samsung Galaxy S II, etc..
What about my toaster? :-P
I've ended up going back to Fons's pragmatism. If
non-blocking/lock-free programming is so impossibly difficult,
requiring intimate hardware knowledge of numerous different
architectures then there's only one solution available to people like
me, and that's to code for AMD64/Intel and use the existing ringbuffer
implementations.
I'd be interested though if my usage of __sync_bool_compare_and_swap
and __sync_fetch_and_and improves the ring buffer at all? I like the
fact the implementation I'm using is so simple. Trouble is, using the
GCC builtins instead of volatile slows it down. Guess that means it's
duff.
James.
8-
#include rng_buf.h
#include stdlib.h
#include string.h
struct _RingBuffer
{
void** buf;
void** bufend;
void** w;
void** r;
};
RngBuf* rng_buf_new(size_t count)
{
size_t sz = 1;
RngBuf* mb = malloc(sizeof(RngBuf));
if (!mb)
return 0;
for (sz = 1; sz count; sz = 1)
;
mb-buf = calloc(sz, sizeof(void*));
if (!mb-buf)
{
free(mb);
return 0;
}
mb-bufend = mb-buf + sz - 1;
mb-w = mb-buf;
mb-r = mb-buf;
return mb;
}
void rng_buf_free(RngBuf* mb)
{
free(mb-buf);
free(mb);
}
size_t rng_buf_write(RngBuf* mb, const void* data)
{
if (__sync_bool_compare_and_swap(mb-w, 0, data))
{
mb-w = (mb-w == mb-bufend) ? mb-buf : mb-w + 1;
return (size_t)1;
}
return (size_t)0;
}
void* rng_buf_read(RngBuf* mb)
{
void* data;
if ((data = __sync_fetch_and_and(mb-r, 0)))
{
mb-r = (mb-r == mb-bufend) ? mb-buf : mb-r + 1;
return data;
}
return NULL;
}
8-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On Mon, Jul 11, 2011 at 03:02:57PM +0300, Dan Muresan wrote: Well, if you are content with any old possible value of xval (i.e. you have no synchronization on it anywhere), you are right; but then you might as well make xval a constant -- just use the first value it ever had. You have no guarantees that the thread calling f() will EVER have its hardware cache synchronized to whoever is producing xval. Cache coherency again... The typical use case would be xval being some parameter used by e.g. a Jack callback and updated by e.g. MIDI events, or a measurement; and f() being the code that runs periodically to update the GUI element for that parameter or measurement. There is no synchronisation and occasionally using an out- dated value has no fatal consequences - it will very probably be put right on the next update which is 1/10 second or so in the future. The display is informative only, correct audio processing does in no way depend on it being up to date. Otherwise, I bet you *do* have some synchronization, somewhere, for xval in the thread that calls f. Wherever that place is, save the cached value, i.e. mutex_lock() x = xval mutex_unlock() f (x) That would mean the other side has to use the mutex as well when updating xval, and in a Jack callback that is 'not done', at least not if the mutex could be held by a non-realtime thread such as one updating the GUI. In the signal case, you should of course make sure the signal is caught by the thread who reads x, by using pthread_sigmask() appropriately. Or make the program non-threaded. Otherwise, you now have two problems... Not if there is no synchronisation involved as in the example above. If all the signal handler has to do is update xval, it doesn't matter in which thread it runs. Also, strictly speaking if you're using a sighandler plus volatile, you should also declare xval as sig_atomic_t. Strictly true, but R/W of ints is atomic on the platforms that matter to me. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On Monday 11 July 2011, at 22.32.08, James Morris jwm.art@gmail.com wrote: On 11 July 2011 20:19, Olivier Guilyardi l...@samalyse.com wrote: Good catch... Multi-core ARM devices are actually arriving massively. With Android, there's the Motorola Atrix, the Samsung Galaxy S II, etc.. What about my toaster? :-P I've ended up going back to Fons's pragmatism. If non-blocking/lock-free programming is so impossibly difficult, requiring intimate hardware knowledge of numerous different architectures then there's only one solution available to people like me, and that's to code for AMD64/Intel and use the existing ringbuffer implementations. Also, if/when it's time to port, find the code and/or information you need at the time, and test thoroughly on the actual hardware. These things can usually be done on anything, one way or another, more or less efficiently. The only thing that's worse than missing support for some new platform is support that doesn't actually work properly. Lots of debugging fun to be had that way... :-) -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On 11 July 2011 21:32, James Morris jwm.art@gmail.com wrote: I've ended up going back to Fons's pragmatism. If non-blocking/lock-free programming is so impossibly difficult, requiring intimate hardware knowledge of numerous different architectures then there's only one solution available to people like me, and that's to code for AMD64/Intel and use the existing ringbuffer implementations. Perhaps the pragmatic solution is to _lock_ the shared buffer? I'm not at all sound on this subject, but I wouldn't be surprised if Dan was right that memory ordering guarantees on the read/write index variables might still leave the data that is just copied into the buffer exposed to cache coherency problems. I know taking locks in a RT process is deeply frowned upon around here, but a critical section juts across the code used to update the buffer and read back from it -- with an accompanying guarantee of actually getting the right data out again -- might not be such a bad tradeoff these days as we'd be inclined to think? Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On 11 July 2011 21:50, Chris Cannam can...@all-day-breakfast.com wrote: [...] a critical section juts across the code just across Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On Mon, Jul 11, 2011 at 09:59:25PM +0300, Dan Muresan wrote: and the NPTL code in glibc *seems* to perform a memory barrier only on sem_post(). Wouldn't that seem quite natural ? Semas provide one-way communication. It's the sem_post() that means there is an event to be seen by some other thread. So it has to make sure that any data related to it is visible to the receiver. The receiver taking the event (returning from sem_wait()), or checking for it (calling sem_wait()), is not meant to be an event for the other side. You need a second sema if events have to go both ways. For a ringbuffer you need two anyway if the buffer is longer than one item, and you want to signal both of 'not empty' and 'not full' in the appropriate direction. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On Mon, Jul 11, 2011 at 4:50 PM, Chris Cannam can...@all-day-breakfast.com wrote: On 11 July 2011 21:32, James Morris jwm.art@gmail.com wrote: I've ended up going back to Fons's pragmatism. If non-blocking/lock-free programming is so impossibly difficult, requiring intimate hardware knowledge of numerous different architectures then there's only one solution available to people like me, and that's to code for AMD64/Intel and use the existing ringbuffer implementations. Perhaps the pragmatic solution is to _lock_ the shared buffer? no, the pragmatic solution is to use memory barriers liberally applied. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On July 11, 2011 04:50:06 pm Chris Cannam wrote: I know taking locks in a RT process is deeply frowned upon Likely been answered before, but good time for me to ask: What is the reason it is not recommended? Is it simply because of a long time involved in acquiring the lock, or is it because the lock might block some other Jack thread from running? The same reason why other things like 'malloc' or 'new' are not recommended either? Thanks. Tim. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
and the NPTL code in glibc *seems* to perform a memory barrier only on sem_post(). Wouldn't that seem quite natural ? Semas provide one-way communication. It's the sem_post() that means there is an event to be seen by some other thread. So it has to make sure that any data related to it is visible to the receiver. The receiver taking the event (returning from sem_wait()), or checking for it (calling sem_wait()), is not meant to be an event for the other side. You need a second sema if events have to go both ways. from my understanding, sem_post() implies a write barrier (stores have been executed before sem_post()) and sem_wait() a read barrier (loads have to be executed after sem_wait()). tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On Mon, Jul 11, 2011 at 05:15:26PM -0400, Tim E. Real wrote: Likely been answered before, but good time for me to ask: What is the reason it is not recommended? Is it simply because of a long time involved in acquiring the lock, or is it because the lock might block some other Jack thread from running? The time required to take a lock if it is free is probably not significant in most cases (this should not involve a system call). The problem with e.g. a Jack callback trying to take a lock is that the lock could be held by a non-RT thread, and you have no idea how long it could take before that thread releases it. Even if the Jack thread blocks waiting for the lock, that doesn't mean the one holding the lock will continue, and even if it does that provides no guarantee. OTOH, if you have a number of threads at the same priority as Jack's and doing audio work (e.g. to use all the CPUs of an SMP machine) then using locks between them (but no other threads) should be OK - depending a bit on how they are used. The same reason why other things like 'malloc' or 'new' are not recommended either? These could take a long time in some cases (if your process needs more memory from the system for example), so they can't be used safely. -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On Monday 11 July 2011 23:15:26 Tim E. Real wrote: On July 11, 2011 04:50:06 pm Chris Cannam wrote: I know taking locks in a RT process is deeply frowned upon Likely been answered before, but good time for me to ask: What is the reason it is not recommended? Is it simply because of a long time involved in acquiring the lock, or is it because the lock might block some other Jack thread from running? The same reason why other things like 'malloc' or 'new' are not recommended either? Real-time means as fast as possible. Waiting to acquire a lock isn't exactly what you would call fast... Waiting for a lock is the same as waiting for the kernels/OSs memory managment to allocate some space. Have fun, Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
The problem with e.g. a Jack callback trying to take a lock is that the lock could be held by a non-RT thread, and you have no idea how long it could take before that thread releases it. Even if the Jack thread blocks waiting for the lock, that doesn't mean the one holding the lock will continue, and even if it does that provides no guarantee. Priority inversion. A low-priority disk thread could hold a lock needed by the high-priority Jack process thread. But the disk thread is pre-empted by some other non-related medium-priority process. The medium-priority process could keep running for a long time. So the inversion is that, indirectly, a high-priority thread is waiting for some medium-priority process. Some RTOS's deal with this kind of stuff (like hard real-time OSs) -- Dan ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On Tue, 2011-07-12 at 00:12 +0200, Arnold Krille wrote: Real-time means as fast as possible. Err not really. Real-time means Has a bounded response time, locks generally put your completion time at the mercy of another process that is often not designed to have a bounded response time. It is probably more correct to say that locks should be used with extreme caution in RT processes as their use makes the relevant part of another thread part of the time critical response timing. Trylock is an interesting case can can actually be used to solve some of this, have two copies of the working data structure, one protected by a lock, then in the RT thread call trylock and if it succeeds copy the data protected by the lock over the data set used by the RT process and release the lock. If it fails then you still have a coherent set of data, and it might succeed the next time, this is useful for UI data sets (in both directions). Regards, Dan. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
[oops forgot to CC the list at first] On 07/11/2011 11:15 PM, Tim E. Real wrote: On July 11, 2011 04:50:06 pm Chris Cannam wrote: I know taking locks in a RT process is deeply frowned upon Likely been answered before, but good time for me to ask: What is the reason it is not recommended? Is it simply because of a long time involved in acquiring the lock, or is it because the lock might block some other Jack thread from running? The latter. The real-time thread would block until the other thread (that currently holding the lock) releases the lock. How long it takes until the other thread releases the lock is undefined (context switches, process priority dependent, etc) and thus the concept is not suitable for real-time. The same reason why other things like 'malloc' or 'new' are not recommended either? Yes. malloc, printf, etc can not guarantee to return in time. Allocation of new memory may involve various system-calls, flush cache-lines, result in swapping, context-switches, etc... On most systems the worst-case execution time it takes to allocate new memory can not be guaranteed to be below a certain limit. There are various attempts to provide constant time - O(1) - memory allocation and de-allocation code for real-time systems. None of them have reached widespread adoption. Often the drawbacks (e.g. decreased available memory due to fragmentation) outweigh the benefits, and pre-allocation on application level is easier to implement. HTH, robin Thanks. Tim. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On 07/12/2011 12:12 AM, Arnold Krille wrote: On Monday 11 July 2011 23:15:26 Tim E. Real wrote: On July 11, 2011 04:50:06 pm Chris Cannam wrote: I know taking locks in a RT process is deeply frowned upon Likely been answered before, but good time for me to ask: What is the reason it is not recommended? Is it simply because of a long time involved in acquiring the lock, or is it because the lock might block some other Jack thread from running? The same reason why other things like 'malloc' or 'new' are not recommended either? Real-time means as fast as possible. No, real-time means - _guaranteed_ to be done before time X. AKA. guaranteed response time. real-time (tasks|kernels) are often slower on average than non-RT (tasks|kernels). As for the linux-kernel: This is due to the overhead introduced by real-time scheduling (take care of process priority) While non-real-time (tasks|kernels) may be faster on average; they may also occasionally take more time than they should. For RT-tasks this is not acceptable. e.g. non-RT task 5 runs: 10 sec, 11 sec, 9 sec,*20sec*, 9 sec (avg 11.8) RT task 5 runs: 12 sec, 12 sec, 11sec, 12sec, 13 sec (avg 12.0) I hope that explains it well for you. Cheers! robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On 07/12/2011 12:06 AM, Fons Adriaensen wrote: OTOH, if you have a number of threads at the same priority as Jack's and doing audio work (e.g. to use all the CPUs of an SMP machine) then using locks between them (but no other threads) should be OK - depending a bit on how they are used. So, you can use locks as long as that's only meant to synchronize realtime threads with each other? Should some master thread (could be the JACK process thread) have a realtime priority slightly higher than the other (worker) realtime threads? What are the caveats in general? -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
from my understanding, sem_post() implies a write barrier (stores have been executed before sem_post()) and sem_wait() a read barrier (loads have to be executed after sem_wait()). Given that a mutex can be replaced with a semaphore initialized with 1 (then lock == sem_wait, unlock == sem_post), your statement should be true as long as the semaphore value is 0 / 1. However, I don't know if your statement must still be true when the semaphore is used as a count tied to a number of items, i.e. when it always hovers above 1. POSIX talks about a thread of control, but in this case, there is no exclusion, thus no thread of control. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11 (same link as a few posts ago) -- Dan ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
For a ringbuffer you need two anyway if the buffer is longer than one item, and you want to signal both of 'not empty' and 'not full' in the appropriate direction. Well, if one of the threads is periodic (like a Jack process thread) it can use sem_getvalue() on the same semaphore to figure things out -- it doesn't need to be signalled on another semaphore. There are some small complications that can be solved by double-signalling from the other thread, or by wasting one slot... -- Dan ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
