Hi,
i've got some problems with my ACM driver. An ACM driver is a Windows codec
which enables applications to use ogg vorbis and create .WAV files. Due to
the nature of ACM drivers I ran into a few problems.
The Audio Compression Manager, which is the interface between the
application and the driver sends messages to the driver which has to handle
them. The ACM opens the stream, passing a header structure. Then a lot of
conversion messages are passed to the driver. These conversion messages
provide about 2K of data at the max per message and the driver returns the
decoded data.
Now the problem is, that the ACM wants each message to be processed and PCM
data to be returned. If no PCM data is returned the ACM closes the stream
and no further conversion for that stream is possible.
1.) Headers.
Embedded in the vorbis stream ar three headers, one of them contains the
codebook and is about 10K in size. As long as the headers are read, no PCM
data can be returned. This leads to a few problems:
- the actual PCM data lags behind. You'd see this for example in WinAmp.
The time left displayed does not reflect the actual time left for the file.
- as long as the headers are processed, I only could return a zeroed
sample. This would mean that the with each conversion a few samples of
silence is added.
I would not have the problem if I could save codebook in the header I get
when the stream is opened. This would require, that the codebook can be
saved separately (that is, it is not contained in the ogg stream).
Additionally I'd need to know the exact size of the codebook and it'd
have
to be the same size for all bitrates. But I fear that this is not constant.
2.) Size of ogg packets
Ogg packets are around 4K in size. Unfortunately the ACM cannot handle this
blocksize in most cases. I'd say about 2K at the max could be done.
Currently two or more messages are needed to get a complete ogg block and
extract the vorbis blocks from it. This again leads to bad response times
(about 1/2 of the messages need much more time to be processed).
If already have a few ideas to get around these two problems, but I'd like
to get some feedback from the list:
- Do not use the ogg layer and write the vorbis packets. All vorbis packets
I encountered so far are about 512B in size, that would fit a lot better,
but a lot of compatiblity would be lost, because you couldn't generate a
.ogg file by just eliminating the .WAV header.
- Put the codebook and headers into the .WAV header. Again, this would mean
that a .WAV file could not be converted into a .ogg file.
I hope I have been able to describe what my problems are.
regards,
Florian
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
