On Sat, Aug 11, 2001, Geert Uytterhoeven wrote:
On Fri, 10 Aug 2001, Iain Sandoe wrote:
quoted
quoted
The attached patch adds code to drivers/sound/dmasound/trans_16.c to
byteswap little-endian audio samples for hardware that needs it (like the
DACA audio chip in the iBook and iBook FireWire), and also marks the DACA
in the iBook FireWire as being unable to handle little-endian audio
samples (in dmasound_awacs.c).
we've been round this loop ;-)))
the reason that the byte-swap code was taken out of trans_16.c is that it
will never be allowed into the kernel.
And we'll have to remove the current byteswap code in the kernel (there still
is some).
Well, actually, I'd like to lose all the translation stuff (rate conversion,
format conversion etc.). This belongs in User-Land and is preventing me
from implementing mmio (which would be useful for the more serious
applications).
My main problems atm are:
(a) working out what to do about mksound() - this is messy as it is and
needs fixing in order to deal with DACA & Tumbler (it fiddles with the H/W
which makes it chip-specific at present)...
(b) wondering if losing all that stuff is going to be acceptable to the m68k
ports (or whether we will end up having a PPC-specific driver).
(c) not having any time ... (but that's an old problem) ...
ciao,
Iain.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sun, 12 Aug 2001, Iain Sandoe wrote:
On Sat, Aug 11, 2001, Geert Uytterhoeven wrote:
quoted
On Fri, 10 Aug 2001, Iain Sandoe wrote:
quoted
quoted
The attached patch adds code to drivers/sound/dmasound/trans_16.c to
byteswap little-endian audio samples for hardware that needs it (like the
DACA audio chip in the iBook and iBook FireWire), and also marks the DACA
in the iBook FireWire as being unable to handle little-endian audio
samples (in dmasound_awacs.c).
we've been round this loop ;-)))
the reason that the byte-swap code was taken out of trans_16.c is that it
will never be allowed into the kernel.
And we'll have to remove the current byteswap code in the kernel (there still
is some).
Well, actually, I'd like to lose all the translation stuff (rate conversion,
format conversion etc.). This belongs in User-Land and is preventing me
from implementing mmio (which would be useful for the more serious
applications).
Sorry, that's what I meant: all translation code.
My main problems atm are:
(a) working out what to do about mksound() - this is messy as it is and
needs fixing in order to deal with DACA & Tumbler (it fiddles with the H/W
which makes it chip-specific at present)...
Yes, mksound() messes with the sound hardware on most m68k boxes too.
Perhaps we should make it more generic, and move it to dmasound?
The disadvantage is that you can't get system beep anymore without dmasound.
(b) wondering if losing all that stuff is going to be acceptable to the m68k
ports (or whether we will end up having a PPC-specific driver).
If the removal of the translation stuff is imposed from upstream (Linus/Alan),
we must comply. Once user space is fixed, it should work everywhere. So m68k
will benefit from the work done on PPC (once in a time it was vice versa :-)
(c) not having any time ... (but that's an old problem) ...
Idem ditto.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sun, 12 Aug 2001, Iain Sandoe wrote:
Well, actually, I'd like to lose all the translation stuff (rate conversion,
format conversion etc.). This belongs in User-Land and is preventing me
from implementing mmio (which would be useful for the more serious
applications).
Ok, so why not just take it out, and have the driver printk() a message if
userspace tries to force it to accept an audio format it doesn't know,
saying basically, "Please ask the developers of the software to properly
query the OSS device for supported formats"? If that's really the way
you'd prefer it to be, really nothing else is going to make people sit up
and pay attention other than just saying "Ok, this behavior is now broken,
not just deprecated, but BROKEN".
Derrik Pates | Sysadmin, Douglas School | #linuxOS on EFnet
dpates@dsdk12.net | District (dsdk12.net) | #linuxOS on OPN
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, 13 Aug 2001, Derrik Pates wrote:
On Sun, 12 Aug 2001, Iain Sandoe wrote:
quoted
Well, actually, I'd like to lose all the translation stuff (rate conversion,
format conversion etc.). This belongs in User-Land and is preventing me
from implementing mmio (which would be useful for the more serious
applications).
Ok, so why not just take it out, and have the driver printk() a message if
userspace tries to force it to accept an audio format it doesn't know,
saying basically, "Please ask the developers of the software to properly
^^^^^^^^^^^^
You can even printk() the name of the program.
query the OSS device for supported formats"? If that's really the way
you'd prefer it to be, really nothing else is going to make people sit up
and pay attention other than just saying "Ok, this behavior is now broken,
not just deprecated, but BROKEN".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/