[Flac-dev] Re: ACM codec
danielrsouza at hotmail.com
Fri Oct 5 07:08:04 PDT 2001
I had to make some assumptions writing the driver, because I had no previous
experience writing ACM drivers. I did what I could based in Microsoft's
documentation but, of course, I made same mistakes. I had no time to test
the code I wrote yet and will not in the next 2 weeks. All I can tell you
now is about what I did and about my sources. So, considering your
enthusiasm, I suggest you take the code I wrote and continue or use as
reference. If you want this, let me know. If not, then I ask you for same
patience, since I have not much time. It's not important the paternity of
the driver, but the driver done. I just think it should not be published
Now, let's talk about your lest comments.
>Which says nothing. The above text applies to renderers and capture
>filters, not to intermediate filters like compressors. Especially all
>standard AVI and WAV filters support the WAVEFORMATEXTENSIBLE structure,
>whether the docs state something different or not.
If you say it is, so it is. But then I ask you, did your Vorbis ACM driver
work? Will WAVE_FORMAT_EXTENSIBLE id be recognized in old 16bits Windows
>So when the driver has to decompress the second file it creates a marker
>and the metadata and feeds it to the FLAC encoder. Or do you use a lower
>level API than the stream en/decoder from libFLAC?
Actually, I had not thought about it until now, so the driver assumes the
FLAC data isn't malformed but, yes, the solution is add what is missing.
>May I ask how?
A client software can use the acmFormatSuggest function, that sends an
ACMDM_FORMAT_SUGGEST message to the driver, to check the driver for a
Here's an excerpt about it taken from the Microsoft Platform SDK:
Generating a Nonstandard Format
Sometimes an application needs a nonstandard format. For example, an
application might need a 16-kHz ADPCM-format file. Because 16 kHz is
nonstandard, the enumeration functions will not generate this format. In
fact, short of custom coding the format algorithms into the application,
there is no reliable way to generate a nonstandard format. It is sometimes
possible, however, to generate an analogous format by setting up a valid PCM
format with all the required information and then using the acmFormatSuggest
function. Because compressors and decompressors try to suggest a format that
is closest to the desired format, the number of channels and frequency are
>This may be a dumb question, but where in the registry did you find this?
>So, then which message shows the compression options dialog for ACM
>All drivers support the DRV_CONFIGURE message, which shows the control
>panel dialog. but the DDK says:
>The DRV_CONFIGURE message is one of the standard driver messages. A client
>sends the message by calling the driver's DriverProc entry point, passing
>the specified parameter values. Typically, this message is sent by the
>Control Panel's Multimedia applet.
>Drivers display a dialog box to obtain configuration parameters from the
>system administrator. Your driver must confirm that the client has
>which is an excerpt from the DRV_CONFIGURE reference in the DDK.
>Additionally the DRV_CONFIGURE message is usually sent to a driver, that
>was opened with no parameters (0 as argument to DRV_OPEN). So the options
>would have to be common for one driver instance. Unfortunately one driver
>instance can be used to open multiple streams, which should have their own
>diffferent options each.
>Another dialog is the ACMDM_DRIVER_ABOUT dialog, which has its counterpart
>in the ICM_ABOUT message.
>But only the ICM drivers have the ICM_CONFIGURE message for changing
>compression options. I can't find a similar message for the ACM drivers.
>Can you enlighten me here.
I couldn't find the previous excerpt in the Windows 2000 DDK. Maybe you can
help me on it.
Here's an excerpt about it taken from the Microsoft Platform DDK:
Once a driver is open, you can direct it to carry out tasks by using the
SendDriverMessage function to send driver messages to the driver. For
example, you can direct the driver to display its configuration dialog box
by sending the DRV_CONFIGURE message. Before sending this message, you must
determine whether the driver has a configuration dialog box by sending the
DRV_QUERYCONFIGURE message and checking for a nonzero return value. Many
drivers provide a set of custom messages that you can send to direct the
operations of the driver.
So, a client software can ask for the configuration box at any time.
I confirmed it in the IMA ADPCM driver's code provided by Microsoft. So I
used it as a compression options' dialog.
PS: Sorry for the previous malformed messages. I hope I have it fixed now.
More information about the Flac-dev