Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
audio dropouts still
71 views
Skip to first unread message
Zenaan Harkness
Jan 9, 2014, 7:50:01 PM1/9/14
to
Now I have a "simple" audio setup, and still getting dropouts:
$ ps x | egrep -vi disk\|gvfs | egrep alsa\|jack\|pulse\|mix\|vol\|aqu
3946 ? Ssl 0:00 xfce4-volumed
7849 pts/17 SLl 0:14 qjackctl
7854 ? SLsl 0:34 /usr/bin/jackd -dalsa -dhw:PCH -r44100
-p1024 -n2 -D -Phw:PCH,7
7865 pts/17 SLl 0:22 /usr/bin/alsa_in -j cloop -d cloop -q 1
7866 pts/17 SLl 0:17 /usr/bin/alsa_out -j ploop -d ploop -q 1
7867 pts/17 SLl 1:21 python /usr/bin/jack_mixer
9504 tty1 SLl 0:31 aqualung
There are NO jackd XRUNs (now that I've upped -p anyway).
The drop outs sound like they go for around 50-150ms, I can't be sure.
They 'sound' like there's a bit of fading going on, rather than a full drop out.
Perhaps there's some sort of bit-rate conversion library which is
running out of data?
I would like some suggestions on approaches to debugging this. Willing
to learn :)
TIA
Zenaan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAOsGNST3rHJxgwSRa8F8ssky...@mail.gmail.com
$ ps x | egrep -vi disk\|gvfs | egrep alsa\|jack\|pulse\|mix\|vol\|aqu
3946 ? Ssl 0:00 xfce4-volumed
7849 pts/17 SLl 0:14 qjackctl
7854 ? SLsl 0:34 /usr/bin/jackd -dalsa -dhw:PCH -r44100
-p1024 -n2 -D -Phw:PCH,7
7865 pts/17 SLl 0:22 /usr/bin/alsa_in -j cloop -d cloop -q 1
7866 pts/17 SLl 0:17 /usr/bin/alsa_out -j ploop -d ploop -q 1
7867 pts/17 SLl 1:21 python /usr/bin/jack_mixer
9504 tty1 SLl 0:31 aqualung
There are NO jackd XRUNs (now that I've upped -p anyway).
The drop outs sound like they go for around 50-150ms, I can't be sure.
They 'sound' like there's a bit of fading going on, rather than a full drop out.
Perhaps there's some sort of bit-rate conversion library which is
running out of data?
I would like some suggestions on approaches to debugging this. Willing
to learn :)
TIA
Zenaan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAOsGNST3rHJxgwSRa8F8ssky...@mail.gmail.com
Ralf Mardorf
Jan 9, 2014, 7:50:01 PM1/9/14
to
CPU frequency scaling has to be set to a fixed frequency, e.g. to
performance. Ondemand likely will cause audio glitches, that might not
be visible as xruns.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1389314776.5017.196.camel@archlinux
performance. Ondemand likely will cause audio glitches, that might not
be visible as xruns.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Zenaan Harkness
Jan 10, 2014, 7:10:01 AM1/10/14
to
On 1/10/14, Ralf Mardorf <ralf.m...@alice-dsl.net> wrote:
> CPU frequency scaling has to be set to a fixed frequency, e.g. to
> performance. Ondemand likely will cause audio glitches, that might not
> be visible as xruns.
That makes sense. Thank you for the suggestion.
> CPU frequency scaling has to be set to a fixed frequency, e.g. to
> performance. Ondemand likely will cause audio glitches, that might not
> be visible as xruns.
I've
* installed and read about cpufreqd and cpufreqtools;
* battled with gnome-panel to try the gnome-applets
/usr/lib/gnome-applets/cpufreq-applet (dunno, but it looks like it's
not one of the three "cpu" type applets which XFCE allows me to
install in my xfce4-panel) - gnome-panel sat on top of xfce4-panel,
and killing it it kept coming back from the grave - finally brought up
"Settings -> Session -> Session" from xfce4 desktop menu (luckily
enabled), since my xfce4 panel was hidden, and killed gnome-panel from
there;
* I have three applets installed on my xfce4-panel:
"CPU Graph"
"System Load Monitor"
"CPU Frequency Monitor"
This last one, when I click on it, brings up "CPU Information" window
which allows me to choose from available frequencies for each cpu (it
seems), and also allows (it seems) for me to change the governor
between "performance" and "powersave", per-cpu (it seems).
It looks as though I should be able to set one of the CPU's to a
higher frequency;
in any case, each time I close the window, and bring it back up, my
"settings" are not in effect.
* read this page:
https://wiki.debian.org/HowTo/CpuFrequencyScaling
which possibly relates to older kernels? I'm running sid - uname -a:
Linux x220a02 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux
and now trying the last link on that Debian web page - Arch linux info.
I would like to know if I can choose to set the CPU cores, at least
one of them, to a fixed frequency, say 1.5GHz. Is this possible?
Otherwise, is there another web page I might read to figure out how to
actually control what my CPUs are doing, from an
audio-glitches-minimization perspective?
Thanks again
Zenaan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Zenaan Harkness
Jan 10, 2014, 7:20:02 AM1/10/14
to
On 1/10/14, Zenaan Harkness <z...@freedbms.net> wrote:
> On 1/10/14, Ralf Mardorf <ralf.m...@alice-dsl.net> wrote:
>> CPU frequency scaling has to be set to a fixed frequency, e.g. to
>> performance. Ondemand likely will cause audio glitches, that might not
>> be visible as xruns.
>
> That makes sense. Thank you for the suggestion.
>
> I've
> * installed and read about cpufreqd and cpufreqtools;
> On 1/10/14, Ralf Mardorf <ralf.m...@alice-dsl.net> wrote:
>> CPU frequency scaling has to be set to a fixed frequency, e.g. to
>> performance. Ondemand likely will cause audio glitches, that might not
>> be visible as xruns.
>
> That makes sense. Thank you for the suggestion.
>
> I've
> * installed and read about cpufreqd and cpufreqtools;
> * I have three applets installed on my xfce4-panel:
> "CPU Frequency Monitor"
> This last one, when I click on it, brings up "CPU Information" window
> which allows me to choose from available frequencies for each cpu (it
> seems), and also allows (it seems) for me to change the governor
> between "performance" and "powersave", per-cpu (it seems).
> It looks as though I should be able to set one of the CPU's to a
> higher frequency;
> in any case, each time I close the window, and bring it back up, my
> "settings" are not in effect.
PS, the CPU frequencies as advertised by CPU Frequency Monitor pop-up
> This last one, when I click on it, brings up "CPU Information" window
> which allows me to choose from available frequencies for each cpu (it
> seems), and also allows (it seems) for me to change the governor
> between "performance" and "powersave", per-cpu (it seems).
> It looks as though I should be able to set one of the CPU's to a
> higher frequency;
> in any case, each time I close the window, and bring it back up, my
> "settings" are not in effect.
window (and in the panel itself) don't match the output of
"cpufreq-info" on command line. I must be doing something wrong...
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Jan 10, 2014, 8:00:01 AM1/10/14
to
Those panel things could work, sometimes you need to set up policy rules
or to set an evil bit ;), aka suid.
I use the command line, resp. scripts, without tools, so I don't need to
care for distro specific commands:
$ grep performance /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:performance
$ echo -n ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null
$ grep -v performance /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1389358638.5017.241.camel@archlinux
or to set an evil bit ;), aka suid.
I use the command line, resp. scripts, without tools, so I don't need to
care for distro specific commands:
$ grep performance /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:performance
$ echo -n ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null
$ grep -v performance /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Jan 10, 2014, 8:50:03 AM1/10/14
to
On Fri, 2014-01-10 at 23:14 +1100, Zenaan Harkness wrote:
> PS, the CPU frequencies as advertised by CPU Frequency Monitor pop-up
> window (and in the panel itself) don't match the output of
> "cpufreq-info" on command line. I must be doing something wrong...
You can trust cpufreq-info. I don't use this and equivalent tools
> PS, the CPU frequencies as advertised by CPU Frequency Monitor pop-up
> window (and in the panel itself) don't match the output of
> "cpufreq-info" on command line. I must be doing something wrong...
anymore, but I always install them.
Those command line tools simply read, monitor, edit:
[rocketmouse@archlinux ~]$ ls /mnt/debi386/sys
No output, since Debian isn't running, but it should be equal too:
[rocketmouse@archlinux ~]$ ls /sys/devices/system/cpu/cpu*/cpufreq/
/sys/devices/system/cpu/cpu0/cpufreq/:
affected_cpus cpuinfo_max_freq related_cpus scaling_cur_freq scaling_max_freq
bios_limit cpuinfo_min_freq scaling_available_frequencies scaling_driver scaling_min_freq
cpuinfo_cur_freq cpuinfo_transition_latency scaling_available_governors scaling_governor scaling_setspeed
/sys/devices/system/cpu/cpu1/cpufreq/:
affected_cpus cpuinfo_max_freq related_cpus scaling_cur_freq scaling_max_freq
bios_limit cpuinfo_min_freq scaling_available_frequencies scaling_driver scaling_min_freq
cpuinfo_cur_freq cpuinfo_transition_latency scaling_available_governors scaling_governor scaling_setspeed
A Fake :D, so it's the same for Debian ;) ... :D ...:
[rocketmouse@archlinux ~]$ sudo systemd-nspawn -D /mnt/debi386
Spawning namespace container on /mnt/debi386 (console is /dev/pts/1).
Init process in the container running as PID 12742.
root@debi386:~# ls /sys/devices/system/cpu/cpu*/cpufreq/
/sys/devices/system/cpu/cpu0/cpufreq/:
affected_cpus cpuinfo_max_freq related_cpus scaling_cur_freq scaling_max_freq
bios_limit cpuinfo_min_freq scaling_available_frequencies scaling_driver scaling_min_freq
cpuinfo_cur_freq cpuinfo_transition_latency scaling_available_governors scaling_governor scaling_setspeed
/sys/devices/system/cpu/cpu1/cpufreq/:
affected_cpus cpuinfo_max_freq related_cpus scaling_cur_freq scaling_max_freq
bios_limit cpuinfo_min_freq scaling_available_frequencies scaling_driver scaling_min_freq
cpuinfo_cur_freq cpuinfo_transition_latency scaling_available_governors scaling_governor scaling_setspeed
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Jan 10, 2014, 9:00:04 AM1/10/14
to
PPS: That the panel thingy doesn't work likely is cause by a policy
issue. OTOH monitoring/reading should work, just switching between
governors tends to be a PITA.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1389361824.5017.253.camel@archlinux
issue. OTOH monitoring/reading should work, just switching between
governors tends to be a PITA.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Klaus
Jan 10, 2014, 9:20:03 AM1/10/14
to
On 10/01/14 00:40, Zenaan Harkness wrote:
> Now I have a "simple" audio setup, and still getting dropouts:
>
> $ ps x | egrep -vi disk\|gvfs | egrep alsa\|jack\|pulse\|mix\|vol\|aqu
> 3946 ? Ssl 0:00 xfce4-volumed
>
> 7849 pts/17 SLl 0:14 qjackctl
>
> 7854 ? SLsl 0:34 /usr/bin/jackd -dalsa -dhw:PCH -r44100
> -p1024 -n2 -D -Phw:PCH,7
>
> 7865 pts/17 SLl 0:22 /usr/bin/alsa_in -j cloop -d cloop -q 1
>
> 7866 pts/17 SLl 0:17 /usr/bin/alsa_out -j ploop -d ploop -q 1
>
> 7867 pts/17 SLl 1:21 python /usr/bin/jack_mixer
>
> 9504 tty1 SLl 0:31 aqualung
>
>
> There are NO jackd XRUNs (now that I've upped -p anyway).
>
> The drop outs sound like they go for around 50-150ms, I can't be sure.
>
> They 'sound' like there's a bit of fading going on, rather than a full drop out.
>
> Perhaps there's some sort of bit-rate conversion library which is
> running out of data?
>
> I would like some suggestions on approaches to debugging this. Willing
> to learn :)
>
> TIA
> Zenaan
>
>
Zenaan
> Now I have a "simple" audio setup, and still getting dropouts:
>
> $ ps x | egrep -vi disk\|gvfs | egrep alsa\|jack\|pulse\|mix\|vol\|aqu
> 3946 ? Ssl 0:00 xfce4-volumed
>
> 7849 pts/17 SLl 0:14 qjackctl
>
> 7854 ? SLsl 0:34 /usr/bin/jackd -dalsa -dhw:PCH -r44100
> -p1024 -n2 -D -Phw:PCH,7
>
> 7865 pts/17 SLl 0:22 /usr/bin/alsa_in -j cloop -d cloop -q 1
>
> 7866 pts/17 SLl 0:17 /usr/bin/alsa_out -j ploop -d ploop -q 1
>
> 7867 pts/17 SLl 1:21 python /usr/bin/jack_mixer
>
> 9504 tty1 SLl 0:31 aqualung
>
>
> There are NO jackd XRUNs (now that I've upped -p anyway).
>
> The drop outs sound like they go for around 50-150ms, I can't be sure.
>
> They 'sound' like there's a bit of fading going on, rather than a full drop out.
>
> Perhaps there's some sort of bit-rate conversion library which is
> running out of data?
>
> I would like some suggestions on approaches to debugging this. Willing
> to learn :)
>
> TIA
> Zenaan
>
>
this war against audio drop-outs ;-) has a long-standing history. Look
through a few "audiophile" sites and fora. Keywords like realtime
kernel, low latency, ... sadly, lots of out-of-date stuff.
I'm watching this thread eagerly since my dedicated little MPD server
has occasional hiccups as well. Note that so far I haven't noticed a
correlation between absolute CPU power and drop-outs: whether MPD runs
on a desktop pc, a relatively modern ARM board (Mele A2000), or even the
good ol' slug (Linksys NSLU2), there are drop-out every now and than
(about one or two an hour).
If anybody else here knew how to debug this further, say eg. how to
identify and then log these occasional events, and then try and see what
else the system is doing at that moment, that'll be fantastic. These
drop-out last for far less than a second, ie. manual detection is almost
impossible. (Beyond hearing them, obviously :-)
PS. 'dedicated' above means that I've removed everything I could from
the system except those bits that are needed for mounting an NFS share,
running MPD, and piping the digital stream directly (ie. via ALSA) to
the output (S/PDIF in my case, with an external DAC). No re-encoding,
re-sampling or re-formating. Currently this is on the Mele box, running
headless, wheezy, kernel 3.0.
--
Klaus
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Jan 10, 2014, 9:30:02 AM1/10/14
to
Klaus you are mistaken.
On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
> correlation between absolute CPU power and drop-outs
The issues Zenaan does experience are likely related to jackd, a sound
server that cares about sample accuracy [1].
When using jackd, CPU frequency scaling does matter a lot!
If you don't believe a professional audio engineer using Linux audio
since around 10 years, perhaps a Linux audio link is able to enlighten
you.
"CPU frequency scaling daemons that scale the frequency of the CPU
depending on the CPU load could cause xruns in some cases. More recent
versions of Jack1 (>= 0.118.0) are suffering less from xruns or run xrun
free with a CPU frequency scaling daemon enabled that's set to a scaling
governor like ondemand. A specialized CPU scaling daemon is in the works
that depends on the DSP-load instead of the CPU load: jackfreqd" -
http://wiki.linuxaudio.org/wiki/system_configuration
[1]
-------- Forwarded Message --------
From: Ralf Mardorf <ralf.m...@alice-dsl.net>
To: debia...@lists.debian.org
Subject: Re: going mad - starting jackd starts pulseaudio
Date: Fri, 10 Jan 2014 09:35:19 +0100
Mailer: Evolution 3.10.3
JFTR some users might find setting up jackd to complicated, but jackd
provides advantages, e.g. "Within software, jackd provides
sample-accurate synchronization between all JACK applications." -
http://manual.ardour.org/synchronization/on-clock-and-time/
This does mean, that signals are not out-of-phase, so there won't be
unwanted filtering effects.
The easiness of other sound servers comes at a price.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1389364013.13250.5.camel@archlinux
On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
> correlation between absolute CPU power and drop-outs
server that cares about sample accuracy [1].
When using jackd, CPU frequency scaling does matter a lot!
If you don't believe a professional audio engineer using Linux audio
since around 10 years, perhaps a Linux audio link is able to enlighten
you.
"CPU frequency scaling daemons that scale the frequency of the CPU
depending on the CPU load could cause xruns in some cases. More recent
versions of Jack1 (>= 0.118.0) are suffering less from xruns or run xrun
free with a CPU frequency scaling daemon enabled that's set to a scaling
governor like ondemand. A specialized CPU scaling daemon is in the works
that depends on the DSP-load instead of the CPU load: jackfreqd" -
http://wiki.linuxaudio.org/wiki/system_configuration
[1]
-------- Forwarded Message --------
From: Ralf Mardorf <ralf.m...@alice-dsl.net>
To: debia...@lists.debian.org
Subject: Re: going mad - starting jackd starts pulseaudio
Date: Fri, 10 Jan 2014 09:35:19 +0100
Mailer: Evolution 3.10.3
JFTR some users might find setting up jackd to complicated, but jackd
provides advantages, e.g. "Within software, jackd provides
sample-accurate synchronization between all JACK applications." -
http://manual.ardour.org/synchronization/on-clock-and-time/
This does mean, that signals are not out-of-phase, so there won't be
unwanted filtering effects.
The easiness of other sound servers comes at a price.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Klaus
Jan 10, 2014, 10:00:02 AM1/10/14
to
On 10/01/14 14:26, Ralf Mardorf wrote:
> Klaus you are mistaken.
>
> On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
>> correlation between absolute CPU power and drop-outs
>
> The issues Zenaan does experience are likely related to jackd, a sound
> server that cares about sample accuracy [1].
>
> When using jackd, CPU frequency scaling does matter a lot!
>
> If you don't believe a professional audio engineer using Linux audio
> since around 10 years, perhaps a Linux audio link is able to enlighten
> you.
>
Ralf, not sure how I deserved this outbreak.
> Klaus you are mistaken.
>
> On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
>> correlation between absolute CPU power and drop-outs
>
> The issues Zenaan does experience are likely related to jackd, a sound
> server that cares about sample accuracy [1].
>
> When using jackd, CPU frequency scaling does matter a lot!
>
> If you don't believe a professional audio engineer using Linux audio
> since around 10 years, perhaps a Linux audio link is able to enlighten
> you.
>
What I added to this thread is that even with a whittled down system (in
this case: no jackd, no pulseaudio), audio drop-out can still happen. As
far as I'm aware of, Zenaan has not tested -- or reported about his
tests of -- the most minimalist system. Are you saying that adding jackd
on top of Alsa can potentially avoid those underlying issues? I'm all ears!
--
Klaus
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Jan 10, 2014, 10:00:02 AM1/10/14
to
On Fri, 2014-01-10 at 11:40 +1100, Zenaan Harkness wrote:
> There are NO jackd XRUNs (now that I've upped -p anyway).
Audible glitches are not always shown as xruns and xruns often are not
> There are NO jackd XRUNs (now that I've upped -p anyway).
audible ;).
For some devices it does help to increase -n from 2 to 3.
Note! I'm using professional gear, not even prosumer gear, that's why
asked the following question, I always stay with the default -n 2:
http://lists.linuxaudio.org/pipermail/linux-audio-user/2013-December/095401.html
I often read that people are more lucky when using -n3 also for elCheapo
onboard devices and PCI sound cards, that's why I asked about a myth.
Testing -n 3 doesn't harm.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Jan 10, 2014, 10:10:02 AM1/10/14
to
Zenaan experience issues while using jackd. I simply corrected your
assumption Klaus, it wasn't an outbreak. It's _likely_, no more, no
less, that the used governor does cause the glitches.
"this war against audio drop-outs ;-) has a long-standing history" -
Klaus
It's not a war and I'm not aware about a history. Jack simply tends to
cause issues when not using a fixed CPU freq scaling.
Perhaps Jack provides a quality not everybody needs, but when using
Jack, you need to optimise your setup, but after doing this, you'll run
a better and less painful sound server, than all those consumer usage
desktop sound servers.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1389366259.13250.22.camel@archlinux
assumption Klaus, it wasn't an outbreak. It's _likely_, no more, no
less, that the used governor does cause the glitches.
"this war against audio drop-outs ;-) has a long-standing history" -
Klaus
It's not a war and I'm not aware about a history. Jack simply tends to
cause issues when not using a fixed CPU freq scaling.
Perhaps Jack provides a quality not everybody needs, but when using
Jack, you need to optimise your setup, but after doing this, you'll run
a better and less painful sound server, than all those consumer usage
desktop sound servers.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Zenaan Harkness
Jan 10, 2014, 10:40:02 AM1/10/14
to
On 1/11/14, Ralf Mardorf <ralf.m...@alice-dsl.net> wrote:
> Klaus you are mistaken.
>
> On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
>> correlation between absolute CPU power and drop-outs
>
> The issues Zenaan does experience are likely related to jackd, a sound
> server that cares about sample accuracy [1].
Could be, but before jackd, I was running pulseaudio, and had the same
> Klaus you are mistaken.
>
> On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
>> correlation between absolute CPU power and drop-outs
>
> The issues Zenaan does experience are likely related to jackd, a sound
> server that cares about sample accuracy [1].
problems. So then I installed jackd and others, and went on my war of
stopping pulseaudio (succeeded),
but now, the exact same problem (at least audibly as far as I can tell)!
So this problem (to my ears) sounds identical with pulseaudio, as with jackd.
Perhaps I could test alsaplayer, direct to hardware, from command line
(even no X running), no jackd (don't start it, and check to make sure
it's not running), no pulseaudio (got this one handled now :)
I shall try when I can afford the workstation downtime - but an hour
is usually heaps of time, so I can put on some peaceful reading music,
easy to hear glitches in :)
> When using jackd, CPU frequency scaling does matter a lot!
(eg pulseaudio, or mpd) too yes?
> If you don't believe a professional audio engineer using Linux audio
> since around 10 years, perhaps a Linux audio link is able to enlighten
> you.
>
> "CPU frequency scaling daemons that scale the frequency of the CPU
> depending on the CPU load could cause xruns in some cases. More recent
> versions of Jack1 (>= 0.118.0) are suffering less from xruns or run xrun
> free with a CPU frequency scaling daemon enabled that's set to a scaling
> governor like ondemand. A specialized CPU scaling daemon is in the works
> that depends on the DSP-load instead of the CPU load: jackfreqd" -
> http://wiki.linuxaudio.org/wiki/system_configuration
in the "works" part of "in the works" is this jackfreqd ?
> JFTR some users might find setting up jackd to complicated, but jackd
> provides advantages, e.g. "Within software, jackd provides
> sample-accurate synchronization between all JACK applications." -
> http://manual.ardour.org/synchronization/on-clock-and-time/
> This does mean, that signals are not out-of-phase, so there won't be
> unwanted filtering effects.
> The easiness of other sound servers comes at a price.
Right now, I am driven by merely (very) audible and random but
consistently occurring, audio drop outs. For a modern machine,
something is really wrong if I can't play my music collection!
Thanks for all the pointers,
Zenaan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Klaus
Jan 10, 2014, 10:40:02 AM1/10/14
to
On 10/01/14 15:04, Ralf Mardorf wrote:
> It's not a war
that's what the ;-) smiley was for...
> It's not a war
> I'm not aware about a history.
time, no doubt you know for instance this (self-proclaimed) Classic
paper from 2000:
<http://wiki.linuxaudio.org/wiki/lowlatency_deprecated>
Searching Startpage.com for "linux audio drop-out" yields more than a
million hits.
--
Klaus
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Zenaan Harkness
Jan 10, 2014, 11:00:03 AM1/10/14
to
On 1/11/14, Klaus <klaus.do...@gmail.com> wrote:
> On 10/01/14 14:26, Ralf Mardorf wrote:
>> On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
>>> correlation between absolute CPU power and drop-outs
> On 10/01/14 14:26, Ralf Mardorf wrote:
>> On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
>>> correlation between absolute CPU power and drop-outs
> What I added to this thread is that even with a whittled down system (in
> this case: no jackd, no pulseaudio), audio drop-out can still happen. As
And thank you! This is interesting, and pertinent information, from my
> this case: no jackd, no pulseaudio), audio drop-out can still happen. As
perspective. I too am very keen to get to the bottom of this
apparently illogical problem.
> far as I'm aware of, Zenaan has not tested -- or reported about his
> tests of -- the most minimalist system.
report back. It's an important test.
(A completely unrelated anecdote, the Lenovo X220 laptop which is my
workstation at the moment, has built-in Intel analog audio line out,
and another in the docking station - there is a constant low-level
crackle on both lines (not noticeable when music is playing, but very
annoying when no other sounds are playing), which reflects also
whenever mouse is moved, and other events - clearly crap analog audio
subsystem somewhere; thankfully, the external monitor (displayport,
but appearing in alsa as eg "card 1: PCH [HDA Intel PCH], device 3:
HDMI 0 [HDMI 0]") routes audio, apparently digitally, and this has a
relatively very clean line! Still, I would have thought modern laptops
would have solved the audio out problem by now - evidently built in
audio is not driven by consumer demand enough.)
Thanks all,
Zenaan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Jan 10, 2014, 3:00:03 PM1/10/14
to
On Fri, 2014-01-10 at 15:30 +0000, Klaus wrote:
> no doubt you know for instance this (self-proclaimed) Classic
> paper from 2000:
> <http://wiki.linuxaudio.org/wiki/lowlatency_deprecated>
No, I didn't know this paper, but it reminds me to report an issue with
> no doubt you know for instance this (self-proclaimed) Classic
> paper from 2000:
> <http://wiki.linuxaudio.org/wiki/lowlatency_deprecated>
linux-rt within the next days. Instead of building a kernel, I installed
it from the Debian repositories. However, before reporting it, I'll test
a "normal" kernel from the repositories and I'll build a kernel-rt. Some
days ago I noticed something wicked regarding to IRQs.
However, Zenaan shouldn't need linux-rt or even a full preempt one.
Unfortunately he already experienced the same issues with pulseaudio, so
indeed, the issue isn't jackd related and indeed CPU frequency scaling
unlikely is the culprit.
On Sat, 2014-01-11 at 02:53 +1100, Zenaan Harkness wrote:
> A completely unrelated anecdote, the Lenovo X220 laptop which is my
> workstation at the moment, has built-in Intel analog audio line out,
> and another in the docking station - there is a constant low-level
> crackle on both lines (not noticeable when music is playing, but very
> annoying when no other sounds are playing), which reflects also
> whenever mouse is moved, and other events - clearly crap analog audio
> subsystem somewhere; thankfully, the external monitor (displayport,
> but appearing in alsa as eg "card 1: PCH [HDA Intel PCH], device 3:
> HDMI 0 [HDMI 0]") routes audio, apparently digitally, and this has a
> relatively very clean line! Still, I would have thought modern laptops
> would have solved the audio out problem by now - evidently built in
> audio is not driven by consumer demand enough.
mouse, is something that happens for prosumer and professional audio
cards too, not too much audible on sane levels, but it's there too. I
don't know how loud it's for onboard devices, since I disable onboard
sound. Hm, next time I'll listen if it affects my ADAT device too, in my
homestudio it's not much more than a meter away from the PC. I didn't
make music at home for a long time. Likely that even such an optically
connected, galvanically isolated device will suffer from digital
electric smog.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Zenaan Harkness
Jan 14, 2014, 8:30:02 PM1/14/14
to
On 1/11/14, Zenaan Harkness <z...@freedbms.net> wrote:
> On 1/11/14, Klaus <klaus.do...@gmail.com> wrote:
>> On 10/01/14 14:26, Ralf Mardorf wrote:
>>> On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
>>>> correlation between absolute CPU power and drop-outs
>
>> What I added to this thread is that even with a whittled down system (in
>> this case: no jackd, no pulseaudio), audio drop-out can still happen. As
>
> And thank you! This is interesting, and pertinent information, from my
> perspective. I too am very keen to get to the bottom of this
> apparently illogical problem.
>
>> far as I'm aware of, Zenaan has not tested -- or reported about his
>> tests of -- the most minimalist system.
>
> I shall do so at some point, hopefully in next day or three, and
> report back. It's an important test.
Haven't been able to test no-X environment, but the following may be
> On 1/11/14, Klaus <klaus.do...@gmail.com> wrote:
>> On 10/01/14 14:26, Ralf Mardorf wrote:
>>> On Fri, 2014-01-10 at 14:09 +0000, Klaus wrote:
>>>> correlation between absolute CPU power and drop-outs
>
>> What I added to this thread is that even with a whittled down system (in
>> this case: no jackd, no pulseaudio), audio drop-out can still happen. As
>
> And thank you! This is interesting, and pertinent information, from my
> perspective. I too am very keen to get to the bottom of this
> apparently illogical problem.
>
>> far as I'm aware of, Zenaan has not tested -- or reported about his
>> tests of -- the most minimalist system.
>
> I shall do so at some point, hopefully in next day or three, and
> report back. It's an important test.
of interest (still getting the dropouts):
I installed the latest 3.12-1-rt-amd64 (rt) kernel, with dist-upgrade
and reboot of course.
Reading some of the links provided in this thread, I note that
Debian's -rt kernel has:
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
rather than CONFIG_HZ=1000, which is strongly indicated/recommended in
some of the links provided, and by realtimeconfigquickscan.git
So it looks like we who like audio with reasonably low latency and
without dropouts, may be required to build our own kernels. I do
wonder what the purpose of the debian -rt kernel is... if it is
intended for audio, then a bug ought be filed, but I suspect not.
Now, for the most interesting thing, and I have not found the bug with
a google search, is zita-a2j (see package zita-ajbridge). I am running
zita-a2j as follows:
zita-a2j -j cloop -r 44100 -n 2 -c 2 -Q 1 -d hw:0 -v
and jackd appears as follows:
/usr/bin/jackd -dalsa -dhw:PCH -r44100 -p256 -n2 -D -Phw:PCH,7
When I run zita-a2j (to capture alsa clients and feed them to jack,
just like /usr/bin/alsa_in command) I haven't yet figured out why I'm
not getting audio from alsaplayer (with alsa backend), BUT, I do get
the following errors:
Alsa_pcmi: error on capture pollfd.
-1.458 1.000022 # this line is status output, not error
Starting synchronisation.
which appear every now and then; if I remove "-v" option, I just get
the "Starting synchronisation." messages.
The man page for zita-a2j has the following para:
When starting, and in case of major trouble, you will see the
'Starting synchronisation' message. This can happen if there is a
timeout on the Jack server, e.g. a client crashed or terminated in a
dirty way. Jack1 will skip one or more cycles when new apps are
started, or when a large number of port connections is done in a short
time. his may interrupt the audio signal, but should otherwise not
have any ill consequences nor require a restart.
So, we have an application, zita-a2j, which is consistently showing
_some_ output which _may_ correspond to the audio dropouts we are
hearing.
My next step is to get zita-a2j to actually work the same as alsa_in
command as in, to produce some audio through jack for me, so we can
hopefully correlate the auditory audio drop out, with these errors
(I'm hopeful).
Also, looks like I'll have to get back to compiling own kernel. We'll see.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Zenaan Harkness
Jan 14, 2014, 8:50:01 PM1/14/14
to
On 1/15/14, Zenaan Harkness <z...@freedbms.net> wrote:
> I installed the latest 3.12-1-rt-amd64 (rt) kernel, with dist-upgrade
> and reboot of course.
PS, btw, this kernel randomly fails to hibernate on me. I know that's
> I installed the latest 3.12-1-rt-amd64 (rt) kernel, with dist-upgrade
> and reboot of course.
another thread, and I may start one after some more testing. Just a
random data point in case its useful to anyone.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Jan 14, 2014, 9:20:01 PM1/14/14
to
Hi,
perhaps one of the maintainers mentioned at
http://packages.debian.org/wheezy/linux-image-rt-686-pae could add a few
notes.
On Wed, 2014-01-15 at 12:21 +1100, Zenaan Harkness wrote:
> I installed the latest 3.12-1-rt-amd64 (rt) kernel, with dist-upgrade
> and reboot of course.
>
> Reading some of the links provided in this thread, I note that
> Debian's -rt kernel has:
> CONFIG_HZ_250=y
> # CONFIG_HZ_300 is not set
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=250
This might be ok if the new full no HZ features are used and unlikely
will have impact to audio. For MIDI still hr timer/hpet does provide a
much higher resolution than just 1000 Hz, it's 1000000000 Hz. FWIW until
now no kernel-rt > 3.8 does work on my machine.
[rocketmouse@archlinux ~]$ grep HZ /mnt/debi386/boot/config-3.2.0-4-rt-686-pae
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
[rocketmouse@archlinux ~]$ grep CONFIG_NO_HZ_FULL /mnt/debi386/boot/config-3.2.0-4-rt-686-pae
Not available for this kernel version.
[rocketmouse@archlinux ~]$ grep HPET /mnt/debi386/boot/config-3.2.0-4-rt-686-pae
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
I also installed from the Debian repositories, usually I build linux-rt
myself. It IMO is a bad idea to use 250 Hz since hr timer/hpet can't be
used by everybody and for MIDI queue timer resolution you want at least
1000 Hz, assumed you care for lets say MIDI jitter.
JFTR
[rocketmouse@archlinux ~]$ grep CONFIG_NO_HZ /mnt/debi386/boot/config-3.2.0-4-rt-686-pae
CONFIG_NO_HZ=y
is not the same as CONFIG_NO_HZ_FULL.
Next time I'll test such a 250 Hz kernel, but I will install a 1000 Hz
kernel too.
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1389751826.6024.31.camel@archlinux
perhaps one of the maintainers mentioned at
http://packages.debian.org/wheezy/linux-image-rt-686-pae could add a few
notes.
On Wed, 2014-01-15 at 12:21 +1100, Zenaan Harkness wrote:
> I installed the latest 3.12-1-rt-amd64 (rt) kernel, with dist-upgrade
> and reboot of course.
>
> Reading some of the links provided in this thread, I note that
> Debian's -rt kernel has:
> CONFIG_HZ_250=y
> # CONFIG_HZ_300 is not set
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=250
will have impact to audio. For MIDI still hr timer/hpet does provide a
much higher resolution than just 1000 Hz, it's 1000000000 Hz. FWIW until
now no kernel-rt > 3.8 does work on my machine.
[rocketmouse@archlinux ~]$ grep HZ /mnt/debi386/boot/config-3.2.0-4-rt-686-pae
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_MACHZ_WDT=m
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
[rocketmouse@archlinux ~]$ grep CONFIG_NO_HZ_FULL /mnt/debi386/boot/config-3.2.0-4-rt-686-pae
Not available for this kernel version.
[rocketmouse@archlinux ~]$ grep HPET /mnt/debi386/boot/config-3.2.0-4-rt-686-pae
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
I also installed from the Debian repositories, usually I build linux-rt
myself. It IMO is a bad idea to use 250 Hz since hr timer/hpet can't be
used by everybody and for MIDI queue timer resolution you want at least
1000 Hz, assumed you care for lets say MIDI jitter.
JFTR
[rocketmouse@archlinux ~]$ grep CONFIG_NO_HZ /mnt/debi386/boot/config-3.2.0-4-rt-686-pae
CONFIG_NO_HZ=y
is not the same as CONFIG_NO_HZ_FULL.
Next time I'll test such a 250 Hz kernel, but I will install a 1000 Hz
kernel too.
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Raffaele Morelli
Jan 14, 2014, 11:50:01 PM1/14/14
to
2014/1/15 Zenaan Harkness <z...@freedbms.net>
I see you are experiencing audio dropouts still, can I ask which audio card are you using?
Zenaan Harkness
Jan 15, 2014, 11:20:02 AM1/15/14
to
On 1/15/14, Raffaele Morelli <raffaele...@gmail.com> wrote:
> 2014/1/15 Zenaan Harkness <z...@freedbms.net>
>> Also, looks like I'll have to get back to compiling own kernel. We'll
>> see.
>
> I see you are experiencing audio dropouts still, can I ask which audio card
> are you using?
Just built-in Intel for now.
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset
Family High Definition Audio Controller (rev 04)
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAOsGNSS2dLWE2MAP3cWT4-PA...@mail.gmail.com
> 2014/1/15 Zenaan Harkness <z...@freedbms.net>
>> Also, looks like I'll have to get back to compiling own kernel. We'll
>> see.
>
> I see you are experiencing audio dropouts still, can I ask which audio card
> are you using?
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset
Family High Definition Audio Controller (rev 04)
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Zenaan Harkness
Jan 23, 2014, 8:40:02 AM1/23/14
to
On 1/11/14, Zenaan Harkness <z...@freedbms.net> wrote:
> On 1/11/14, Klaus <klaus.do...@gmail.com> wrote:
>> far as I'm aware of, Zenaan has not tested -- or reported about his
>> tests of -- the most minimalist system.
>
> I shall do so at some point, hopefully in next day or three, and
> report back. It's an important test.
OK, finally got to do a clean reboot, running no gui (not even an
>> far as I'm aware of, Zenaan has not tested -- or reported about his
>> tests of -- the most minimalist system.
>
> I shall do so at some point, hopefully in next day or three, and
> report back. It's an important test.
Xdm), and these audio dropouts at random intervals do continue.
alsaplayer -S myaudio.file -o alsa -d hdmi:PCH,1 -r -F 32000 -l 0.5
This audio is going out my external monitor. Audio is really dodge
without -F 32000, so it appears the DP monitor audio out is not DACing
the full 48KHz that out be possible. Either that or I don't know how
to set this sound card feature from the command line.
Kernel:
Linux x220a02 3.12-1-rt-amd64 #1 SMP PREEMPT RT Debian 3.12.6-2
(2013-12-29) x86_64 GNU/Linux
But same happened with my old kernel, config-3.9-1-amd64 .
My intention now is to build my own custom kernel. Been a few years,
hopefully can determine the source of the problem.
FYI
Zenaan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAOsGNSTPoWaQ+6+DZk3aunT8...@mail.gmail.com
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Zenaan Harkness
Jan 23, 2014, 5:20:02 PM1/23/14
to
On 1/24/14, Klaus <klaus.do...@gmail.com> wrote:
'Tis. Which dist are you running, sid, jessie or wheezy?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAOsGNSTYqK6X0UDy3XMx+M7c...@mail.gmail.com
> On 23/01/14 13:32, Zenaan Harkness wrote:
>> On 1/11/14, Zenaan Harkness <z...@freedbms.net> wrote:
>
>> alsaplayer -S myaudio.file -o alsa -d hdmi:PCH,1 -r -F 32000 -l 0.5
>> On 1/11/14, Zenaan Harkness <z...@freedbms.net> wrote:
>
>> alsaplayer -S myaudio.file -o alsa -d hdmi:PCH,1 -r -F 32000 -l 0.5
>> Kernel:
>> Linux x220a02 3.12-1-rt-amd64 #1 SMP PREEMPT RT Debian 3.12.6-2
>> (2013-12-29) x86_64 GNU/Linux
>>
>> But same happened with my old kernel, config-3.9-1-amd64 .
> Do I remember correctly that this is on a Thinkpad X220 ?
>> Linux x220a02 3.12-1-rt-amd64 #1 SMP PREEMPT RT Debian 3.12.6-2
>> (2013-12-29) x86_64 GNU/Linux
>>
>> But same happened with my old kernel, config-3.9-1-amd64 .
'Tis. Which dist are you running, sid, jessie or wheezy?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Klaus
Jan 24, 2014, 4:30:02 AM1/24/14
to
Just realised that yesterday's reply didn't go to the list. Sorry.
On 23/01/14 22:15, Zenaan Harkness wrote:
> 'Tis. Which dist are you running, sid, jessie or wheezy?
Minutes earlier, Klaus had scribbled this:
> JFTR: my X220 is a type 4290-FC1, cpu i5-2540, 8GB ram, up-to-date
> SID, 3.12-1-amd64 kernel, mostly standard install (Gnome3)
--
Klaus
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/52E230D...@gmail.com
On 23/01/14 22:15, Zenaan Harkness wrote:
> 'Tis. Which dist are you running, sid, jessie or wheezy?
> JFTR: my X220 is a type 4290-FC1, cpu i5-2540, 8GB ram, up-to-date
> SID, 3.12-1-amd64 kernel, mostly standard install (Gnome3)
--
Klaus
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages