28 Dec
2009
28 Dec
'09
8:24 a.m.
Nature of xruns
I never paid attention to mentions of xruns since I rarely got
them using a stock Fedora 8 kernel (and F6 before that) on a
x86_64 architecture, 4GB RAM. Yesterday though, I got plenty of
them and my observation is that in this case any real-time
feature associated to the kernel does not matter. In this case
the xruns are made by the way applications handles
stuff (whatever that is). So that makes me think that there
ought to be a guideline, a best practices in developing Linux
audio/jack applications.
Here's the observation setup.
First, the song. The song does not matter, It always plays
fine. The song is made by the use of Seq24 which drives several
soundfonts loaded by Qsynth in different engine instances, as
well as two sounds made by Zyn. Qsynth has several instances of
FluidR3_GM (120MB) and one SGM (250MB) loaded.
Second, the xruns. I take the outputs and drive them through
jackmix, add electric guitar line-in from a Vox amp, and have the
outputs of jackmix feed into Qarecord. Start recording. The
.wav result is polluted with xruns.
Third, same song w/o xruns. I terminate jackmix and Qarecord
and launch Ardour. I run all outputs into Ardour, and run the
electric guitar as well. Add some Freeverb and MultiEQ. Record.
No xruns at all in the resulting .wav file.
From this it is obvious that the application layer helps a lot
in promoting xruns. It is safe to assume that Qarecord is a
quick hack. But, there's seemingly a big difference in
application design regarding the handling of audio/jack stuff
between Qarecord and Ardour since one produces a festival of
xruns and the other none.
My question is, is there a guide/HOWTO around that addresses
the proper design of audio/jack applications or, is - in 2009 -
the only to know about that is by actually going through the source
code of successful Linux audio/jack applications ?
Cheers.
28 Dec
28 Dec
9:47 a.m.
[...]
My question is, is there a guide/HOWTO around that
addresses
the proper design of audio/jack applications or, is - in 2009 -
the only to know about that is by actually going through the source
code of successful Linux audio/jack applications ?
As a non-lad I just say: It is not that bad.
As of 2009, there are some guidelines:
The 'JACK API Reference Manual' and
'Writing Audio Applications With JACK - A tutorial/journal'
are linked from here:
http://jackaudio.org/documentation
This recent thread might be instructive as well:
http://www.linuxaudio.org/mailarchive/lad/2009/11/25/162459
best,
d
11:01 a.m.
On Monday 28 of December 2009 13:24:24 lanas wrote:
Third, same song w/o xruns. I terminate jackmix and
Qarecord
and launch Ardour. I run all outputs into Ardour, and run the
electric guitar as well. Add some Freeverb and MultiEQ. Record.
No xruns at all in the resulting .wav file.
I don't know about Qarecord, but unfortunately JackMix is an example of
a JACK app that does not "follow the rules".
My question is, is there a guide/HOWTO around that
addresses
the proper design of audio/jack applications or, is - in 2009 -
the only to know about that is by actually going through the source
code of successful Linux audio/jack applications ?
The rules are quite simple, but in many cases not exactly easy to
implement.
Inside the JACK process callback, you may not call anything that might
block, i.e. that might suspend the calling thread indefinitely. That
includes:
- memory allocations (and deallocations)
- waiting for mutexes etc.
- file IO, printing to the console, etc.
The main difficulty lies in the fact that these things are often hidden
deep inside some library code. So you should either verify that a
function is safe to use in realtime code, or avoid using it in this
context.
As for common solutions to these problems, the link to the previous
thread David posted should be a good start.
Dominic
3:19 p.m.
Le Lundi, 28 Décembre 2009 16:00:04 +0100,
Dominic Sacré <dominic.sacre(a)gmx.de> a écrit :
The rules are quite simple, but in many cases not
exactly easy to
implement.
Inside the JACK process callback, you may not call
anything that
might block, i.e. that might suspend the calling thread indefinitely.
That includes:
- memory allocations (and deallocations)
- waiting for mutexes etc.
- file IO, printing to the console, etc.
Thanks for the pointers. For me this does not consitute any problem.
Such callbacks must be treated like, if I may make the analogy, the
bottom part of an ISR.
The main difficulty lies in the fact that these things
are often
hidden deep inside some library code. So you should either verify
that a function is safe to use in realtime code, or avoid using it in
this context.
Yes. It is better to set context and return from such callbacks
as soon as possible. Then some kind of observer, free of such time
contraints, would react on the set context variables/structures.
As for common solutions to these problems, the link to
the previous
thread David posted should be a good start.
Thanks to David also. I'll start reading the JACK API. Looks
interesting from a programming point of view.
Cheers/Salut/Tschüß
3 Jan
3 Jan
3:20 p.m.
On Mon, Dec 28, 2009 at 02:19:35PM -0500, lanas wrote:
Le Lundi, 28 D??cembre 2009 16:00:04 +0100,
Dominic Sacr?? <dominic.sacre(a)gmx.de> a ??crit :
The general approach I've seen in well-behaved apps is to do all the audio processing
in a separate thread, and stream the resulting 32-bit floats into a shared circular
buffer. The JACK callback then does little if anything more than just reading floats out
of the buffer, and incrementing a counter or pointer (not protected by any mutex, the JACK
callback thread is the only thing that writes it, and all other threads only read it) to
show where it left off. Keeps the jack callback thread very light.
Then again, this is my completely novice impression from only reading the code of various
JACK apps, never actually writing one myself.
-ken
The rules are quite simple, but in many cases not
exactly easy to
implement.
Inside the JACK process callback, you may not
call anything that
might block, i.e. that might suspend the calling thread indefinitely.
That includes:
- memory allocations (and deallocations)
- waiting for mutexes etc.
- file IO, printing to the console, etc.
Thanks for the pointers. For me this does not consitute any problem.
Such callbacks must be treated like, if I may make the analogy, the
bottom part of an ISR.
The main difficulty lies in the fact that these
things are often
hidden deep inside some library code. So you should either verify
that a function is safe to use in realtime code, or avoid using it in
this context.
Yes. It is better to set context and return from such callbacks
as soon as possible. Then some kind of observer, free of such time
contraints, would react on the set context variables/structures.
As for common solutions to these problems, the
link to the previous
thread David posted should be a good start.
Thanks to David also. I'll start reading the JACK API. Looks
interesting from a programming point of view.
3:42 p.m.
Hi,
On Sunday 03 January 2010 20:19:10 Ken Restivo wrote:
The general approach I've seen in well-behaved
apps is to do all the audio
processing in a separate thread, and stream the resulting 32-bit floats
into a shared circular buffer. The JACK callback then does little if
anything more than just reading floats out of the buffer, and incrementing
a counter or pointer (not protected by any mutex, the JACK callback thread
is the only thing that writes it, and all other threads only read it) to
show where it left off. Keeps the jack callback thread very light.
But the main reason for the jack-thread is that processing there happens when
jack needs it and with the priority jacks needs while all the extra threads
(gui is one of them) have lower priority to not block the audio stuff. When you
do the audio creation in another thread and only push it to the jack-threads
ringbuffer, you have to make sure that buffer is always filled to not get gaps
(actual xruns but without jack complaining, only audio missing).
While this works when you "just" stream media from disk, this will not work
with samplers/synths/effects as these react to external signals that come in in
the same priority and should be processed as fast as possible instead of when
the to-jack-ringbuffer actually reaches that data...
If the sampler uses a separate thread (with lower priority), this would mean
that the midi-event comes in and the according tone is just generated and
appended to the ringbuffer. Some time in the future the ringbuffer would get
sent to jack. But you actually want the jack-thread to only interpolate the
events time inside its current audio-buffer and push the tone out as fast as
possible. Otherwise there would be no valid reason to tune the audio-latency
to low values for live-synths and effects...
A well behaved jack app is not one that does almost nothing inside the jack-
callback, its one that does what is necessary as fast as possible. That
implies not using certain operations such as new/delete/free/malloc but allows
for audio generation to be done inside the callback.
And especially this allows for the callback to process the incoming audio and
output it again in the very same call. (Which makes JackMix well-behaved:)
Otherwise mixing and effects would all add a delay you don't want.
Have fun,
Arnold
28 Dec
28 Dec
4:08 p.m.
On Monday 28 December 2009 16:00:04 Dominic Sacré wrote:
On Monday 28 of December 2009 13:24:24 lanas wrote:
Interesting. Do you care to explain that?
Afaik I am not doing any of the forbidden stuff in JackMix. And did not
encounter any problems in my own usage.
But the OP mentioned Zyn, which to the general experience is not real-time
capable resulting in the various rewrites/ports...
Arnold
Third, same song w/o xruns. I terminate
jackmix and Qarecord
and launch Ardour. I run all outputs into Ardour, and run the
electric guitar as well. Add some Freeverb and MultiEQ. Record.
No xruns at all in the resulting .wav file.
I don't know about Qarecord, but unfortunately JackMix is an example of
a JACK app that does not "follow the rules".
4:33 p.m.
Le Lundi, 28 Décembre 2009 21:08:05 +0100,
Arnold Krille <arnold(a)arnoldarts.de> a écrit :
But the OP mentioned Zyn, which to the general
experience is not
real-time capable resulting in the various rewrites/ports...
Zyn is squarely out of the problem domain since xruns can be had with
and without it, by changing other applications eg. switching from
jackmix/QARecord to Ardour).
Tschüß.
7:46 p.m.
On Monday 28 of December 2009 21:08:05 Arnold Krille wrote:
In JackMix::process(), two QMaps are created and filled with objects
(every single time the callback is invoked). I didn't look at the
implementation of QMap, but I don't see how this could work without
dynamic memory allocations happening somewhere.
In this particular case, I'd expect memory to be allocated for the
storage of the map elements, and probably for the content of the
QStrings (which are used as map keys) as well.
That said, I have no conclusive evidence to prove that any of the xruns
I've seen in the past were actually JackMix's fault. The real problem
might have been elsewhere.
I also use a lot of STL and various Boost libraries in my own JACK
projects (including the realtime parts), so I know how painful it can be
to figure out which parts of some convoluted template classes are "safe"
to use...
Dominic
PS: the jackmix-0.4.1.tar.gz tarball seems to be gzipped twice, so tar
can't open it without gunzipping it first...
I don't
know about Qarecord, but unfortunately JackMix is an
example of a JACK app that does not "follow the rules".
Interesting. Do you care to explain that? 
3:17 p.m.
Am Mon, 28. Dec 2009 um 07:24:24 -0500 schrieb lanas:
Hi "lanas",
From this it is obvious that the application layer
helps a lot
in promoting xruns. It is safe to assume that Qarecord is a
quick hack. But, there's seemingly a big difference in
application design regarding the handling of audio/jack stuff
between Qarecord and Ardour since one produces a festival of
xruns and the other none.
as far as I understood your experiment, you compared these two setups to
conclude "QARecord is to blame":
1) noise -> jackmix -> QARecord -> wav-file
2) noise -> Ardour -> wav-file
For mathematical reasons I would like to get your result from this
alternative setup (also giving better access to a root cause):
3) noise -> jackmix -> Ardour -> wav-file
Some other interesting information would be, what program versions
(jackmix, QARecord) are you using?
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
4:23 p.m.
Le Lundi, 28 Décembre 2009 20:17:21 +0100,
Guido Scholz <guido.scholz(a)bayernline.de> a écrit :
as far as I understood your experiment, you compared
these two setups
to conclude "QARecord is to blame":
Not really. And I forgot to mention jackmix which looks like another
quick hack.
This is because it was not much of an experiment to start with but
rather an observation derived from finding a way to record the song
without so many xruns.
As such, the observation was quite clear: kernel real-time
capabilities, although they might play a role somewhere, had nothing
to do in producing xruns since switching applications resolved the
problem. From that observation then a question arose: there must be a
bad way and a good way of writing a Linux audio/jack application: what
is it ?
For mathematical reasons I would like to get your
result from this
alternative setup (also giving better access to a root cause):
3) noise -> jackmix -> Ardour -> wav-file
Indeed. That's the possibility I haven't explored since I think the
result of the observation was to see that there's a bad and good way of
writing such applications. Now, that the bad way lies with jackmix
and/or Qarecord is a second point that has more to do with technical
performance in the context of writing such an audio/jack application.
Which is not the case at the moment. I'm currently working on a project
that has nothing to do with such matters but I consider for a next
project to make a Linux jack application that would ease my music
making as I find there are some things that could make it easier to
make music.
Some other interesting information would be, what
program versions
(jackmix, QARecord) are you using?
Hmmm.. I'd disagree with this insofar as debugging these apps is
certainly not the matter.
Tschüß.
5:06 p.m.
Am Mon, 28. Dec 2009 um 15:24:02 -0500 schrieb lanas:
Le Lundi, 28 Décembre 2009 20:17:21 +0100,
Guido Scholz <guido.scholz(a)bayernline.de> a écrit :
Hi "lanas",
could you please reply to the list an not to my private e-mail?
> as far as I understood your experiment, you
compared these two setups
> to conclude "QARecord is to blame":
Not really. And I forgot to mention jackmix which
looks like another
quick hack.
Hm, yes that sounds pretty persuading.
This is because it was not much of an experiment to
start with but
rather an observation derived from finding a way to record the song
without so many xruns.
I am aware of that and chose this wording to encourage you to discover
the real root cause. Currently we suffer from hypotheses (at least I
do).
As such, the observation was quite clear: kernel
real-time
capabilities, although they might play a role somewhere, had nothing
to do in producing xruns since switching applications resolved the
problem. From that observation then a question arose: there must be a
bad way and a good way of writing a Linux audio/jack application: what
is it ?
So did you get the answer?
> For mathematical reasons I would like to get your
result from this
> alternative setup (also giving better access to a root cause):
>
> 3) noise -> jackmix -> Ardour -> wav-file
Indeed. That's the possibility I haven't
explored since I think the
result of the observation was to see that there's a bad and good way of
writing such applications.
I see, so you are more interested from a philosophical (or moral?) point
of view.
Now, that the bad way lies with jackmix
and/or Qarecord is a second point that has more to do with technical
performance in the context of writing such an audio/jack application.
Which is not the case at the moment.
Hm sorry, I didn't get that.
> Some other interesting information would be, what
program versions
> (jackmix, QARecord) are you using?
Hmmm.. I'd disagree with this insofar as debugging
these apps is
certainly not the matter.
So yes well, but are you sure, you understood my question?
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
5:24 p.m.
Le Lundi, 28 Décembre 2009 22:06:47 +0100,
Guido Scholz <guido.scholz(a)bayernline.de> a écrit :
Yes. See the first two replies in ths thread, by David and Dominic.
As I added, treating jack callbacks as bottom part ISRs could certainly
improve performance and who knows (not I so far, do you ?) avoid a good
deal of xruns ?
I always tend to approach projects with a high-level overview before
delving into the details. As such I get a first round on how to define
objects, data paths, responsibilities, etc... Of course these will get
refined when details come in. That's how I do it.
In other words, this is not about debugging jackmix and/or QARecord.
are you the author of QARecord by any chance ?
Am Mon, 28. Dec 2009 um 15:24:02 -0500 schrieb lanas:
Well, one or both (jackmix, QARecord) are doing it. Now, I think it is
clear, without looking at the code, that there's more effort put in
Ardour than jackmix, not on the amount of features obviously, but on
making it well-behaved in the context of Linux audio/jack apps. I'm
not certain, but I think the author of jackd is also author of Ardour.
Do not quote me on that.
Not really. And I forgot to mention jackmix
which looks like
another quick hack.
Hm, yes that sounds pretty persuading. > This is because it was not much of an experiment
to start with but
> rather an observation derived from finding a way to record the song
> without so many xruns.
I am aware of that and chose this wording to encourage
you to discover
the real root cause. Currently we suffer from hypotheses (at least I
do).
If, when I start my little project, I face the same number of xruns,
then I'll take a look. if not, my purpose is not to debug jackmix
and/or QARecord. I simply made an orbservation.
As such, the
observation was quite clear: kernel real-time
capabilities, although they might play a role somewhere, had nothing
to do in producing xruns since switching applications resolved the
problem. From that observation then a question arose: there must
be a bad way and a good way of writing a Linux audio/jack
application: what is it ?
So did you get the answer? > For
mathematical reasons I would like to get your result from this
> alternative setup (also giving better access to a root cause):
>
> 3) noise -> jackmix -> Ardour -> wav-file
Indeed. That's the possibility I haven't
explored since I think the
result of the observation was to see that there's a bad and good
way of writing such applications.
I see, so you are more interested from a philosophical (or moral?)
point of view. Now, that the
bad way lies with jackmix
and/or Qarecord is a second point that has more to do with technical
performance in the context of writing such an audio/jack
application. Which is not the case at the moment.
Hm sorry, I didn't get that. > > Some other interesting information would be,
what program versions
> > (jackmix, QARecord) are you using?
> Hmmm.. I'd disagree with this insofar as
debugging these apps is
> certainly not the matter.
So yes well, but are you sure, you understood my
question?
Yes. Program versions do not matter in that observation.
Tschüß.
6:50 p.m.
Am Mon, 28. Dec 2009 um 16:24:48 -0500 schrieb lanas:
Guido Scholz <guido.scholz(a)bayernline.de> a
écrit :
Hi "lanas",
> Am Mon, 28. Dec 2009 um 15:24:02 -0500 schrieb
lanas:
> I am aware of that and chose this wording to
encourage you to discover
> the real root cause. Currently we suffer from hypotheses (at least I
> do).
If, when I start my little project, I face the same
number of xruns,
then I'll take a look. if not, my purpose is not to debug jackmix
and/or QARecord. I simply made an orbservation.
my contributions to this thread are not about "debugging" more about
"operating", but obviously this topic did not come across. May be if you
once publish your project you will find out what it was about.
> > From that observation then a question arose:
there must
> > be a bad way and a good way of writing a Linux audio/jack
> > application: what is it ?
> So did you get the answer?
Yes. See the first two replies in ths thread, by
David and Dominic.
As I added, treating jack callbacks as bottom part ISRs could certainly
improve performance and who knows (not I so far, do you ?) avoid a good
deal of xruns ?
Yes sure, this is common audio programming standard. But is it the whole
picture?
> I see, so you are more interested from a
philosophical (or moral?)
> point of view.
I always tend to approach projects with a high-level
overview before
delving into the details. As such I get a first round on how to define
objects, data paths, responsibilities, etc... Of course these will get
refined when details come in. That's how I do it.
I see :).
In other words, this is not about debugging jackmix
and/or QARecord.
Yes you got it, this conversation is not about "debugging", at least
from my side.
are you the author of QARecord by any chance ?
A look at the about box could tell you. But does it really matter?
Program versions do not matter in that observation.
OK, I will not join this (simple) view. Code changes from time to time
(from release to release?) and even operating errors can occur. But
finding the error clearly needs an other strategy.
Good night.
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
8:11 p.m.
Le Lundi, 28 Décembre 2009 23:50:17 +0100,
Guido Scholz <guido.scholz(a)bayernline.de> a écrit :
Well, this is some kind of conversation, so I figured I'd ask. Of
course, much information can be gotten without conversation.
Am Mon, 28. Dec 2009 um 16:24:48 -0500 schrieb lanas:
> If, when I start my little project, I face the
same number of xruns,
> then I'll take a look. if not, my purpose is not to debug jackmix
> and/or QARecord. I simply made an orbservation.
my contributions to this thread are not about
"debugging" more about
"operating", but obviously this topic did not come across. May be if
you once publish your project you will find out what it was about.
Operating... Yep. Plug inputs into jackmix, plug jackmix outputs into
QARecord. Adjust levels. Ah, did I forgot to turn the computer on ?
Publish to find out ? Everything works well with Ardour, as I've
mentionned in the original post. So why bother with apps that I
just about never use and probably will never again ?
> Yes. See the first two replies in ths thread, by
David and Dominic.
> As I added, treating jack callbacks as bottom part ISRs could
> certainly improve performance and who knows (not I so far, do
> you ?) avoid a good deal of xruns ?
Yes sure, this is common audio programming standard.
But is it the
whole picture?
I'll see when I'll be doing an audio/jack app. Then I'll have
details. It could be that I'll never get details about what makes the
jackmix/QARecord fails. Could be. Will I be missing much ? I don't
think so.
are you the
author of QARecord by any chance ?
A look at the about box could tell you. But does it really matter? > Program versions do not matter in that
observation.
OK, I will not join this (simple) view. Code changes
from time to time
(from release to release?) and even operating errors can occur. But
finding the error clearly needs an other strategy.
Well, if the only way to go was with jackmix/QARecord then yes, a
solution should be found. But since the problem is easily solved by
simply using Ardour (I always use Ardour by the way and I've never used
jackmix before, and now, thinking about it, in the last two years,
recordings (few, near the beginning) with xruns were done when QARecord
was in the loop) then there's no need to look deeply in the
mechanics of jackmix/QARecord. If I want to look at some example code
I'll at least look up Ardour because it works well (or any other app
that I can try and works well).
Tschüß, und vielleicht bis später.
30 Dec
30 Dec
4:15 a.m.
Guido Scholz wrote:
Am Mon, 28. Dec 2009 um 15:24:02 -0500 schrieb lanas:
I use thunderbird, and I have two reply-buttons, which works like this
with messages on lau:
"Reply" will send a reply to the author only.
"Reply All" will send a reply to the author + cc other authors + cc the
lau list.
About half the FLOSS lists I'm on (abcusers, blue-music, chuck, csound,
livecode, supercollider) will send a reply to the list when pressing
"Reply". The other half (ardour, ffado, lau, lilypond, mscore, pd, zyn)
work like lau, replying to author when pressing "Reply".
I asked before, and there doesn't seem be anything to do about it in my
thunderbird setup). So someone (here, I think) suggested that I just
made a habit of using "Reply all" on all lists.
I even got heavy flaming once for cc'ing a reply to the lau list. The
poster had *intentionally* *only* replied to me, and my message filter
placed the message in the lau folder, due to [LAU] in the subject. When
I hit "Reply" or "Reply All" I noticed that I was only writing to the
author, and hence figured I accidentally must have hit "Reply", and thus
manually added cc:lau.
Bottom line: I know that you two are heated, but if I cannot press
"Reply All" without prospect of getting corrected, I would really and
sincerely like to know that I should do? Please don't flame me, I would
actually like to know!
--
Atte
http://atte.dk http://modlys.dk
Le Lundi, 28 Décembre 2009 20:17:21 +0100,
Guido Scholz <guido.scholz(a)bayernline.de> a écrit :
Hi "lanas",
could you please reply to the list an not to my private e-mail?
5 Jan
5 Jan
2:01 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
Am Wed, 30. Dec 2009 um 09:15:23 +0100 schrieb Atte André Jensen:
Guido Scholz wrote:
Hi Atte,
> Hi "lanas",
> could you please reply to the list an not to my private e-mail?
I use thunderbird, and I have two reply-buttons, which
works like this
with messages on lau:
"Reply" will send a reply to the author
only.
"Reply All" will send a reply to the author
+ cc other authors + cc the
lau list.
yes and a simple "List-Reply" is missing since years (Bug #45715).
I asked before, and there doesn't seem be anything
to do about it in my
thunderbird setup). So someone (here, I think) suggested that I just
made a habit of using "Reply all" on all lists.
I do not use Thunderbird but "mutt"; here I can type "l" to activate
"List-Reply". Pretty simple, even works with cc-ed mail.
I just did some internet search for you and found this (possible)
solution:
https://addons.mozilla.org/de/thunderbird/addon/4455
I hope this helps; it is definitively worth a try.
Regards
Guidpo
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
2:14 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
Am Tue, 05. Jan 2010 um 19:01:56 +0100 schrieb Guido Scholz:
Sorry, this link is also available in English:
https://addons.mozilla.org/en/thunderbird/addon/4455
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
4:32 p.m.
New subject: How to do a list reply?
Guido Scholz wrote:
Sorry, this link is also available in English:
https://addons.mozilla.org/en/thunderbird/addon/4455
Thanks a bunch, that was nice!
--
Atte
http://atte.dk http://modlys.dk
2:14 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
I'm pretty sure that the list server can be configured to put the
list's address in the Reply-To field. That way, there's no need for
MUA-specific tricks.
Just my 2 cents.
Andras
On 1/5/10, Guido Scholz <guido.scholz(a)bayernline.de> wrote:
Am Wed, 30. Dec 2009 um 09:15:23 +0100 schrieb Atte André Jensen:
Guido Scholz wrote:
Hi Atte,
> Hi "lanas",
> could you please reply to the list an not to my private e-mail?
I use thunderbird, and I have two reply-buttons,
which works like this
with messages on lau:
"Reply" will send a reply to the author
only.
"Reply All" will send a reply to the
author + cc other authors + cc the
lau list.
yes and a simple "List-Reply" is missing since years (Bug #45715).
I asked before, and there doesn't seem be
anything to do about it in my
thunderbird setup). So someone (here, I think) suggested that I just
made a habit of using "Reply all" on all lists.
I do not use Thunderbird but "mutt"; here I can type "l" to activate
"List-Reply". Pretty simple, even works with cc-ed mail.
I just did some internet search for you and found this (possible)
solution:
https://addons.mozilla.org/de/thunderbird/addon/4455
I hope this helps; it is definitively worth a try.
Regards
Guidpo
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
2:33 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
On Tue, 5 Jan 2010 19:14:26 +0100
Andras Simon <szajmi(a)gmail.com> wrote:
I'm pretty sure that the list server can be
configured to put the
list's address in the Reply-To field. That way, there's no need for
MUA-specific tricks.
Just my 2 cents.
Andras
you mean reply-to munging
http://www.unicom.com/pw/reply-to-harmful.html
I would not go that route.
Dieter
2:48 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
On 1/5/10, Dieter Plaetinck <dieter(a)plaetinck.be> wrote:
On Tue, 5 Jan 2010 19:14:26 +0100
Andras Simon <szajmi(a)gmail.com> wrote:
Exactly!
I'm pretty sure that the list server can be
configured to put the
list's address in the Reply-To field. That way, there's no need for
MUA-specific tricks.
Just my 2 cents.
Andras
you mean reply-to munging
http://www.unicom.com/pw/reply-to-harmful.html I would not go that route.
After reading that article, I'm no so sure I would either...
Thanks for the link!
Andras
6 Jan
6 Jan
9:08 a.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
On Tue, 5 Jan 2010 19:14:26 +0100, Andras Simon <szajmi(a)gmail.com> wrote:
I'm pretty sure that the list server can be
configured to put the
list's address in the Reply-To field. That way, there's no need for
MUA-specific tricks.
Just my 2 cents.
Andras
NO, NO, NO
Read here : http://www.unicom.com/pw/reply-to-harmful.html
This is not subject to debate.
--
Marc-Olivier Barre
XMPP ID : marco(a)marcochapeau.org
www.MarcOChapeau.org
1:27 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
I've ended up by configuring gmail to "reply to all" for everything.
Oh, and the link you post really assumes that everyone is using ELM. I
used that program in the 1980s ... I think this is 2010 :) Maybe I
need to put on my reverse-time-suit :)
On Wed, Jan 6, 2010 at 6:08 AM, Marc-Olivier Barre
<marco(a)marcochapeau.org> wrote:
On Tue, 5 Jan 2010 19:14:26 +0100, Andras Simon
<szajmi(a)gmail.com> wrote:
--
**** Listen to my CD at http://www.mellowood.ca/music/cedars ****
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: bob(a)mellowood.ca
WWW: http://www.mellowood.ca
I'm pretty sure that the list server can be
configured to put the
list's address in the Reply-To field. That way, there's no need for
MUA-specific tricks.
Just my 2 cents.
Andras
NO, NO, NO
Read here : http://www.unicom.com/pw/reply-to-harmful.html
This is not subject to debate.
--
Marc-Olivier Barre
XMPP ID : marco(a)marcochapeau.org
www.MarcOChapeau.org
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
5:25 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
On Wed, Jan 6, 2010 at 5:27 PM, Bob van der Poel <bob(a)mellowood.ca> wrote:
Oh, and the link you post really assumes that everyone
is using ELM. I
used that program in the 1980s ... I think this is 2010 :) Maybe I
need to put on my reverse-time-suit :)
If you've never received a potentially embarrassing personal email
inadvertently via a public mailing list, you clearly haven't been
around for as long as...
Hey -- hang on -- you've been around for ages!
Either you're very careful and you look away discreetly when other
people do weird things, or you've mostly been hanging out on lists
that don't do reply-to munging. Me, I don't really want to see
another "hey! how are you? I'm fine, just about to divorce so-and-so"
or "you guys really sold me out on that audio reseller deal"... No, I
really don't.
The arguments about convenience are mostly moot, you could argue
either side. The difference in seriousness of the most common "user
failure" case is the argument that surely matters most.
Chris
7:34 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
On Wed, 2010-01-06 at 21:25 +0000, Chris Cannam wrote:
On Wed, Jan 6, 2010 at 5:27 PM, Bob van der Poel
<bob(a)mellowood.ca> wrote:
As well as the fact that reply-to munging removes options (reply, reply
all, and reply list ALL do the same thing).
Oh, and the link you post really assumes that
everyone is using ELM. I
used that program in the 1980s ... I think this is 2010 :) Maybe I
need to put on my reverse-time-suit :)
If you've never received a potentially embarrassing personal email
inadvertently via a public mailing list, you clearly haven't been
around for as long as...
Hey -- hang on -- you've been around for ages!
Either you're very careful and you look away discreetly when other
people do weird things, or you've mostly been hanging out on lists
that don't do reply-to munging. Me, I don't really want to see
another "hey! how are you? I'm fine, just about to divorce so-and-so"
or "you guys really sold me out on that audio reseller deal"... No, I
really don't.
The arguments about convenience are mostly moot, you could argue
either side. The difference in seriousness of the most common "user
failure" case is the argument that surely matters most.
7:35 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
If you've never received a potentially embarrassing personal email
inadvertently via a public mailing list, you clearly haven't been
around for as long as...
Hey -- hang on -- you've been around for ages!
Shhh... you're giving away my age :)
But, seriously (as well) I think the biggest problem with all this is
that just about every mailing list I subscribe to uses a different
reply format. Some are like this one, others give a reply to the list
and the poster, and others are just a mystery.
And getting everyone to agree is probably not going to happen :)
So, probably best to leave well enough alone.
As far as getting/sending inappropriate mail .... naw, never happened to me :)
--
**** Listen to my CD at http://www.mellowood.ca/music/cedars ****
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: bob(a)mellowood.ca
WWW: http://www.mellowood.ca
10:11 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
On Wed, 2010-01-06 at 16:35 -0700, Bob van der Poel wrote:
For me its not too difficult (and yes I'm on some lists with reply-to
munging), just click reply-all and problem solved.
If you've never received a potentially embarrassing personal email
inadvertently via a public mailing list, you clearly haven't been
around for as long as...
Hey -- hang on -- you've been around for ages!
Shhh... you're giving away my age :)
But, seriously (as well) I think the biggest problem with all this is
that just about every mailing list I subscribe to uses a different
reply format. Some are like this one, others give a reply to the list
and the poster, and others are just a mystery.
And getting everyone to agree is probably not going to happen :)
So, probably best to leave well enough alone.
As far as getting/sending inappropriate mail .... naw, never happened to me :) 
11:34 p.m.
New subject: How to do a list reply? (was: Linux audio app design: The nature of xruns)
Ng Oon-Ee wrote:
For me its not too difficult (and yes I'm on some
lists with reply-to
munging), just click reply-all and problem solved.
Problem solved for you, but not necessarily for the recipient. For
instance if you reply-all to this email, one of two things happens:
a) I get one email directly from you and none from the mailing
list. However, since it doesn't come from the list manager it
ends up in my inbox and not in my LAU folder. Bummer.
b) I get two copies, one directly from you in my inbox and the
other in my duplicates folder. Double bummer.
If its meant for the list send it only to the list. If its mean
for the person only send it only to that person.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
5 Jan
5 Jan
2:39 p.m.
New subject: How to do a list reply?
Hi Atte,
just to let you know: this is available in thunderbird v3 (Shredder/3.0)
- just using it right now...
cheers,
holger
"Reply
All" will send a reply to the author + cc other authors + cc the
lau list.
yes and a simple "List-Reply" is missing since years (Bug #45715).
5464
days inactive
5473
days old
linux-audio-user@lists.linuxaudio.org
29 comments
15 participants
participants (15)
-
Andras Simon -
Arnold Krille -
Atte André Jensen -
Bob van der Poel -
Chris Cannam -
David Adler -
Dieter Plaetinck -
Dominic Sacré -
Erik de Castro Lopo -
Guido Scholz -
Holger Ballweg -
Ken Restivo -
lanas -
Marc-Olivier Barre -
Ng Oon-Ee