[patch] little-endian dmasound silently fails

[patch] little-endian dmasound silently fails

[Brad Midgley]

ha. that's a pun. it's not silent at all when you listen.

seriously, the dmasound driver advertises itself as little-endian capable
but doesn't provide the proper translators. so clients like openh323
switch the mode to little-endian (without any errors) and write
little-endian data and the result is a hissing noise!

i think this is all that is needed so the little-endian switch will fail
(i can't test this; i'm not at home). the proper fix will be to implement
the little-endian versions and i've started that but i'm getting mired in
the details -- this is terse code!

--- drivers/sound/dmasound.c.orig       Fri Feb  4 16:01:17 2000
+++ drivers/sound/dmasound.c    Fri Feb  4 16:02:26 2000
@@ -2211,12 +2211,12 @@
 #ifdef CONFIG_PPC
 static TRANS transAwacsNormal = {
        pmac_ct_law, pmac_ct_law, pmac_ct_s8, pmac_ct_u8,
-       pmac_ct_s16, pmac_ct_u16, pmac_ct_s16, pmac_ct_u16
+       pmac_ct_s16, pmac_ct_u16, NULL, NULL
 };

 static TRANS transAwacsExpand = {
        pmac_ctx_law, pmac_ctx_law, pmac_ctx_s8, pmac_ctx_u8,
-       pmac_ctx_s16, pmac_ctx_u16, pmac_ctx_s16, pmac_ctx_u16
+       pmac_ctx_s16, pmac_ctx_u16, NULL, NULL
 };
 #endif /* CONFIG_PPC */

Brad
brad@turbolinux.com | http://www.turbolinux.com/~brad/


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

Re: [patch] little-endian dmasound silently fails

[Takashi Oe]

On Fri, 4 Feb 2000, Brad Midgley wrote:

> ha. that's a pun. it's not silent at all when you listen.
>
> seriously, the dmasound driver advertises itself as little-endian capable
> but doesn't provide the proper translators. so clients like openh323
> switch the mode to little-endian (without any errors) and write
> little-endian data and the result is a hissing noise!

How does it write "little-endian data"?  Does the program take care of CPU
being big-endian in some way?  If not, I'd think it's the program's fault.


Takashi Oe


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

Re: [patch] little-endian dmasound silently fails

[Brad Midgley]

> How does it write "little-endian data"?  Does the program take care of CPU
> being big-endian in some way?  If not, I'd think it's the program's fault.

the api provides for a way for clients to set the driver to accept
little-endian data. worse than simply not implementing it, dmasound also
makes it *appear* that it implements it.

#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/soundcard.h>

void die(char *m) {
  printf("%s\n", m);
  exit(1);
}

int main(int argc, char *argv[]) {
  int fd, bytesex;

  fd = open("/dev/dsp", O_WRONLY);
  if(fd < 0) die("couldn't open /dev/dsp");

  bytesex = AFMT_S16_LE;
  if(ioctl(fd, SNDCTL_DSP_SETFMT, &bytesex))
    die("little-endian sound isn't implemented in this driver\n");

  printf("supposedly the sound driver supports little-endian data. :(\n");

  return 0;
}


Brad
brad@turbolinux.com | http://www.turbolinux.com/~brad/


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

Re: [patch] little-endian dmasound silently fails

[Takashi Oe]

On Fri, 4 Feb 2000, Brad Midgley wrote:

> > How does it write "little-endian data"?  Does the program take care of CPU
> > being big-endian in some way?  If not, I'd think it's the program's fault.
>
> the api provides for a way for clients to set the driver to accept
> little-endian data. worse than simply not implementing it, dmasound also
> makes it *appear* that it implements it.

Maybe because it does support it?  Well, seriously, I've just checked the
driver is okay wrt *S16_LE/BE at least on AWACS rev. 2.

First, I wrote an app to play a sound file correctly when AFMT_S16_BE is
specified.  Then, I modified the app so that it will byte swap the 16-bit
data but still with AFMT_S16_BE.  As expected, it made some annoying
noise when it was asked to play the same sound file.  Now, I modified the
code again to let it specify AFMT_S16_LE instead.  Well, it played the
sound file correctly just as hoped.

I know a lot of people are not happy about our sound driver, but I
don't think this is dmasound's fault.  Luckily for us, many "broken"
OSS-compatible apps tend to work just fine if we simply modify them to ask
for AFMT_S16_NE not *_LE, though performance critical apps should be fixed
with more effort.


Takashi Oe


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

Re: [patch] little-endian dmasound silently fails

[BenH]

On Fri, Feb 4, 2000, Takashi Oe <toe@unlserve.unl.edu> wrote:

>Maybe because it does support it?  Well, seriously, I've just checked the
>driver is okay wrt *S16_LE/BE at least on AWACS rev. 2.
>
>First, I wrote an app to play a sound file correctly when AFMT_S16_BE is
>specified.  Then, I modified the app so that it will byte swap the 16-bit
>data but still with AFMT_S16_BE.  As expected, it made some annoying
>noise when it was asked to play the same sound file.  Now, I modified the
>code again to let it specify AFMT_S16_LE instead.  Well, it played the
>sound file correctly just as hoped.
>
>I know a lot of people are not happy about our sound driver, but I
>don't think this is dmasound's fault.  Luckily for us, many "broken"
>OSS-compatible apps tend to work just fine if we simply modify them to ask
>for AFMT_S16_NE not *_LE, though performance critical apps should be fixed
>with more effort.

Actually, I had some reports about this problem too and I'm wondering if
all revisions of AWACS actually support byte swapping. (I think I
remember seeing a comment on this list telling explicitely that some
revisions didn't support it).


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

Re: [patch] little-endian dmasound silently fails

[Takashi Oe]

BenH wrote:
>
> Actually, I had some reports about this problem too and I'm wondering if
> all revisions of AWACS actually support byte swapping. (I think I
> remember seeing a comment on this list telling explicitely that some
> revisions didn't support it).

AWACS on Nubus PowerMac doesn't support byte swapping.  I know for sure
rev. 2 and 3 (beige G3) do support it.  In any case, many apps are
simply broken.

By the way, I was looking through Darwin code the other day, and I
noticed their pmu code have the following for pmu command:

        kPMUsoundSet            = 0x90,  // sound power control
        kPMUSetDFAC             = 0x91,  // set DFAC register (DBLite)
        kPMUsoundRead           = 0x98,  // read sound power state
        kPMUReadDFAC            = 0x99,  // read DFAC register (DBLite)

Do you have any idea if they are used with G3 PowerBooks under Mac OS?
There was a report long time that an user would lose ability to play
audio CD from media bay drive after sleep, and he needed to boot Mac OS
completely before coming back to Linux to get the lost audio CD
capability back, though beep and other sound functions weren't affected
at all.


Takashi Oe

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

Re: [patch] little-endian dmasound silently fails

[BenH]

On Sat, Feb 5, 2000, Takashi Oe <toe@unlserve.unl.edu> wrote:

>Do you have any idea if they are used with G3 PowerBooks under Mac OS?
>There was a report long time that an user would lose ability to play
>audio CD from media bay drive after sleep, and he needed to boot Mac OS
>completely before coming back to Linux to get the lost audio CD
>capability back, though beep and other sound functions weren't affected
>at all.

They don't seem to be called on the wallstreet. In recent kernels, me and
Paul added a few timing fixes (mostly some delays here or there) and I
added some basic power control via the FCR register. I now have sleep
working fine when getting out of sleep. I can even play an MP3, sleep,
and the play resumes when I wake up.


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

Re: [patch] little-endian dmasound silently fails

[Brad Boyer]

BenH wrote:
> Actually, I had some reports about this problem too and I'm wondering if
> all revisions of AWACS actually support byte swapping. (I think I
> remember seeing a comment on this list telling explicitely that some
> revisions didn't support it).

Well, I know I complained several times, but I found out recently when I
did some more careful testing that I was wrong.  I have a rev 2 AWACS chip
in my computer, and the byteswap does work.  My problem was that I had a
number of programs which set the format improperly, and I didn't notice
the problem when I looked at the code.  As an example, snes9x explicitly
asks for a little-endian format, then generates the sound in native
order.  Unless you can find someone with a rev 1 AWACS chip and test
that one, I imagine you can assume that all of them support byteswap
properly.  And since the 7600 I have is one of the oldest machines that
is supported, I imagine you won't find anyone with rev 1 unless they
changed in between the 7500 and 7600.  I would guess that rev 1 was
used in the nubus powermacs.

	Brad Boyer
	flar@pants.nu


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

Re: [patch] little-endian dmasound silently fails

[Brad Midgley]

> don't think this is dmasound's fault.  Luckily for us, many "broken"
> OSS-compatible apps tend to work just fine if we simply modify them to
> ask for AFMT_S16_NE not *_LE, though performance critical apps should
> be fixed with more effort.

is the app broken because it tries to use _LE formats?

i agree it's not optimal and reflects laziness on the developer's part to
try to make everything work as if it's little-endian, but that the api
allows it, right?

Brad
brad@turbolinux.com | http://www.turbolinux.com/~brad/


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

Re: [patch] little-endian dmasound silently fails

[Takashi Oe]

Hi,

Brad Midgley wrote:
>
> > don't think this is dmasound's fault.  Luckily for us, many "broken"
> > OSS-compatible apps tend to work just fine if we simply modify them to
> > ask for AFMT_S16_NE not *_LE, though performance critical apps should
> > be fixed with more effort.
>
> is the app broken because it tries to use _LE formats?

No, no, no.  There is no problem in trying to use _LE or whatever
formats.  The problem is that many apps *don't* pass the data in
little-endian format when, in fact, they ask the driver to be ready for
little-endian data.  Please have a closer look at any app that you think
should work but fail.  I bet they are genuinely broken (i.e. passing
data in wrong byte order).  Note that, whenever apps use short or long
or int, they must be aware of byte order.

> i agree it's not optimal and reflects laziness on the developer's part to
> try to make everything work as if it's little-endian, but that the api
> allows it, right?

Some sound formats are little endian, and others are big endian.  If the
app can pass the multi-byte data to the driver without byte-swapping in
software, it should, but, of course, it can do in any way.

By the way, dmasound should probably optimize for stereo not mono, and
it should not support _U8/16 variants, perhaps, since AWACS doesn't
support them in hardware.  The format conversion is done in software
(kernel space).


Takashi Oe

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

Re: [patch] little-endian dmasound silently fails

[Giuliano Pochini]

> ha. that's a pun. it's not silent at all when you listen.
>
> seriously, the dmasound driver advertises itself as little-endian capable
> but doesn't provide the proper translators.

On my PMac7300 little-endian mode works fine. I don't know the revision of the
snd chip. Some programs don't pay attention on the endianess of the CPU and
always set AFMT_*_LE -->KSHSHSHSHSHSHSH

Bye.


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