13 Dec
2010
13 Dec
'10
10:08 a.m.
Hi you all,
what do you think about that? Have you got some personal experience?
http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
Regards
Raffaele
--
*L'unica speranza di catarsi, ammesso che ne esista una, resta affidata
all'istinto di ribellione, alla rivolta non isterilita in progetti, alla
protesta violenta e viscerale.*
13 Dec
13 Dec
1:13 p.m.
2010/12/13 Raffaele Morelli <raffaele.morelli(a)gmail.com>om>:
Hi you all,
what do you think about that? Have you got some personal experience?
http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
This quote:
"If you were doing semi-professional audio recording you might, and
then you'd need to understand the inner workings of the software and
the -rt patchset to make the most of it. Just patching it in and
expecting it to work for you will not really give you any advantage."
is not really true. It is true that there are quite a few complexities
to using the RT patchset's full capabilities. Most people probably do
not use them. But this doesn't mean that a general claim that the
patchset offers them no benefits is wrong. Its really completely wrong
to claim that someone actually *doing* audio recording would need to
understand this sort of stuff - if you write software for that
purpose, then its more correct, but even then part of the point of
JACK is to hide that sort of thing for the majority of applications.
This quote:
"Human perceptible latencies are in the millisecond range, where
anything within about the 5ms range will not be noticeable. The -rt
patchset is designed to decrease latencies in the microsecond range"
is misleading, because it ignores the cumulative effects of scheduling
delays. You really do want stuff to just be as fast as possible.
My own take on this is that Con Kolivas has some interesting insights
and does some cool stuff with his scheduling patches, but he seems to
always be at odds with the other kernel scheduler folk. He also has
never quite seemed to grasp what realtime audio actually requires, and
in his defense tends to say that he's more interested in the
"desktop".
Anecdotally, a couple of people on IRC have noted that their desktop
behaviour with BFS is very nice. I haven't seen any evidence that its
better for RT scheduling than the current mainstream kernel, let alone
the RT patch.
1:58 p.m.
On 12/13/2010 01:13 PM, Paul Davis wrote:
2010/12/13 Raffaele Morelli
<raffaele.morelli(a)gmail.com>om>:
> Hi you all,
>
> what do you think about that? Have you got some personal experience?
> http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
yes. In short: Desktop performance: amazing, Desktop-audio-performance:
good, pro-audio performance: deficient.
This quote:
"If you were doing semi-professional audio recording you might, and
then you'd need to understand the inner workings of the software and
the -rt patchset to make the most of it. Just patching it in and
expecting it to work for you will not really give you any advantage."
is not really true. It is true that there are quite a few complexities
to using the RT patchset's full capabilities. Most people probably do
not use them. But this doesn't mean that a general claim that the
patchset offers them no benefits is wrong.
quite, but it is true in the sense that it is much easier to screw up a
kernel by blindly applying patches and generating a .config if you don't
know what you're doing (and sometimes even if you know what you're
doing). Also, one needs additional tools (like rtirq) to make good use
of RT-linux, while -bfs runs OOTB.
However these days most distributions do that setup for the users.
Its really completely wrong
to claim that someone actually *doing* audio recording would need to
understand this sort of stuff - if you write software for that
purpose, then its more correct, but even then part of the point of
JACK is to hide that sort of thing for the majority of applications.
This quote:
"Human perceptible latencies are in the millisecond range, where
anything within about the 5ms range will not be noticeable. The -rt
patchset is designed to decrease latencies in the microsecond range"
is misleading, because it ignores the cumulative effects of scheduling
delays. You really do want stuff to just be as fast as possible.
I don't care so much about speed. The important issue in pro-audio is
reliability. It's not the smallest possible latency that counts, but the
max. latency of the system.
My own take on this is that Con Kolivas has some
interesting insights
and does some cool stuff with his scheduling patches, but he seems to
always be at odds with the other kernel scheduler folk. He also has
never quite seemed to grasp what realtime audio actually requires, and
in his defense tends to say that he's more interested in the
"desktop".
Anecdotally, a couple of people on IRC have noted that their desktop
behaviour with BFS is very nice. I haven't seen any evidence that its
better for RT scheduling than the current mainstream kernel, let alone
the RT patch.
I can second this: http://permalink.gmane.org/gmane.linux.rt.user/6512
FWIW: the "200 lines kernel patch" (also discussed on this list a few
weeks back), -bfs, etc are great to improve speed on the Desktop but
they do not yield _reliable_ low latency.
2c,
robin
2:28 p.m.
2010/12/13 Robin Gareus <robin(a)gareus.org>
On 12/13/2010 01:13 PM, Paul Davis wrote:
I really hoped that :)
I am now sure that RT patchset is something for kernel folks to deal with,
but neverthless that it's something good to apply for me.
2010/12/13 Raffaele Morelli
<raffaele.morelli(a)gmail.com>om>:
> Hi you all,
>
> what do you think about that? Have you got some personal experience?
> http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
yes. In short: Desktop performance: amazing, Desktop-audio-performance:
good, pro-audio performance: deficient.
This quote:
"If you were doing semi-professional audio recording you might, and
then you'd need to understand the inner workings of the software and
the -rt patchset to make the most of it. Just patching it in and
expecting it to work for you will not really give you any advantage."
is not really true. It is true that there are quite a few complexities
to using the RT patchset's full capabilities. Most people probably do
not use them. But this doesn't mean that a general claim that the
patchset offers them no benefits is wrong.
quite, but it is true in the sense that it is much
easier to screw up a
kernel by blindly applying patches and generating a .config if you don't
know what you're doing (and sometimes even if you know what you're
doing). Also, one needs additional tools (like rtirq) to make good use
of RT-linux, while -bfs runs OOTB.
However these days most distributions do that setup for the users.
well, I always followed
http://www.alsa-project.org/main/index.php/Low_latency_howto and never
screwed up a kernel
I don't care so much about speed. The important issue in pro-audio is
reliability. It's not the smallest possible
latency that counts, but the
max. latency of the system.
I really did not understand this statement and anyway I would not agree...
why anybody should be safe knowing that his box max latency is 20ms instead
of 50ms or 70ms?
Regards
--
*L'unica speranza di catarsi, ammesso che ne esista una, resta affidata
all'istinto di ribellione, alla rivolta non isterilita in progetti, alla
protesta violenta e viscerale.*
3:25 p.m.
On 12/13/2010 02:28 PM, Raffaele Morelli wrote:
The max. system-latency determines the audio-latency at which you will
never have any x-runs. (The minimal and avg. latency determines the
speed and reactivity of your Desktop.)
Without the RT-linux patch you may be good at 99.9% of the time, but
since there is no guarantee for system-latency: there may be drop-outs.
And Murphy says that this 0.1% chance will always become real when
you're on stage in the middle of a performance. The resulting click will
not only kill the PA but half the audience will sue you for becoming
deaf ;-)
An other use-case is a studio: It's not about low-latency there but
about no x-runs at all, they are just unprofessional. YMMV.
2c,
robin
2010/12/13 Robin Gareus <robin(a)gareus.org>
Lucky you :) The information on the alsa-wiki is very good, but not
every user is diligently following instructions as you do.
It is also much easier to make a custom kernel that runs on one (your)
system only, than tackling the task of compiling one that can be
distributed.
On 12/13/2010 01:13 PM, Paul Davis wrote:
I really hoped that :)
I am now sure that RT patchset is something for kernel folks to deal with,
but neverthless that it's something good to apply for me.
2010/12/13 Raffaele Morelli
<raffaele.morelli(a)gmail.com>om>:
> Hi you all,
>
> what do you think about that? Have you got some personal experience?
> http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
yes. In short: Desktop performance: amazing, Desktop-audio-performance:
good, pro-audio performance: deficient.
This quote:
"If you were doing semi-professional audio recording you might, and
then you'd need to understand the inner workings of the software and
the -rt patchset to make the most of it. Just patching it in and
expecting it to work for you will not really give you any advantage."
is not really true. It is true that there are quite a few complexities
to using the RT patchset's full capabilities. Most people probably do
not use them. But this doesn't mean that a general claim that the
patchset offers them no benefits is wrong.
quite, but it is true in the sense that it is
much easier to screw up a
kernel by blindly applying patches and generating a .config if you don't
know what you're doing (and sometimes even if you know what you're
doing). Also, one needs additional tools (like rtirq) to make good use
of RT-linux, while -bfs runs OOTB.
However these days most distributions do that setup for the users.
well, I always followed
http://www.alsa-project.org/main/index.php/Low_latency_howto and never
screwed up a kernel I don't
care so much about speed. The important issue in pro-audio is
reliability. It's not the smallest possible latency that counts, but the
max. latency of the system.
I really did not understand this statement and anyway I would not agree...
why anybody should be safe knowing that his box max latency is 20ms instead
of 50ms or 70ms?
4:26 p.m.
2010/12/13 Robin Gareus <robin(a)gareus.org>
Lucky you :) The information on the alsa-wiki is very good, but not
every user is diligently following instructions as you do.
It is also much easier to make a custom kernel that runs on one (your)
system only, than tackling the task of compiling one that can be
distributed.
let's say I learned to be careful the day after I forgot to put the --initrd
option in a make-kpkg command line statement and got a kernel panic after
rebooting my first brand new... not-working-at-all-kernel :)
agree...
you're right but as a statistician I prefer to call it *law of large numbers
*... same results but more complicated to explain :)
it is much easier to screw up a
kernel by blindly applying patches and generating a .config if you don't
know what you're doing (and sometimes even if you know what you're
doing). Also, one needs additional tools (like rtirq) to make good use
of RT-linux, while -bfs runs OOTB.
However these days most distributions do that setup for the users.
well, I always followed
http://www.alsa-project.org/main/index.php/Low_latency_howto and never
screwed up a kernel I don't care so much about speed. The important
issue in pro-audio is
reliability. It's not the smallest possible latency that counts, but the
max. latency of the system.
I really did not understand this statement and anyway I would not why anybody should be safe knowing that his box
max latency is 20ms
instead
of 50ms or 70ms?
The max. system-latency determines the audio-latency at which you will
never have any x-runs. (The minimal and avg. latency determines the
speed and reactivity of your Desktop.)
Without the RT-linux patch you may be good at 99.9% of the time, but
since there is no guarantee for system-latency: there may be drop-outs.
And Murphy says that this 0.1% chance will always become real when
you're on stage in the middle of a performance. The resulting click will
not only kill the PA but half the audience will sue you for becoming
deaf ;-)
An other use-case is a studio: It's not about
low-latency there but
about no x-runs at all, they are just unprofessional. YMMV.
I agree about unprofessionality of xruns but what about our ears?
I trust my ears and bless them, thanks to them I can appreciate music from
Ella to Jimi and so on... but do they betray me when I realize I can't
recognize an xrun in a mix? How long is an xrun? Can we hear it when it
occurs only 3,4,5 times in a mix?
I guess I am going off topic now but I am a fan of "if it's sounds good then
it's ok"
Regards
--
*L'unica speranza di catarsi, ammesso che ne esista una, resta affidata
all'istinto di ribellione, alla rivolta non isterilita in progetti, alla
protesta violenta e viscerale.*
4:48 p.m.
On Mon, Dec 13, 2010 at 10:26 AM, Raffaele Morelli
<raffaele.morelli(a)gmail.com> wrote:
I agree about unprofessionality of xruns but what
about our ears?
I trust my ears and bless them, thanks to them I can appreciate music from
Ella to Jimi and so on... but do they betray me when I realize I can't
recognize an xrun in a mix? How long is an xrun? Can we hear it when it
occurs only 3,4,5 times in a mix?
if you can't hear the click caused by an xrun, then you probably
should give up mixing :)
more seriously, it is possible for there to be an xrun without any
audible effect (though this is rare). the clicks that they cause are
very similar (most of the time) to those caused by sample clock sync
issues (e.g. a bad word clock cable or connector), and i don't know
anyone who would pay to work in a studio with such a configuration
(until it was fixed).
14 Dec
14 Dec
10:28 a.m.
2010/12/13 Paul Davis <paul(a)linuxaudiosystems.com>
On Mon, Dec 13, 2010 at 10:26 AM, Raffaele Morelli
<raffaele.morelli(a)gmail.com> wrote:
ah ah ah, yes of course... anyway I can't swear my mixing experience will
never cross the border :-)
I agree about unprofessionality of xruns but what
about our ears?
I trust my ears and bless them, thanks to them I can appreciate music
from
Ella to Jimi and so on... but do they betray me
when I realize I can't
recognize an xrun in a mix? How long is an xrun? Can we hear it when it
occurs only 3,4,5 times in a mix?
if you can't hear the click caused by an xrun, then you probably
should give up mixing :)
more seriously, it is possible for there to be an xrun without any
audible effect (though this is rare). the clicks that they cause are
very similar (most of the time) to those caused by sample clock sync
issues (e.g. a bad word clock cable or connector), and i don't know
anyone who would pay to work in a studio with such a configuration
(until it was fixed).
I should have been more precise. I bought a condenser mic (AKG Perception
120) to record some acoustic stuff at home.
I recorded a session - st james infirmary
blues<http://www.catastocen.apat.it/st_james_infirmary_blues.mp3>
- and used the punch in/out feature for the guitar solo and for parts the
two vocal tracks (I had a cold... and still got it)
Well, there's an xrun every time the recording starts, ie after the locator
passes the punch in marker... can you hear it? I can give you the exact
timing.
I also got other session (with the full band playing) but I deleted the xrun
markers... and now I really can't gues where they occurred
Regards
PS: destroy the mp3 after :)
PSPS: apologize in advance for the bad english in the recording :(
--
*L'unica speranza di catarsi, ammesso che ne esista una, resta affidata
all'istinto di ribellione, alla rivolta non isterilita in progetti, alla
protesta violenta e viscerale.*
12:49 p.m.
Em terça-feira 14 dezembro 2010, às 07:28:46, Raffaele Morelli escreveu:
I should have been more precise. I bought a condenser
mic (AKG Perception
120) to record some acoustic stuff at home.
I recorded a session - st james infirmary
blues<http://www.catastocen.apat.it/st_james_infirmary_blues.mp3>
- and used the punch in/out feature for the guitar solo and for parts the
two vocal tracks (I had a cold... and still got it)
Well, there's an xrun every time the recording starts, ie after the locator
passes the punch in marker... can you hear it? I can give you the exact
timing.
I also got other session (with the full band playing) but I deleted the xrun
markers... and now I really can't gues where they occurred
loved the sound quaility, both vocals and voice, also te playing.
i indentified 3 for now, but you have to listen at high volume and carfully: 0:24, 0:34,
1:10 and i think at 0:04 there is another. i'm sure i could find more BUT 99,9% of the
people wont here that, for sure
6:07 p.m.
2010/12/14 Fabio <capoeirista(a)arcor.de>
Em terça-feira 14 dezembro 2010, às 07:28:46, Raffaele
Morelli escreveu:
thank you :)
I should have been more precise. I bought a
condenser mic (AKG Perception
120) to record some acoustic stuff at home.
I recorded a session - st james infirmary
blues<http://www.catastocen.apat.it/st_james_infirmary_blues.mp3>
- and used the punch in/out feature for the guitar solo and for parts the
two vocal tracks (I had a cold... and still got it)
Well, there's an xrun every time the recording starts, ie after the
locator
passes the punch in marker... can you hear it? I
can give you the exact
timing.
I also got other session (with the full band playing) but I deleted the
xrun
markers... and now I really can't gues where
they occurred
loved the sound quaility, both vocals and voice, also te playing.
i indentified 3 for now, but you have to listen at high volume and
carfully: 0:24, 0:34, 1:10 and i think at 0:04 there is another. i'm sure i
could find more BUT 99,9% of the people wont here that, for sure
you're wrong, I had xruns only 2 bars (1:04) and 1 bar before (1:21) the
guitar solo starts and 1 bar after (1:37) no xruns during the guitar track
recording or vocal track recording but, as I wrote, only when punching in.
regards
raffaele
--
*L'unica speranza di catarsi, ammesso che ne esista una, resta affidata
all'istinto di ribellione, alla rivolta non isterilita in progetti, alla
protesta violenta e viscerale.*
14 Jan
14 Jan
1:02 p.m.
Excerpts from Raffaele Morelli's message of 2010-12-14 10:28:46 +0100:
2010/12/13 Paul Davis
<paul(a)linuxaudiosystems.com>
I really enjoy it :)
On Mon, Dec 13, 2010 at 10:26 AM, Raffaele
Morelli
<raffaele.morelli(a)gmail.com> wrote:
ah ah ah, yes of course... anyway I can't swear my mixing experience will
never cross the border :-)
I agree about unprofessionality of xruns but what
about our ears?
I trust my ears and bless them, thanks to them I can appreciate music
from
Ella to Jimi and so on... but do they betray me
when I realize I can't
recognize an xrun in a mix? How long is an xrun? Can we hear it when it
occurs only 3,4,5 times in a mix?
if you can't hear the click caused by an xrun, then you probably
should give up mixing :)
more seriously, it is possible for there to be an xrun without any
audible effect (though this is rare). the clicks that they cause are
very similar (most of the time) to those caused by sample clock sync
issues (e.g. a bad word clock cable or connector), and i don't know
anyone who would pay to work in a studio with such a configuration
(until it was fixed).
I should have been more precise. I bought a condenser mic (AKG Perception
120) to record some acoustic stuff at home.
I recorded a session - st james infirmary
blues<http://www.catastocen.apat.it/st_james_infirmary_blues.mp3>
- and used the punch in/out feature for the guitar solo and for parts the
two vocal tracks (I had a cold... and still got it)
Well, there's an xrun every time the recording starts, ie after the locator
passes the punch in marker... can you hear it? I can give you the exact
timing.
I also got other session (with the full band playing) but I deleted the xrun
markers... and now I really can't gues where they occurred
Regards
PS: destroy the mp3 after :)
PSPS: apologize in advance for the bad english in the recording :(
1:21 p.m.
2011/1/14 Philipp Überbacher <hollunder(a)lavabit.com>
Excerpts from Raffaele Morelli's message of
2010-12-14 10:28:46 +0100:
thanks!
-r
I should have been more precise. I bought a condenser mic (AKG Perception
120) to record some acoustic stuff at home.
I recorded a session - st james infirmary
blues<http://www.catastocen.apat.it/st_james_infirmary_blues.mp3>
- and used the punch in/out feature for the guitar solo and for parts the
two vocal tracks (I had a cold... and still got it)
Well, there's an xrun every time the recording starts, ie after the
locator
passes the punch in marker... can you hear it? I
can give you the exact
timing.
I also got other session (with the full band playing) but I deleted the
xrun
markers... and now I really can't gues where
they occurred
Regards
PS: destroy the mp3 after :)
PSPS: apologize in advance for the bad english in the recording :(
I really enjoy it :)
13 Dec
13 Dec
6:39 p.m.
Em segunda-feira 13 dezembro 2010, às 13:26:48, Raffaele Morelli escreveu:
but do they betray me when I realize I can't
recognize an xrun in a mix? How long is an xrun? Can we hear it when it
occurs only 3,4,5 times in a mix?
be carefull with that, you might not here it in the recording-situation but perhaps after
some processing or on other monitors you hear it. or sometimes with fresher ears they
suddenly appear
9:05 p.m.
On 14 December 2010 01:38, Fabio <capoeirista(a)arcor.de> wrote:
Em segunda-feira 13 dezembro 2010, às 13:26:48,
Raffaele Morelli escreveu:
This is _very_ important. Always, always give your ears a rest. Never
mix for days and conclude that you're done. Give a rest period of at
least 24-48 hours between sessions. Typically a session can be
anywhere from 2 to 8 hours, and on urgent calls sometimes overnight
with 1-2 hour breaks and of course, 6 for some sleep.
You may miss anything from a click to a bad tone or even tune. Been
there, done that.
--
GPG/PGP ID: B42DDCAD
but do they betray me when I realize I can't
recognize an xrun in a mix? How long is an xrun? Can we hear it when it
occurs only 3,4,5 times in a mix?
be carefull with that, you might not here it in the recording-situation but perhaps after
some processing or on other monitors you hear it. or sometimes with fresher ears they
suddenly appear 
10:06 p.m.
Am 13.12.2010 16:26, schrieb Raffaele Morelli:
...recognize an xrun in a mix? How long is an xrun?
Can we hear it when it
occurs only 3,4,5 times in a mix?
Of course there is a major difference between xruns that occur *during a
recording* and those, that may occur, when you working on a mix and open
the GUI of a plugin and the like. I use to have xruns in such situations
on a regular basis. But I make sure to have zero xruns during recordings.
During a recording an xrun adds something uncomprehendable to the
stream, that will in 9/10 cases cause audible noise if the stream is
played. Though the error could be only a few milliseconds in length, the
system, that plays the stream will produce something extremely
recognisable as it hits the place in the stream, where the data is
corrupted by the xrun. Its like a scratch on a vinyl: even if it is
microscopic your record is not mint anymore...
You can have the same effect, if you cut wave-files in a very very wrong
way or if you have extreme peaks above 0db in a recording.
I guess I am going off topic now but I am a fan of
"if it's sounds good then
it's ok"
That is my philosophy also.
So, if you are sure, that it sounds good and 2 or 3 others with sane
hearing agree...
And also if you like to spice up a industrial metal track with some
really evil noises, that all the other cowards fearfully avoid -- just
set jack to run with 0.33 ms latency and record some tracks with a
hda-chip in a netbook ;-)
best regards
HZN
10:04 p.m.
On Mon, Dec 13, 2010 at 03:25:44PM +0100, Robin Gareus wrote:
On 12/13/2010 02:28 PM, Raffaele Morelli wrote:
The max. system-latency determines the audio-latency at which you will
never have any x-runs. (The minimal and avg. latency determines the
speed and reactivity of your Desktop.)
Without the RT-linux patch you may be good at 99.9% of the time, but
since there is no guarantee for system-latency: there may be drop-outs.
And Murphy says that this 0.1% chance will always become real when
you're on stage in the middle of a performance. The resulting click will
not only kill the PA but half the audience will sue you for becoming
deaf ;-)
I don't get clicks, but with my latest bass setup (using LinuxSampler instead of
FluidSynth), I occasionally get moments where all audio just stops for a second or two,
then whatever notes have been played suddenly rush out in a thundering-herd kind of
situation. I suspect this may be a LinuxSampler issue since I've heard it happen
before with other gigs, and it may possibly be related to slow seek times on my SSD on my
EEE.
I've also in the past had fluidsynth cause nasty stuttering (like a DJ snare-rush kind
of sound), particularly with a grand piano soundfont when I get kind of violent with it,
hammering a chord or interval repeatedly Jerry-Lee-Lewis-style with varying velocities.
I'm going to be using this new setup (using LinuxSampler for bass instead of
FluidSynth) for the first time live on the 29th, it will be interesting to see how it
goes.
-ken
2010/12/13 Robin Gareus <robin(a)gareus.org>
Lucky you :) The information on the alsa-wiki is very good, but not
every user is diligently following instructions as you do.
It is also much easier to make a custom kernel that runs on one (your)
system only, than tackling the task of compiling one that can be
distributed.
On 12/13/2010 01:13 PM, Paul Davis wrote:
I really hoped that :)
I am now sure that RT patchset is something for kernel folks to deal with,
but neverthless that it's something good to apply for me.
2010/12/13 Raffaele Morelli
<raffaele.morelli(a)gmail.com>om>:
> Hi you all,
>
> what do you think about that? Have you got some personal experience?
> http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
yes. In short: Desktop performance: amazing, Desktop-audio-performance:
good, pro-audio performance: deficient.
This quote:
"If you were doing semi-professional audio recording you might, and
then you'd need to understand the inner workings of the software and
the -rt patchset to make the most of it. Just patching it in and
expecting it to work for you will not really give you any advantage."
is not really true. It is true that there are quite a few complexities
to using the RT patchset's full capabilities. Most people probably do
not use them. But this doesn't mean that a general claim that the
patchset offers them no benefits is wrong.
quite, but it is true in the sense that it is
much easier to screw up a
kernel by blindly applying patches and generating a .config if you don't
know what you're doing (and sometimes even if you know what you're
doing). Also, one needs additional tools (like rtirq) to make good use
of RT-linux, while -bfs runs OOTB.
However these days most distributions do that setup for the users.
well, I always followed
http://www.alsa-project.org/main/index.php/Low_latency_howto and never
screwed up a kernel I
don't care so much about speed. The important issue in pro-audio is
reliability. It's not the smallest possible latency that counts, but the
max. latency of the system.
I really did not understand this statement and anyway I would not agree...
why anybody should be safe knowing that his box max latency is 20ms instead
of 50ms or 70ms?
14 Dec
14 Dec
7:51 p.m.
On Mon, Dec 13, 2010 at 08:08:50PM -0200, Fabio wrote:
Em segunda-feira 13 dezembro 2010, ?s 19:03:32, Ken
Restivo escreveu:
I found a free gig of a Pedulla bass. I don't remember where exactly I got it. I did
have to modify it, but gigedit worked great for that.
-ken
my latest bass setup (using LinuxSampler instead
of FluidSynth)
can I ask what sampels you are using? I am still searching for a good bass
4861
days inactive
4893
days old
linux-audio-user@lists.linuxaudio.org
17 comments
8 participants
participants (8)
-
Fabio -
Hartmut Noack -
Ken Restivo -
Paul Davis -
Philipp Überbacher -
Raffaele Morelli -
Ray Rashif -
Robin Gareus