[LAU] Crackles in audio - how to troubleshoot ?

Len Ovens len at ovenwerks.net
Sat Aug 27 23:35:55 UTC 2016


On Sat, 27 Aug 2016, jonetsu at teksavvy.com wrote:

>> That sounds like there are two dbus running and two pulse. normally
>> pulse is run across dbus which should ensure only one of them. Do you
>> have two sessions open? (one with a dfferent user?)
>
> No, only one user.  OTOH, it seems there's some kind of dbus fiesta
> there, with no less than 5 /bin/dbus-daemon processes running.  I do
> not know dbus, although it seems that instances are run depending of
> applications connecting to it.  Having 5 might just make sense.  See
> below for a list.

dbus passes it's pid (or is it some other number) so that things like 
session or system can run different instanses of dbus. In my experiments 
with audio in a cli only system using VTs or screen. I found when using 
VTs I have to start a dbus version and capture it's PID from the 
environment in that instance and then add that to each of the VTs I was 
using. I was then able to run jackdbus on one VT and pulseaudio on another 
and have module-jackdbusdetect find jackdbus. I could use jack_control 
from yet another VT to talk to jackdbus and make changes (different 
device, buffersize or whatever). With screen I found I could just get dbus 
to start screen and all bash instances inside that would see the same 
dbus.

dbus is interesting, it passes messages from one application to another, 
but, it also will try to start the process the message is being sent to if 
it is not yet running. So my guess is that some application is trying to 
talk to pulseaudio on a second dbus instance and so pulse starts and can't 
get the audio device(s) because another PA already has then (your session) 
and so it trys to signal the Audio port hold to give it up and fails that 
too... it fails and because of the respawn ends up stuck (defunct).

So it sounds like your session may be started in a wrong manner, perhaps 
something that worked with an older version dbus, but does not any more. 
It seems to me at one time running dbus twice was quite common using each 
one to get a different value to pass to the environment. These days dbus 
starts the session passing both values to the environment on it's own.

> First time I hear about zita.  What is it about ?

You may have heard of alsa-in and alsa-out that comes with jack? This is a 
better version of the same thing... uses less cpu and still has a much 
better sound quality. (Thank you Fons)
http://kokkinizita.linuxaudio.org/linuxaudio/zita-ajbridge-doc/quickguide.html

Jackd1 now include this code so far as I know. (I use jackd2 cause it 
comes in the distro  :P  )

> 1) Bitwig audio enable can provoke a plethora of crackling once the
> audio system as reached an unknown state in which these can happen in
> both Bitwig and vlc.

First asumption: you have more than one audio interface (1010 and internal 
audio)
second asunption: bitwig grabs both and keeps them open.
third asumption: bitwig bases its sync on the first AI it can find 
(internal) and refills it's buffers based on that.

If you can disable the internal audio does this problem go away? If you 
can't disable in bios, maybe unload the right kernel module will have the 
same effect. having two AIs open in the same application with no resample 
will very much make noise. Also you should try running at 48000sample/sec, 
just to see if that makes any difference. I once had an internal AI where 
one of the devices (A mic as happens) was 48K only and it caused crackles 
when PA was set to 44100 (the default) because the internal AI "said" that 
was ok. A good MB should not have this... I seen enough wierd stuff I 
don't count much out.


--
Len Ovens
www.ovenwerks.net



More information about the Linux-audio-user mailing list