On Sat, 27 Aug 2016, jonetsu@xxxxxxxxxxxx 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
