Re: audio dropouts still
On 1/11/14, Zenaan Harkness <zen@freedbms.net> wrote:
> On 1/11/14, Klaus <klaus.doering999@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.
Reply to: