Re: Enhanced PLAY.CMD with play list support
From: Michael Baldwin Bruce (mbbruce_at_mighty.co.za)
Date: 11/05/04
- Next message: TimC: "Re: Ambiguous interfaces"
- Previous message: Richard E Maine: "Re: how to efficienly remove elements from an array"
- Maybe in reply to: Michael Baldwin Bruce: "Re: Enhanced PLAY.CMD with play list support"
- Next in thread: Real Friendly Neighborhood Vote Ranger: "Re: Enhanced PLAY.CMD with play list support"
- Reply: Real Friendly Neighborhood Vote Ranger: "Re: Enhanced PLAY.CMD with play list support"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 4 Nov 2004 16:53:30 -0800
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.
>
> >> 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: TimC: "Re: Ambiguous interfaces"
- Previous message: Richard E Maine: "Re: how to efficienly remove elements from an array"
- Maybe in reply to: Michael Baldwin Bruce: "Re: Enhanced PLAY.CMD with play list support"
- Next in thread: Real Friendly Neighborhood Vote Ranger: "Re: Enhanced PLAY.CMD with play list support"
- Reply: Real Friendly Neighborhood Vote Ranger: "Re: Enhanced PLAY.CMD with play list support"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|