Subject: Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack
From: Andy Lo-A-Foe (andy_AT_alsaplayer.org)
Date: Tue Nov 27 2001 - 21:40:22 EET
On Tue, Nov 27, 2001 at 12:02:21AM -0500, Paul Davis wrote:
> OK, i just tried it on my dual PII450 box, with
>
> jackd -d trident -R -p 64
> jackplayer -i text some.wav
>
> and got no xruns at all. this is on 2.4.0+lowish.
Hah, UP Athlon 1.33, exact same commands, 2.4.16-pre1 + ll
ALSA I/O: xrun of 3853 frames, (80.271 msecs)
ALSA I/O: xrun of 1805 frames, (37.604 msecs)
ALSA I/O: xrun of 1542 frames, (32.125 msecs)
etc...
Could you try the above with a single CPU kernel??
If I set the fragment size to 2 (current jackd default) it will xrun
without anything connected:
ALSA I/O: xrun of 130 frames, (2.708 msecs)
ALSA I/O: xrun of 130 frames, (2.708 msecs)
etc..
I will hack jackd tonight to do only Output.
> there is definitely some clipping or other wierd effect occuring with
> "jackplayer". it is present even when jackplayer is the only client,
> but then just gets worse when other clients connect and use the same
The process() call is in app/AlsaNode.cpp, the code looks allright to
me, but I have only simple_client to compare it to :)
Oh, I just noticed something weird with the above commands running.
Every few seconds both jackplayer and jackd will cause a burst of CPU
activity. The time inbetween bursts looks random, sometimes it happens
within 2 seconds, other times it works fine for minutes. Definitely
looks like a client/server communication problem.
> port. this is odd, since they have no input. when i run them with
> input, but without jackplayer, the effect is not present.
Sometimes an overrun will cause massive corruption with the sound, only
fixable by quitting and restarting jackd. I.e. quitting jackplayer and
reconnecting will still produce garbled sound. This happens because the
frequency of the process() calls gets erratic. Jackd will also segfault
randomly once it is in this state. I can't seem to use GDB to trace the
crash. I'll try connecting GDB to a running jackd next.
> the effect is strange. its not like harsh clipping. its a strange kind
> of constant buzzing, but its definitely like clipping in that its
> clearly signal level related.
Yes, I can get rid of pops by lowering the volume of jackplayer (need
GTK+ GUI for this). But this suggest the clipping problem is inside
jackd.
> sort of suspect an issue with the
> sample_move_dS_s16 function that you borrowed.
I put some debug code in there that checks if values are all between
-1.0f and 1.0f and it hasn't triggered yet.
> i hate to say this, but this sounds like 1 of only 2 possibilities:
>
> * kernel issues
The same kernel has excellent lowlatency(-test) results and running
alsaplayer -r -f 256 -g 3 is rock solid, no xruns.
> * uniprocessor issues
I suspect this.
> also, i note that your code is burning a *LOT* of CPU time. the
> "jack_simple_client", which copies 1 channel from input to output,
> almost doesn't register in xosview (jackd is invisible).
xosview has a granularity of roughly 9% here. The only significant CPU usage
by alsaplayer is for decoding compressed data, and that value is negligible.
If there is excessive CPU usage it is probably triggered by the
process() frequency and nframe number. I noticed there are quite a few
calles where nframes is 1. I did some statistics over 5000 calls for 64
frames per interrupt. Roughly 45% of the calls are with nframes around
64, another 45% around 1, the remaining % is evenly distributed inbetween these 2 values. Doesn't this make it very inefficient?
I.e. minimize process() roundtrips with nframes = 1 ?!
> with a text interface is burning chunks of CPU comparable to what
> ardour uses for 8-16 tracks of highly non-contiguous audio plus a GUI,
> sometimes even more.
How does it compare to using -o alsa, or -o oss?
Regards,
Andy
This archive was generated by hypermail 2b28 : Tue Nov 27 2001 - 21:51:23 EET