Re: Enhanced PLAY.CMD with play list support
From: Real Friendly Neighborhood Vote Ranger (yyyiiinnnggg_at_yahoo.com)
Date: 11/05/04
- Next message: Michael Baldwin Bruce: "Re: digest 2453313"
- Previous message: Michael Baldwin Bruce: "Re: Enhanced PLAY.CMD with play list support"
- In reply to: Michael Baldwin Bruce: "Re: Enhanced PLAY.CMD with play list support"
- Next in thread: Lady Chatterly: "Re: Enhanced PLAY.CMD with play list support"
- Messages sorted by: [ date ] [ thread ]
Date: 5 Nov 2004 00:57:28 GMT
"Michael Baldwin Bruce" <mbbruce@mighty.co.za> wrote in message
news:602faa6b.0411041653.31b1558b@posting.google.com...
> bruce aka tholen@antispam.ham wrote in message
news:<Epfid.61086$Kl3.53120@twister.socal.rr.com>...
> > Marty writes:
> >
> > >>>>> Peter Weilbacher wrote:
> >
> > >>>>>> Michael DeBusk wrote:
> >
> > >>>>>>> Marty wrote:
> >
> > >>>>> The most important aspect of the script for me was the resource
leak
> > >>>>> fix. Something inside of Timidity_MCD does not get cleaned up
correctly
> > >>>>> without the call to mciRxExit(). Strangely, missing this call
doesn't
> > >>>>> seem to cause a problem with any other codecs that I've found,
just
> > >>>>> Timidity. I guess the other codecs are smarter about cleaning up
after
> > >>>>> sloppy processes.
> >
> > >>>> I've probably encountered that problem. There have been times when
> > >>>> PLAY.CMD would fail, while other audio file playing utilities would
> > >>>> continue to work, including some Windows-based ones. But I have
also
> > >>>> encountered one instance in which PLAY.CMD worked from inside my
editing
> > >>>> program but failed as a standalone utility in another windowed
command
> > >>>> prompt session. Haven't been able to figure that one out.
> >
> > >>> Did you get any messages from PLAY about a "REXX Alias" or something
to
> > >>> that effect?
> >
> > >> Unfortunately, I cannot reproduce the problem on demand, so I have to
> > >> rely on memory for the error message, but it was something like
> > >> "mciRxInit routine not found".
> >
> > > I've seen this type of thing before with other DLLs (most prominently
> > > REXXUTIL). The call to SysLoadFuncs returns a success, but REXX later
> > > claims that the functions which were allegedly just loaded are not
> > > available. I think this is a separate issue from the ones that I
> > > addressed with my changes.
> >
> > A separate issue involving a bug in REXX?
>
> Who's Rexx, bruce?
>
> >
> > >>> Instead of maintaining handles with binary data and the
> > >>> like, in REXX you create a name or "alias" to associate with your
MCI
> > >>> device. Every multimedia operation you do in REXX is done against
this
> > >>> alias so that the state is maintained by the MMPM libraries, but
your
> > >>> context is maintained.
> > >>>
> > >>> Unfortunately, PLAY.CMD hard-codes a REXX alias name, so that if you
> > >>> attempt to run two of them at the same time, the same alias is used
and
> > >>> the context is applied from your original running PLAY.CMD.
Likewise,
> > >>> if you fail to close out and free the REXX alias (due to killing the
CMD
> > >>> process, for example), its state continues to be maintained by the
> > >>> system. The alias is global. You have to free up the REXX alias
before
> > >>> it can be used again.
> >
> > >> Well, that seems consistent with one occasion in which I was
repeatedly
> > >> playing a very short audio clip, pressing the key to repeat the play
> > >> very rapidly, such that it seems possible the system started up the
next
> > >> PLAY before completely cleaning up after the previous PLAY.
> >
> > >>> My version of PLAY checks for this condition and performs the free
if
> > >>> needed.
> >
> > >> I'm not sure under what conditions my audio subsystem supports the
> > >> simultaneous playing of two audio streams. I'm using the SoundMax
> > >> audio built in to the Intel 850 motherboard (ADI 1885). I know that
> > >> if I'm playing a .wav file, then fire up Mahjongg, it complains about
> > >> the device being busy, even though I've disabled sounds in Mahjongg.
> >
> > > Even if your audio drivers are capable of audio stream mixing, an
> > > application can still open the device in exclusive mode. What are you
> > > using to play the wave file?
> >
> > I've tried a variety of different utilities over the years. I probably
> > use PLAY.CMD more often than anything else. I like the simplicity of
> > the command line interface.
> >
> > > I don't think the system will default to
> > > opening it exclusively if you double-click a wave file or use PLAY.
> >
> > Well, Mahjongg complains that the device is locked when PLAY is
> > being used to play a .wav file. When it's finished playing, no
> > such message occurs. Maybe Mahjongg wants exclusive access and
> > refuses to share, but then it shouldn't say that the device is
> > locked when it really isn't (if that is indeed the case).
>
> lol! Silly! Mahjong is a Chinese game of tiles. It can't complain
> about anything.
>
> > >Gamblers never win
> > >Mr Chin takes a cut from everything.
>
>
> >
> > >> On the other hand, the driver came with WarpMix, so it looks like it
> > >> should be able to mix at least a few audio sources.
> >
> > > I think WarpMix is tool used to set volume levels of various audio
> > > channels (CD, line in, etc.), correct?
> >
> > Yes.
> >
> > > That's different from stream
> > > "mixing" where different audio streams are combined, in software or
> > > hardware in some cases, into one stream that is played. The former
> > > process is an analog one and only happens among a fixed set of
channels.
> > > The latter is digital and can take place over a variable number of
> > > audio streams.
> >
> > Odd to use "mix" in the name if it doesn't do any mixing.
>
> Like Tom Mix, bruce?
>
> >
> > >>>> And I've
> > >>>> also seen cases where the first invocation of PLAY.CMD would return
an
> > >>>> error message but a second invocation would cause the entire
windowed
> > >>>> command prompt session to die.
> >
> > >>> This one sounds like the MM libraries ran out of resources somewhere
or
> > >>> were left in an unstable state. This can be caused by not cleaning
up
> > >>> properly. I've seen this happen on my own system but haven't been
able
> > >>> to nail down the exact spark that triggered it. Since modifying
> > >>> PLAY.CMD, I haven't seen this happen, but I'm not convinced that the
> > >>> problem is gone yet.
> >
> > >>>> I'm curious as to how much digging others did to try and find the
> > >>>> kinds of TIMEFMT supported by PLAY.CMD. I know it supports
"samples"
> > >>>> and "ms" (for milliseconds), but the default units are something
like
> > >>>> 15 samples (for 44.1 kHz audio). Haven't dug enough to understand
> > >>>> the origin of that choice. Any other time formats supported?
> >
> > >>> 15 samples / 44100 samples/sec = .00034 secs of audio
> > >>>
> > >>> Seems like a strange choice indeed. It is approximately 1/100th of
a
> > >>> normal process time slice (32ms). That's a bit of a stretch,
though.
> >
> > >> Sufficiently odd that I never use the default (other than to
> > >> investigate it), which means I always have to use the TIMEFMT
keyword,
> > >> which is a bit annoying. On the other hand, my editing program works
> > >> with the audio samples in memory, so to play an edited clip using
> > >> PLAY.CMD, I need to write it to disk, so as long as I write just the
> > >> clip I want to hear, I don't have to bother with the FROM, TO, and
> > >> TIMEFMT keywords. Would be nicer to simply play a clip of audio
> > >> samples directly from memory and thus avoid hitting the disk every
> > >> time I want to repeat a short clip, but then I'd have to learn an
> > >> entirely new part of the multimedia system. One of the editing
> > >> tools plays a short clip whose end points I can move in 0.01 sec
> > >> increments using the cursor keys; it has to write a new .wav file
> > >> every time I press the key so as to utilize PLAY.CMD.
> >
> > > The learning curve for the multimedia subsystem proper can be quite
> > > steep. It would allow you the ability to play from memory, volume
> > > control, and data format independence (you could use codecs to read
and
> > > write your raw audio data), but getting there is tricky.
> >
> > Reading .wav files is sufficiently simple that I can avoid the overhead
> > of a codec. On the other hand, handling every possible data type is a
> > headache for the source code. There are digital audio units becoming
> > available that can record 24-bit samples. Judging from the recording
> > time available, they're not wasting space by padding the samples to
> > 32-bit. If I wanted to handle files like that, I'd need to rewrite
> > the code to read three 8-bit samples, because there is no native 24-bit
> > data type.
> >
> > > In what language is your main project written?
> >
> > I rely heavily on a library of routines that I've written over the last
> > two decades, largely in Fortran. The Fourier transform is an example.
> > A lot of the "magic" my editor can perform (fixing wrong notes, for
> > example) uses the Fourier transform.
>
> Fortran, bruce? lol!!!
>
> >
> > > I ask because I'm
> > > trudging my way through the same territory right now in one of my C
> > > projects, and maybe I can provide you with a simplified code snippet
to
> > > get the system going for you. I have DART and raw MMPM code from past
> > > projects, but they were muddled down in the mechanics of
synchronization
> > > with a video stream, so they don't serve as good examples.
> >
> > They might make good examples to the WarpVision people. The only time
> > I tried WarpVision, I never could get decent synchronization with the
> > video, even with the adjustment keys provided.
> >
> > > Also, they
> > > only dealt in pumping raw data out to the sound card. My new code
will
> > > need to be a bit more robust (being format-independent, for example).
> >
> > But API calls are API calls, regardless of the language used to call
> > them.
>
> do you often call apis, bruce?
- Next message: Michael Baldwin Bruce: "Re: digest 2453313"
- Previous message: Michael Baldwin Bruce: "Re: Enhanced PLAY.CMD with play list support"
- In reply to: Michael Baldwin Bruce: "Re: Enhanced PLAY.CMD with play list support"
- Next in thread: Lady Chatterly: "Re: Enhanced PLAY.CMD with play list support"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
