Re: [LAD] PHASEX (jacksession)
On 07/07/2011 11:20 AM, rosea grammostola wrote: On 07/02/2011 07:25 PM, Emanuel Rumpf wrote: 2011/7/2 rosea grammostolarosea.grammost...@gmail.com: It seems to work good here. You have to disable JACK autoconnect in PHASEX and then the connections seems to work. Here they don't. And phasex requires much time to start. Tested with Phasex and jack-rack (jackd1). Connections seems to be restored here (all though at one occasion I used the 'recent' option in qjackctl - session, and the connections didn't restore, another test with 'recent' seems to work though). The problem with a2jmidid I reported a while ago, was because qjackctl doesn't support infra clients atm I think. What's next? Is JackSession in PHASEX ready now? Would be nice if the Linuxaudio users could use this feature and if it hits the different distros. 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?
The apps already need to do some type of synchronization internally.
For example a player's disk thread, when its ringbuffer is full, needs
to wait for the process thread to consume some data and thus free up
Depends. If both ends are periodic processes no other synchronisation
is required. And e.g. Jack callback is such a process, and likely to
be one end.
How about the other end (i.e. the disk thread?) Would that
normally be periodic?
OK, even if your disk thread is periodic for some reason, how does
that argue for library-level synchronization, *instead of* app-level
synchronization? In this case the cost would be the same -- no loss.
You may be right about the (HW as opposed to compiler) re-ordering of
data w.r.t. pointers on some architectures. But AFAIK, at least on Intel
and AMD writes are not re-ordered w.r.t. other writes from the same CPU,
From the same CPU? Are we regressing to non-SMP-only schemes? And
Intel and AMD only?
How about multiple cores / CPUs / caches? Pipeline reordering is not
the main concern (though it can happen) -- cache coherence is.
Regarding the volatile declarations, at least on my version (which
is slightly different from Jack's) there is no performance penalty.
Under which access patterns, with what compiler / optimization flags
etc? I would not make such generalizations... Volatile frustrates the
optimizer's ability to chose the optimal access patterns.
So I keep them just as reminders that these data are shared and may
change in unexpected ways.
Hijacking volatile for *manual* type checking, at the cost of
frustrating the optimizer? Andrei Alexandrescu once advocated that
approach for *automatic* type checking in a famous article
(http://drdobbs.com/cpp/184403766). I believe the shortcomings have
been thoroughly discussed in comp.lang.c++.
If you want to remind yourself, you could group the variable(s) and
the mutex / semaphore in a structure, or name them similarly etc.
You are wrong in saying that 'volatile' has no place in multi-threading.
It is the correct way to go if you want to ensure that a value is e.g.
read/written just once even if it is used many times:
It has no place in properly synchronized threaded programs. And it
cannot guarantee the correctness of un-synchronized threaded programs
(unless you assume non-SMP, non-hyper-threaded, Intely-type hardware
-- *maybe*)
extern volatile int xval; // Written by other thread(s)
void f (void)
{
int x;
x = xval;
// use x many times, it won't change.
}
Without the 'volatile', the compiler is free to read
the memory value xval as many times as it wants, even
if it has a local copy, and it probably will do so if
you have many local variables.
What does that accomplish? You're merely frustrating the compiler's
ability to optimize. You're not achieving complete thread safety by
*adding* volatile -- not on arbitrary hardware. If your code is
completely thread-safe with volatile, it is also completely
thread-safe (and faster) without volatile. Volatile does not offer any
guarantees that cannot be later undone by the pipeline or CPU cache.
-- 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 Sat, Jul 09, 2011 at 04:25:22PM +0300, Dan Muresan wrote: The apps already need to do some type of synchronization internally. For example a player's disk thread, when its ringbuffer is full, needs to wait for the process thread to consume some data and thus free up Depends. If both ends are periodic processes no other synchronisation is required. And e.g. Jack callback is such a process, and likely to be one end. How about the other end (i.e. the disk thread?) Would that normally be periodic? It could be, and that would be perfectly ok in some cases. But I'm not arguing agains synchronisation, and my own implementation of this ringbuffer optionally provides in either direction (buffer becoming non-empyt/non full). OK, even if your disk thread is periodic for some reason, how does that argue for library-level synchronization, *instead of* app-level synchronization? In this case the cost would be the same -- no loss. I don't see the point. You may be right about the (HW as opposed to compiler) re-ordering of data w.r.t. pointers on some architectures. But AFAIK, at least on Intel and AMD writes are not re-ordered w.r.t. other writes from the same CPU, From the same CPU? Are we regressing to non-SMP-only schemes? And No, I'm talking about SMP systems. Writing the data and updating the write pointer is done by the same thread and hence CPU, these actions won't be re-ordered. Intel and AMD only? There is no legal obligation for code to be portable. Nor is there any moral obligation. If I choose to support only Intel and AMD PCs and not embedded systems or mobile devices (and for the kind of SW I write that does make sense) then that is my choice, period. I get usually sick when computer scientist or language buffs start waving their finger about programming style etc. There is room for some pragmatism in everything. Regarding the volatile declarations, at least on my version (which is slightly different from Jack's) there is no performance penalty. Under which access patterns, with what compiler / optimization flags etc? I would not make such generalizations... Volatile frustrates the optimizer's ability to chose the optimal access patterns. In the example I provided the essential point is that there is *one* *correct* access pattern which is to read it once for each call to f(), to ensure that the same value is used everywhere in that function. Declaring this value volatile and taking a local copy does exactly the right thing. The alternative would be protect it by a mutex for as long as f() runs. For no good reason, as I don't mind it being overwritten while f() runs. Would that be more 'optimal' ? Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
