Sudden and occasional Jack crackling sound (Jesse, are you there?)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Sudden and occasional Jack crackling sound (Jesse, are you there?)

Salvatore Di Pietro
I repost here this message (about occasional crackling sound problem,
and Jesse Chappel trying to fix it), that I posted to linux-audio-user,
maybe it's more appropriate here.

Aaaargh. It Happened Again(TM).

Do you remember
I have always suffered the same problem, (though much less now) along
many jack, alsa and kernel versions and configurations...

I got:

Slackware 10.1
kernel vanilla (but older versions worked equally well)
(but this problem has always been, even with 2.4 + lowlatency + preempt
(andrew Morton and Robert Love), and with 2.6.x + RT patches by Ingo Molnar)
ALSA 1.0.8 - ALSA 1.0.9b
JACK 0.99.0
all compiled from sources

AMD Athlon XP 3000+
AsRock K7S8X
SB Live! Digital 5.1  (hw:0)
SB Live! Player 5.1   (hw:1)
ForteMedia FM801      (hw:2)
Matrox G450 DualHead AGP

every card runs on its own IRQ:

root at slack101-sal:/home/salvuz# cat /proc/interrupts
    0:    3067468    IO-APIC-edge  timer
    1:       4252    IO-APIC-edge  i8042
    8:          0    IO-APIC-edge  rtc
    9:          0   IO-APIC-level  acpi
   12:      68805    IO-APIC-edge  i8042
   14:     130386    IO-APIC-edge  ide0
   15:     107823    IO-APIC-edge  ide1
   16:          0   IO-APIC-level  FM801
   17:       2080   IO-APIC-level  eth0
   18:       1138   IO-APIC-level  EMU10K1
   19:          0   IO-APIC-level  EMU10K1
   20:          0   IO-APIC-level  ohci_hcd:usb2
   21:          0   IO-APIC-level  ohci_hcd:usb3
   23:          0   IO-APIC-level  ehci_hcd:usb1
NMI:          0
LOC:    3067418
ERR:          0
MIS:          0

The problem in detail:
Sometimes in occurence of a client being closed or added, but sometimes
apparently randomly, without xruns and not necessarily under heavy load,
I experience sudden corruption of sound, in form of crackling sound
coming out of alsa_pcm:playback ports.
Capture and client ones are not affected, i.e. I can record cleanly even
under crackling sound condition: if I close every client, restart jack
and play what I recorded just before, the sound is not corrupted at all,
just (software) monitoring is horrible.
I use my SB Lives always at 48kHz (but the problem arises at other SR
too), I tried on the ForteMedia FM801, on the intel8x0 C-Media builtin
soundcard (ugh!), on the PC of a friend of mine with NVidia chipset,
nVidia builtin soundcard, SB Live and Agnula 1.2.1, I tried Agnula 1.2.1
along with my Slackware on my system, with various buffer, periods and
other settings that jackd accepted. Nothing helped. The show-stopping
noise, even if certainly not seldom, came out.

Well, I noticed that continuing to open and close clients, or doing
something apparently "heavy" such as choosing a PADsynth intsrument
(such as ChoirPad 1) in Zynad (upon choosing PADsyn instruments Zynad
GUI hangs for a moment, then the instrument is ready), I could screw the
sound in the same identical manner (the sound appears distorted in the
very same way), but also I could restore (after one, two or little more
tries) the clean sound from alsa_pcm:playback ports.

To make things easier, I wrote this little script that does the dirty work:
itstarts jack_simple_client, than *stops the process* (do you hear the
alarm siren?) then CONTinues it, then kills it (quite obvious)

# Pound on broken TV set
sudo jack_simple_client POUND! &
sudo kill -STOP `ps -el|grep simple|awk '{print $4}'`
sleep 0.2
sudo kill -CONT `ps -el|grep simple|awk '{print $4}'`
sleep 0.1
sudo kill -9 `ps -el|grep simple|awk '{print $4}'`

I know, with this script I am juggling chainsaws over Jack... sorry
about that. But it somewhat works (I must admit sometimes jackd dies
after the treatment, but there's a let's say 80% probability it doesn't).

A painless,and "100% success cases, no jackd deaths" approach is to use
jack_bufsize: I simply re-set jackd buffer size and voila, back to clean
sound. Try that if you have the same problem:

sudo jack_bufsize `ps aux|grep jack|grep " -p" \
| awk '{print $19}'|sed 's/-p//'|uniq`

So I think it's a buffer issue that somewhat involves the hardware
output ports...

I lived satisfied with this setup...until I discovered that oss2jack
0.21 stops working upon executing jack_bufsize. Aaarghh!
Maybe oss2jack 0.21 isn't happy with buffer resizing, whereas 0.15 was ok.
Tooooooooo bad, because I had:

Gnome Wave Cleaner
ReZound (playback only)
GNUsound (native JACK supports segfaults)
ZynAdSubFX (it gives me rock solid performance even upon loading a
PADsynt instrument)

all working with jack... :(

oss2jack 0.15 doesn't die with jack_bufsize, but doesn't handle capture.

I then read this from Jesse Chappell:

excerpt from
Anyone who is having this problem, please try a version of JACK
from CVS where the version is >= 0.99.52 (after 17 march).  I
made some fixes to jack's alsa driver that *might* help this
problem.  I know compiling your own jackd might be a little much
to ask, but I'm very curious.

Now that jack 0.100.0 was out, I grabbed the source,

./configure --prefix=/usr --enable-stripped-jackd --disable-portaudio
--disable-coreaudio --enable-capabilities --enable-optimize
--enable-posix-shm --enable-resize --enable-timestamps

make && make install

and thought the end of my nightmare had
finally come, but, unfortunately, that's not the case...
As in subject, It Happened Again.
And,worst of all, all jack clients (not only oss2jack), even ardour
(even via his latency panel), die with

cannot open shm segment /jack-1 (No such file or directory)
cannot attach port segment shared memory (No such file or directory)

upon setting jack buffersize.

I prepared two ogg files that will explain the weird sound:

For those who don't speak Italian...
- check the "Seleziona tutti" (select all) checkbox
- then click on "Scarica" (download) button

I had Jack running on hw:0 via qjackctl at 256 frames per buffer:

  /usr/bin/jackstart -v -R -p512 -t10000 -dalsa -dhw:0 -r48000 -p256 -n2
-s -S

I fired up ZynAddSubFX, Hydrogen and two istances of qarecord, one with
--jack, connected to Zyn and Hydrogen, the other one on another card
(hw:1) with ALSA, capturing via "Line in" what came out of hw:0 "Line
out", begin to record something (just a test case, as I am a guitarist
that tries to play keyboards)
then induced corruption with the "pound" script. Another couple of
"pounds", and the sound comes clear again, but you know the story.

I hope to have been of any help, and I wonder whan can be done...
Thanks for your care!

  Linux registered user #291700 | machine #174619
  get counted on ---> <---

SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement *
Jackit-devel mailing list
[hidden email]