30 Aug
2017
30 Aug
'17
1:16 a.m.
On Aug 29, 2017 03:39, "Peter P." <peterparker(a)fastmail.com> wrote:
* list <list(a)contacte.xyz> [2017-08-29 15:25]:
I think there is some disagreement over whether hard RT is needed for audio work. I think
hard RT is meant more for systems running manufacturing hardware.
My systems work just fine for audio work using Debian's and KXStudio's -rt
kernels. Is KXStudio's kernel hard RT or low-latency?
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
apt-daily.timer loaded active waiting Daily apt
download activities
Which you can disable safely.
and
remote-fs.target loaded active active Remote File Systems
Can be disabled as
well I think.
Not sure they are vital. But i see nothing about
them on the journalctl
that matches the time of the XRUN - the apt-daily time occurs like 1
time every 8 hours or so.
Did you look at jackd priorities?
The Card(s) are alone on they interrupt line -
already manage that -
thank linux audio wiki & others, well explained and documented, and
still up to date.
Thank you again for reading you all ! Appreciate that a lot !
ps : I think it was a wrong routed message from David. J but i do not
want a RT Kernel (do i really need one ?!) for my simple recording
needs. A good low latency, well configured Kernel should do the trick.
As far as
I understand, if I may chime in, the -rt kernel from the
Debian packages does implement several realtime patches, but not all of
them and is not a completely hard realtime kernel. You should at least
install one in parallel to your existing kernel and give it a try to
rule this possibility out and not lose time over speculations. 
30 Aug
30 Aug
10:16 a.m.
New subject: Debian 9 - Xrun
On 08/30/2017 01:16 AM, David Jones wrote:
I think there is some disagreement over whether hard
RT is needed for audio work. I think hard RT is meant more for systems running
manufacturing hardware.
Hard RT in an audio context would only be useful for applying real-time
effects or doing other real-time operations on audio streams that need
very low latency. The OWL and Bela are examples in the audio domain. The
RT patchset doesn't do real hard RT, therefore you need something like
Xenomai or even a dedicated real-time OS. And yes, hard RT is primarily
needed for stuff like CNC machines.
My systems work just fine for audio work using
Debian's and KXStudio's -rt kernels. Is KXStudio's kernel hard RT or
low-latency?
I assume Debian's -rt kernels are fully preemptible (PREEMPT RT), you
don't add a -rt suffix to a low-latency or other kernel. Maybe a basic
preemptible kernel but I've never seen those in the wild. The KXStudio
ones should be fully preemptible.
Jeremy
11:06 a.m.
New subject: Debian 9 - Xrun
I'm not sure if RT intended for industrial control is suitable for audio.
PLCs (Programmable Logic Controllers) are designed to give the most accurate
(deterministic) timing, to the extent that (say) repeating 1S pulses must
always be 1S apart. If they are 10mS late, that is slightly less important
provided they are *always* 10mS late. I don't know what current loop times are,
but that used to be considered fast.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
31 Aug
31 Aug
8:08 a.m.
New subject: Debian 9 - Xrun
On Wed, 30 Aug 2017 10:16:22 +0200, Jeremy Jongepier wrote:
Hard RT in an audio context would only be useful for
applying real-time
effects or doing other real-time operations on audio streams that need
very low latency.
The rt-patch might allow to chose a frame rate a step below the value
you could use without the patch. E.g.instead of 256 frames, you might
need just 128 frames to get rid of xruns. This could be important for
software monitoring, since 10 ms are usually too long, while 5 ms
latency are not unusual for digital effect processors, at least I never
heard somebody complaining about a Behringer V-Amp being unusable,
regarding too long latency and a V-Amp has got 5 ms latency.
I experienced better sync between audio tracks, that are recorded MIDI
tracks [1]. For some reason it affects something responsible for MIDI
jitter.
Regards,
Ralf
[1] If recording the same MIDI track two times, one time after the
other, e.g. a kick, the early reflection alike offset decreases. The
lower the audio frame value, the less MIDI jitter.
2439
days inactive
2441
days old
linux-audio-user@lists.linuxaudio.org
3 comments
4 participants
participants (4)
-
David Jones -
Jeremy Jongepier -
Ralf Mardorf -
Will Godfrey