f



Re: SYS$STARTUP:MMOV$STARTUP.COM -- lacks something (priority)

From: lewis@mazda.mitre.org (Keith A. Lewis)

> [...]
> 
> Actually the problem is recurring in a different way since I moved the
> music library to a Linux disk and now play it over NFS.  Thinking of
> copying to a scratch directory on VMS before playing... if I can't figure
> out how to raise the priority of the NFS-serving Linux processes.

   Locating the bottleneck could help.  Is the sloth at the server or
the client?  Can the (VMS) NFS client do more read-ahesd or caching,
perhaps?

> Do you get a popping sound between songs due to audio device resets?  I have
> a solution to that.

   I've done very little with the audio, but I'd suggest posting it. 
That way I (or one of the other six people who care) might discover it
in a Google search someday.

------------------------------------------------------------------------

   Steven M. Schweda               (+1) 651-699-9818
   382 South Warwick Street        sms@antinode-org
   Saint Paul  MN  55105-2547
0
sms (1038)
2/12/2004 10:57:05 PM
comp.os.vms 21904 articles. 1 followers. Post Follow

1 Replies
380 Views

Similar Articles

[PageSpeed] 52

sms@antinode.org writes in article <04021216570566@antinode.org> dated Thu, 12 Feb 2004 16:57:05 -0600 (CST):
>From: lewis@mazda.mitre.org (Keith A. Lewis)
>> Actually the problem is recurring in a different way since I moved the
>> music library to a Linux disk and now play it over NFS.  Thinking of
>> copying to a scratch directory on VMS before playing... if I can't figure
>> out how to raise the priority of the NFS-serving Linux processes.
>
>   Locating the bottleneck could help.  Is the sloth at the server or
>the client?  Can the (VMS) NFS client do more read-ahesd or caching,
>perhaps?

The bottleneck is somewhere on the Linux (server) side of things, probably
the disk, because the problem is worst when waking up sleepy Linux processes
that are presumably swapped out (or whatever the *n%x equivalent of that
is).  Sorry I'm getting a little off-topic in a VMS newsgroup.

Increasing the client-side buffer size is a good idea, much cleaner than
copying the file.

>> Do you get a popping sound between songs due to audio device resets?  I have
>> a solution to that.
>
>   I've done very little with the audio, but I'd suggest posting it. 
>That way I (or one of the other six people who care) might discover it
>in a Google search someday.

I hesitate to post all the C code but I'll briefly explain my problem and
solution. When the last virtual audio (output) device is closed, VMS
(MMOV$SERVER I think) seems to perform a hardware reset on my PWS sound
device.  I'm not sure if it's a hardware reset exactly but it makes an
audible pop as if a cable is suddenly unplugged.  

So the solution is to keep at least one virtual device open all the time. 
You could dummy up a fake sound app which wrote a flatline output
continuously, but it would cut the output signal in half (MMOV$SERVER seems
to average the virtual outputs to calculate the physical output).  Not
really a problem if you bump up the volume, but that's not what I did.

I modifed MPG123 (a simple, command-line MP3 player which runs on VMS) to
use two system locks, call them "inner" and "outer".  It works like this:

Open MP3 file
Wait for "outer" lock		! don't let anybody leave
Wait for "inner" lock		! wait until it's my turn to play
Open virtual audio device
Release "outer" lock		! let the old guy go
Play audio
Release "inner" lock		! I'm done playing
Wait for "outer" lock		! is it OK to leave?
Close virtual audio device
Release "outer" lock		! bye

And of course I set the audio queue's JOB_LIMIT to 2.  

If anybody wants the C code, drop me a line at the address below (the one in
the headers doesn't work).  I will put it on the web some day soon.  

--Keith Lewis              klewis {at} mitre.org
The above may not (yet) represent the opinions of my employer.
0
lewis17 (80)
2/13/2004 8:04:36 PM
Reply: