2014/1/15 Zenaan Harkness <z...@freedbms.net> > On 1/11/14, Zenaan Harkness <z...@freedbms.net> wrote: > > On 1/11/14, Klaus <klaus.doering...@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 > 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.
I see you are experiencing audio dropouts still, can I ask which audio card are you using?
