Byte order in sound drivers

Byte order in sound drivers

[Bryce McKinlay]

It seems that some of the newwer media player applications (including
mplayer and the latest xmms from CVS) swap the byte order of sound
samples before playing them on PPC, and this results in nothing but
static from both the dmasound and usb audio drivers.

Is this because the sound driver perhaps already doing endian-swapping,
and can I disable it? Are these applications correct to want to convert
samples into the native endian-ness?

I'm using a 2.4.14 benh kernel.

cheers

Bryce.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Byte order in sound drivers

[Jeff Koftinoff]

On Saturday, December 1, 2001, at 02:16 AM, Bryce McKinlay wrote:

>
> It seems that some of the newwer media player applications (including
> mplayer and the latest xmms from CVS) swap the byte order of sound
> samples before playing them on PPC, and this results in nothing but
> static from both the dmasound and usb audio drivers.
>
> Is this because the sound driver perhaps already doing endian-swapping,
> and can I disable it? Are these applications correct to want to convert
> samples into the native endian-ness?
>
> I'm using a 2.4.14 benh kernel.
>
> cheers
>
> Bryce.
>
>

XMMS has endian problems with wav files, but not mp3 files - It is
listed as a bug as well for sparc.  The problem solely lies with
applications that are written incorrectly.

jeff


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Byte order in sound drivers

[Bryce McKinlay]

Jeff Koftinoff wrote:

> XMMS has endian problems with wav files, but not mp3 files - It is
> listed as a bug as well for sparc.  The problem solely lies with
> applications that are written incorrectly.


The most recent release of XMMS (0.9.5) works correctly for me for both
MP3 and WAV files, but not CD audio for which the input plugin returns
sound in the native endian-ness.

But, since that release, the following change was made in XMMS CVS:

Thu Jul  5 12:25:51 CEST 2001  Håvard Kvålen  <havardk@xmms.org>

    * Output/OSS/audio.c (oss_set_audio_params): Do endian/sign
    conversion if necessary.


This breaks it on LinuxPPC 2.4.14-ben0 with both the dmasound and
usb/audio drivers (but, amusingly, fixes the CD audio). Another
application, mplayer, also seems to have the same problem - it says
something like "big endian detected, byte conversion enabled" and
doesn't work, except for 8-bit sound files.

What I want to know is whether these applications are wrong to do this -
does the Linux PPC audio drivers expect audio to be little endian?

regards

Bryce.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Byte order in sound drivers

[Bryce McKinlay]

Bryce McKinlay wrote:

> The most recent release of XMMS (0.9.5) works correctly for me for both
> MP3 and WAV files, but not CD audio for which the input plugin returns
> sound in the native endian-ness.


Sorry, I meant to say version 1.2.5 not 0.9.5.

regards

Bryce.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Byte order in sound drivers

[Benjamin Herrenschmidt]

>
>The most recent release of XMMS (0.9.5) works correctly for me for both
>MP3 and WAV files, but not CD audio for which the input plugin returns
>sound in the native endian-ness.

So far, I had MP3s working but not WAV nor cdread (blank noise in both
cases). I didn't yet try 0.9.5 though.

>But, since that release, the following change was made in XMMS CVS:
>
>Thu Jul  5 12:25:51 CEST 2001  Håvard Kvålen  <havardk@xmms.org>
>
>    * Output/OSS/audio.c (oss_set_audio_params): Do endian/sign
>    conversion if necessary.
>
>
>This breaks it on LinuxPPC 2.4.14-ben0 with both the dmasound and
>usb/audio drivers (but, amusingly, fixes the CD audio). Another
>application, mplayer, also seems to have the same problem - it says
>something like "big endian detected, byte conversion enabled" and
>doesn't work, except for 8-bit sound files.
>
>What I want to know is whether these applications are wrong to do this -
>does the Linux PPC audio drivers expect audio to be little endian?

It depends on the HW you have. Most recent machines don't do HW
byteswap, and so accept only big-endian samples. The way this is
implemented in our driver currently is a bit weird though, the
setformat ioctl won't fail when trying to set an LE format, but
it will set the equivalent BE format. So the application is
expected to read back the format to figure out what had to be
done.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Byte order in sound drivers

[Benjamin Herrenschmidt]

>It depends on the HW you have. Most recent machines don't do HW
>byteswap, and so accept only big-endian samples. The way this is
>implemented in our driver currently is a bit weird though, the
>setformat ioctl won't fail when trying to set an LE format, but
>it will set the equivalent BE format. So the application is
>expected to read back the format to figure out what had to be
>done.

Well, the current dmasound behaviour is definitely broken. I'm
changing it now so that when asked for an _LE format on a chip
that do only _BE will return -EINVAL.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Byte order in sound drivers

[Giuliano Pochini]

> >It depends on the HW you have. Most recent machines don't do HW
> >byteswap, and so accept only big-endian samples. The way this is
> >implemented in our driver currently is a bit weird though, the
> >setformat ioctl won't fail when trying to set an LE format, but
> >it will set the equivalent BE format. So the application is
> >expected to read back the format to figure out what had to be
> >done.

Same thing with some SoundBlasters. That's why there is a mess with
audio andianess.


Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Byte order in sound drivers

[Haavard Kvaalen]

On Sun, 2 Dec 2001, Benjamin Herrenschmidt wrote:

> Most recent machines don't do HW byteswap, and so accept only
> big-endian samples. The way this is implemented in our driver
> currently is a bit weird though, the setformat ioctl won't fail when
> trying to set an LE format, but it will set the equivalent BE format.

This is the correct way to tell the application what format the driver can
handle, and XMMS depends on this to be working.

--
Håvard Kvålen


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Byte order in sound drivers

[Bryce McKinlay]

Benjamin Herrenschmidt wrote:

>>The most recent release of XMMS (0.9.5) works correctly for me for both
>>MP3 and WAV files, but not CD audio for which the input plugin returns
>>sound in the native endian-ness.
>>
>
>So far, I had MP3s working but not WAV nor cdread (blank noise in both
>cases). I didn't yet try 0.9.5 though.
>

I should mention I was using the "xmms-cdread" plugin from
ftp://mud.stack.nl/pub/OuterSpace/willem, along with the ide-scsi
driver, to get cd audio going. The built in XMMS "cdaudio" plugin didn't
work for my Ti 500.

>>It depends on the HW you have. Most recent machines don't do HW
>>byteswap, and so accept only big-endian samples. The way this is
>>implemented in our driver currently is a bit weird though, the
>>setformat ioctl won't fail when trying to set an LE format, but
>>it will set the equivalent BE format. So the application is
>>expected to read back the format to figure out what had to be
>>done.
>
>
>Well, the current dmasound behaviour is definitely broken. I'm
>changing it now so that when asked for an _LE format on a chip
>that do only _BE will return -EINVAL.
>

Interesting, thanks for looking at that. I wonder if the USB audio
driver has the same problem, since I get exactly the same behaviour with
my sound sticks.

regards

Bryce.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/