Re: [LAD] hard realtime performance synth

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <linux-audio-dev@...>
Date: Tuesday, January 26, 2010 - 8:15 pm

--000e0cd70cf6559cbd047e16f33d
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Thanks for the response. Some thoughts

1. Bristol synth was one the first synths I tried. I had installed
Ubuntu(Karma I think. BTW: Ubuntu is based off Debian and that packaging
system didn't seem to save me from breaking things) and then used various
"apt" commands suggested on the Ubuntu Studio site to install sections I
wanted(including the "realtime" kernel). When I ran Bristol(or ZynAddSub for
that matter) it would lockup and not even display the keyboard interface. I
eventually discovered that networking(the loop device interface) was not
hooked in. I got a little further in that graphic interface came up and I
got a plink or 2 before lockup. I'll take a look at the suggestions given
however.

2. As for some of other suggestions, I don't care what interface(X11,curses
etc) is available on the sound host(the dell in this case). As long as I
could control it and get some usable status output that'd be ok. (I'll check
into linux sampler). I could see it functioning perfectly well via some
midi/serial connection which I think ALSA has.

3. I'm a little worried about what some are calling realtime systems. The
realtime system that is part of Ubuntu Studio and others may be more
preemptible than the normal kernel(as in kernel calls themselves can be
preempted), but that's not a hard realtime system. A hard realtime
system(simplistic I know) might entail a task whose sole job is to pump out
a sinusoidal sound sample to the D-to-A on the sound card. A hard realtime
scheduler would run that task at 44Khz no matter what. This would entail
developing code that when the machine instructions were analyzed, would run
in the time constraints(aka the 44Khz). RTLinux appears to be suitable and
RTAI might be. Perhaps others.

The way things are now even with the "realtime kernel" on U. Studio. , xruns
can occur because there's no hard limit on accessing resources-only
priorities. This may work fine on newer/faster machines but not on the older
ones. Some may say, "Go buy a faster machine". My answer is that won't
necessarily solve the problem which is a proliferation of "systems" on top
of systems without any assurance they'll all work together on time. I could
go buy a new systems but I have the feeling I'd be still "tuning" to get
things running. Roland, Korg, Yamaha put out turnkey products on what I
suspect is simpler hardware and my question is there any reason why similar
turnkey systems could not be developed on a Linux system(even on an older
machine). There may be some reason. I just don't think I've heard it yet.

david

David

--000e0cd70cf6559cbd047e16f33d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,Thanks for the response. Some thoughts1. Bristol syn=
th was one the first synths I tried. I had installed Ubuntu(Karma I think. =
BTW: Ubuntu is based off Debian and that packaging system didn't seem t=
o save me from breaking things) and then used various "apt" comma=
nds suggested on the Ubuntu Studio site to install sections I wanted(includ=
ing the "realtime" kernel). When I ran Bristol(or ZynAddSub for t=
hat matter) it would lockup and not even display the keyboard interface. I =
eventually discovered that networking(the loop device interface) was not ho=
oked in. I got a little further in that graphic interface came up and I got=
a plink or 2 before lockup. I'll take a look at the suggestions given =
however.
2. As for some of other suggestions, I don't care what interface(X1=
1,curses etc) is available on the sound host(the dell in this case). As lon=
g as I could control it and get some usable status output that'd be ok.=
(I'll check into linux sampler). I could see it functioning perfectly =
well via some midi/serial connection=A0 which I think ALSA has.
3. I'm a little worried about what some are calling realtime system=
s. The realtime system that is part of Ubuntu Studio and others may be more=
preemptible than the normal kernel(as in kernel calls themselves can be pr=
eempted), but that's not a hard realtime system. A hard realtime system=
(simplistic I know) might entail a task whose sole job is to pump out a sin=
usoidal sound sample to the D-to-A on the sound card. A hard realtime sched=
uler would run that task at 44Khz no matter what. This would entail develop=
ing code that when the machine instructions were analyzed, would run in the=
time constraints(aka the 44Khz). RTLinux appears to be suitable and RTAI m=
ight be. Perhaps others.
The way things are now even with the "realtime kernel" on U. =
Studio. , xruns can occur because there's no hard limit on accessing re=
sources-only priorities. This may work fine on newer/faster machines but no=
t on the older ones. Some may say, "Go buy a faster machine". My =
answer is that won't necessarily solve the problem which is a prolifera=
tion of "systems" on top of systems without any assurance they&#3=
9;ll all work together on time. I could go buy a new systems but I have the=
feeling I'd be still "tuning" to get things running. Roland,=
Korg, Yamaha put out turnkey products on what I suspect is simpler hardwar=
e and my question is there any reason why similar turnkey systems could not=
be developed on a Linux system(even on an older machine). There may be som=
e reason. I just don't think I've heard it yet.
davidDavid

--000e0cd70cf6559cbd047e16f33d--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] hard realtime performance synth, David McClanahan, (Sat Jan 23, 10:33 pm)
Re: [LAD] hard realtime performance synth, David McClanahan, (Tue Jan 26, 8:15 pm)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Wed Jan 27, 8:40 am)
Re: [LAD] hard realtime performance synth, David Olofson, (Wed Jan 27, 1:48 am)
Re: [LAD] hard realtime performance synth, David McClanahan, (Thu Jan 28, 8:01 pm)
Re: [LAD] hard realtime performance synth, David Olofson, (Fri Jan 29, 1:32 am)
Re: [LAD] hard realtime performance synth, David McClanahan, (Fri Jan 29, 10:24 pm)
Re: [LAD] hard realtime performance synth, Gabriel M. Beddingfield, (Sat Jan 30, 5:37 am)
Re: [LAD] hard realtime performance synth, Paul Davis, (Sat Jan 30, 12:20 am)
Re: [LAD] hard realtime performance synth, Gabriel M. Beddingfield, (Thu Jan 28, 9:40 pm)
Re: [LAD] hard realtime performance synth, Folderol, (Thu Jan 28, 10:12 pm)
Re: [LAD] hard realtime performance synth, torbenh, (Thu Jan 28, 8:55 pm)
Re: [LAD] hard realtime performance synth, Louigi Verona, (Wed Jan 27, 1:51 am)
Re: [LAD] hard realtime performance synth, Louigi Verona, (Wed Jan 27, 1:34 am)
Re: [LAD] hard realtime performance synth, Stephen Sinclair, (Tue Jan 26, 9:48 pm)
Re: [LAD] hard realtime performance synth, David McClanahan, (Thu Jan 28, 6:55 pm)
Re: [LAD] hard realtime performance synth, Paul Davis, (Thu Jan 28, 7:56 pm)
Re: [LAD] hard realtime performance synth, David McClanahan, (Thu Jan 28, 8:07 pm)
Re: [LAD] hard realtime performance synth, Josh Lawrence, (Tue Jan 26, 8:39 pm)
Re: [LAD] hard realtime performance synth, Gabriel M. Beddingfield, (Sun Jan 24, 2:46 am)
Re: [LAD] hard realtime performance synth, Ray Rashif, (Sun Jan 24, 6:35 am)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Sun Jan 24, 1:27 pm)
Re: [LAD] hard realtime performance synth, Louigi Verona, (Sun Jan 24, 2:46 pm)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Sun Jan 24, 3:06 pm)
Re: [LAD] hard realtime performance synth, Victor Lazzarini, (Mon Jan 25, 6:16 pm)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Mon Jan 25, 5:17 pm)
Re: [LAD] hard realtime performance synth, Gene Heskett, (Mon Jan 25, 6:32 pm)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Mon Jan 25, 6:09 pm)