Re: [9fans] 3e mpg123 plays on off on off on off on 4e

Re: [9fans] 3e mpg123 plays on off on off on off on 4e

[Russ Cox]

> Without recompiling mpg123 I just used it to play an mp3 file that
> is served over (my hacked wrt '-l user' in attach message) u9fs.
> It no plays a second, pauses a (part of?) a second, plays again, pauses
> again, etc etc. The load on the machine is pretty low -- lower than
> I recall from using mpg123 on 3e.

Try copying the mp3 over to local disk first.
I'm assuming that won't change anything, in which
case you should make sure you've disabled the usb
driver.

Russ

Re: [9fans] 3e mpg123 plays on off on off on off on 4e

[Don]

> Try copying the mp3 over to local disk first.
> I'm assuming that won't change anything, in which
> case you should make sure you've disabled the usb
> driver.
>
Happens on my box even without the USB driver when
the mp3 is local to the audio driver. Except, its
not as accentuated as Axel states in my case. Its
more like for every 5 minutes of play there is a
5 second pause. This is an average I've taken of
9 occurances of the pause over today's daily work.
It only seems to occur in files (large?) enough
to contain data for more than a 5 minute period.
Mostly trance, the Grateful Dead or Cecilia Bartoli
in my case, lol. Based on the 'marriage' of time
and data could it be possible that the audio driver
buffer gets backed up? Audio from cdroms seems to
do this too, however, I don't listen to many cds
so my info on that angle is limited. If his audio
is choppy after he bails from USB use (or applies
the patch), if he uses it, I would think the
audio driver is at fault. Anyone else having
experiences like this?
Don

Re: [9fans] 3e mpg123 plays on off on off on off on 4e

[Axel Belinfante]

> > Try copying the mp3 over to local disk first.

Sorry. no local disk (currently).
it's a diskless cpu/auth server that doubles as terminal,
boots kernel from flop, takes root from fs.
(150 Mhz pentium with 64 Mb ram)
My only other plan 9 machine here is a laptop
with unsupported audio hardware.

> > I'm assuming that won't change anything, in which
> > case you should make sure you've disabled the usb
> > driver.

my config file contains neither dev->usb nor misc->usbuhci
is based on pccpu, with audio, serial, and a lot of net and
video drivers

> Happens on my box even without the USB driver when
> the mp3 is local to the audio driver. Except, its
> not as accentuated as Axel states in my case. Its
> more like for every 5 minutes of play there is a
> 5 second pause.

As I mentioned, the other thing I did notice is that
in the stats window the load is now dramatically less
(almost half) than I used to see (unless load very
much depends on the particular mp3 file being played).

I now intend to just install the update, and see what happens.

Axel.

Re: [9fans] 3e mpg123 plays on off on off on off on 4e

[Axel Belinfante]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Russ suggested:
> > > Try copying the mp3 over to local disk first.

To which I replied:
> Sorry. no local disk (currently).
> it's a diskless cpu/auth server that doubles as terminal,
> boots kernel from flop, takes root from fs.
> (150 Mhz pentium with 64 Mb ram)
> My only other plan 9 machine here is a laptop
> with unsupported audio hardware.
[...]
> I now intend to just install the update, and see what happens

Installing the update did not make a difference.
However, copying the mp3 to the (real fake worm) fs
_does_ make a difference, and solves the problem.
I do use my u9fs '-l user' aname hack:

% srv tcp!unix!9fs
% mount /srv/tcp!unix!9fs /n/unix '-l user'

With the 3e installation it did work fine.
The 'probelmatic' 4e u9fs is of the 2002-04-27 release.

In the hope it sheds some light I ran
	iostats cat a.mp3
with a.mp3 taken from fs and u9fs (attached).
The unix machine was basically idle, and has 100Mb/s
network, the fs only 10 Mb/s.

Any ideas how to improve this?
(If there is a FM I should R, a pointer would be appreciated!)

Axel.

[-- Attachment #2.1: Type: text/plain, Size: 333 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: text/plain ; name="mp3.iostats"; charset=us-ascii
	Content-Description: mp3.iostats
	Content-Disposition: attachment; filename="mp3.iostats"

[-- Attachment #2.2: mp3.iostats.suspect --]
[-- Type: application/octet-stream, Size: 1926 bytes --]

cpu% iostats cat  /n/zamenhof/tmp/a.mp3 > /dev/null

read      4569410 bytes, 380.1597 Kb/sec
write     4558730 bytes, 46373.32 Kb/sec
protocol  9167243 bytes, 730.8666 Kb/sec
rpc       1143 count

Message    Count   Low  High  Time Averg          in      out
version        1     0     0     0     0 ms       19       19 bytes
attach         1     2     2     2     2 ms       25       20 bytes
walk           9     1   197   351    39 ms      261      332 bytes
open           5     0    35    39     7 ms       60      120 bytes
read         562     2   145 11738    20 ms    12926  4575592 bytes
write        557     0     1    96     0 ms  4571541     6127 bytes
clunk          8     0    19    23     2 ms       88       56 bytes

Opens    Reads  (bytes)   Writes  (bytes) File
    1      558  4558730        0        0 /n/zamenhof/tmp/a.mp3
    1        0        0      557  4558730 (stdout)
    1        4    10680        0        0 /bin/cat

cpu%  iostats cat /tmp/a.mp3 > /dev/null

read      4569410 bytes, 760.5784 Kb/sec
write     4558730 bytes, 44968.08 Kb/sec
protocol  9167204 bytes, 1384.312 Kb/sec
rpc       1143 count

Message    Count   Low  High  Time Averg          in      out
version        1     0     0     0     0 ms       19       19 bytes
attach         1     2     2     2     2 ms       25       20 bytes
walk           9     1   436   488    54 ms      248      306 bytes
open           5     0     4     9     1 ms       60      120 bytes
read         562     1    16  5867    10 ms    12926  4575592 bytes
write        557     0     4    99     0 ms  4571541     6127 bytes
clunk          8     0     1     2     0 ms       88       56 bytes

Opens    Reads  (bytes)   Writes  (bytes) File
    1      558  4558730        0        0 /tmp/a.mp3
    1        0        0      557  4558730 (stdout)
    1        4    10680        0        0 /bin/cat
cpu%

Re: [9fans] 3e mpg123 plays on off on off on off on 4e

[Russ Cox]

One more thing to try.

Instead of

	mp3dec < file
or	mp3dec file

do

	cat file | cat | mp3dec

The pipes will get you some buffering
which in turn will induce some readahead.

It could be that we're just not doing a good
job with scheduling this particular task,
although that doesn't really explain the
fs/u9fs discrepancy.

Russ

Re: [9fans] 3e mpg123 plays on off on off on off on 4e

[Axel Belinfante]

> Instead of
>
> 	mp3dec < file
> or	mp3dec file
>
> do
>
> 	cat file | cat | mp3dec

works like a charm. Tried also the following, which also works:

	cat file | mpg123 -s - > /dev/audio

Thanks for the trick!

Axel.

Re: [9fans] 3e mpg123 plays on off on off on off on 4e

[Russ Cox]

I believe you that the 3e installation worked fine.
Much has changed, though.  One thing you might try
is boot your 3e installation (if you still have it)
but use the 4e u9fs (which speaks both protocols).

Maybe I managed to make u9fs even slower than it
was, although I expect it should be about the same.

What if you just time cp?  Can you see a difference
between fs and u9fs?  Between 3e and 4e u9fs?

Russ

Re: [9fans] 3e mpg123 plays on off on off on off on 4e

[Axel Belinfante]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

> I believe you that the 3e installation worked fine.
> Much has changed, though.  One thing you might try
> is boot your 3e installation (if you still have it)
> but use the 4e u9fs (which speaks both protocols).
>
> Maybe I managed to make u9fs even slower than it
> was, although I expect it should be about the same.
>
> What if you just time cp?  Can you see a difference
> between fs and u9fs?  Between 3e and 4e u9fs?

I just tried your last suggestion, repeating the same
iostats experiment with 3 u9fs.
(see last part of attachment)

(By the way: for maintenance they will shut down main
 servers here in about 20 minutes, for several hours;
 next week I'm away and may or may not have email access)

Axel.


[-- Attachment #2.1: Type: text/plain, Size: 333 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: text/plain ; name="mp3.iostats"; charset=us-ascii
	Content-Description: mp3.iostats
	Content-Disposition: attachment; filename="mp3.iostats"

[-- Attachment #2.2: mp3.iostats.suspect --]
[-- Type: application/octet-stream, Size: 2957 bytes --]

cpu% iostats cat  /n/zamenhof/tmp/a.mp3 > /dev/null

read      4569410 bytes, 380.1597 Kb/sec
write     4558730 bytes, 46373.32 Kb/sec
protocol  9167243 bytes, 730.8666 Kb/sec
rpc       1143 count

Message    Count   Low  High  Time Averg          in      out
version        1     0     0     0     0 ms       19       19 bytes
attach         1     2     2     2     2 ms       25       20 bytes
walk           9     1   197   351    39 ms      261      332 bytes
open           5     0    35    39     7 ms       60      120 bytes
read         562     2   145 11738    20 ms    12926  4575592 bytes
write        557     0     1    96     0 ms  4571541     6127 bytes
clunk          8     0    19    23     2 ms       88       56 bytes

Opens    Reads  (bytes)   Writes  (bytes) File
    1      558  4558730        0        0 /n/zamenhof/tmp/a.mp3
    1        0        0      557  4558730 (stdout)
    1        4    10680        0        0 /bin/cat
cpu%  iostats cat /tmp/a.mp3 > /dev/null

read      4569410 bytes, 760.5784 Kb/sec
write     4558730 bytes, 44968.08 Kb/sec
protocol  9167204 bytes, 1384.312 Kb/sec
rpc       1143 count

Message    Count   Low  High  Time Averg          in      out
version        1     0     0     0     0 ms       19       19 bytes
attach         1     2     2     2     2 ms       25       20 bytes
walk           9     1   436   488    54 ms      248      306 bytes
open           5     0     4     9     1 ms       60      120 bytes
read         562     1    16  5867    10 ms    12926  4575592 bytes
write        557     0     4    99     0 ms  4571541     6127 bytes
clunk          8     0     1     2     0 ms       88       56 bytes

Opens    Reads  (bytes)   Writes  (bytes) File
    1      558  4558730        0        0 /tmp/a.mp3
    1        0        0      557  4558730 (stdout)
    1        4    10680        0        0 /bin/cat
cpu%
cpu% srvold9p -c -F -m /n/kremvax -p kremvax -n tcp!zamenhof!9fs
cpu% iostats cat  /n/kremvax/tmp/a.mp3 > /dev/null

read      4569410 bytes, 1501.957 Kb/sec
write     4558730 bytes, 42398.5 Kb/sec
protocol  9167190 bytes, 2840.207 Kb/sec
rpc       1143 count

Message    Count   Low  High  Time Averg          in      out
version        1     1     1     1     1 ms       19       19 bytes
attach         1     3     3     3     3 ms       25       20 bytes
walk           9     1    26    54     6 ms      246      306 bytes
open           5     1     8    14     2 ms       60      120 bytes
read         562     1    13  2971     5 ms    12926  4575592 bytes
write        557     0     1   105     0 ms  4571541     6127 bytes
clunk          8     0     2     4     0 ms       88       56 bytes

Opens    Reads  (bytes)   Writes  (bytes) File
    1      558  4558730        0        0 /n/kremvax/tmp/a.mp3
    1        0        0      557  4558730 (stdout)
    1        4    10680        0        0 /bin/cat

[9fans] 3e mpg123 plays on off on off on off on 4e

[Axel Belinfante]

Without recompiling mpg123 I just used it to play an mp3 file that
is served over (my hacked wrt '-l user' in attach message) u9fs.
It no plays a second, pauses a (part of?) a second, plays again, pauses
again, etc etc. The load on the machine is pretty low -- lower than
I recall from using mpg123 on 3e.

Anyone any ideas?

Axel -- who will now run to catch his train.