Jack O'Quin | 1 Jan 2005 01:01
Picon

CVS commit [0.99.42] move several function prototypes to statistics.h


  * moved several function prototypes to <jack/statistics.h>

	* jack_get_max_delayed_usecs()

	* jack_reset_max_delayed_usecs()

	* jack_get_xrun_delayed_usecs()

This is a source (but not binary) incompatibility with recent
intermediate CVS versions.  There is *no* compatibility problem with
any JACK release, since these are all new interfaces.
--

-- 
  joq

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Jack O'Quin | 1 Jan 2005 17:39
Picon

CVS commit [0.99.43] update alsa_driver to release 1.0 SW/HW param interface


  * based on Rohan Drape's patch, significantly modified for current
    driver version

  * updated Takashi's _set_periods_near() logic like this...

	*nperiodsp = driver->user_nperiods;
	snd_pcm_hw_params_set_periods_min (handle, hw_params, nperiodsp, NULL);
	if (*nperiodsp < driver->user_nperiods)
		*nperiodsp = driver->user_nperiods;
	if (snd_pcm_hw_params_set_periods_near (handle, hw_params,
						nperiodsp, NULL) < 0) {
		jack_error ("ALSA: cannot set number of periods to %u for %s",
			    *nperiodsp, stream_name);
		return -1;
	}

  * also added code to force the minimum nperiods to 2, even if the
    user specifies something like -n1.  JACK doesn't work with less
    than two periods.

Please review and let me know if I got this right.  I don't understand
those interfaces very clearly.  The newer _set_periods_near() modifies
the contents of *nperiodsp, the older one did not (it was passed by
value).
--

-- 
  joq

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
(Continue reading)

Paul Davis | 1 Jan 2005 21:51

recent CVS changes

JACK from CVS currently fails to open on my ICH (builtin) audio
interface because it only supports 16bit. the alsa backend reports:

creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
Sorry. The audio interface "hw:0" doesn't support any of the hardware sample formats that JACK's
alsa-driver can use.

if the -S option is provided (try 16 bit format first), it works OK.

i don't have the time to track this down right now, but will later if
whoever made the relevant change doesn't fix it. was this part of
takashi's patches for the new ALSA API?

--p

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Lee Revell | 2 Jan 2005 00:23

Re: 2.6.10

On Thu, 2004-12-30 at 11:19 +0000, Rui Nuno Capela wrote:
> 
>                                   2.6.10-cko1  RT-V0.7.33-04
>                                   ------------- -------------
>   Timeout Rate  . . . . . . . . :    (    0.0)    (    0.0)   /hour
>   XRUN Rate . . . . . . . . . . :       216.8          2.2    /hour
>   Delay Rate (>spare time)  . . :       395.2          0.0    /hour
>   Delay Rate (>1000 usecs)  . . :       375.8          0.0    /hour
>   Delay Maximum . . . . . . . . :      4320          308      usecs
>   Cycle Maximum . . . . . . . . :       845         1051      usecs
>   Average DSP Load. . . . . . . :        44.0         50.2    %
>   Average CPU System Load . . . :        14.4         31.7    %
>   Average CPU User Load . . . . :        19.8         21.4    %
>   Average CPU Nice Load . . . . :         0.0          0.0    %
>   Average CPU I/O Wait Load . . :         0.1          0.1    %
>   Average CPU IRQ Load  . . . . :         0.0          0.0    %
>   Average CPU Soft-IRQ Load . . :         0.0          0.0    %
>   Average Interrupt Rate  . . . :      1691.7       1692.6    /sec
>   Average Context-Switch Rate . :     13368.8      18213.9    /sec
> 

How long do you have to run it for, and what kind of load are you
producing, to get those results?  Here are my results with 2.6.10
vanilla.  No xruns.

rlrevell <at> mindpipe:~/jack_test3.2$ ./jack_test3_run.sh 
Launching jack_test3_nmeter...done.
Launching 16 ./jack_test3_client(s) instance(s)...done.
Running jackd...1...2...3...4...5...6...7...8...9...10...11...12...13...14...15...16...done.
Killing jack_test3_nmeter...OK.
(Continue reading)

Lee Revell | 2 Jan 2005 00:35

Re: [linux-audio-user] Re: 2.6.10

On Sat, 2005-01-01 at 18:23 -0500, Lee Revell wrote:
> ************* SUMMARY RESULT ****************
> Total seconds ran . . . . . . :   300
> Number of clients . . . . . . :    16
> Ports per client  . . . . . . :     4
> *********************************************
> Timeout Count . . . . . . . . :(    0)
> XRUN Count  . . . . . . . . . :     0
> Delay Count (>spare time) . . :     0
> Delay Count (>1000 usecs) . . :     0
> Delay Maximum . . . . . . . . :     0   usecs
> Cycle Maximum . . . . . . . . :   125   usecs
> Average DSP Load. . . . . . . :     1.8 %
> Average CPU System Load . . . :     3.1 %
> Average CPU User Load . . . . :    26.7 %
> Average CPU Nice Load . . . . :     0.0 %
> Average CPU I/O Wait Load . . :     0.6 %
> Average CPU IRQ Load  . . . . :     1.9 %
> Average CPU Soft-IRQ Load . . :     0.0 %
> Average Interrupt Rate  . . . :  1949.4 /sec
> Average Context-Switch Rate . :  1833.6 /sec
> *********************************************
> 

Here are my results with "dbench 8" running in the background.

************* SUMMARY RESULT ****************
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :    16
Ports per client  . . . . . . :     4
(Continue reading)

Lee Revell | 2 Jan 2005 00:40

Re: 2.6.10

On Sat, 2005-01-01 at 18:23 -0500, Lee Revell wrote:
> How long do you have to run it for, and what kind of load are you
> producing, to get those results?  Here are my results with 2.6.10
> vanilla.  No xruns.

Sorry, these results are incorrect.  There seems to be a bug in the
jack_test suite.  It is running the jackd in /usr/bin, which is broken
on my system, even though /usr/local/bin precedes it in my $PATH.  And
it seems to report that it ran 16 clients, with no xruns, while if I run
jackd and the test clients manually, it can't handle more than a few.

Lee

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Jack O'Quin | 2 Jan 2005 04:13
Picon

Re: recent CVS changes

Paul Davis <paul <at> linuxaudiosystems.com> writes:

> JACK from CVS currently fails to open on my ICH (builtin) audio
> interface because it only supports 16bit. the alsa backend reports:
>
> creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
> control device hw:0
> configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
> Sorry. The audio interface "hw:0" doesn't support any of the hardware sample formats that JACK's
alsa-driver can use.
>
> if the -S option is provided (try 16 bit format first), it works OK.
>
> i don't have the time to track this down right now, but will later if
> whoever made the relevant change doesn't fix it. was this part of
> takashi's patches for the new ALSA API?

I committed a version of Rohan's patch for the new ALSA API this
morning, JACK 0.99.43.  I had a difficult time integrating it with
Takashi's --nperiods patch.  I could very well have messed up 16bit
support (or anything else).

It seems to work with my 24bit Delta-66 card.  I don't have a 16bit
card to try it on, but I'll look at the code some more.

It's possible that this is due to some other ALSA version
incompatibility that was missed in the original patch.
--

-- 
  joq

(Continue reading)

Matthew Allen | 2 Jan 2005 11:49
Picon

Re: 2.6.10

using 2.6.10-rc3-mm with Ingo's latest Real-Time Preempt on a pentium
M 1.6ghz laptop with a gig of ram. The test was done as a normal user
using the realtime-lsm patch and I have Rui's rtirq script up and
running. One of the three tests was completed while compiling gnuplot
in the background :).

*********** CONSOLIDATED RESULTS ************
Total seconds ran . . . . . . :  1200
Number of clients . . . . . . :    20
Ports per client  . . . . . . :     4
Frames per buffer . . . . . . :    64
*********************************************
Summary Result Count  . . . . :     3 /     3
*********************************************
Timeout Rate  . . . . . . . . :(    0.0)/hour
XRUN Rate . . . . . . . . . . :     4.0 /hour
Delay Rate (>spare time)  . . : 85477.0 /hour
Delay Rate (>1000 usecs)  . . :     0.0 /hour
Delay Maximum . . . . . . . . :     0   usecs
Cycle Maximum . . . . . . . . :     0   usecs
Average DSP Load. . . . . . . :    34.0 %
Average CPU System Load . . . :    25.5 %
Average CPU User Load . . . . :    27.7 %
Average CPU Nice Load . . . . :     0.0 %
Average CPU I/O Wait Load . . :     0.1 %
Average CPU IRQ Load  . . . . :     0.0 %
Average CPU Soft-IRQ Load . . :     0.0 %
Average Interrupt Rate  . . . :  1881.0 /sec
Average Context-Switch Rate . : 42065.8 /sec
*********************************************
(Continue reading)

Rui Nuno Capela | 2 Jan 2005 13:46
Favicon
Gravatar

Re: 2.6.10

Hi,

Just some notes about my jack_test3 suite I've posted a few days back,
which I find worth regarding.

Always check the source on jack_test3_run.sh and try to adapt it to your 
own needs or environment. This is highly recommended if you're trying to
run some definitive tests.

The results obtained only make sense for your own hardware and software
setup. In my case, it has been barely useful about comparing _between_
kernels and/or jackd versions. It was not (never) meant to benchmark your
specific hardware, nor it makes sense when comparing with someone else
results.

The main objectives have been to check and confirm the performance
benefits of the Ingo's RT patch, specially regarding the jackd realtime
audio work. It may also fit to stress your audio station into such a
(un)practical scenario that it may fall apart. I think we all be
discussing those scenarios very soon :)

For example, my laptop starts behaving in a seriously compromised state if
I reach above the 24 test clients. It runs fairly well for a couple of
minutes, topping 90%CPU, then it lockups badly with no determined cause.
Guess this behavior will be my next subject onto the kernel folks ;)

Matthew Allen wrote:
> using 2.6.10-rc3-mm with Ingo's latest Real-Time Preempt on a pentium
> M 1.6ghz laptop with a gig of ram. The test was done as a normal user
> using the realtime-lsm patch and I have Rui's rtirq script up and
(Continue reading)

Jack O'Quin | 2 Jan 2005 14:34
Picon

Re: 2.6.10

"Rui Nuno Capela" <rncbc <at> rncbc.org> writes:

>> $  ./jack_test3_run.sh 600
>> Launching jack_test3_nmeter...done.
>> Launching 20 ./jack_test3_client(s) instance(s)...done.
>> Running
>> jackd...1...2...3...4...5...6...7...8...9...10...11...12...13...14...15...16..../jack_test3_run.sh:
>> line 48: 32325 Killed                  ${CMD} >>${LOG} 2>&1
>> done.
>
> OK. That's it. Your test runs were being terminated prematurely. I think
> your setup can't handle the stress of more than 16 clients. This maybe
> caused by an old jackd version. Please, retry with 14 clients only, and be
> back after then ;)

I believe several people have hit this problem due to /usr/bin/jackd
being hard-coded in the script.  The default location is actually
/usr/local/bin/jackd.  It's probably better to just use `jackd' and
let $PATH resolve the name...

--- jack_test3_run.sh~	Fri Dec 10 06:21:21 2004
+++ jack_test3_run.sh	Thu Dec 30 08:04:10 2004
 <at>  <at>  -24,7 +24,7  <at>  <at> 
 NMETER_ARGS="t c i x b m"

 # jackd configuration.
-JACKD="/usr/bin/jackd"
+JACKD="jackd"
 JACKD_DRIVER="alsa"
 JACKD_DEVICE="hw:0"
(Continue reading)


Gmane