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
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/
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/
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/
On Fri, Feb 4, 2000, Takashi Oe [off-list ref] 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/
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/
On Sat, Feb 5, 2000, Takashi Oe [off-list ref] 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/
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/
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/
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/
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/