21 Oct
2014
21 Oct
'14
1:20 p.m.
Hi all,
I'm the team leader of Voice Communication Systems development in ARTISYS company. We
try to utilize RME RayDat sound device on Linux system with ALSA sound interface. After a
lot of experiments we are not able to set up proper sound output from this device, so we
kindly ask you for a help to solve our problem. Here is a brief description:
General task of our troubleshooting is that our audio signal output is not continuous. The
output signal is rather interrupted. Here is our configuration:
PC with Linux (kernel v. 3.17.0) with ALSA sound libraries compiled in kernel. We have
also additional packages installed: alsa-tools, alsa-utils and alsa-lib (all version
1.0.28).
Inside the PC there is PCI Express card RME Raydat, whose drivers are also compiled in the
Linux kernel. This interface is connected by optical fibres (ADAT) to the Ferrofish A16
MK-II (2 pairs of TOSLINK cables).
Playing test files using commands
aplay -D pcm.out_test -r 48000 -f S32_LE /usr/share/sounds/alsa/Front_Left.wav -vv
and
aplay -D pcm.out_test2 -r 48000 -f S32_LE /usr/share/sounds/alsa/Front_Right.wav -vv
causes audible interruptions. The configuration of the ALSA device is following:
pcm.out_dmix {
type dmix
ipc_key 56874
ipc_key_add_uid false
ipc_perm 0666
slave {
pcm "hw:2,0"
period_size 2048
channels 36
rate 48000
}
bindings {
0 0 # from 0 => to 0
1 1 # from 1 => to 1
}
}
pcm.out_test {
type plug
slave.pcm "out_dmix"
ttable.0.0 1
}
pcm.out_test2 {
type route
slave.pcm "out_dmix"
ttable.0.1 1
}
Let me describe other two example experiments:
1. If I try to record sound using the same parameters as out_dmix device but of type
"dsnoop" (equivalent of dmix for capturing), there are no interruptions and the
recorded sound is perfect.
2. If I play single sound file to the output of the RME card while the ALSA device is of
type "route", the sound output is perfect. Playing second file on different
output channel this way I'm not able to open
other output channel simultaneously by another program because the device is busy. There
is this experiment's ALSA device configuration:
pcm.out_test {
type route
slave.pcm "hw:2,0"
slave.format "S32_LE"
slave.channels 36
ttable.0.0 1
}
pcm.out_test2 {
type route
slave.pcm "hw:2,0"
slave.format "S32_LE"
slave.channels 36
ttable.0.1 1
}
This should be solved by "dmix" type ALSA device, which currently causes
interruptions in our configuration.
The question is: how can we play multiple audio streams to multiple output channels using
our equipment?
Thank you.
Dear Mr. Knoth,
I'm the team leader of Voice Communication Systems development in ARTISYS company. We
try to utilize RME RayDat sound device on Linux system with ALSA sound interface. After a
lot of experiments we are not able to set up proper sound output from this device, so we
kindly ask you for a help to solve our problem. Here is a brief description:
General task of our troubleshooting is that our audio signal output is not continuous. The
output signal is rather interrupted. Here is our configuration:
PC with Linux (kernel v. 3.17.0) with ALSA sound libraries compiled in kernel. We have
also additional packages installed: alsa-tools, alsa-utils and alsa-lib (all version
1.0.28).
Inside the PC there is PCI Express card RME Raydat, whose drivers are also compiled in the
Linux kernel. This interface is connected by optical fibres (ADAT) to the Ferrofish A16
MK-II (2 pairs of TOSLINK cables).
Playing test files using commands
aplay -D pcm.out_test -r 48000 -f S32_LE /usr/share/sounds/alsa/Front_Left.wav -vv
and
aplay -D pcm.out_test2 -r 48000 -f S32_LE /usr/share/sounds/alsa/Front_Right.wav -vv
causes audible interruptions. The configuration of the ALSA device is following:
pcm.out_dmix {
type dmix
ipc_key 56874
ipc_key_add_uid false
ipc_perm 0666
slave {
pcm "hw:2,0"
period_size 2048
channels 36
rate 48000
}
bindings {
0 0 # from 0 => to 0
1 1 # from 1 => to 1
}
}
pcm.out_test {
type plug
slave.pcm "out_dmix"
ttable.0.0 1
}
pcm.out_test2 {
type route
slave.pcm "out_dmix"
ttable.0.1 1
}
Let me describe other two example experiments:
1. If I try to record sound using the same parameters as out_dmix device but of type
"dsnoop" (equivalent of dmix for capturing), there are no interruptions and the
recorded sound is perfect.
2. If I play single sound file to the output of the RME card while the ALSA device is of
type "route", the sound output is perfect. Playing second file on different
output channel this way I'm not able to open
other output channel simultaneously by another program because the device is busy. There
is this experiment's ALSA device configuration:
pcm.out_test {
type route
slave.pcm "hw:2,0"
slave.format "S32_LE"
slave.channels 36
ttable.0.0 1
}
pcm.out_test2 {
type route
slave.pcm "hw:2,0"
slave.format "S32_LE"
slave.channels 36
ttable.0.1 1
}
This should be solved by "dmix" type ALSA device, which currently causes
interruptions in our configuration.
The question is: how can we play multiple audio streams to multiple output channels using
our equipment?
Thank you.
Yours sincerely
Ing. Vaclav Mach
Voice Communications System team leader
ARTISYS
www: http://www.artisys.aero
21 Oct
21 Oct
2:02 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 21.10.2014 13:20, Vaclav Mach wrote:
pcm.out_dmix { type dmix ipc_key 56874 ipc_key_add_uid
false
ipc_perm 0666 slave { pcm "hw:2,0" period_size 2048 channels 36
rate 48000 } bindings { 0 0 # from 0 => to 0 1 1 # from 1 => to 1
} }
Just a shot in the dark (it has been a looooong time since I last
played with this stuff):
Is the period size maybe too large? Does the hardware actually support
2048 frames? Maybe try 1024 frames. Also maybe try setting the
buffer_size attribute to something that makes sense with the channel
count and period size. Maybe 2^16 = 65536 Or even bigger? Would have
to read documentation on the exact semantics. I leave that to you
though ;)
Good luck,
Flo
P.S.: There's also a channel #alsa on irc.freenode.org. Knowledgable
people hang around there, too
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJURks2AAoJEA5f4Coltk8Zp44H/R1gcNRhfJMz4b9JNJ+7tJs+
DcqtQ0u2hl0CtvSlIw3iermcCmzQ6vKCC+iZbLlLzTEuJOP07Ozb6ONjCew4JAqq
Ygx31qQ5/pAzSYfiFi27rZJS/ScqR2AWqqpYXAIR+MmVvzadsjol6cLvv884ZCQO
LBWbmVvFt5ZLf8+tcsj8TfmfDznY2N81wyDcn87Fr+U7YBI2LxePBIBnm9o1XZ7+
mgZKw4xgteaIIQG5uTuQJNxyxSM2UoIVc3AijoMMgPvYRjc0gL/8PS7CtMCk297i
HRWCZ4bTpH8wKkI9CLDJ0J7RWsUkCJgjx3vAgaXyBkvQWJVdZ3Dqvt2nipAoNgI=
=K5ty
-----END PGP SIGNATURE-----
22 Oct
22 Oct
11:32 a.m.
I've tried to change period size from 256 to 4096 (2^n values) and there
was no difference.
The only difference was during changing of master sample rate where I
could hear different "position" of interruptions while setting 32kHz or
48 kHz.
Note that buffer size is fixed at 16384 samples (note is from the driver
source code) and I also proved it during experiments.
Vaclav
On 10/21/2014 02:02 PM, Florian Paul Schmidt wrote:
On 21.10.2014 13:20, Vaclav Mach wrote:
pcm.out_dmix { type dmix ipc_key 56874
ipc_key_add_uid false
ipc_perm 0666 slave { pcm "hw:2,0" period_size 2048 channels 36
rate 48000 } bindings { 0 0 # from 0 => to 0 1 1 # from 1 => to 1
} }
Just a shot in the dark (it has been a looooong time since I last
played with this stuff):
Is the period size maybe too large? Does the hardware actually support
2048 frames? Maybe try 1024 frames. Also maybe try setting the
buffer_size attribute to something that makes sense with the channel
count and period size. Maybe 2^16 = 65536 Or even bigger? Would have
to read documentation on the exact semantics. I leave that to you
though ;)
Good luck,
Flo
P.S.: There's also a channel #alsa on irc.freenode.org. Knowledgable
people hang around there, too
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
21 Oct
21 Oct
4:11 p.m.
On Tue, Oct 21, 2014 at 7:20 AM, Vaclav Mach <vaclav.mach(a)artisys.aero>
wrote:
Hi all,
I'm the team leader of Voice Communication Systems development in ARTISYS
company. We try to utilize RME RayDat sound device on Linux system with
ALSA sound interface. After a lot of experiments we are not able to set up
proper sound output from this device, so we kindly ask you for a help to
solve our problem. Here is a brief description:
General task of our troubleshooting is that our audio signal output is not
continuous. The output signal is rather interrupted.
testing this configuration using aplay doesn't make any sense. you
apparently believe that getting glitch-free audio playback is a trivial
task ... it isn't unless you are prepared to use a lot of buffering (which
is what happens in a lot of consumer-ish software.
you are also attempting to use ALSA dmix facilities, which is not
recommended by anyone for any purpose (distributions that used to use this
now use pulseaudio to accomplish multiplexing streams to a single hardware
device).
it is certainly possible to play streams to multiple devices at once, but
if you expect utilities like aplay to do this correctly on an arbitrary
system, you are mistaken. your problems could be in the ALSA dmix layer, or
your kernel or your overall system configuration (see, for example, this
list of problem areas:
http://manual.ardour.org/setting-up-your-system/the-right-computer-system-f…
)
you haven't really described what your application area is, but if it
involves multiple appplications sharing an audio device and using low
latency, then i think most people would suggest you look into JACK, either
to use it directly or as a code model (remembering, however, that is is
released under the GPL).
22 Oct
22 Oct
11:39 a.m.
Hello,
On 10/21/2014 04:11 PM, Paul Davis wrote:
testing this configuration using aplay doesn't make any sense. you
apparently believe that getting glitch-free audio playback is a
trivial task ... it isn't unless you are prepared to use a lot of
buffering (which is what happens in a lot of consumer-ish software.
I've used
aplay just for an example, we have a software application
where it behaves the same way.
you are also attempting to use ALSA dmix facilities, which is not
recommended by anyone for any purpose (distributions that used to use
this now use pulseaudio to accomplish multiplexing streams to a single
hardware device).
it is certainly possible to play streams to multiple devices at once,
but if you expect utilities like aplay to do this correctly on an
arbitrary system, you are mistaken. your problems could be in the ALSA
dmix layer, or your kernel or your overall system configuration (see,
for example, this list of problem areas:
http://manual.ardour.org/setting-up-your-system/the-right-computer-system-f…)
dmixing is no problem on MB Intel HDA sound device, but I know that
there should be a difference in setting up a professional audio device
you haven't really described what your application area is, but if it
involves multiple appplications sharing an audio device and using low
latency, then i think most people would suggest you look into JACK,
either to use it directly or as a code model (remembering, however,
that is is released under the GPL).
we have a bad experience with Jack: we were
running jack on a computer
with external and internal sound cards simultaneously. Jack was
complaining that there is no clock sync (since there is no clock sync
possibility on internal HDA / sound blaster sound cards).
Thank you for your ideas.
Vaclav
12:04 p.m.
On Wed, 2014-10-22 at 11:39 +0200, Vaclav Mach wrote:.
we have a bad experience with Jack: we were running
jack on a computer
with external and internal sound cards simultaneously. Jack was
complaining that there is no clock sync (since there is no clock sync
possibility on internal HDA / sound blaster sound cards).
"when combining sound cards wich do not have a common word clock" -
http://kokkinizita.linuxaudio.org/linuxaudio/zita-resampler/resampler.html
Perhaps I misunderstood it, but perhaps this can be used to solve this
issue?
2:17 p.m.
On Wed, Oct 22, 2014 at 5:39 AM, Vaclav Mach <vaclav.mach(a)artisys.aero>
wrote:
we have a bad experience with Jack: we were running jack on a computer
with external and internal sound cards simultaneously. Jack was
complaining that there is no clock sync (since there is no clock sync
possibility on internal HDA / sound blaster sound cards).
sure, but this doesn't have anything to do with your current issue or the
system design you are using.
JACK is perfectly capable of using any number of audio interfaces whether
they are clock synced or not. It just isn't a good idea and isn't how a
professional system would be built. It also isn't done by using the -P and
-C arguments to the backend, because this doesn't do any resampling to keep
the streams synchronized, but by using bridge clients like zita_a2j.
6:23 p.m.
On Wed, 2014-10-22 at 08:17 -0400, Paul Davis wrote:
JACK is perfectly capable of using any number of audio
interfaces
whether they are clock synced or not. It just isn't a good idea and
isn't how a professional system would be built. It also isn't done by
using the -P and -C arguments to the backend, because this doesn't do
any resampling to keep the streams synchronized, but by using bridge
clients like zita_a2j.
http://kokkinizita.linuxaudio.org/linuxaudio/zita-ajbridge-doc/quickguide.h… which needs
zita-resampler.
Indeed, it sounds confusing to read that somebody wants to use RME audio
gear and internal HDA / sound blaster sound cards at the same time. For
language laboratory usage there might be the need to have as much IOs as
possible, without taking care about the quality, but for common audio
production we likely would use the RME gear and disable on-board audio
and similar crappy devices.
23 Oct
23 Oct
12:36 p.m.
Does JACK cause any additional buffering/latency in the signal flow in
comparison with pure ALSA? We have to take care of the lowest latency as
possible.
On 10/22/2014 02:17 PM, Paul Davis wrote:
On Wed, Oct 22, 2014 at 5:39 AM, Vaclav Mach <vaclav.mach(a)artisys.aero
<mailto:vaclav.mach@artisys.aero>> wrote:
we have a bad experience with Jack: we were running jack on a computer
with external and internal sound cards simultaneously. Jack was
complaining that there is no clock sync (since there is no clock sync
possibility on internal HDA / sound blaster sound cards).
sure, but this doesn't have anything to do with your current issue or
the system design you are using.
JACK is perfectly capable of using any number of audio interfaces
whether they are clock synced or not. It just isn't a good idea and
isn't how a professional system would be built. It also isn't done by
using the -P and -C arguments to the backend, because this doesn't do
any resampling to keep the streams synchronized, but by using bridge
clients like zita_a2j.
3:37 p.m.
On Thu, Oct 23, 2014 at 6:36 AM, Vaclav Mach <vaclav.mach(a)artisys.aero>
wrote:
Does JACK cause any additional buffering/latency in
the signal flow in
comparison with pure ALSA? We have to take care of the lowest latency as
possible.
http://jackaudio.org/faq/no_extra_latency.html
21 Oct
21 Oct
4:54 p.m.
Vaclav Mach wrote:
We try to utilize RME RayDat sound device on Linux
system with ALSA
sound interface.
General task of our troubleshooting is that our audio signal output is
not continuous. The output signal is rather interrupted.
PC
x86?
pcm.out_dmix {
type dmix
slave {
period_size 2048
Try using other values.
...
}
pcm.out_test {
type plug
slave.pcm "out_dmix"
ttable.0.0 1
}
pcm.out_test2 {
type route
slave.pcm "out_dmix"
ttable.0.1 1
}
Do you need to mix multiple signals into a single channel? If not, try
using dshare instead:
pcm_slave.out_slave {
pcm "hw:2,0"
channels 36
# ...
}
pcm.out1 {
type plug
slave.pcm {
type dshare
ipc_key 56874
slave out_slave
bindings [ 0 ]
}
}
pcm.out2 {
type plug
slave.pcm {
type dshare
ipc_key 56874
slave out_slave
bindings [ 1 ]
}
}
Regards,
Clemens
22 Oct
22 Oct
11:45 a.m.
Hi,
thanks for your suggestion with dshare. It solved half of our problems.
I can play different sounds on different channels, but I still need to
capture input sounds simultaneously, which is now not possible (device
is busy).
We use x86_64 systems.
And using other period size value I described in my previous reply.
Vaclav
On 10/21/2014 04:54 PM, Clemens Ladisch wrote:
Vaclav Mach wrote:
We try to utilize RME RayDat sound device on
Linux system with ALSA
sound interface.
General task of our troubleshooting is that our audio signal output is
not continuous. The output signal is rather interrupted.
PC
x86?
pcm.out_dmix {
type dmix
slave {
period_size 2048
Try using other values.
...
}
pcm.out_test {
type plug
slave.pcm "out_dmix"
ttable.0.0 1
}
pcm.out_test2 {
type route
slave.pcm "out_dmix"
ttable.0.1 1
}
Do you need to mix multiple signals into a single channel? If not, try
using dshare instead:
pcm_slave.out_slave {
pcm "hw:2,0"
channels 36
# ...
}
pcm.out1 {
type plug
slave.pcm {
type dshare
ipc_key 56874
slave out_slave
bindings [ 0 ]
}
}
pcm.out2 {
type plug
slave.pcm {
type dshare
ipc_key 56874
slave out_slave
bindings [ 1 ]
}
}
Regards,
Clemens
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
21 Oct
21 Oct
5:37 p.m.
Hi,
I've been using RME Raydat for avout 2 years, and it works very well for
me.
First of all I only use Jack to make all my audio stuff.
I'm using Fedora 20 for x86_64, stock kernel with some configuration; my
kernel command line has these extra options: pcie_aspm=off threadirqs
i915.enable_rc6=0
I added the rtirq package to set irq priorities. I'm running jack at 60
priority 512 buffer 2 periods 44100 sampling frequency.
I get rare XRuns, usually when I start or close programs.
I use the builtin RME matrix mixer to monitor incoming signals, so
latency is not important to me.
When I use some virtual instrument I set the buffer at 256, I get some
more XRun of course... I also switch to the performance governor in that
case.
Pulseaudio is disabled.
And no custom ALSA configuration at all, IMHO Jack is a must to work
with multichannel cards.
Ciao
Guido
5:46 p.m.
On Tue, 2014-10-21 at 17:36 +0200, Guido Aulisi wrote:
I'm using Fedora 20 for x86_64, stock kernel with
some configuration; my
kernel command line has these extra options: pcie_aspm=off threadirqs
i915.enable_rc6=0
I added the rtirq package to set irq priorities.
Hi,
I don't know the "stock" Fedora kernel, but "threadirqs" and
"rtirq"
sounds like a full preempted kernel, AFAIK those have no effect when
using a vanilla kernel, compiled with settings that are common for other
distro's default kernels.
Regards,
Ralf
6 p.m.
Threadirq works with vanilla kernels.
In the kernel docs:
threadirqs [KNL]
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
And with rtirq I can set priorities for the card.
It's not an RT kernel, vanilla kernels have now some "RT" features built
in now.
Fedora doesn't ship an RT kernel, you have to use the one from ccrma,
but I had more problems with that kernel in the past.
Il giorno mar, 21/10/2014 alle 17.46 +0200, Ralf Mardorf ha scritto:
On Tue, 2014-10-21 at 17:36 +0200, Guido Aulisi
wrote:
I'm using Fedora 20 for x86_64, stock kernel
with some configuration; my
kernel command line has these extra options: pcie_aspm=off threadirqs
i915.enable_rc6=0
I added the rtirq package to set irq priorities.
Hi,
I don't know the "stock" Fedora kernel, but "threadirqs" and
"rtirq"
sounds like a full preempted kernel, AFAIK those have no effect when
using a vanilla kernel, compiled with settings that are common for other
distro's default kernels.
Regards,
Ralf
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
6:16 p.m.
On Tue, 2014-10-21 at 17:52 +0200, Guido Aulisi wrote:
Threadirq works with vanilla kernels.
In the kernel docs:
threadirqs [KNL]
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
But does it cause a noticeable improvement? Since you're using it the
answer likely is, that it does ;). I'll test it :).
It's not an RT kernel
Yes, but there are different increments of preemption available,
depending on the settings when you compile a vanilla kernel ...or I'm
mistaken? Are those settings only available for rt patched kernels?
[rocketmouse@archlinux ~]$ uname -r
3.16.4-1-ARCH
[rocketmouse@archlinux ~]$ zgrep PREE /proc/config.gz
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
[rocketmouse@archlinux ~]$ grep PREE /usr/src/linux-3.10.47-rt50-1-rt-lts/.config
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RT_BASE=y
CONFIG_HAVE_PREEMPT_LAZY=y
CONFIG_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT__LL is not set
# CONFIG_PREEMPT_RTB is not set
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
Ok, full preempt seems to need the rt patch.
Hm?
http://stackoverflow.com/questions/21997122/linux-kernel-preemption-levels
7:42 p.m.
Il giorno mar, 21/10/2014 alle 18.15 +0200, Ralf Mardorf ha scritto:
These are the settings of my kernel:
# CONFIG_PREEMPT_RCU is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
IMHO you don't need an RT kernel if you don't make massive use of soft
synths, because you can increase jack buffering and monitor using RME
internal mixer. I occasionally only use setBfree (I have some xruns, but
they didn't turn in some click noise), Zynaddsubfx, phasex. All other
sources are external.
Ciao
Guido
On Tue, 2014-10-21 at 17:52 +0200, Guido Aulisi
wrote:
Yes it does improve... of course you have to assign priorities and
rtirq does that for you. This is an example of process list for the
driver:
root 458 2 458 1 FF 109 16:24 ? 00:00:36 [irq/18-snd_hdsp]
Threadirq works with vanilla kernels.
In the kernel docs:
threadirqs [KNL]
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
But does it cause a noticeable improvement? Since you're using it the
answer likely is, that it does ;). I'll test it :).
It's not
an RT kernel
Yes, but there are different increments of preemption available,
depending on the settings when you compile a vanilla kernel ...or I'm
mistaken? Are those settings only available for rt patched kernels?
[rocketmouse@archlinux ~]$ uname -r
3.16.4-1-ARCH
[rocketmouse@archlinux ~]$ zgrep PREE /proc/config.gz
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
[rocketmouse@archlinux ~]$ grep PREE /usr/src/linux-3.10.47-rt50-1-rt-lts/.config
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RT_BASE=y
CONFIG_HAVE_PREEMPT_LAZY=y
CONFIG_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT__LL is not set
# CONFIG_PREEMPT_RTB is not set
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
Ok, full preempt seems to need the rt patch.
Hm?
http://stackoverflow.com/questions/21997122/linux-kernel-preemption-levels
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
8:01 p.m.
OT:
On Tue, 2014-10-21 at 19:42 +0200, Guido Aulisi wrote:
phasex
Did you apply Fons' DC offset fix? Until now I didn't tested it, but it
likely is better to compile phasex with Fons' patches.
http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-August/098653.h…
https://github.com/williamweston/phasex/issues/10
Sorry for the OT, but just in case that Fedora might not have applied
it, I guess it's worse to mention it.
Regards,
Ralf
PS: The RT patch is also useful when using MIDI with external MIDI gear,
that's why I compile RT kernels, MIDI jitter is a PITA.
8:19 p.m.
On Tue, 2014-10-21 at 20:04 +0200, Ralf Mardorf wrote:
On Tue, 2014-10-21 at 20:01 +0200, Ralf Mardorf
wrote:
I couldn't resist: Loriot Die Inhaltsangabe
http://www.youtube.com/watch?v=ZygK3yvUee4
Sorry for the OT, but just in case that Fedora
might not have applied
it, I guess it's worse to mention it.
^^^^^ worth (Germans
don't know a voiceless tea-age ;)
11 p.m.
Il giorno mar, 21/10/2014 alle 20.01 +0200, Ralf Mardorf ha scritto:
OT:
On Tue, 2014-10-21 at 19:42 +0200, Guido Aulisi wrote:
No, I didn't. I didn't notice the problem. I only used it for arpeggios.
My favourite soft "synth" is setBfree, it's the one I use mostly.
Ciao
Guido
phasex
Did you apply Fons' DC offset fix? Until now I didn't tested it, but it
likely is better to compile phasex with Fons' patches.
3737
days inactive
3739
days old
linux-audio-user@lists.linuxaudio.org
20 comments
6 participants
participants (6)
-
Clemens Ladisch -
Florian Paul Schmidt -
Guido Aulisi -
Paul Davis -
Ralf Mardorf -
Vaclav Mach