9 Oct
2003
9 Oct
'03
10:36 a.m.
-------- directBOX Reply ---------------
From: paul(a)linuxaudiosystems.com
To : linux-audio-dev(a)music.columbia.edu
Date: 09.10.2003 15:59:37
I am interested how 2.6.X Linux kernel will handle OSS.
I mean that alsa is the driver
-layer for these kernels, are OSS-drivers/applications still supported ??
my understanding is that the OSS drivers will continue to exist in the
kernel tree and there will be configure time options to select
them. the default will be to use ALSA. this is up to distributions,
obviously.
ALSA supports all OSS applications, with very few exceptions. things
that don't work need to be reported so that they can be fixed.
--------------------------
Well, will be new drivers available for oss ? And will alsa-drivers be ported ?
__________________________________________________
Verpassen Sie keine eBay-Auktion und bieten Sie bequem
und schnell über das Telefon mit http://www.telefonbieten.de
Ihre eMails auf dem Handy lesen - ohne Zeitverlust - 24h/Tag
eMail, FAX, SMS, VoiceMail mit http://www.directbox.com
9 Oct
9 Oct
10:54 a.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
Well, will be new drivers available for oss ? And will
alsa-drivers be ported ?
i doubt if people will write new OSS drivers, but they may. whether
linus accepts them into the tree is another matter.
as for alsa drivers being ported: that's extremely unlikely, though
again, if someone has some reason to do it, they can.
OSS is dead. You should not be writing apps with OSS. If you want
portability use PortAudio.
--p
1:10 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
Hallo,
Paul Davis hat gesagt: // Paul Davis wrote:
i doubt if people will write new OSS drivers, but they
may. whether
linus accepts them into the tree is another matter.
as for alsa drivers being ported: that's extremely unlikely, though
again, if someone has some reason to do it, they can.
How I understand it - and I could need some clarification from the
real driver pros - one of the goals of ALSA was to modularize driver
architecture and get more tasks away from the kernel to user land or
expressed another way: abstract software design from hardware design.
This in turn should make it easier to write drivers for ALSA or maybe
easier to write drivers that provide more functionality?
Am I describing this somehow correctly?
ciao
--
Frank Barknecht _ ______footils.org__
3:35 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
How I understand it - and I could need some
clarification from the
real driver pros - one of the goals of ALSA was to modularize driver
architecture and get more tasks away from the kernel to user land or
expressed another way: abstract software design from hardware design.
This in turn should make it easier to write drivers for ALSA or maybe
easier to write drivers that provide more functionality?
Am I describing this somehow correctly?
almost. i think it would be more accurate to say "easier to write
drivers for ALSA and easier to provide additional functionality in
userspace via alsa-lib". IMHO the core idea of ALSA is to limit
drivers to simply exporting the capabilities of the hardware up to
user space, and leaving it to alsa-lib to do various things with
that. this is quite different to OSS, in which all the action is in
the kernel. in addition, a lot of code in the kernel is shared between
drivers.
but note: compared to OS X, writing drivers for ALSA is still
disturbingly complex. this is mostly due to OS X's use of C++ within
the kernel, and so there's not much ALSA can do about this.
--p
10 Oct
10 Oct
4:09 a.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
On Thu, 9 Oct 2003, Paul Davis wrote:
Hi,
You say that the alsa kernel drivers export the hardware capabilities to
user level.
Would it be possible to write an API in C++ for ALSA then, basically
not using the alsalib, but the fast hardware abstraction ?
Guenter
How I
understand it - and I could need some clarification from the
real driver pros - one of the goals of ALSA was to modularize driver
architecture and get more tasks away from the kernel to user land or
expressed another way: abstract software design from hardware design.
This in turn should make it easier to write drivers for ALSA or maybe
easier to write drivers that provide more functionality?
Am I describing this somehow correctly?
almost. i think it would be more accurate to say "easier to write
drivers for ALSA and easier to provide additional functionality in
userspace via alsa-lib". IMHO the core idea of ALSA is to limit
drivers to simply exporting the capabilities of the hardware up to
user space, and leaving it to alsa-lib to do various things with
that. this is quite different to OSS, in which all the action is in
the kernel. in addition, a lot of code in the kernel is shared between
drivers.
but note: compared to OS X, writing drivers for ALSA is still
disturbingly complex. this is mostly due to OS X's use of C++ within
the kernel, and so there's not much ALSA can do about this.
11:39 a.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
You say that the alsa kernel drivers export the
hardware capabilities to
user level.
Would it be possible to write an API in C++ for ALSA then, basically
not using the alsalib, but the fast hardware abstraction ?
its certainly possible. whether its worth it is another
question. using alsa-lib on a "hw:N" ALSA device adds very very little
code to the execution path. i take it that you understand that the
"hw:N" devices presented by alsa-lib correspond precisely to the
hardware-limited capabilities offered by the hardware? that is, access
to these devices has to use parameters offered by the hardware, and no
format conversion, channel mapping, rate conversion or anything else
is done by alsa-lib. you basically get to the system calls and then
into the kernel in 1-3 layers of function calls, which is likely as
good as you'd get in another library.
if you want C++, i think you'd be better off wrapping alsa-lib. i can
see no reason to implement another library that has to handle the
kernel API (read, write, ioctl, open, close, etc.).
but yes, its possible.
--p
1:33 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
On Fri, 10 Oct 2003, Paul Davis wrote:
Thanks for the clarifications. Actually I was thinking in terms
of the OSX driver structure you mentioned, but of course, you were
talking about the kernel modules, while I was thinking about the
user level alsalib (which has nothing to do with driver programming
per se).
Anyhow, last but not least, I think the rtaudio should be mentioned
in this context http://www-ccrma.stanford.edu/~gary/rtaudio/,
which to my understanding the C++ wrapper around alsa-lib that you
mention. (and more ..)
Guenter
You say that
the alsa kernel drivers export the hardware capabilities to
user level.
Would it be possible to write an API in C++ for ALSA then, basically
not using the alsalib, but the fast hardware abstraction ?
its certainly possible. whether its worth it is another
question. using alsa-lib on a "hw:N" ALSA device adds very very little
code to the execution path. i take it that you understand that the
"hw:N" devices presented by alsa-lib correspond precisely to the
hardware-limited capabilities offered by the hardware? that is, access
to these devices has to use parameters offered by the hardware, and no
format conversion, channel mapping, rate conversion or anything else
is done by alsa-lib. you basically get to the system calls and then
into the kernel in 1-3 layers of function calls, which is likely as
good as you'd get in another library.
if you want C++, i think you'd be better off wrapping alsa-lib. i can
see no reason to implement another library that has to handle the
kernel API (read, write, ioctl, open, close, etc.).
but yes, its possible. 
4:26 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
On Thu, 2003-10-09 at 17:44, Paul Davis wrote:
OSS is dead. You should not be writing apps with OSS.
If you want
portability use PortAudio.
It's not dead if you are doing audio work on any other IEEE-1003.1 OS
than Linux.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
4:50 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
On Thu, 2003-10-09 at 17:44, Paul Davis wrote:
PortAudio works on most of them, and is much better for many reasons.
OSS is dead. You should not be writing apps with
OSS. If you want
portability use PortAudio.
It's not dead if you are doing audio work on any other IEEE-1003.1 OS
than Linux.
17 Oct
17 Oct
1:37 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
On Fri, 2003-10-10 at 23:40, Paul Davis wrote:
PortAudio works on most of them, and is much better
for many reasons.
PortAudio uses OSS? Or are there many drivers for M-Audio Delta1010 and
the likes?
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
2 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
PortAudio
works on most of them, and is much better for many reasons.
PortAudio uses OSS? Or are there many drivers for M-Audio Delta1010 and
the likes? 
10 Oct
10 Oct
5:35 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
--- Jussi Laako <jussi.laako(a)pp.inet.fi> wrote:
On Thu, 2003-10-09 at 17:44, Paul Davis wrote:
The prob. w/ portaudio is it abstracts to OSS, not
ALSA and I'd rather not take the least-common
denominator road. I'd rather my app take advantage of
all the end user's system has, yet work if the person
doesn't have the latest & greatest. What's wrong w/
writing layers yourself that fit better to your
particular app's needs?
A lot of coders here would rather avoid writing to an
API or platform they don't like than have an app that
is more likely to work on more people's computers,
playing favorites with bleeding edge technologies like
JACK. from a marketing perspective, that's insane. My
app is for $ and I want people to be able to run it
w/o having to check out CVS, yet still have support
for these new things (such as JACK and ALSA) if they
have it. I know it's more work to write your own
abstractions, but it's worth it. abstraction layers
are too cookie-cutter unless you are making something
simple like an mp3 player.
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
OSS is dead. You should not be writing apps with
OSS. If you want
portability use PortAudio.
It's not dead if you are doing audio work on any
other IEEE-1003.1 OS
than Linux.
6:04 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
OSS is dead. You should not be writing apps with
OSS. If you want
portability use PortAudio.
It's not dead if you are doing audio work on any
other IEEE-1003.1 OS
than Linux.
6:54 p.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
The prob. w/
portaudio is it abstracts to OSS, not
ALSA and I'd rather not take the least-common
denominator road.
No. PortAudio abstracts to a callback model. Its
closer to JACK than
either OSS or ALSA. It isn't any closer to ALSA than
it is to OSS.
11 Oct
11 Oct
6:29 a.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
Hallo,
Thomas Webb hat gesagt: // Thomas Webb wrote:
I phrased that poorly. Say someone has ALSA and
doesn't have OSS compatibility. Would an app written
in portaudio work on their sys? If it doesn't, then
that's what I meant by that it doesn't abstract to
ALSA. If it does, then What I said was wrong, my bad.
ALSA, OSS, JACK or CoreAudio are treated as backends in PortAudio. You
can choose which backend to use. I *think* you can even decide at
runtime which PaHostApi to use, but this is unchecked and I'm no
Portaudio expert at all.
ciao
--
Frank Barknecht _ ______footils.org__
9 Oct
9 Oct
11:58 a.m.
New subject: [linux-audio-dev] Linux VERSUS OSS ???
On Thu, 09 Oct 2003 16:18:22 +0200
<hexe_2003(a)directbox.com> wrote:
Well, will be new drivers available for oss ? And will
alsa-drivers be ported ?
The 2.6.0-test5 kernel lists OSS as "(DEPRECATED)", hinting that it probably
won't be around at some time in the future. This would certainly suggest that they
would rather not have people putting more time and effort into it at this point.
|)
|)enji
7501
days inactive
7509
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
7 participants
participants (7)
-
Benjamin Flaming -
Frank Barknecht -
guenter geiger -
hexe_2003＠directbox.com -
Jussi Laako -
Paul Davis -
Thomas Webb