RE: [xine-devel] Byteorder problems with lpcm audio decoder

[James Courtier-D. <Ja...@su...>]

The liblpcm plugin is the only one which has "ntohs" calls.
I vote to replace them with swab.
I don't think any of the demuxers do any swabs or byte reordering.
Most Sound cards output in LE format.
So, put a swab in there instead of the for loop.
I don't think the
> #if     WORDS_BIGENDIAN
is needed. I think we need a swab on all platforms.
I am downloading EGGMEN now, to test on my i386 platform with the swab in
there.

It might be a good idea to go through the entire xine source, and hightlight
BIG/Little engian sensitive parts.
It might also be a good idea to create a web site, with as many different
sample sources as possible for testing purposes.


Cheers
James




> -----Original Message-----
> From: xin...@li...
> [mailto:xin...@li...]On Behalf Of Juergen Keil
> Sent: 30 August 2001 20:56
> To: xin...@li...
> Subject: [xine-devel] Byteorder problems with lpcm audio decoder
>
>
> Hi,
>
> there's a byteorder problem when playing AVI files with PCM audio through
> xine. Example file:
>
>     http://www.pad.myweb.nl/Eggmen%20in%20Space.html
>
>
> demux_avi.c obviously sends 16-bit PCM samples in
> intel/little-endian format
> to the liblpcm/xine_decoder.c LPCM audio decoder.
>
> liblpcm/xine_decoder.c includes some byte-swapping code before the PCM
> samples are sent to the audio driver:
>
>     for(i=0; i<buf->size/2; i++)
> 	p[i] = ntohs(p[i]);
>
> Note that on a SPARC/big-endian CPU, ntohs() is a NOOP, i.e. the
> samples are
> sent to audio driver untranslated, using the wrong byte order ==> noise.
>
> On an Intel/little-endian CPU, ntohs() swaps bytes, i.e. the samples are
> send to the audio driver in wrong byte order, too ==> noise.
>
>
> The obvious fix (for AVI files) would be, to replace the for() loop with:
>
> #if     WORDS_BIGENDIAN
>     swab(buf->content, buf->content, buf->size);
> #endif
>
>
> Problem is, that there are other demuxers that can send out LPCM audio
> (demux_mpeg_block.c, demux_ts.c) and that change might break LPCM
> for these
> demuxers / file formats.  Since I currently have no test files for the
> mgeg_block and ts demuxers that use LPCM, I cannot test the change.
>
>
> Probably my change is to simplistic, I'm sure the ntohs() is there for
> a reason.  Maybe we need two PCM audio formats (BUF_AUDIO_LPCM_BE and
> BUF_AUDIO_LPCM_LE), both handled by liblpcm/xine_decoder.c and
> liblpcm/xine_decoder.c uses the PCM format code and the WORDS_BIGENDIAN
> define to decide, if we need to swap the samples or not.
>
>
> So, does anyone know what byte order is sent by mpeg_block/ts in the LPCM
> case?
>
> --
> Jürgen Keil          		jk...@to...
> Tools GmbH			+49 (228) 9858011
>
>
> _______________________________________________
> xine-devel mailing list
> xin...@li...
> http://lists.sourceforge.net/lists/listinfo/xine-devel