From: Robert Sanders <esquimaux73@ma...> - 2003-10-19 07:30:30
I've developed support for a variety of lower-bandwidth CODECs to
rdesktop. So far mu-Law and A-Law sound good, in addition to linear
PCM, but I'm having trouble getting IMA (DVI) ADPCM and Microsoft
ADPCM to work.
There are two remaining issues that seem simple. Any help would be appreciated.
The first is decoding the "extra data" chunk at the end of the format
chunk in sound format negotiation. Straight PCM and mu/A-law CODECs
don't have it, but MS ADPCM, IMA ADPCM, WMA, MP3, and GSM610 do. I
think I understand the structure of the GSM and ADPCM chunks, and
probably MP3. These should be identical to the format of the
corresponding WAV format chunks, but I can't find info on WMA within
WAV. It may not exist outside of RDP.
The second and more perplexing problem is that there seem to be 4
bytes of zeroes at the beginning of every packet of sound samples.
The current rdpsnd code skips over those first 4 bytes. That seems to
work well for linear PCM. It stops the popping. For more complicated
CODECs, though, that doesn't work. For ADPCM, that throws the packet
out of alignment. It goes from being evenly divisible by the
nBlockAlign (say, 512 bytes for ADPCM), to having 508 bytes of
incomplete data at the end that makes the decoder very unhappy.
No matter what CODEC I use, there are four zero bytes at the beginning
of the sample data. It seems unlikely that every format just
coincidentally includes 4 zeroes. I'm stumped. I'd almost think that
the packet parsing code is off by 4 bytes somehow, inserting 4 bytes
of trash at the beginning and losing 4 bytes of sample data at the
P.S. Right now I'm using the FFMPEG A/V CODEC suite, which is rather
huge, but the framework is in place to allow other libraries. I've
also pulled the relevant code out of SoX for inclusion within
rdesktop. The configure script will allow choosing between them.
From: Robert Sanders <esquimaux73@ma...> - 2003-10-20 10:52:17
Robert Sanders <esquimaux73@...> writes:
> The second and more perplexing problem is that there seem to be 4
> bytes of zeroes at the beginning of every packet of sound samples.
> The current rdpsnd code skips over those first 4 bytes. That seems to
> work well for linear PCM. It stops the popping. For more complicated
> CODECs, though, that doesn't work. For ADPCM, that throws the packet
> out of alignment.
I found a trick that seems to solve this. Basically, I copy the last
4 bytes of the RDPSND_WRITE command that precedes the sample data.
It's not being used by anything else. I can't tell whether this is
some trick to "pre-load" the sample buffer, or some error in
rdesktop's interpretation of the RDP sound protocol. As so much of
RDP seems to have been puzzled out without the benefit of
documentation, it's a wonder it works at all.