Re: [LAD] Feature requests: add JackSession support
On 07/03/2011 12:27 AM, Fons Adriaensen wrote: On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea grammostola wrote: Next thing what would be good to have imo is a good software mixer with JackSession support. Unfortunately non-mixer is not a good candidate afaik, cause it changes port names. I don't know if Fons is still busy with his mixer and if he has explored and made up his mind about the actual implementation of the JackSession API already. As to Jack Session support, I won't even consider it as long as it doesn't support quit-without-save. The rationale for not supporting this is IMNSHO completely bogus. I just can't imagine any app that a) can't do this, and b) can't be modified easily to do it. 'Easily' here means requiring a fraction of the effort to support Jack Session at all. I've got some other gripes with Jack Session as well, but these have been discussed (or at least presented) before. 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. My 2 cents \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Feature requests: add JackSession support
On 07/10/2011 10:08 AM, 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. Actually, I've had the opposite impression... quit-without-save is a total PITA and actually causes data corruption for me. :-/ (Oops... I forgot to save as a bogus session before hitting `Quit`.) -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Feature requests: add JackSession support
2011/7/10 rosea grammostola rosea.grammost...@gmail.com: On 07/03/2011 12:27 AM, Fons Adriaensen wrote: As to Jack Session support, I won't even consider it as long as it doesn't support quit-without-save. The rationale for not supporting this is IMNSHO completely bogus. After playing around with it, I'm with you here. It should have quit-without-save and a few more improvements. I've got some other gripes with Jack Session as well, but these have been discussed (or at least presented) before. Looks like I missed that discussion. I think Torben Hohn did very well, introducing jack-session, it's the way to go, but I think too, it's not mature. I've prepared a proposal that tries to improve some parts of jack-session, without making it much more complicated. Everyone is welcome, to add his ideas and opinion. http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft Better to have JackSession without a quit-without-save option, then no JackSession at all. Agreed. -- 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?
Ah. pthread_mutex_lock() / unlock(), as EXTERNAL functions, will never be optimized away or inlined. Now, being all sequence points, if you simply do pthread_mutex_lock(); xval = x; pthread_mutex_unlock(); the compiler is not allowed to move statements out the locked section or reorder them in any way (without need for any volatile qualifiers). the hardware would be allowed to reorder them ... this is the reason why mutex implementations involve memory barriers ... the main problem is the lack of a memory model for multi-threaded applications at the level of the language (c or c++). fortunately this is about to change with c++0x and probably c1x. 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?
the hardware would be allowed to reorder them ... this is the reason why mutex implementations involve memory barriers ... Yes, the hardware would be allowed to reorder them, so pthread_mutex_lock() has memory barriers. I think everyone knew that much :) However my point to Fons was that, because pthread_mutex_lock() is an external function, the compiler is not allowed to make any assumptions about the global variable x (both functions might modify it): it cannot re-read x after unlock(), or read x before lock(). This was the missing ingredient. So it's a cooperation of sequence point-rules and memory barriers that achieves the effects of a critical section in C. the main problem is the lack of a memory model for multi-threaded applications at the level of the language (c or c++). fortunately this is about to change with c++0x and probably c1x. So in 10 years we will be able to rely on a conformant compiler being available on all relevant platforms :) -- 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?
the main problem is the lack of a memory model for multi-threaded applications at the level of the language (c or c++). fortunately this is about to change with c++0x and probably c1x. So in 10 years we will be able to rely on a conformant compiler being available on all relevant platforms :) http://www.chaoticmind.net/~hcb/projects/boost.atomic/ 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?
On Sun, Jul 10, 2011 at 1:28 PM, Tim Blechmann t...@klingt.org wrote: the main problem is the lack of a memory model for multi-threaded applications at the level of the language (c or c++). fortunately this is about to change with c++0x and probably c1x. So in 10 years we will be able to rely on a conformant compiler being available on all relevant platforms :) http://www.chaoticmind.net/~hcb/projects/boost.atomic/ if it all works ... very nice. but note that its only been tested on a couple of versions of gcc on a couple of *nix-ish platforms. ___ 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 main problem is the lack of a memory model for multi-threaded applications at the level of the language (c or c++). fortunately this is about to change with c++0x and probably c1x. So in 10 years we will be able to rely on a conformant compiler being available on all relevant platforms :) http://www.chaoticmind.net/~hcb/projects/boost.atomic/ if it all works ... very nice. but note that its only been tested on a couple of versions of gcc on a couple of *nix-ish platforms. the number of supported compilers in the documentation is outdated. it supports the most commonly used compilers and multiple architectures. if a compiler is not supported natively, it uses a fallback implementation based on a pool of spinlocks, which of course is not lock-free, but c++0x doesn't guarantee lock-freedom either ... i've been using it for quite some time in boost.lockfree (in a slightly modified version). tim 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] Feature requests: add JackSession support
On 07/10/2011 06:33 PM, Emanuel Rumpf wrote: 2011/7/10 rosea grammostolarosea.grammost...@gmail.com: On 07/03/2011 12:27 AM, Fons Adriaensen wrote: As to Jack Session support, I won't even consider it as long as it doesn't support quit-without-save. The rationale for not supporting this is IMNSHO completely bogus. After playing around with it, I'm with you here. It should have quit-without-save and a few more improvements. I've got some other gripes with Jack Session as well, but these have been discussed (or at least presented) before. Looks like I missed that discussion. I think Torben Hohn did very well, introducing jack-session, it's the way to go, but I think too, it's not mature. I've prepared a proposal that tries to improve some parts of jack-session, without making it much more complicated. Everyone is welcome, to add his ideas and opinion. http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft Good job. I added some comments. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Feature requests: add JackSession support
Am Sun, 10 Jul 2011 17:08:32 +0200 schrieb rosea grammostola rosea.grammost...@gmail.com: On 07/03/2011 12:27 AM, Fons Adriaensen wrote: On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea grammostola wrote: Next thing what would be good to have imo is a good software mixer with JackSession support. Unfortunately non-mixer is not a good candidate afaik, cause it changes port names. I don't know if Fons is still busy with his mixer and if he has explored and made up his mind about the actual implementation of the JackSession API already. As to Jack Session support, I won't even consider it as long as it doesn't support quit-without-save. The rationale for not supporting this is IMNSHO completely bogus. I just can't imagine any app that a) can't do this, and b) can't be modified easily to do it. 'Easily' here means requiring a fraction of the effort to support Jack Session at all. I've got some other gripes with Jack Session as well, but these have been discussed (or at least presented) before. 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. agree. i use jack-session since two weeks. and now i know for sure, that i never again will miss it!!! whatever, i think it makes more sense to support jack-session with a positive feedback, as endless more or less destructive discussions about some details to challenge the whole thing. IMO, if more jack applications will implement it, and more users will work with it, features requests or improvement requests will make clear in which direction the session management will run. and than, maybe there a answer which save or even not save function makes sense or not. greetings wolke My 2 cents \r ___ 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 Sun, Jul 10, 2011 at 06:05:45PM +0300, Dan Muresan wrote:
Ah. pthread_mutex_lock() / unlock(), as EXTERNAL functions, will never
be optimized away or inlined. Now, being all sequence points, if you
simply do
pthread_mutex_lock();
xval = x;
pthread_mutex_unlock();
the compiler is not allowed to move statements out the locked section
or reorder them in any way (without need for any volatile qualifiers).
OK. This is becoming an interesting discussion, so please
allow me to restate clearly the context.
We have a variable 'int xval' that is being modified
by forces unknown to the code we are discussing. This
code is a function f() which uses the value of xval,
but the algorithm implemented by f() requires that
the same value is used at all points where f() uses
xval during a single invocation of that function.
So we have:
extern int xval;
void f(void)
{
int a, b, c, ... x, y, z;
x = xval;
// lots of code using a ... z;
}
Since f() has much more local variables than the CPU
has registers, the compiler could be tempted to reuse
the register used to store x for some other purpose
at some point in the code. It could do that in two ways:
1. Store x on the stack, and read that location when
xval is required again, or
2. Just reuse the register without saving it, and read
the memory location 'xval' again when required.
(2) could make the algorithm fail, because xval could
have changed. So we want to prevent that happening.
The solution I propose is to declare xval volatile.
This forces the compiler to read it just once, as
expressed by the source code. So it either will do (1),
or maybe decide not to trash the register holding x at
all but use another one.
The solution you propose is to protect xval by a mutex.
I invite you to consider the following:
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.
B. From the point of view of the code we are discussing
*there is no difference* between xval being modified by
an interrupt handler, or by another thread. The difference
is completely irrelevant to f(). The only thing that
matters is that xval can change while f() executes.
You would probably accept the 'volatile' if xval is
being written by an interrupt handler. Given (B),
there is no good reason to reject it in either case.
I see. But as I said, in general the cache coherency problem is worse
than the pipeline reordering problem -- i.e. when there are multiple
CPUs/cores using different caches, they may see actions out-of-order.
On that I absolutely agree - cache coherency is the real
problem, not pipelining. The latter should in fact be
transparent from a language such as C/C++.
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 Sun, Jul 10, 2011 at 5:14 PM, Fons Adriaensen f...@linuxaudio.org wrote: On that I absolutely agree - cache coherency is the real problem, not pipelining. The latter should in fact be transparent from a language such as C/C++. i may be way out of the loop, but having worked with some of the early massively parallel conventional processor systems of the late 80's and early 90's (such as the sequent symmetry and the kendall square research machines), my impression was that everyone gave up on clever cache coherency because it turned out to be too hard (as an engineering problem, not as a CS problem). i've gotten stuck with the idea that the industry went for simple cache coherency that simply does what any moderately skilled designer would do when faced with the problem and no concerns about elegance or speed: locks, signalling, and all the usual stuff that is the h/w equiivalent of the pthreads mutex API. do we have SMP systems these days that do not guarantee cache coherency? btw: i do understand that whether they do or do not doesn't affect the basic point about cache coherency possibly leading to incorrect data being read. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Feature requests: add JackSession support
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. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Feature requests: add JackSession support
On Sun, 10 Jul 2011 19:43:53 +0200 rosea grammostola rosea.grammost...@gmail.com wrote: On 07/10/2011 06:33 PM, Emanuel Rumpf wrote: 2011/7/10 rosea grammostolarosea.grammost...@gmail.com: On 07/03/2011 12:27 AM, Fons Adriaensen wrote: As to Jack Session support, I won't even consider it as long as it doesn't support quit-without-save. The rationale for not supporting this is IMNSHO completely bogus. After playing around with it, I'm with you here. It should have quit-without-save and a few more improvements. I've got some other gripes with Jack Session as well, but these have been discussed (or at least presented) before. Looks like I missed that discussion. I think Torben Hohn did very well, introducing jack-session, it's the way to go, but I think too, it's not mature. I've prepared a proposal that tries to improve some parts of jack-session, without making it much more complicated. Everyone is welcome, to add his ideas and opinion. http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft Good job. I added some comments. 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. cheers renato ___ 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?
Guys, if you're writing code for your own use, and don't care about portability or security, go ahead and use volatile as a synchronization primitive. But if the code is going to be accepted into an open source project that gets wide use, volatile is a bad idea. But don't take my word for it; here's what kernel.org, cert.org, and an intel researcher say about it: Volatile considered harmful, http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt The use of volatile is likely to be seen as a bug and will bring additional scrutiny to the code. CERT Secure Coding Standards, recommendation POS03: Do not use volatile as a synchronization primitive https://www.securecoding.cert.org/confluence/display/seccode/POS03-C.+Do+not+use+volatile+as+a+synchronization+primitive A variable declared as volatile is not cached in a register, leading to this confusion that it can be used safely as a synchronization primitive. When declared volatile, the compiler does not re-order the sequence of reads and writes to that memory location. However, the compiler might re-order these reads and writes with those to other memory locations. This might result in non-atomic operations on the synchronization variable resulting in errors. Ad Hoc Synchronization Considered Harmful, www.xiongww.com/papers/osdi10-xiong.pdf Ad hoc synchronizations are error-prone. Significant percentages (22-67%) of these ad hoc synchronizations introduced bugs or severe performance issues. Volatile is a 1980's solution to a 2000's problem, and it just doesn't cut the mustard anymore. - 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 Jul 10, 2011, at 2:41 PM, Paul Davis wrote: On Sun, Jul 10, 2011 at 5:14 PM, Fons Adriaensen f...@linuxaudio.org wrote: On that I absolutely agree - cache coherency is the real problem, not pipelining. The latter should in fact be transparent from a language such as C/C++. i may be way out of the loop, but having worked with some of the early massively parallel conventional processor systems of the late 80's and early 90's (such as the sequent symmetry and the kendall square research machines), my impression was that everyone gave up on clever cache coherency because it turned out to be too hard (as an engineering problem, not as a CS problem). i've gotten stuck with the idea that the industry went for simple cache coherency that simply does what any moderately skilled designer would do when faced with the problem and no concerns about elegance or speed: locks, signalling, and all the usual stuff that is the h/w equiivalent of the pthreads mutex API. 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.) Here's some good reading that may help: Memory Ordering in Modern Microprocessors, Part I http://www.linuxjournal.com/article/8211 Memory Ordering in Modern Microprocessors, Part II http://www.linuxjournal.com/article/8212 Linux Kernel Memory Barriers http://www.kernel.org/doc/Documentation/memory-barriers.txt ARM11 Processors: Ordering requirements for memory accesses http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211i/Babcijbf.html btw: i do understand that whether they do or do not doesn't affect the basic point about cache coherency possibly leading to incorrect data being read. Good--without memory barriers, JACK's ringbuffer is at risk for this corruption on these platforms. Cheers, -Sean ___ 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 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/ -Sean ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
